EP3847597A1 - Génération, application et vérification de codes de suivi à l'aide de la technologie des chaînes de blocs - Google Patents

Génération, application et vérification de codes de suivi à l'aide de la technologie des chaînes de blocs

Info

Publication number
EP3847597A1
EP3847597A1 EP18932519.4A EP18932519A EP3847597A1 EP 3847597 A1 EP3847597 A1 EP 3847597A1 EP 18932519 A EP18932519 A EP 18932519A EP 3847597 A1 EP3847597 A1 EP 3847597A1
Authority
EP
European Patent Office
Prior art keywords
tracking
codes
tracking codes
peer
code
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.)
Withdrawn
Application number
EP18932519.4A
Other languages
German (de)
English (en)
Other versions
EP3847597A4 (fr
Inventor
Ian A. Nazzari
Paul Eipper
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.)
Huru Systems Ltd
Original Assignee
Huru Systems 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
Priority claimed from US16/121,526 external-priority patent/US10192198B2/en
Application filed by Huru Systems Ltd filed Critical Huru Systems Ltd
Publication of EP3847597A1 publication Critical patent/EP3847597A1/fr
Publication of EP3847597A4 publication Critical patent/EP3847597A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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
    • G06Q10/083—Shipping
    • G06Q10/0833—Tracking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • tracking codes such as serial numbers
  • security seals for articles to ensure that the articles remain closed, un-tampered with, or otherwise secured.
  • tracking codes and the article on which they are applied are treated separately from each other and differently by each industry, or even by different businesses within the same industry, and are often inefficient and insecure in their use.
  • Embodiments described herein relate to systems for secure tracking code generation, application, and verification, including use of blockchain technology to manage tracking code and physical article lifecycle.
  • some embodiments include a centralized computer- implemented management platform for securely generating tracking codes, and for verifiably imprinting those tracking codes onto physical articles.
  • the computer- implemented management platform be configured for securely generating tracking codes that are formatted to include group tracking codes and unit tracking codes, and for securely imprinting these tracking codes on physical articles in a secure and verified manner.
  • the computer-implemented management platform provides for lifecycle management of tracking codes and assets, such as tracking custody of tracking codes, associating tracking codes with assets, and managing field service orders related to the tracking codes, even as the assets/tracking codes pass between different entities.
  • a computer system generates, at one or more hardware processors, one or more tracking codes.
  • the computer system sends the one or more tracking codes towards an automated computer-controlled production line, along with one or more first messages which cause the production line to physically imprint, by one or more hardware imprinting units, each of the one or more tracking codes onto a corresponding article.
  • the one or more first messages also cause the production line to physically verify, by one or more hardware verification units, the physical imprinting by the one or more hardware imprinting units of each of the one or more tracking codes onto their corresponding article.
  • the verification includes the one or more hardware verification units performing a machine reading of each of the one or more tracking codes, as imprinted on its corresponding article.
  • the computer system receives at least one result of the verification by the one or more hardware verification units of the physical imprinting of each of the one or more tracking codes onto their corresponding article.
  • the computer system For each of the one or more tracking codes, if the at least one result of the verification indicates that the tracking code was correctly imprinted on its corresponding article, the computer system records, in a durable computer-readable hardware storage medium, one or more records that indicate the tracking code as being imprinted on an article and that initiate a custody chain for the tracking code and the article. Alternatively, if the at least one result of the verification indicates that the tracking code was incorrectly imprinted on its corresponding article, the computer system sends one or more second messages towards the automated computer-controlled production line, causing the one or more hardware verification units to physically reject the corresponding article.
  • a blockchain distributed ledger to manage tracking code and physical article lifecycle, using a plurality of peers that each store at least a portion of the blockchain distributed ledger.
  • a first peer computer system generates at least one cryptographic key for each of the plurality of peer computer systems. Each cryptographic key enables its corresponding peer computer system to view blocks on the blockchain distributed ledger and to insert blocks onto the blockchain distributed ledger.
  • the first peer computer system also generates a plurality of tracking codes and inserts one or more first blocks including the plurality of tracking codes onto the blockchain distributed ledger.
  • Inserting the one or more first blocks onto the blockchain distributed ledger (i) initiates a lifecycle for each of the plurality of tracking codes, and (ii) makes each of the plurality of tracking codes visible to the plurality of peer computer systems.
  • a second peer computer system imprints each of the plurality of tracking codes onto a corresponding physical article, inserts one or more second blocks onto the blockchain distributed ledger recording the imprinting of each of the plurality of tracking codes onto its corresponding physical article.
  • the second peer computer system also inserts one or more third blocks onto the blockchain distributed ledger indicating that custody of the plurality of tracking codes and their corresponding physical articles has been transferred to a third peer computer system.
  • a third peer computer system inserts one or more fourth blocks onto the blockchain distributed ledger indicating that receipt of custody of the plurality of tracking codes and their corresponding physical articles from the second peer computer system has been confirmed by the third peer computer system.
  • Yet other embodiments use a blockchain distributed ledger to manage tracking code and physical article lifecycle, including mapping legacy tracking codes to native tracking codes, using a plurality of peers that each store at least a portion of the blockchain distributed ledger.
  • a first peer computer system generates a plurality of native tracking codes and inserts one or more first blocks including the plurality of native tracking codes onto the blockchain distributed ledger, inserting the one or more first blocks onto the blockchain distributed ledger (i) initiating a lifecycle for each of the plurality of native tracking codes, and (ii) making each of the plurality of native tracking codes visible to the plurality of peer computer systems.
  • a second peer computer system communicates the plurality of native tracking codes to an internal mobile device associated with the peer, receives from the internal mobile device an association of at least one of the plurality of native tracking codes with at least one legacy tracking code associated with a physical article, and inserts one or more second blocks onto the blockchain distributed ledger indicating that the at least one of the plurality of native tracking codes is associated with the at least one legacy tracking code associated with a physical article.
  • a first peer computer system uses a blockchain distributed ledger to manage tracking code and physical article lifecycle, including managing a verified packaging, using a plurality of peers that each store at least a portion of the blockchain distributed ledger.
  • a first peer computer system generates a plurality of tracking codes including a group tracking code and a plurality of unit tracking codes that are associated with the group tracking code, and inserts one or more first blocks including the plurality of tracking codes onto the blockchain distributed ledger, inserting the one or more first blocks onto the blockchain distributed ledger (i) initiating a lifecycle for each of the plurality of tracking codes, and (ii) making each of the plurality of tracking codes visible to the plurality of peer computer systems.
  • a second peer computer system communicates the plurality of tracking codes to an internal mobile device associated with the peer.
  • the second peer then receives from the internal mobile device (i) an first indication that the group tracking code has been scanned by the internal mobile device to open the group tracking code, (ii) one or more second indications that each of the plurality of unit tracking codes have been scanned by the internal mobile device as part of packaging articles associated with the plurality of unit tracking codes into a container associated with the group tracking code, and (iii) an third indication that the group tracking code has been scanned by the internal mobile device to close the group tracking code after each of the plurality of unit tracking codes have been scanned.
  • the second peer inserts one or more second blocks onto the blockchain distributed ledger indicating that the plurality of unit tracking codes have been packaged within the group tracking code.
  • Figure 1 illustrates an example computing environment for tracking code generation and management
  • Figure 2 illustrates an embodiment of unit tracking codes and group tracking codes
  • Figure 3 A illustrates a first example computing environment for imprinting tracking codes onto articles
  • Figure 3B illustrates a second example computing environment for imprinting tracking codes onto articles
  • Figure 4 illustrates an example article that has been imprinted with a both a first imprinting process and a second imprinting process
  • Figure 5 illustrates an example tray of articles that has been imprinted with both unit tracking codes and a group tracking code
  • Figure 6 illustrates a flowchart of an example method for verifiably imprinting tracking codes onto physical articles
  • Figure 7 illustrates a flowchart of an example method for facilitating assigning tracking units to a user and/or transferring tracking units between users
  • Figure 8 illustrates a flowchart of an example method for assigning tracking units to other assets
  • Figure 9 illustrates an environment in which a plurality of peers communicate over a network to maintain a distributed ledger, and to use the distributed ledger to manage the lifecycle of tracking codes;
  • Figure 10 illustrates a flowchart of an example method for using a distributed ledger to manage tracking code and physical article lifecycle;
  • Figure 11 illustrates a flowchart of an example method for using a blockchain distributed ledger to manage tracking code and physical article lifecycle, including mapping legacy tracking codes to native tracking codes;
  • Figure 12 illustrates a flowchart of an example method for using a blockchain distributed ledger to manage tracking code and physical article lifecycle, including managing a verified packaging.
  • Embodiments described herein relate to systems for secure tracking code generation, application, and verification, including use of blockchain technology to manage tracking code and physical article lifecycle.
  • some embodiments include a centralized computer- implemented management platform for securely generating tracking codes, and for verifiably imprinting those tracking codes onto physical articles.
  • the computer- implemented management platform be configured for securely generating tracking codes that are formatted to include group tracking codes and unit tracking codes, and for securely imprinting these tracking codes on physical articles in a secure and verified manner.
  • the computer-implemented management platform provides for lifecycle management of tracking codes and assets, such as tracking custody of tracking codes, associating tracking codes with assets, and managing field service orders related to the tracking codes, even as the assets/tracking codes pass between different entities.
  • Figure 1 illustrates an example computing environment 100 for tracking code generation and management, and in which embodiments described herein may operate.
  • the example computing environment 100 may provide a management platform for securely generating tracking codes, for verifiably imprinting those tracking codes onto physical articles, and for securely managing those physical articles throughout their lifecycle, based on the securely-generated and verifiably-imprinted tracking codes.
  • the computing environment 100 includes a management system 101, which is connected via a network 102 (e.g., a LAN, WAN, and/or the Internet) to a plurality of other computing systems, such as computer system(s) at the production facilit(ies) 103, and such as the depicted management device(s) 104.
  • the ellipses l03a indicate that the management system 101 may communicate with more than one production facility, and the ellipses l04a indicate that the management system 101 may communicate with a variety of management devices (both in number and in type, such as the depicted smartphone, tablet, and laptop computer).
  • the management system 101 is configured to generate tracking codes configured for tracking individual articles and/or groups of articles, and to manage a lifecycle of those tracking codes (and, by extension, a lifecycle of any articles/groupings associated with those tracking codes).
  • an article can comprise virtually any physical item (or groups of items).
  • An article may be an asset (or group of assets), or a tracking unit (or groupings of tracking units) that is (or can be) applied to an asset.
  • the tracking codes described herein when managed by the management system 101, function as“harmonizing codes” that stay with articles throughout their lifecycles, and that are used to track any desired events associated with those articles (e.g., being passed between individuals; changing geographical location; being applied to and associated with an asset; undergoing maintenance or upgrades; being sold; being stolen, destroyed, lost; etc.).
  • the management system 101 generates tracking codes, and communicates (e.g., over the network 102) with one or more computer systems at production facilit(ies) 103 or at least one production facility 103, to cause hardware units of one or more production lines at a production facility 103 to physically imprint those tracking codes onto physical articles, and to verify that the imprinting was performed correctly and legibly. Additionally, the management system 101 communicates (e.g., over the network 102) with a variety of management devices 104 (e.g., associated with production facilities, warehouses, companies, individual end-users, etc.), as part of managing the lifecycle of tracking codes and any associated articles.
  • management devices 104 e.g., associated with production facilities, warehouses, companies, individual end-users, etc.
  • one or more management devices 104 may operate with the management system 101 to assign custody of tracking codes (and associated articles) to individuals or to transfer custody between individuals, to check status of a tracking code/article, to change status of a tracking code/article, to apply a tracking code (e.g., tracking unit) to an asset, etc.
  • a tracking code e.g., tracking unit
  • Figure 1 depicts that the management system 101 can include a code generator module 105, a code applicator module 106, a lifecycle manager module 107, and an interface module 108.
  • Figure 1 also illustrates that the management system 101 can include one or more communications interface(s) 112 (e.g., for communicating over the network 102), and includes (or is connected to) one or more storage device(s) 109.
  • the storage device(s) 109 can comprise any durable computer-readable hardware storage medium (e.g., magnetic storage, flash storage, optical storage), including arrays of storage media, that be used to store any data generated by, received by (e.g., by the communications interface(s) 112), or otherwise used by any modules/components of the management system 101. Data may be stored in any appropriate form, such as in one or more database tables, one or more flat files, etc.
  • durable computer-readable hardware storage medium e.g., magnetic storage, flash storage, optical storage
  • arrays of storage media that be used to store any data generated by, received by (e.g., by the communications interface(s) 112), or otherwise used by any modules/components of the management system 101.
  • Data may be stored in any appropriate form, such as in one or more database tables, one or more flat files, etc.
  • each of the modules/components depicted as part of the management system 101 may be configured to communicate with each other, and that the management system 101 may combine functionality of some modules into single modules, break functionality of individual modules into a plurality of modules, etc.
  • the particular number, naming, and arrangement of the model s/components of the management system 101 are for illustrative purposes only, as an aid to describing the embodiments herein, and are non-limiting.
  • the code generator module 105 can include a variety sub-components for accomplishing any the code generation embodiments described herein.
  • Figure 1 illustrates that the code generator module 105 may include one or more of a generation component l05a, an encryption component l05b, and an encoding component l05c.
  • the generation component l05a is configured to generate unique tracking codes, preferably based on a random number generator (whether that random number generator be implemented as dedicated hardware, or as a software algorithm).
  • the encryption component l05b is configured to implement one or more cryptographic encryption algorithms (e.g., public key, symmetric, asymmetric, etc.), in cooperation with the generation component l05a, to encrypt the tracking codes that are generated by the code generator module 105.
  • the code generator module 105 can generate cryptographically-obfuscated tracking codes that protect the identity the tracking code that was actually generated by the generation component l05a.
  • the encryption component l05b can make it prohibitively difficult (i.e., practically impossible) for a third party to decipher the tracking codes generated by the generation component l05a, and the algorithms used by the generation component l05a to produce the tracking codes, without having access to a cryptographic key used to encrypt the tracking codes.
  • the encryption component l05b can beneficially help prevent unauthorized third parties from producing counterfeit tracking codes, or anticipating tracking codes that may be used next, or the like.
  • the encryption component l05b not only obfuscates tracking codes, but also normalizes their length (e.g., number of bytes), and/or represents the codes with a particular character encoding (e.g., ASCII, hexadecimal, etc.) that is useful for a specific purpose.
  • the encryption component l05b may apply a first cryptographic algorithm (e.g., Advanced Encryption Standard (AES)) to the tracking code, to obfuscate the tracking code, and to also produce a representation that is a predefined number of bytes (e.g., 16, 24, or 32) that is useful for encoding/imprinting in a machine-readable form.
  • AES Advanced Encryption Standard
  • the encryption component l05b may also apply a second cryptographic algorithm (e.g., Triple Data Encryption Algorithm (DES3)) to the tracking code, to obfuscate the tracking code, and to also produce a representation that is a predefined number of bytes (e.g., 13) and that uses an encoding (e.g. ASCII, hexadecimal, etc.) that is useful for encoding/imprinting in a human-readable form.
  • DES3 Triple Data Encryption Algorithm
  • the encoding component l05c is configured to encode tracking codes (whether encrypted or unencrypted) into appropriate forms for physical imprinting/application to articles.
  • the encoding component l05c may convert tracking codes to machine- readable representations (e.g., QR Codes, Matrix Codes, etc.) and/or to human-readable forms (e.g., ASCII representations, ETnicode representations, pictorial representations, etc.).
  • the code applicator module 106 is configured to orchestrate application of tracking codes to articles.
  • the code applicator module 106 communicates with computer system(s) 110 at the production facilit(ies) 103, in order to cause hardware units (e.g., imprinting unit 11 la and verification unit 11 lb) at production line(s) 111 of the production facilit(ies) 103 to imprint tracking codes generated by the code generator module 105 onto articles.
  • hardware units e.g., imprinting unit 11 la and verification unit 11 lb
  • the ellipses 1 lOc and 11 ld indicate that each production facility 103 can include more than one computer system 110 and/or one or more corresponding production lines 111.
  • the ellipses 11 lc indicate that each production line 111 can include a variety of hardware units (both in number and in type).
  • the code applicator module 106 can include a variety sub-components for accomplishing the application embodiments described herein.
  • Figure 1 illustrates that the code applicator module 106 may include one or more of an imprinting component l06a, a verification component l06b, and a queue l06c.
  • the queue l06c is configured to receive and store one or more tracking codes received from the code generator module 105.
  • the imprinting component l06a is configured to cause the production line to imprint these tracking codes to articles.
  • the imprinting component l06a may send one or more messages through the network 102 to the computer system 110 of a particular production facility 103.
  • These messages can be configured to cause a production line 111 at the production facility 103 to imprint one or more of the tracking codes obtained from the queue l06c to corresponding articles.
  • the messages may trigger a control component l lOb of the computer system 110 to cause a hardware imprinting unit 111 a to imprint the tracking codes to corresponding articles.
  • Hardware imprinting units can imprint tracking codes onto articles using a vast array of imprinting processes and encoding formats.
  • imprinting processes may include an application of ink or other materials (e.g., using thermal transfer, propulsion, electrostatic processes, adhesives, etc.), etching (e.g., using heat, light, or mechanical components), application or programming of a digital chip (e.g., radio-frequency identification (RFID)), writing a magnetic or optical medium, or any other available application techniques.
  • RFID radio-frequency identification
  • examples of encoding formats may include machine-readable forms (e.g., QR Code, bar code, Matrix Code, etc.) and/or to human-readable forms (e.g., ASCII, Unicode, or other textual representations; pictorial representations; etc.).
  • machine-readable forms e.g., QR Code, bar code, Matrix Code, etc.
  • human-readable forms e.g., ASCII, Unicode, or other textual representations; pictorial representations; etc.
  • the verification component l06b is configured to verify that tracking codes have been imprinted onto articles correctly and legibly.
  • the verification component l06b may send one or more messages through the network 102 to the computer system 110 of the particular production facility 103. These messages can be configured to cause the production line 111 at the production facility 103 verify that the tracking codes were imprinted on the articles correctly and legibly.
  • the messages may trigger the control component 110b of the computer system 110 to cause a hardware verification unit 11 lb to verify that the correct tracking codes were imprinted on the articles, and that these tracking codes are legible.
  • the hardware verification unit 11 lb may read a machine-readable code representation of the tracking code, may perform an optical character recognition (OCR) of a human-readable representation of the tracking code, etc.
  • OCR optical character recognition
  • the messages sent by the imprinting component l06a and the messages sent by the verification component l06b may be the same messages.
  • the hardware verification unit 11 lb may physically reject the articles, such as by routing them to a different location than articles that were properly imprinted, discarding the articles, or even destroying the articles.
  • the verification component l06b can either discard the corresponding tracking code(s) codes (e.g., delete them, mark them as invalid in one or more records stored in the storage device(s) 109, etc.) or recycle them by placing them back on the queue l06c.
  • the code applicator module 106 can pass the codes to the lifecycle manager module 107 to begin a lifecycle and custody chain for the codes/articles, as discussed below in connection with the lifecycle manager module 107.
  • the code generator module 105 and/or the code applicator module 106 may be located, at least in part, at the computer systems(s) 110 of one or more of the production facilit(ies) 103 (or even fully duplicated at both systems).
  • the computer system(s) 110 may be viewed as being distributed extensions of the management system 101. Locating all or portions of the code generator module 105 and/or the code applicator module 106 can reduce the amount of network communications necessary to carry out code application.
  • the lifecycle manager module 107 is configured to maintain one or more records in the storage device(s) 109 as part of tracking and managing a lifecycle of tracking codes. These records can be used to track, for example, tracking codes that are active, a chain of custody associated with the tracking codes, and any information associated with a lifecycle of an article associated with the tracking code (e.g., geographical locations, images, work orders, associated assets, users who have interacted with the article, etc.), associations between different tracking codes, physical attributes of articles associated with tracking codes, etc.
  • the lifecycle manager module 107 can manage lifecycle even as tracking codes/assets pass between different companies or levels of a supply chain.
  • the lifecycle manager module 107 may begin tracking lifecycle of a tracking code when it is created and applied to an asset at a production facility.
  • the lifecycle manager module 107 may continue to track and manage the lifecycle of the tracking code as the asset to which it is applied is distributed to a warehouse, sold or supplied to a company, used by the company, etc.
  • Figure 1 depicts that the lifecycle manager module 107 may include a variety of components, such as the depicted registration component l07a (e.g., for initiating records for new tracking codes), custody component l07b (e.g., for tracking custody, ownership, possession, etc.), and asset pairing component l07c (e.g., for associating a tracking code with a particular asset, such as would be the case if the article to which the tracking code is imprinted is a security seal or other tracking unit).
  • the depicted registration component l07a e.g., for initiating records for new tracking codes
  • custody component l07b e.g., for tracking custody, ownership, possession, etc.
  • asset pairing component l07c e.g., for associating a tracking code with a particular asset, such as would be the case if the article to which the tracking code is imprinted is a security seal or other tracking unit.
  • the interface module 108 is configured to provide one or more interfaces for interacting with the management device(s) 104 and/or the computer system(s) 110 at the production facility(ies) 103.
  • the interface module 108 may provide web interfaces for presentation within web browser applications at the management device(s) 104 and/or the computer system(s) 110, application programming interfaces (APIs) for interacting with specialized applications at the management device(s) 104 and/or the computer system(s) 110, etc.
  • APIs application programming interfaces
  • Figure 1 depicts that the interface module 108 can include a variety of components for providing these interfaces, such as the depicted APIs component l08a and the depicted web interface component l08b.
  • the interfaces provided by the interface module 108 can enable end-users to interact with tracking codes and their associated records, such as to record lifecycle events, to complete work orders, to transfer ownership/custody, etc.
  • this disclosure references communications between the management system 101 and the computer system(s) 110 and/or the management device(s) 104, it will be appreciated that the communications may be facilitated by interfaces provided by the interface module 108
  • the generation component l05a is configured to generate unique group tracking codes, as well as a plurality of unique unit tracking codes that correspond to each group tracking code. In some embodiments, the generation component l05a is also configured to generate group tracking codes corresponding to sub-groupings. These group tracking codes may be formatted such that— based only on a group code— the identity of each unit tracking code that is part of the grouping can be determined, as well as the identity of each group tracking code of each sub-grouping (if any). As such, embodiments enable tracking groupings of articles, and subgroupings of articles, while freeing management devices 104 that interact with grouped articles from the requirement of accessing data stored at the management system 101 to identify which tracking codes correspond to which group/sub -group.
  • embodiments contemplate production lines 111 that operate to apply tracking codes to groupings of articles in a secure and verified manner.
  • Grouping articles may be useful in a great variety of contexts in which articles are distributed or used in groups, and in which custody of the articles, including their groups is helpful (e.g., pharmaceuticals).
  • One particular example context is the grouping of security seals (that can be securely applied to assets to be tracked) into groupings such as trays, bags, boxes, pallets, etc. that can be distributed various parties. For instance, a warehouse manager may take custody of a pallet of seals from a factory, and then assign each box to individual field managers. The field managers may then assign custody of bags of seals to individual workers. The individual workers may transfer custody of bags and/trays of seals among each other, apply seals to assets that are to be tracked (e.g., as part of fulfilling work orders), marks seals as being lost or damaged, etc.
  • Figure 2 illustrates an example of unit tracking codes and group tracking codes, according to one embodiment.
  • the generation component l05a generates unit tracking codes for individual units, and also generates group tracking codes for trays of units (ten units per tray), bags of trays (ten trays per bag), boxes of bags (fifty bags per box), and pallets of boxes (twenty boxes per pallet). While the units of trays, bag, boxes, and pallets are given in this example, it will be appreciated that any groupings are possible.
  • the generation component l05a can generate 100,000 unit tracking codes, beginning with unit code A000000 and ending with unit code A099999. For trays, the generation component l05a generates a group tracking code comprising the unit tracking identifier of the first unit in the tray, and a multiplier indicating how many units are in each tray.
  • the group tracking identifier 20la i.e., A000000.10 identifies that unit A000000 is the first unit in the grouping, and that there are ten units in the grouping (i.e., units A000000
  • the group tracking identifier 20lb (A000010.10) identifies that unit A000010 is the first unit in the grouping, and that there are ten units in the grouping (i.e., units A000010 - A000019, as depicted).
  • the generation component l05a generates a group tracking code comprising the unit tracking identifier of the first unit in each bag, and a multiplier indicating how many units are in the bag.
  • the group tracking identifier 202a i.e., A000000.10.10 identifies that unit A000000 is the first unit in the grouping, and that there are 100 units (i.e., 10 x 10) in the grouping (i.e., units A000000 - A000099, as depicted).
  • the group tracking identifier 202b (A000100.10.10) identifies that unit A000100 is the first unit in the grouping, and that there are 100 units (i.e., 10 x 10) in the grouping (i.e., units A000100
  • the generation component l05a generates a group tracking code comprising the unit tracking identifier of the first unit in each box, and a multiplier indicating how many units are in the box.
  • the group tracking identifier 203 i.e., A000000.50.10.10 identifies that unit A000000 is the first unit in the grouping, and that there are 5000 units (i.e., 50 x 10 x 10) in the grouping (i.e., units A000000 - A004999, as depicted).
  • the generation component 105a generates a group tracking code comprising the unit tracking identifier of the first unit in the pallet, and a multiplier indicating how many units are in the pallet.
  • the group tracking identifier 204 i.e., A000000.20.50.10.10 identifies that unit A000000 is the first unit in the grouping, and that there are 100,000 units (i.e., 20 x 50 x 10 x 10) in the grouping (i.e., units A000000 - A099999, as depicted).
  • each subgrouping including the units in each subgrouping, are identifiable from each group tracking code.
  • group tracking identifier 204 identifies that the unit tracking code is A000000, with the multiplier of 20.50.10.10. From the multiplier, each sub-grouping that sub-grouping’s units, can be calculated.
  • FIG. 3A illustrates an example computing environment 300a for imprinting tracking codes onto articles.
  • the computing environment 300a performs one or more unique computer-controlled multi-step processes that verifiably apply tracking codes to articles, thereby physically transforming ordinary articles (e.g., individual assets, security seals, etc.) into uniquely-trackable articles.
  • the environment 300a may correspond, at least in part, to computer systems and other hardware devices of one of the production facilit(ies) 103 of Figure 1.
  • the computing environment 300a includes a control system 30la that is communicatively coupled to components of a factory line 302a.
  • control system 30la could correspond to the control component 1 lOb and/or the computer system 110, or even all or part of the management system 101.
  • the factory line 302a includes a plurality of hardware units, such as the depicted imprinting unit 303a (e.g., corresponding to hardware imprinting unit 11 la) and the depicted verification unit 304a (e.g., corresponding to hardware verification unit 11 lb).
  • the factory line can include additional hardware units (e.g., to perform additional code imprinting/verifications, or to otherwise transform an article), and each hardware unit may comprise multiple hardware units (e.g., the verification unit 304a could comprise one or more tracking code reading devices and one or more actuators for use in rejecting articles to which tracking codes were incorrectly applied).
  • Each hardware unit (303a, 304a, etc.) is controlled by the control system 30la, and may provide feedback to the control system 30la, as indicated by the double-sided arrows.
  • the factory line 302a comprises one or more conveyer belts (e.g., represented by the horizontal arrow) or other devices that carry one or more articles through the hardware units (303a, 304a, etc.).
  • FIG. 3B illustrates a similar computing environment 300b for imprinting tracking codes onto articles.
  • the computing environment 300b depicts that there may be multiple control systems and multiple factory lines.
  • a control system 30lb communicates with two different control systems (30lc and 30ld) corresponding to two different factory lines (302b and 302c) that each include their own hardware units (e.g., hardware imprinting units 303b and 303c, and hardware verification units 304b and 304c).
  • hardware units e.g., hardware imprinting units 303b and 303c, and hardware verification units 304b and 304c.
  • control system 30lb may correspond to the management system 101 of Figure 1, and each of control system 30 lc and 30 ld correspond to different computer system 110 of the same production facility 103 or different production facilities.
  • control system 30lb may correspond to the computer system 110 of a production facility 103, and each of control system 30lc and 30ld correspond to different control components 110b of the computer system 110, or correspond to different computer systems 110 of the production facility 103.
  • many other combinations are possible.
  • the hardware imprinting unit(s) 303a physically imprint tracking codes onto corresponding articles. As discussed previously, this may comprise application of ink or other materials, etching, application or programming of a digital chip, writing a magnetic or optical medium, etc. Then, the hardware verification unit(s) 304a verify that the imprinting was performed correctly (e.g., that the correct tracking code was imprinted on the article, and that the tracking code is readable/legible).
  • the hardware verification unit(s) 304a can comprise any appropriate hardware for reading tracking codes, such as camera(s), bar code reader(s), RFID reader(s), etc.
  • one or more of the control system 30 la or the hardware verification unit(s) 304a can perform image processing such as, for example, to perform an OCR of text, to recognize a barcode or QR code, etc.
  • the hardware verification unit(s) 304a can determine whether each tracking code was imprinted legibly, or can send data (e.g., imagery data) to the control system 30la that is usable by the control system 30 la to determine whether each tracking code was imprinted legibly.
  • the article to which the code was imprinted can be rejected by one or more hardware elements of the hardware verification unit(s) 304a if the code was not imprinted correctly, or the tracking code can be recorded as active in the storage device(s) 109 if it was imprinted correctly.
  • the embodiments herein provide a verified process that ensures that tracking codes are only made active in storage device(s) if they have been properly applied to an article.
  • the computing environment 300a imprints articles using multiple imprinting processes.
  • the hardware imprinting unit(s) 303a and the hardware verification unit(s) 304a could imprint/verify using different processes, or there could be additional hardware imprinting unit(s) / hardware verification unit(s) that imprint/verify using different processes than the hardware imprinting unit(s) 303a and the hardware verification unit(s) 304a.
  • the hardware imprinting unit(s) 303a and the hardware verification unit(s) 304a may operate using a first process (e.g., a transfer of ink), while additional hardware imprinting unit(s) / hardware verification unit(s) operate using a second process (e.g., etching). Any combination of imprinting processes can be used.
  • a first process e.g., a transfer of ink
  • additional hardware imprinting unit(s) / hardware verification unit(s) operate using a second process (e.g., etching).
  • a second process e.g., etching
  • Figure 4 illustrates an article 400 (e.g., a security seal) that has been imprinted with both a first imprinting process and a second imprinting process.
  • the first portion of the seal has been imprinted with using a first process (e.g., a thermal transfer of ink) with a tracking code in both a human-readable form 402 (i.e., the ASCII ‘X13V002010’) and a machine-readable form 401 (i.e., the bar code).
  • a first process e.g., a thermal transfer of ink
  • a tracking code in both a human-readable form 402 (i.e., the ASCII ‘X13V002010’) and a machine-readable form 401 (i.e., the bar code).
  • a second potion of the seal has also been imprinted using a second process (e.g., a laser etching) with the tracking code in a human-readable form 403 (i.e., the ASCII‘X13V002010’).
  • the factory line 302a can verify each of these imprintings, all at once or progressively, to ensure that the proper code was imprinted, and that it is legible.
  • embodiments include generating tracking codes that are parts of groupings.
  • the factory line 302a imprints and verifies a group tracking code and its unit tracking codes together.
  • Figure 5 illustrates an example tray of articles (i.e., a tray of the seals 400 of Figure 4) that has been imprinted with both unit tracking codes and a group tracking code.
  • the factory line 302a has printed a QR code onto each seal, with each QR code encoding the unit tracking code that corresponds to that seal.
  • the factory line 302a has imprinted a QR code 502 onto a tab 501 that is associated with the tray of seal. This QR code encodes the group tracking code for the tray.
  • the whole group can be accepted or rejected. For example, if, during the verification, single QR code (whether on a seal or on the tab 501) is incorrect or unreadable, the entire tray can be rejected.
  • Embodiments can include verification of packaging of articles into larger units. For example, using the above example of packaging articles into trays, bags, boxes, pallets, etc., a verification can be performed during each packaging operation. As discussed above in connection with Figure 5, a verified association of each individual article (e.g., seal) with a group code for a tray may have occurred when imprinting those each articles (i.e., each seal and the tray tab) with tracking codes.
  • each individual article e.g., seal
  • group code for a tray may have occurred when imprinting those each articles (i.e., each seal and the tray tab) with tracking codes.
  • a verified process may then be used when packing those trays into bags. For example, a group code may be“opened” when it is printed on a bag label, or when it is scanned. Then, the group code for each tray may be scanned as they are inserted into the bag. The bag may then be“closed” by re-scanning its group code, after all the required trays have been scanned. A record of each of these events may be recorded in the storage devices(s) 109, thus ensuring a verified packaging. If there was any error during the process (e.g., a tray was omitted, the wrong tray was scanned, etc.), the management system 101 may prevent the bag from being closed, may produce errors or exceptions, may discard or deactivate all tracking codes involved, etc. A similar process may be followed when packaging bags into boxes, and when packaging boxes onto pallets.
  • Figure 6 illustrates a flowchart of an example method 600 for verifiably imprinting tracking codes onto physical articles.
  • the method 600 will be described in connection with the computing environments of Figures 1 and 3 A.
  • method 600 includes an act 601 of generating tracking code(s).
  • Act 601 may comprise generating, at one or more hardware processors, one or more tracking codes.
  • the code generator module 105 may generate one or more tracking codes using the generation component l05a. These tracking codes may be cryptographically protected by the encryption component l05b.
  • the code generator module 105 may produce different encodings (e.g., QR code, ASCII, etc.) of each tracking code using the encoding component l05c.
  • the code generator module 105 may generate a group tracking code, as well as a plurality of unique unit tracking codes that correspond to the group tracking code.
  • Method 600 also includes an act 602 of sending the code(s) to a production line.
  • Act 602 may comprise sending the one or more tracking codes towards an automated computer- controlled production line, along with one or more first messages.
  • the code applicator module 106 may send one or more of the tracking codes towards a control component 110b of a production facility 103 that includes a production line 111.
  • act 602 includes sending tracking codes using multiple encoding techniques (e.g., QR code and ASCII). Sending the code(s) can include sending additional instructions, such as which imprinting process(es) should be used.
  • Method 600 also includes an act 603 of physically imprinting the code(s) to articles.
  • Act 603 may comprise the production line being caused by the one or more first messages to physically imprint, by one or more hardware imprinting units of the production line, each of the one or more tracking codes onto a corresponding article.
  • the control component 110b can cause the hardware imprinting unit 111 a to physically imprint the tracking code(s) to a corresponding article using one or more imprinting processes and one or more encoding techniques.
  • hardware imprinting unit 11 la to imprints corresponding unit tracking codes to each of a plurality of associated articles, as well as a group tracking code to a group identification article (e.g., the tab 501).
  • Method 600 also includes an act 604 of verifying the imprinting.
  • Act 604 may comprise the production line being caused by the one or more first messages to physically verify, by one or more hardware verification units of the production line, the physical imprinting by the one or more hardware imprinting units of each of the one or more tracking codes onto their corresponding article, including the one or more hardware verification units performing a machine reading of each of the one or more tracking codes as imprinted on its corresponding article.
  • the control component 1 lOb can cause the hardware verification unit 11 lb to verify each imprinting performed in act 603. This can include imaging machine-readable codes and/or human-readable codes, performing an electromagnetic reading, etc.
  • Act 604 may also comprise at least one result of the verification by the one or more hardware verification units of the physical imprinting of each of the one or more tracking codes onto their corresponding article.
  • the verification component l06b can receive any applicable data generated by the hardware verification unit 11 lb.
  • Act 604 may include an act 605 of updating a database.
  • Act 605 may comprise, for each of the one or more tracking codes, if the at least one result of the verification indicates that the tracking code was correctly imprinted on its corresponding article, recording, in a durable computer-readable hardware storage medium, one or more records that indicate the tracking code as being imprinted on an article and that initiate a custody chain for the tracking code and the article.
  • the verification component l06b may cause the registration component l07a and/or the custody component l07b of the lifecycle manager module 107 can create or modify one or more records in the storage device(s) 109, indicating that the code(s) are imprinted and initiating a custody chain for the code(s).
  • act 604 may include an act 606 of physically rejecting the article.
  • Act 606 may comprise, for each of the one or more tracking codes, if the at least one result of the verification indicates that the tracking code was incorrectly imprinted on its corresponding article, sending one or more second messages towards the automated computer-controlled production line, which cause the one or more hardware verification units to physically reject the corresponding article.
  • the verification component l06b may cause the control component 110b to instruct the hardware verification unit 11 lb to physically reject the article(s) associated with the tracking code(s).
  • the hardware verification unit 11 lb may discard, destroy, or re-route the article(s).
  • the tracking code(s) comprise group and unit tracking codes, the articles may be rejected if any of the codes are improperly applied or illegible.
  • the verification component l06b discards the tracking code(s), queue the tracking code(s) for re-imprinting (e.g., in the queue l06c), and/or cause one or more records to be recorded in the storage device(s), which indicate the tracking code(s) as being invalid or inactive.
  • the lifecycle manager module 107 is configured to maintain one or more records in the storage device(s) 109 as part of tracking and managing a lifecycle of tracking codes.
  • the management system 101 serves as a centralized platform for tracking and managing the lifecycle of individual articles (and groups of articles) as they pass from location-to-location and from user-to-user.
  • the records stored in the storage device(s) 109 can store a great variety of information, relative to an article that has been imprinted with a tracking code. As indicated previously, the one or more records can indicate that the tracking code was correctly imprinted on the article, and can store a custody chain for the article (e.g., one or more user identifiers of users who have possessed, interacted with, have been otherwise responsible for the article).
  • the one or more records may store, for example, one or more photos of the article; one or more current or past geo-locations of the article (e.g., GPS coordinates); one or more date/time- stamps of any event associated with the article; one or more indications of article state, such as lost, stolen, damaged, defective, etc.; one or more user-entered comments/observations about the article; one or more indications of work or maintenance that has been performed on the article; one or more indications of contents of an article (e.g., if the article is a container); etc.
  • articles may comprise seals that can be applied to assets that are to be tracked.
  • the one or more records may identify an asset identifier for the asset to which the seal has been applied. This may be a serial number, another tracking code (e.g., as generated by the management system 101), or any other appropriate identifier.
  • any of the foregoing data fields can also apply to the asset to which the seal has been applied.
  • the asset identifier for the asset to which a seal has been applied may comprise another tracking code as generated by the management system 101.
  • the one or more records may associate articles that were each imprinted with tracking codes using the embodiments described herein, and that are each managed by the management system 101.
  • tracking codes may be applied to articles comprising security seals, and to articles comprising utility meters. Then, the management system 101 can be used to track/manage the utility meters throughout their lifecycle (e.g., deployment in the field, maintenance, etc.), including their being sealed by the seals when work is performed. Thus, the management system 101 may store associations between the tracking codes of the seals, and the tracking codes of the utility meters.
  • the one or more records can store separate data specific to the asset (e.g., photos of the asset, comments/observations relative to the asset, etc.).
  • the one or more records may store a user identifier of the user who applied the seal to the asset; whether the seal has been sealed/applied, tampered with, damaged, etc.; a visual confirmation seal was applied to the asset (e.g., a photograph of the seal on the asset); the identity of one or more field service orders (work orders) associated with the seal/asset (e.g., a fields service order that instructed a worker to apply the seal to the asset); etc.
  • the lifecycle manager module 107 can enable a great variety of management actions relative to tracking codes. For example, the lifecycle manager module 107 can facilitate assigning tracking unit(s) to a user and/or transferring tracking unit(s) between users; assigning tracking units (e.g., seals) to other assets, modifying and/or providing status of tracking codes, etc.
  • tracking units e.g., seals
  • Figure 7 illustrates a flowchart of an example method 700 for facilitating assigning tracking unit(s) to a user and/or transferring tracking unit(s) between users.
  • the method 700 includes an act 701 of receiving a user identifier and a tracking code.
  • the lifecycle manager module 107 may receive a user identifier from a management device 104, such as in response to the management device 104 having scanned a machine-readable encoding of the tracking code, or having received user input providing the tracking code.
  • the method 700 also includes an act 702 of verifying whether the user is permitted to take custody of the tracking code.
  • the custody component l07b may query the storage device(s) 109 to identify custody records for the tracking unit.
  • the custody component l07b may also identify one or more rules for determining whether custody can be granted to the received user identifier.
  • rules may include rules that identify tracking codes of which the user identifier is permitted to take custody, that identify users the user identifier is permitted to take custody from, that identify how to permit re-assignment of tracking codes that are part of groupings, that identify how to permit assignment of tracking codes that are associated with other assets, that identify if reassignments must be authorized by the prior user, etc.
  • the method 700 also includes either (re)assigning custody of the tracking code to the user identifier (act 703), or denying custody (act 704).
  • the custody component l07b may update one or more records in the storage device(s) 109 to assign custody of the tracking code to the user, or to re-assign the tracking code from the prior user.
  • the method 700 may include and act 705 of sending a notice to the prior user, such by way of a message from the management system 101 to a management device 104 of the prior user.
  • a management device 104 corresponding to the prior user may update a user interface to reflect the reassignment, may receive a push notification and display a notice of the reassignment, etc.
  • the method 700 can include a variety of additional functions as part of assigning or re- reassigning custody of a tracking code.
  • the lifecycle manager module 107 may record in the storage device(s) 109 one or more of a photo of the article associated with the tracking code, a date/time-stamp of when the (re)assignment occurred, a geo-location of the article at the time of the (re)assignment, any user-submitted comments/observations, etc.
  • This information may be received from one or more of the management device(s) 104, such as from a prompting that was made at the management device(s) 104 in connection with the APIs l08a or the web interface l08b of the interface module 108.
  • (re)assignment of a tracking code may include (re)assigning a plurality of tracking codes, either because the tracking code was a group code (and so the group code and all unit codes in the group are (re)assigned to the user identifier), or because the tracking was a unit code that is part of a group (and so each unit code in the group is (re)assigned to the user identifier).
  • embodiments may enable individuals to re-assign groupings of articles between each other.
  • a transfer is initiated by the custody component l07b when it receives an identified tracking code from a management device 104 (e.g., a mobile phone) of the user that currently has custody of the identified tracking code, as well as a user identifier of a user that should receive a plurality of tracking codes that are identified based on the identified tracking code.
  • a management device 104 may be used to scan a group tracking code associated with a plurality of unit tracking codes, or to scan one of the plurality unit tracking codes.
  • the plurality of tracking codes may include each unit tracking code associated with the group tracking code.
  • the plurality of articles may include each of the plurality of unit tracking codes of which the unit tracking code is a member.
  • the custody component l07b may verify that the received user identifier is authorized to take custody of the plurality of tracking codes, and, when the user identifier is authorized, re-assign the plurality of tracking codes to the received user identifier (e.g., by updating one or more custody records in the storage device(s) 109). In some embodiments, recipient must verify/acknowledge the receipt for the reassignment to be authorized.
  • first worker can approach a second worker, and ask the second worker for some additional seals.
  • the second worker can then scan, with a mobile management device 104, a group of seals (e.g., group tracking code imprinted on the tray) and specify that custody of those seals be reassigned to the first worker.
  • a group of seals e.g., group tracking code imprinted on the tray
  • only an entire grouping of articles can be authorized for reassignment.
  • the second worker may only be permitted to reassign an entire tray of seals, and not a partial tray.
  • a transfer request may be denied if the second worker attempts to reassign a group tracking code (e.g., for a tray of seals) to the first worker, in which some of the plurality of unit tracking codes of the group (e.g., seals in the tray) are unavailable (e.g., because the second worker has already used some of the seals).
  • a transfer is initiated by the custody component l07b when it receives an identified tracking code from a management device 104 (e.g., a mobile phone) of the user desired to receive custody of the identified tracking code.
  • the custody component l07b may verify that the user identifier associated with the management device 104 is authorized to take custody of a plurality of tracking codes that are identified based on the identified tracking code, and, when the user identifier is authorized, re-assign the plurality of tracking codes to the received user identifier (e.g., by updating one or more custody records in the storage device(s) 109).
  • the re-assignment is performed without any additional authorization or input from the user that currently has custody of the tracking codes.
  • only an entire grouping of articles can be authorized for reassignment.
  • the second worker may only be permitted to reassign an entire tray of seals, and not a partial tray.
  • a transfer request may be denied if the second worker attempts to reassign a group tracking code (e.g., for a tray of seals) to the first worker, in which some of the plurality of unit tracking codes of the group (e.g., seals in the tray) are unavailable (e.g., because the second worker has already used some of the seals).
  • Figure 8 illustrates a flowchart of an example method 800 for assigning tracking units
  • the method 800 includes an act 801 of receiving a tracking code, an asset identifier, and a user identifier.
  • the asset pairing component l07c can receive from a management device 104 a tracking code (e.g., associated with a security seal), an asset identifier (e.g., associated with an asset to which the security seal is being applied, and a user identifier (e.g., associated with a user of the management device 104).
  • the method 800 also includes an act 802 of verifying tracking code status.
  • the asset pairing component l07c can verify, based on one or more records in the storage device(s) 109, whether the tracking code is available to be paired with the asset identifier.
  • the tracking code may be associated with various status, such as available (e.g., a security seal is available to be applied), applied (e.g., the security seal has been applied to an asset), lost (e.g., the security seal has been reported as lost), damaged (e.g., the security seal has been reported as damaged), or fraud (e.g., the security seal has been reported as tampered with, broken, etc.).
  • Act 802 may also include verifying that the user identifier has custody of the tracking code, and that the user identifier is authorized to associate the tracking code with assets.
  • the method 800 also includes an act 803 of assigning the asset identifier to the tracking code, or alternatively and act 804 of denying the request. For example, if the status of the tracking code is available, and the user has custody of the tracking code and is authorized to associate the tracking code with assets, then the asset pairing component l07c may authorize the pairing, and update one or more records in the storage device(s) 109 to identify the tracking code as being applied and associated with the asset identifier. Alternatively, if the status of the tracking code is applied, lost, damaged, fraud, etc., if the user does not have custody of the tracking code, or the user is not authorized to associate the tracking code with assets, the request to pair the tracking code with the asset identifier can be denied.
  • the management system 101 only permits a user to begin interacting with tracking codes that are part of a group when they have already used all other tacking units applied to the same type of article. For example, if the articles are seals, the management system 101 may prevent a user from associating a seal from a new tray of seals with an asset if the user also has custody of another tray that is partially used (i.e., some seals from the tray have been applied, but others have not). The same goes for groupings.
  • the management system 101 may prevent a user from using trays/seals from a new bag until all of the seals in their prior bags have been applied or marked as lost/damage, may prevent a user from using trays/seals/bags from a new box until all of the seals in their prior boxes have been applied or marked as lost/damage, etc.
  • the management system 101 can ensure that custody and use of seals (or other articles to which tracking codes are applied) is tightly regulated.
  • the lifecycle manager module 107 is configured to treat different types of group tracking codes differently.
  • the lifecycle manager module 107 may treat some group tracking codes as corresponding to second-class“batch groups,” and/or treat other group tracking codes as corresponding to“list groups.”
  • the function of second-class batch groups is to apply the same action to a number of first-class groups or items that are within the batch group.
  • the lifecycle manager module 107 may treat any group tracking codes corresponding to trays as batch groups. When trays are treated as batch groups, the lifecycle manager module 107 allows actions to take place with respect to the group without first having to first“open” or“unpack” that group.
  • seals within a tray may be used/applied without first having to“open” the tray.
  • the lifecycle manager module 107 may treat any group tracking codes corresponding to pallets as batch groups, enabling pallets to be split/opened for transport and delivery without authorization from the lifecycle manager module 107.
  • batch groups are “second class,” since the lifecycle manager 107 does not manage their lifecycle. This allows for partial transfers, where, for example, a tray that is half-used can be transferred since the actions apply over the remaining seals, and not the tray itself.
  • the functionality of second-class batch groups is achieved by use of a special marker in the generated group tracking code, but the group tracking codes are otherwise encoded the same as the first class groups.
  • first class groups are encoded without taking into account these second-class groups.
  • first-class“list groups” The function of first-class“list groups” is to generate tracking codes for a mix of unserialized tracking codes.
  • a tracking code for a list group may be used for a delivery order for different tracked materials, where the tracking codes on the tracked materials are not susceptible to grouping, since they have different product identifiers/code ranges.
  • the functionality of list groups achieved by a special marker in the generated group tracking code, and by storing a count and then a list of all serializable tracking codes inside this larger list code.
  • the lifecycle manager module 107 may be configured to facilitate processing of field service orders (work orders).
  • the lifecycle manager module 107 may interact with a management device 104 at each step of the process of processing a service order, to verify and document that each step is performed correctly, and to ensure that incorrect actions are not permitted.
  • a field service order can outline to a worker one or more tasks to be performed with respect to an asset (e.g., a utility meter), such as installation, maintenance, inspection, etc., including the association of a security seal with the asset in connection with performing the service order.
  • an asset e.g., a utility meter
  • seals and utility meters is used to illustrate some examples, though the management system 101 may be usable in a great variety of contexts for managing performance of service orders. As such, any reference to seal and utility meters can be interpreted as being references to articles more generally.
  • the storage device(s) 109 store a field service orders.
  • the management system 101 can then send service orders to management devices 104 of workers, who may then perform the service orders in a manner presented at the management devices 104 (e.g., as instructed using the lifecycle manager module 107 and/or the interface component 108).
  • a service order may specify that a worker install a utility meter.
  • the management system 101 and/or the service order may cause the worker’s management device 104 prompt and instruct the worker in each step of the process, to ensure that worker installs the correct utility meter, to document the worker’ s performance, and to ensure that the utility meter is sealed.
  • the management system 101 and/or the service order may cause the worker’s management device 104 to prompt the worker to scan or enter a first tracking code of the utility meter that the user is installing.
  • the management device 104 may send that first tracking code to the management system 101, where the management system 101 may access one or more records in the storage device(s) 109 relative to the first tracking code. These records may identify the type of the utility meter, the custody chain for the utility meter, or any other relevant data about the utility meter.
  • the management system 101 may assign custody of the utility meter to the worker, and cause the worker’s management device 104 to instruct the worker to perform one or more installation tasks.
  • the management system 101 may cause the worker’s management device 104 to instruct the worker of the error, and to prompt the worker to provide a tracking code for the correct type of utility meter or for an available utility meter.
  • the management system 101 provides a unique feedback system that ensures that the correct assets are used in the correct contexts.
  • the management system 101 and/or the service order may cause the worker’s management device 104 to prompt the user to provide a verification of each task (e.g., by taking a photograph, etc.), and send those verifications to the management system 101 for recording in the storage device(s) 109.
  • the worker is not permitted by the management device 104 to proceed with the next task until the current task is completed.
  • the management system 101 and/or the service order may cause the worker’s management device 104 to prompt the worker to apply a seal to the utility meter.
  • the worker’s management device 104 can receive a second tracking code associated with a security seal, and send it to the management system 101.
  • the management service can then record an association between the first tracking code of the utility meter and the second tracking code of the seal.
  • the management system 101 can record a great variety of information in connection with completion of a service order and/or application of a seal to an asset (e.g., utility meter). For example, based on information received from the worker’s management device 104, the management system 101 may record the identity of the worker, a worker“signature” verifying that the work was performed properly, verification that the utility meter has passed a particular test, a geo-location of where the work was performed (and where the utility meter is located), a date/time stamp, one or more photos (e.g., of the seal, of the asset, of the work order, of the seal on the asset), etc.
  • an asset e.g., utility meter
  • the management system 101 can be used to verify the integrity of the seal and/or utility meter remains intact. For example, in connection with performance of a subsequent service order on the utility meter, the management system 101 and/or the subsequent service order can cause the worker’s management device 104 to prompt the worker to re-scan the first tracking code of the utility meter and/or the second tracking code of the security seal. The management system 101 can then verify that these tracking codes are the ones that are recorded at the storage device(s) 109, and that are expected. If they differ from what is expected, the management system 101 can identify that the seal and/or the utility meter has been tampered with.
  • a blockchain is a data structure comprising a growing list of records, called blocks, which are cryptographically linked to each other.
  • each block comprises at least a cryptographic hash of the previous block, a timestamp, and transaction data.
  • a blockchain is resistant to modification of the data once it has been added as a block.
  • data that has been added to a blockchain can be considered to be immutable; furthermore, its integrity can be cryptographically verified by any computer system having appropriate access to the blockchain.
  • blockchains are distributed across peer computers in a peer- to-peer network.
  • a blockchain forms a distributed ledger. Blocks are added to the blockchain based on the peers collectively adhering to a protocol for inter-node communication and for validating new blocks.
  • a blockchain might be public and accessible to anyone who can join the peer-to-peer network, or might be private (i.e., permissioned) and accessible only to those possessing the appropriate cryptographic keys.
  • a“proof of work” e.g., resource-intensive cryptographic calculation(s)
  • Private blockchains may permit a peer to add a block to the blockchain based on the peer possessing a cryptographic key that is assigned to it by an authoritative party.
  • some embodiments operate to perform asset management and tracking in connection with distributed ledger technology, such as distributed ledgers implemented as blockchains.
  • distributed ledgers implemented as blockchains.
  • separate logical entities e.g., different companies, different divisions within a company, etc.
  • a common distributed ledger to track the entire lifecycle of physical assets as those assets are interacted with— both within the entities and among the entities.
  • Figure 9 illustrates an environment 900 in which a plurality of peers (e.g., each corresponding to a different entity) communicate over a network to maintain a distributed ledger, and to use the distributed ledger to manage the lifecycle of tracking codes (and their corresponding physical assets).
  • a plurality of peers 90la-90ld in communication with each other over a network 908 (e.g., such as a private WAN or LAN, or a public WAN such as the Internet). While four peers 901 are illustrated for purposes of this example, environment 900 could include any number of a plurality of peers (i.e., two or more) as indicated by the ellipses 910.
  • each peer includes a plurality of modules and one or more data stores used to implement corresponding functionality of the peer.
  • the particular number, identity, and arrangement of these modules/data stores can vary from peer to peer (i.e., depending on the needs and authority of its corresponding entity), as indicated by the ellipsis 909 within each peer.
  • the particular arrangements shown in Figure 9 are for illustrative purposes only and are non-limiting.
  • each peer 901 includes a corresponding blockchain module 902 that operates to communicate with other peers and to maintain a corresponding copy of a distributed ledger 905.
  • blockchain module 902 might comprise software installed at each peer that defines the environment 900’s protocol for inter-node communication and block validation. This software might also define the format and structure of the distributed ledger 905 and manage the addition of new blocks to the ledger.
  • each peer stores a corresponding copy of the distributed ledger 905. These copies are kept in sync by the blockchain modules 902 at each peer.
  • Each peer 901 also includes a corresponding lifecycle manager 904 that leverages the distributed ledger 905 to manage the lifecycle of tracking codes and assets, such as using the lifecycle management techniques already described herein.
  • Each peer 901 could, in some embodiments, comprise a different computing environment (e.g., one or more server computer systems) operated by its corresponding entity.
  • peer 90 la could comprise computer system(s) operated by an administrative (e.g., logistics) company responsible for overall maintenance and operation of the software technology that implements the distributed ledger 905, including asset management using the distributed ledger 905.
  • an administrative company operating peer 90 la could manage and maintain the blockchain 901 and lifecycle manager 904 modules that are installed at each peer.
  • peer 90 la is also responsible for the generating and assigning (e.g., using key generator 911) cryptographic keys needed to interoperate with the distributed ledger 905, and for the genesis (e.g., using code generator 903) of any tracking codes that are managed by the distributed ledger 905.
  • code generator 903 might generate codes formatted as shown in Figure 2.
  • peer 90 la may add such tracking codes to the distributed ledger 905 (i.e., in new blocks on the distributed ledger 905), making them available for use by the other peers.
  • peer 90 la might be viewed as a“master” peer that serves as a gatekeeper for ledger access and tracking code generation.
  • peer 90lb could comprise computer system(s) operated by a manufacturing company (e.g., factory) responsible for assigning and imprinting tracking codes generated by the code generator 903 at peer 90 lb to physical articles.
  • peer 90 lb is shown as including a code applicator module 907, which could be responsible for controlling the verified imprinting of tracking codes generated by peer 90 la onto articles and for controlling the verified packaging of those articles into containers, if appropriate (e.g., following the methodologies described in connection with Figures 3A-6).
  • peer 90 lb may include or be in communication with one or more internal computing devices 906b, such as network-connected cameras, printers, scanners, control devices, etc. that are part of one or more factory lines, and/or mobile devices (e.g., smartphones) used by personnel handling these assets (e.g., warehouse workers) to track asset custody once it leaves a factory line and to transfer assets to external entities.
  • internal computing devices 906b such as network-connected cameras, printers, scanners, control devices, etc. that are part of one or more factory lines, and/or mobile devices (e.g., smartphones) used by personnel handling these assets (e.g., warehouse workers) to track asset custody once it leaves a factory line and to transfer assets to external entities.
  • peers 90lc and 90ld could comprise computer system(s) operated by entities responsible for physical assets once they leave the custody of peer 90lb.
  • peers 90 lc and 90 ld could be operated by transport companies that transport these assets, companies that deploy and use these assets (e.g., utility companies), contractors that operate on behalf of utility companies, etc.
  • transport companies that transport these assets
  • companies that deploy and use these assets e.g., utility companies
  • contractors that operate on behalf of utility companies, etc.
  • peer 90 lc is operated by a transport company and that peer 90 ld is operated by a utility company.
  • internal computing devices 906c at peer 90 lc might be mobile devices (e.g., smartphones) operated by transport workers to obtain custody of assets from the manufacturing entity operating peer 90 lb, and to track custody and other information (e.g., geographical location, transport truck, etc.) as these assets are handled by the transport company.
  • Internal computing devices 906d might be mobile devices (e.g., smartphones) operated by utility workers to obtain custody of assets from the transport entity operating peer 90lc, and to track custody and other information (e.g., geographical location, verified installation, etc.) as these assets are handled by utility workers.
  • peers 90la and 90lb could be operated as separate computer systems (as shown), or their functionality could be merged into a single peer computer system.
  • peer 90 la can use key generator 911 to generate one or more cryptographic keys for each peer. These cryptographic keys are usable by the blockchain modules 902 at the peers to verify the identity of each peer, and to authorize each peer to access the distributed ledger 905 and add blocks to the distributed ledger 905a.
  • Peer 90la can also utilize its code generator 903 to generate one or more tracking codes that can be imprinted onto assets by peer 90 lb, and can utilize it blockchain module 902a to add one or more blocks to the distributed ledger 905 that include these tracking codes.
  • peer 90la might generate tracking codes in accordance with those described previously herein, that capture both groupings and units within those groupings.
  • Peer 901 a might generate these tracking codes based on communication(s) received directly from peer 90 lb over network 908, or based on a block added to the distributed ledger 905 by peer 90lb. Once these tracking codes are added to the distributed ledger 905a, the lifecycle manager 904 at each peer can now recognize these codes as valid tracking codes.
  • peer 90lb can now utilize the code applicator 907 to direct internal devices 906b (e.g., factory line components) to verifiably imprint these tracking codes onto physical articles (e.g., following method 600) and to potentially verifiably package these physical articles into containers (e.g., following method 700).
  • Peer 90 lb might then use its blockchain module 902b to record this application/packaging within the ledger 905.
  • the lifecycle manager 904 at each peer could then recognize these tracking codes as having been applied to assets.
  • peer 90 lb might defer adding any entries to ledger 905 until the physical assets have actually been (or about to be) transferred to another entity.
  • peer 90 lb might record application of tracking codes within a local database (e.g., in storage 905b-n) prior to recording their application within the ledger 905.
  • peer 90lc can receive these imprinted assets from peer 90 lb for transport to the utility company.
  • transfers between peers is recorded using two entries on the distributed ledger 905.
  • peer 90 lb might insert a first record onto the ledger 905 indicating that the asset(s) associated with one or more tracking codes have been transferred to peer 90 lc.
  • this first record could be an initial record on the ledger 905 that records application of tracking code(s) to assets(s) (e.g., if peer 90lb defers adding any entries to ledger 905 until transfer of an asset to another entity).
  • peer 90 lc might insert a second record onto the ledger 905 confirming/endorsing that it received the asset(s).
  • Other implementations could use more or fewer ledger entries to record a custody transfer.
  • peer 90 lc can transfer custody of the asset(s) to peer 90 ld— such as when assets are delivered to the utility company— and this transfer could be recorded using two-record mechanism (e.g., a block/record by peer 90 lc indicating that the asset(s) have been transferred to peer 90 ld, and a block/record by peer 90 ld confirming/endorsing that it received the asset(s)).
  • peers might leverage internal computing devices to manage the lifecycle of the physical articles imprinted with tracking codes.
  • physical articles may comprise utility meters, and the peer’s internal computing devices 906d might be used by field service workers to track custody of utility meters as the utility meters are handled by the field service workers (using the mechanisms already described herein) and transferred between the field service workers.
  • Internal computing devices 906d might be used by the field service workers to track lifecycle events with respect to these meters (e.g., installation events, maintenance events, retirement events, etc.).
  • physical articles may comprise security seals, and internal computing devices 906d might be used by field service workers to track custody of the seals and lifecycle events of seals, such as their application to utility meters and/or their retirement.
  • the various custody/lifecycle events generated by the internal computing devices 906d at peer 90 ld might be recorded onto the distributed ledger 905d, in real-time, or with a delay.
  • the internal computing devices 906d are typically internet-connected (e.g., as is the usual case with a smartphone)
  • events generated by the internal computing devices 906d might be recorded as blocks on the distributed ledger 905d in substantially real-time.
  • the internal computing devices 906d might communicate with one or more computer systems operated by peer 90 ld to cause the blockchain module 902d and the lifecycle manager module 904d to add appropriate blocks to the distributed ledger 905d to record the events.
  • the internal computing devices 906d are not internet-connected, they might store records of these events locally and then later synchronize them with the peer 90 ld to cause record of the events to be added to distributed ledger 905d (e.g., at the end of the workday).
  • embodiments could include internal devices at a peer operating in offline (i.e., non network connected) modes, but still interoperating with the distributed leger 905. For example, at the beginning of a work day and when user’s mobile devices are online, a peer might assign custody of a batch of assets to a user (or multiple users) based on the tracking codes imprinted on those assets. This custody information might be stored both at internal databases at the peer, and on each of the users’ mobile devices.
  • the peer might store additional identity information such as each of the mobile device’s IMEI, MAC address, etc.
  • the user(s) might then proceed to transport and/or deploy these assets during the workday while their mobile device(s) is/are offline.
  • lifecycle management software on the mobile device(s) may still be used to record change in custody events (e.g., with other workers), lifecycle events, etc.
  • the users’ devices can be synchronized back with the peer.
  • each user’ s device can be verified (e.g., using the stored IMEI, MAC address, etc.), and the data stored on each device can be audited for correctness and consistency (e.g., comparing records of transfers between two devices, verifying proper documentation of lifecycle events, etc.) and the audited data can be integrated back into the peer’s database, and potentially pushed onto the distributed ledger if appropriate. If there are any inconsistencies or errors, responsibility and accountability can be attributed to the user based on the data from his device.
  • custody/lifecycle events generated by the internal computing devices 906d at peer 90 ld might not be recorded onto the distributed ledger 905d at all. Instead, these events might be recorded by the lifecycle manager 904d within a local database at peer 90ld (e.g., within storage 905d-n). In these embodiments, custody/lifecycle events could be stored within this peer-local database in real-time, or with a delay, similar to the preceding description. It is noted that it may be desirable to store custody/lifecycle events within a local database— and not on the distributed ledger 905d— since these events might be applicable only to peer 90 ld and may, in fact, be information that should be held privately by peer 90 ld.
  • the distributed ledger 905d could be used to store potentially all events relating to tracking codes and their associated physical assets.
  • the distributed ledger 905d could store only events relating to tracking code generation, tracking code application and asset packaging, and transfer of custody of assets between peers.
  • all events by internal computing devices at peers 90la, 90lb, and 90lc are recorded on the distributed ledger 905d, but events by internal computing devices 906d at peer 90ld (i.e., an end-user of the assets) are not.
  • the distributed ledger 905 could include both public and private data streams (i.e., channels). Private channels could exist on the distributed ledger 905 but be accessible to only to those peers who possess appropriate cryptographic keys. Thus, for example, peer 90 la may generate cryptographic keys for one or more peers that enable those peers to view and add private blocks to the distributed ledger 905. Private channels could be used by single peers. For example, peer 90 ld might use a channel to which only peer 90 ld has access to store local events (e.g., such as those events generated by internal devices 906d at peer 90 ld) on the distributed ledger 905.
  • local events e.g., such as those events generated by internal devices 906d at peer 90 ld
  • Private channels could also be used by multiple peers.
  • a utility company operating peer 90 ld may contract with another company to help install and manage its utility meters.
  • environment 900 might include a fifth peer (not shown) operated by this contractor.
  • these two peers i.e., corresponding to the utility company and the contractor
  • peer 90 lc and peer 90 ld might participate in a private channel to record the transfer of assets from peer 90 lc to peer 90 ld.
  • the other peers e.g., 90 la and 90 lb
  • the other peers might be aware of a tracking code’s generation, application to an asset, and transfer to a transport company, but might be unaware of where the asset was shipped or what was done with that asset after it was delivered.
  • the distributed ledger 905 could implement smart contract functionality.
  • a smart contract defines machine-executable code logic that is executed prior to a block being added to a blockchain. The outcome of this code execution might determine whether or not the block can actually be added.
  • contracts might be programmatically enforced by the blockchain modules 902 prior to those modules permitting a block to be added to the distributed ledger 905.
  • a contract might define particular conditions that must be met prior to adding a block recording the transfer of an asset (e.g., between peers or between internal devices), prior to adding a block recording application of a seal to an asset, prior to adding a block recording deployment/installation of an asset, etc.
  • peer 90 la may provide programming tools that enable the peers within environment 900 to create and modify smart contracts on their own.
  • the data that is included in a particular block may vary depending on implementation and on the nature of the event the block is recording.
  • a block will include the identity of one or more tracking codes involved, a type identifier of the event being recorded (e.g., code application, asset transfer, etc.), and the party or parties involved (if applicable).
  • Other supporting digital resources e.g., photographs, signatures, etc.
  • supporting resources might instead be stored in some other database and then be referenced within the block. For example, a photograph might be stored in a database at an appropriate peer, with that resource’s identity being recorded within the block.
  • the block contains information usable to verify the authenticity of the resource, such as a checksum of the resource itself.
  • One implementation assigns resources filenames that include the resource’s checksum, and then stores these checksums with the block in order to both identify and verify the resources.
  • FIG. 10 illustrates an example flowchart 1000 of actions performed by a plurality of network-connected peer computer systems lOOla-lOOln (e.g., corresponding to some, or all, of peers 901 of Figure 9).
  • each of these peers 1001 store and operate on at least a portion of a blockchain-based distributed ledger to perform lifecycle management tasks with respect to assets to which tracking codes are associated.
  • each peer 1001 could include a corresponding blockchain module 902, lifecycle manager 904, and copy of distributed ledger 905a.
  • a first peer 100 la can generate cryptographic keys (act 1002).
  • act 1002 comprises generating at least one cryptographic key for each of the plurality of peer computer systems, each cryptographic key enabling its corresponding peer computer system to view blocks on the blockchain distributed ledger and to insert blocks onto the blockchain distributed ledger.
  • peer 90 la might use a code generator 903 to generate cryptographic keys for each peer that will be accessing the distributed ledger 905a. These cryptographic keys enable these peers to read blocks from and insert blocks into the distributed ledger.
  • Peer lOOla can also generate tracking codes and insert them onto a blockchain (act 1003).
  • act 1003 comprises generating a plurality of tracking codes, and inserting one or more first blocks including the plurality of tracking codes onto the blockchain distributed ledger. Inserting the one or more first blocks onto the blockchain distributed ledger (i) initiates a lifecycle for each of the plurality of tracking codes (e.g., using the lifecycle manager 904), and (ii) makes each of the plurality of tracking codes visible to the plurality of peer computer systems.
  • act 1002 appears prior to act 1003 in Figure 10, it is noted that this ordering is for illustrative purposes only, and is non-limiting. For example, act 1003 could be performed prior to, or in parallel with, act 1002.
  • act 1004 comprises imprinting each of the plurality of tracking codes onto a corresponding physical article.
  • peer 90 lb might obtain these tracking codes from the distributed ledger 905, and use its code applicator module 907 to instruct its internal devices 906b to imprint the tracking codes onto physical articles, and verify the imprinting.
  • Embodiments for a verified imprinting are described in detail earlier in this application, and any of those embodiments can be utilized by method 1000.
  • Peer lOOlb also records the imprinting on the blockchain (act 1005).
  • act 1005 comprises inserting one or more second blocks onto the blockchain distributed ledger recording the imprinting of each of the plurality of tracking codes onto its corresponding physical article.
  • Peer lOOlb might then transfer the physical assets to another entity, such as a transport company, a utility company, a contractor, or practically any other type of organization. As was discussed, transfers can be recorded on a distributed ledger using two entries: one from the transferor and one from the recipient. Thus, as shown in Figure 10, Peer lOOlb (as transferor) records a custody transfer on the blockchain (act 1006). In some embodiments, act 1006 comprises inserting one or more third blocks onto the blockchain distributed ledger indicating that custody of the plurality of tracking codes and their corresponding physical articles has been transferred to a third peer computer system. For example, returning to Figure 9, peer 90lb might transfer assets to peer 90 lc or peer 90 ld. In this case, peer 90 lb records onto the distributed ledger 905b an indication that the asset(s) have been transferred and which peer to which they have been transferred (e.g., peer 90 lc or peer 90 ld).
  • act 1006 comprises inserting one or more third blocks onto the blockchain distributed led
  • act 1007 comprises inserting one or more fourth blocks onto the blockchain distributed ledger indicating that receipt of custody of the plurality of tracking codes and their corresponding physical articles from the second peer computer system has been confirmed by the third peer computer system.
  • peer 901 c or peer 901 d can record on to the distributed ledger 905b an indication that it has received the transferred asset(s) from peer 90lb.
  • flowchart 1000 can include any number of peers (i.e., as indicated by peer 1001 n, and custody transfers can happen between any two peers and be logged onto the blockchain distributed ledger in the manner described in connection with acts 1006 and 1007.
  • peer lOOlc might transfer assets to peer 1001 n, and this transfer can be carried out by peer lOOlc recording the custody transfer to peer 1000 n on the blockchain (act 1008), and peer 1001 n recording acceptance of the transfer from peer lOOlc on the blockchain (act 1009).
  • the first peer 100 la generates tracking codes that include at least one group tracking code and a plurality of unit tracking codes that are part of the group tracking code, such as using the tracking code format already described herein.
  • the second peer 100 lb can imprint the group tracking code onto a container, and imprint each of the unit tracking codes onto articles belonging within the container.
  • the second peer computer system imprinting each of the plurality of tracking codes onto a corresponding physical article can include the second peer 100 lb imprinting the group tracking code onto a physical article comprising a container, and imprinting each of the plurality of unit tracking codes onto a corresponding physical article that is placed within the container.
  • act 1005 can include the second peer inserting at least one block onto the blockchain distributed ledger that confirms that the group tracking code and each of the plurality of unit tracking codes were properly imprinted onto their corresponding physical articles.
  • embodiments include a verified packaging methodology that not only ensures that codes are properly imprinted, but also ensures that all items are packaged properly in their containers.
  • Peer 100 lb can perform such a packaging methodology, and then insert at least one block onto the blockchain distributed ledger that confirms that each physical article having one of the plurality of unit tracking codes imprinted thereon have been placed within the container.
  • Any of the peers can generate custody change events and/or lifecycle events with respect to tracking codes (and their associated physical articles) for which the peer has assigned custody. As discussed, these events can be recorded in a local database at the peer, and/or on the distributed ledger. As such, method 1000 can, for example, include any of the peer computer systems recording one or more custody change events and/or one or more lifecycle events relating to the plurality of tracking codes by devices internal to that peer within a private database at the peer computer system or within the blockchain distributed ledger.
  • method 1000 can include one or both of two or more of the plurality of peer computer systems participating in a private channel on the blockchain distributed ledger, or at least one of the plurality of peer computer systems participating in a smart contract when inserting a block onto the blockchain distributed ledger.
  • blockchains enable reverse logistics— i.e., originating an asset’s lifecycle and/or performing verified packaging at user’s mobile devices (e.g., internal devices 906d), rather than by a peer operating a factory line (e.g., peer 90lb with factory line devices as part of its internal devices 906b).
  • a peer operating a factory line e.g., peer 90lb with factory line devices as part of its internal devices 906b.
  • Reverse logistics generally embodies two primary functions: first, using a user’s mobile device to associate assets having“legacy” (i.e., pre-existing) tracking codes with“native” tracking codes generated by code generator 903 (such as the group/item codes described herein); and second, using a user’ s mobile device to perform a verified packaging methodology.
  • these two functions could be used singly or together.
  • the first function might be used by peer 90ld to import existing legacy assets (e.g., such as utility meters) into the distributed ledger 905 and begin lifecycle management of those legacy assets. This could include associating existing legacy tracking codes with newly-generated native tracking codes.
  • the second function might be used by peer 90 ld as part of retiring and re- packaging assets (e.g., such as utility meters). Again, could include associating existing legacy tracking codes with newly-generated native tracking codes. Furthermore, it could include printing tracking labels containing native group codes for application to containers.
  • assets e.g., such as utility meters.
  • a native tracking code is one that is generated according to the embodiments described herein (e.g., including concepts of group codes and unit codes), such as those generated by code generator 903.
  • Legacy tracking codes are any tracking codes already existing on or associated with assets, and as such could come in a wide variety of formats. These tracking codes could even comprise, for example, product’s serial number, a code from an asset tag, a code from a security seal already associated with the asset, etc.
  • mapping of a legacy tracking code to a native tracking code can be initiated by a peer’s internal devices 906.
  • a peer might use one of the peer’s internal devices 906d (e.g., a smartphone running software that interoperates with the blockchain module 902d and lifecycle manager 904d) to scan or otherwise receive input of one or more legacy tracking codes.
  • These tracking codes could originate, for example, from utility meters the worker is performing maintenance or inspections on, or that the worker is retiring.
  • This internal device 906d can cause peer 90 ld to request one or more native tracking codes from peer 90 la, which then generates them using code generator 903 and adds them to the distributed ledger 905.
  • the internal device 906d (or peer 90 ld) can initiate association(s) between the legacy tracking codes and the native tracking codes, and record these associations in the distributed ledger 905 using the blockchain module 902d at peer 90 ld.
  • the lifecycle manager 904d at peer 90 ld and initiate a lifecycle record (including custody changes) of the assets associated with these tracking codes.
  • the association with native tracking codes can be discovered on the distributed ledger 905, along with any associated custody and lifecycle state.
  • a verified packaging of assets into containers can be performed by peer’s internal devices 906.
  • a mobile device e.g., smartphone
  • this workflow starts with a user receiving input of a group tracking code associated with a container (e.g., by scanning with a camera, RFID reader, NFC reader, etc.; or manual code entry), resulting in the group tracking code being changed to an“opened” status.
  • the mobile device can prompt the user to input (e.g., by scanning) each of the unit tracking codes that are to be placed into this container.
  • the user can again scan the group tracking code (or otherwise provide input indicating that the group is to be closed), resulting in the group tracking code being changed to a“closed” status.
  • the container can only be“closed” when each article that should be in the container has been recorded as being placed within the container.
  • the container in the foregoing example might be a bag, which is to be placed in a box with other bags.
  • the tracking codes could include a group tracking code for the box that contains a plurality of tracking codes for bags (including the group tracking code referred to above).
  • the workflow might start with the mobile device prompting the user to“open” the box’ s grouping code prior to opening the bag’ s grouping code. Once the bag has been“closed” it can be registered as being placed within the box.
  • the user can then proceed to the other bags that are part of the box’ s grouping code and close the box’ s grouping code only when all of the bags (and their corresponding articles) are accounted for.
  • This can be extended to any number of ever-larger groupings.
  • the box grouping code might be part of a pallet grouping code.
  • Records of this verified packaging can be recorded by the peer to the distributed ledger 905b and/or to an internal database of the peer. If the mobile devices being used are operating in an online mode, this might be done in real-time (or substantially real-time). If the mobile devices are operating in an offline mode, the mobile devices might check-out a set of codes to use for the packaging, perform the work, and then synchronize the work back to their peer later (where the work is verified prior to being pushed the distributed ledger 905b and/or to an internal database of the peer.
  • This verified packaging methodology can be performed in conjunction with a legacy- to-native code conversion.
  • some individual articles might have legacy tracking codes associated therewith.
  • these legacy tracking codes can be associated with native tracking codes.
  • the containers will typically be associated directly with native group tracking codes.
  • the mobile devices could be connected to printing devices in order to print these group tracking codes on-demand onto labels that are affixed by the users to the containers during packaging.
  • these labels could be printed based on an instruction from the peer and provided to a worker prior to the worker performing the packaging.
  • Either of the code assignment or the verified packaging embodiments can also work in an offline mode as well.
  • internal devices can work in offline modes that synchronize with their peer 901 at the beginning and end of a work cycle.
  • the peer can verify devices (e.g., by their IMEI or MAC address) and verify/audit all records logged by the device while it was offline.
  • This embodiment can be extended to requesting a batch of native tracking codes prior to the device going offline and assigning these tracking codes to the device during the initial synchronization step.
  • the device can be used to associate native tracking codes with legacy tracking codes, perform a verified packaging process, etc., and this information can then be synchronized back to the peer with the device is again online. After verifying/auditing these records, the peer can insert the appropriate data onto the distributed ledger 905.
  • either of the code assignment or the verified packaging embodiments can also incorporate the added security layer of enforcing geographical restrictions.
  • many mobile devices include geo-location hardware and services (e.g., using GPS, WiFi, and/or Bluetooth). In some embodiments, these mobile devices can be instructed to only permit reverse logistics operations when the device is within one or more defined geographical areas. In this way, peers can ensure that reverse logistics operations are only performed in trusted locations.
  • distributed ledgers can be used as evidence of compliance with company or regulatory requirements. For instance, some when lifecycle events associated with tracking codes are recorded, these events might be recorded with evidence that particular procedures were performed, or that certain documentation was reviewed. This could be enforced by software running on an internal device used for recording the lifecycle event and/or by smart contracts. This evidence becomes an immutable part of the distributed ledger, providing documentation later that proper procedures were followed and/or that appropriate documentation was reviewed.
  • FIG. 11 illustrates an example flowchart 1100 of actions performed by a plurality of network-connected peer computer systems 110 la and 110 lb (e.g., corresponding to some, or all, of peers 901 of Figure 9).
  • each of these peers 1101 store and operate on at least a portion of a blockchain-based distributed ledger to perform lifecycle management tasks with respect to assets to which tracking codes are associated.
  • each peer 1101 could include a corresponding blockchain module 902, lifecycle manager 904, and copy of distributed ledger 905a.
  • a first peer 1 lOla can generate native tracking codes and insert them onto a blockchain (act 1102).
  • act 1102 comprises generating a plurality of native tracking codes and inserting one or more first blocks including the plurality of native tracking codes onto the blockchain distributed ledger, inserting the one or more first blocks onto the blockchain distributed ledger (i) initiating a lifecycle for each of the plurality of native tracking codes, and (ii) making each of the plurality of native tracking codes visible to the plurality of peer computer systems.
  • peer 90 la might use its code generator 903 to generate native tracking codes, and use its blockchain module 902a and its lifecycle manager 904a to insert these codes onto the distributed ledger 905a and initiate their lifecycle.
  • peer l lOlb can communicate these tracking codes to an internal device (act 1103).
  • act 1103 comprises communicating the plurality of native tracking codes to an internal mobile device associated with the peer.
  • peer 90 ld can communicate these codes to one or more of internal devices 906d, such as smartphone devices running software that interoperates with peer 90 ld.
  • Peer l lOlb can also receive a native to legacy code association (act 1104).
  • act 1104 can comprise receiving from the internal mobile device an association of at least one of the plurality of native tracking codes with at least one legacy tracking code associated with a physical article.
  • one of the internal devices 906d can scan or otherwise receive a legacy tracking code that is associated with some article.
  • the internal device 906d can associate that legacy tracking code with one of the native tracking codes and communicate this information to peer 90 ld.
  • Peer l lOlb can also record the association on the blockchain (act 1105).
  • act 1105 comprises inserting one or more second blocks onto the blockchain distributed ledger indicating that the at least one of the plurality of native tracking codes is associated with the at least one legacy tracking code associated with a physical article.
  • peer 90 ld can use its blockchain module 902 to record this association onto the distributed ledger 905.
  • the legacy to native code mapping function of reverse logistics can interoperate with the packaging function of reverse logistics.
  • the plurality of native tracking codes could include a group tracking code and a plurality of unit tracking codes. Then when the native tracking codes is associated with the legacy tracking code, it might be associated with one of the plurality of unit tracking codes. Additionally, or alternatively, the second peer could insert one or more third blocks onto the blockchain distributed ledger indicating that the plurality of unit tracking codes have been packaged into a container corresponding to the group tracking code.
  • FIG. 12 illustrates an example flowchart 1200 of actions performed by a plurality of network- connected peer computer systems l20la and l20lb (e.g., corresponding to some, or all, of peers 901 of Figure 9).
  • each of these peers 1201 store and operate on at least a portion of a blockchain-based distributed ledger to perform lifecycle management tasks with respect to assets to which tracking codes are associated.
  • each peer 1101 could include a corresponding blockchain module 902, lifecycle manager 904, and copy of distributed ledger 905a.
  • a first peer l20la can generate grouped tracking codes and insert them onto a blockchain (act 1202).
  • act 1202 comprises generating a plurality of tracking codes including a group tracking code and a plurality of unit tracking codes that are associated with the group tracking code, and inserting one or more first blocks including the plurality of tracking codes onto the blockchain distributed ledger, inserting the one or more first blocks onto the blockchain distributed ledger (i) initiating a lifecycle for each of the plurality of tracking codes, and (ii) making each of the plurality of tracking codes visible to the plurality of peer computer systems.
  • peer 90 la can use its code generator 903 to generate grouped tracking codes, and place these tracking codes on the distributed ledger 905a.
  • peer l20lb can communicate these tracking codes to an internal device (act 1203).
  • act 1203 can comprise communicating the plurality of tracking codes to an internal mobile device associated with the peer.
  • peer 90 ld can send these grouped tracking codes to one of its internal devices 906d.
  • Peer l20lb can also receive an indication of the group code being opened (act 1204).
  • act 1204 comprises receiving from the internal mobile device a first indication that the group tracking code has been scanned by the internal mobile device to open the group tracking code.
  • an internal device 906d might scan a code associated with a container, such as a bag or a box, causing that code to be“opened.” The internal device 906d can communicate this action to peer 90 ld.
  • Peer l20lb can also receive indication(s) of the unit codes being packaged (act 1205).
  • act 1205 comprises receiving from the internal mobile device one or more second indications that each of the plurality of unit tracking codes have been scanned by the internal mobile device as part of packaging articles associated with the plurality of unit tracking codes into a container associated with the group tracking code.
  • the internal device 906d might scan unit codes associated with articles as they are packaged into the container, causing them to be recorded as being packaged in the container.
  • the internal device 906d can communicate this action to peer 90 ld.
  • Peer l20lb can also receive an indication of the group code being closed (act 1206).
  • act 1206 comprises receiving from the internal mobile device a third indication that the group tracking code has been scanned by the internal mobile device to close the group tracking code after each of the plurality of unit tracking codes have been scanned. For example, once all the units have been packaged, the internal device 906d might again scan the code associated with a container causing that code to be“closed”. The internal device 906d can communicate this action to peer 90 ld.
  • Peer l20lb can also record the packaging on the blockchain (act 1207).
  • act 1207 comprises inserting one or more second blocks onto the blockchain distributed ledger indicating that the plurality of unit tracking codes have been packaged within the group tracking code. For example, after receiving confirmation that all units have been packaged and the container has been closed, peer 90 ld can make record of this on the distributed ledger 905d.
  • Internal devices might participate in method 1200 in ether an online or an offline mode.
  • the first, second, and third indications can be received by the second peer computer system substantially in real-time as the internal mobile device scans the group tracking code and the plurality of unit tracking codes.
  • these indications may be received by the second peer computer system in a delayed and batched manner, which would mean all the indications would be received after the closing of the group tracking code.
  • Embodiments of the present invention may comprise or utilize a special-purpose or general-purpose computer system that includes computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below.
  • Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures.
  • Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system.
  • Computer-readable media that store computer-executable instructions and/or data structures are computer storage media.
  • Computer-readable media that carry computer-executable instructions and/or data structures are transmission media.
  • embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.
  • Computer storage media are physical storage media that store computer-executable instructions and/or data structures.
  • Physical storage media include computer hardware, such as RAM, ROM, EEPROM, solid state drives (“SSDs”), flash memory, phase-change memory (“PCM”), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention.
  • Transmission media can include a network and/or data links which can be used to carry program code in the form of computer-executable instructions or data structures, and which can be accessed by a general-purpose or special-purpose computer system.
  • A“network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices.
  • program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa).
  • computer- executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a“NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system.
  • a network interface module e.g., a“NIC”
  • NIC network interface module
  • computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.
  • Computer-executable instructions comprise, for example, instructions and data which, when executed at one or more processors, cause a general-purpose computer system, special- purpose computer system, or special-purpose processing device to perform a certain function or group of functions.
  • Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.
  • Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like.
  • the invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
  • a computer system may include a plurality of constituent computer systems.
  • program modules may be located in both local and remote memory storage devices.
  • Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations.
  • “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of“cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.
  • a cloud computing model can be composed of various characteristics, such as on- demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth.
  • a cloud computing model may also come in the form of various service models such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”).
  • SaaS Software as a Service
  • PaaS Platform as a Service
  • IaaS Infrastructure as a Service
  • the cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.
  • Some embodiments may comprise a system that includes one or more hosts that are each capable of running one or more virtual machines.
  • each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources that are abstracted from view of the virtual machines.
  • the hypervisor also provides proper isolation between the virtual machines.
  • the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine only interfaces with the appearance (e.g., a virtual resource) of a physical resource. Examples of physical resources including processing capacity, memory, disk space, network bandwidth, media drives, and so forth.

Landscapes

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

Abstract

Système informatique comprenant un premier homologue (901a) qui génère (911), pour chaque homologue parmi une pluralité d'homologues, une clé cryptographique qui permet à un homologue d'accéder à un registre distribué. Le premier homologue (901a) génère (903) une pluralité de codes de suivi (902a) et insère, sur le registre distribué, un ou des premiers blocs qui commencent un cycle de vie, et rend chaque code visible pour les homologues. Un deuxième homologue (901b) imprime chaque code sur un article physique correspondant, insère (902b) un ou des deuxièmes blocs sur le registre distribué enregistrant cette impression, et insère un ou des troisièmes blocs sur le registre distribué indiquant que la garde (904b) des codes de suivi a été transférée à un troisième homologue (901c). Le troisième homologue (901c) insère un ou des quatrièmes blocs sur le registre distribué indiquant que la réception de la garde (904c, 904d) des codes de suivi et de leurs articles physiques correspondants en provenance du deuxième homologue (901b), a été confirmée par le troisième homologue (901c).
EP18932519.4A 2018-09-04 2018-12-13 Génération, application et vérification de codes de suivi à l'aide de la technologie des chaînes de blocs Withdrawn EP3847597A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/121,526 US10192198B2 (en) 2014-11-05 2018-09-04 Tracking code generation, application, and verification using blockchain technology
PCT/US2018/065466 WO2020050869A1 (fr) 2018-09-04 2018-12-13 Génération, application et vérification de codes de suivi à l'aide de la technologie des chaînes de blocs

Publications (2)

Publication Number Publication Date
EP3847597A1 true EP3847597A1 (fr) 2021-07-14
EP3847597A4 EP3847597A4 (fr) 2022-08-31

Family

ID=69723198

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18932519.4A Withdrawn EP3847597A4 (fr) 2018-09-04 2018-12-13 Génération, application et vérification de codes de suivi à l'aide de la technologie des chaînes de blocs

Country Status (3)

Country Link
EP (1) EP3847597A4 (fr)
BR (1) BR112021004110A2 (fr)
WO (1) WO2020050869A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023114171A2 (fr) * 2021-12-14 2023-06-22 Christmas Gerard Holdings, Llc Système et procédé permettant d'utiliser un jeton non fongible pour optimiser un cycle de vie de produit
US20240029015A1 (en) * 2022-07-20 2024-01-25 Dell Products L.P. Equipment tracking for an information handling system

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6886748B1 (en) * 1996-01-02 2005-05-03 Steven Jerome Moore Apparatus and method for purchased product security
US6148291A (en) * 1998-01-26 2000-11-14 K & T Of Lorain, Ltd. Container and inventory monitoring methods and systems
US6053005A (en) * 1999-02-12 2000-04-25 Boitnott; Gregory J. Method of and kit for protecting the integrity of refrigeration systems
US6845909B2 (en) * 2002-10-31 2005-01-25 United Parcel Service Of America, Inc. Systems and methods of inventory management utilizing unattended facilities
US7204421B2 (en) * 2004-10-27 2007-04-17 Symbol Technologies, Inc. Method of identifying and authenticating products using an identification pattern and a bar code reader
US20180096175A1 (en) * 2016-10-01 2018-04-05 James L. Schmeling Blockchain Enabled Packaging
US9741012B2 (en) * 2014-11-05 2017-08-22 HURU Systems Ltd. Systems for secure tracking code generation, application, and verification
WO2017165909A1 (fr) * 2016-03-31 2017-10-05 Tbsx3 Pty Ltd Système d'information permettant de vérifier un article
US12056691B2 (en) * 2016-09-30 2024-08-06 Cable Television Laboratories, Inc. Systems and methods for securely tracking consumable goods using a distributed ledger
US10275739B2 (en) * 2017-01-05 2019-04-30 International Business Machines Corporation Tracking assets with a blockchain

Also Published As

Publication number Publication date
BR112021004110A2 (pt) 2021-05-25
EP3847597A4 (fr) 2022-08-31
WO2020050869A1 (fr) 2020-03-12

Similar Documents

Publication Publication Date Title
US10192198B2 (en) Tracking code generation, application, and verification using blockchain technology
US10868676B2 (en) Computerized apparatus for secure serialization of supply chain product units
AU2022206741B2 (en) Electronic document platform
US20190258991A1 (en) System and methods for querying the distribution path of product units within a supply chain
US9641342B2 (en) Tracking unitization occurring in a supply chain
US10074075B2 (en) Systems for secure tracking code generation, application, and verification
JP6189454B2 (ja) 無認可製品検出技法
US9928479B2 (en) Management tracking identifier format, processing, and data associations
US20190258986A1 (en) Secure distributed supply chain transactional management system
US20160164884A1 (en) Cryptographic verification of provenance in a supply chain
EP3000069B1 (fr) Procédé et système d'authentification de produit
US11210640B2 (en) Blockchain for asset management
EP3847597A1 (fr) Génération, application et vérification de codes de suivi à l'aide de la technologie des chaînes de blocs
Thakur et al. A Comprehensive Study on Block Chain Technology in Supply-Chain Management
CN115293781A (zh) 基于区块链的商品信息处理方法与计算机可读存储介质
Nayak A COMPREHENSIVE STUDY ON BLOCK CHAIN TECHNOLOGY IN SUPPLY-CHAIN MANAGEMENT
CN112333132A (zh) 区块链网络服务平台及其电子验收方法、存储介质

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210331

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/32 20060101ALI20220425BHEP

Ipc: G06Q 10/08 20120101AFI20220425BHEP

A4 Supplementary search report drawn up and despatched

Effective date: 20220802

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/32 20060101ALI20220727BHEP

Ipc: G06Q 10/08 20120101AFI20220727BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20230302