US20200226540A1 - Distributed cryptographic inventory data collection, storage and processing system - Google Patents
Distributed cryptographic inventory data collection, storage and processing system Download PDFInfo
- Publication number
- US20200226540A1 US20200226540A1 US16/737,726 US202016737726A US2020226540A1 US 20200226540 A1 US20200226540 A1 US 20200226540A1 US 202016737726 A US202016737726 A US 202016737726A US 2020226540 A1 US2020226540 A1 US 2020226540A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- block
- address
- creating
- hash function
- 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.)
- Abandoned
Links
Images
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
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
-
- 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
- the technical field of the invention is related to inventory management and tracking systems which preserve details of how inventories are taken of retail store goods.
- Inventory counts of goods in retail locations can be time consuming and error prone.
- a chain of retail stores may have many locations. In the figure this can be represented by location 1, location 2 and location 3. Each of the locations is responsible for reporting inventory to an administrator. The administrator in turn reports to an auditor.
- Each location during an inventory count “freezes” operations for a predetermined period of time. During this time, inventory takers, represented in the figure by persons 1-6 are responsible for counting items in each location.
- Each location can have different types of retail goods located in different areas of each location. This is represented in the figure by departments 1-12.
- each inventory taker is responsible for counting the items in two separate departments.
- Each of the departments can have different types of items and different numbers of items. In the figure, these are represented by items 1-12.
- the inventory takers are responsible for reporting final counts of each item at each location.
- the count for item 1 is four (4) at location 1, three (3) at location 2 and two (2) at location 3.
- the count for item 2 is five (5) at location 1, six (6) at location 2 and seven (7) at location 3.
- the item count for item 3 is eight (8) at location 1, nine (9) at location 2 and ten (10) at location 3.
- the item count for item 4 is one (1) at location 1, zero (0) at location 2 and one (1) at location 3.
- the totals for each item here item 1, nine (9); item 2, eighteen (18); item 3, twenty-seven (27); and item 4, two (2), are reported directly to the administrator.
- the administrator is responsible for reporting to an auditor who certifies the counts of the various items for the inventory process.
- U.S. Pat. No. 10,474,938 to Pigott, et al. discloses a system for cataloging items that are tagged with a unique identifier.
- the tag can be interrogated in order to accomplish an inventory count, by a number of different tag interrogators.
- Information from the interrogators is then recorded in a blockchain ledger which includes the interrogation transactions.
- a computationally disadvantageous agreement between many nodes is required for the Pigott system.
- China Publication No. CN 110503362A to Zhao discloses a warehouse inventory management system using RFID read write devices to perform an inventory and store the results in a traceability center. Inventory results such as start time, end time, video number and video hash code are included in a blockchain certificate to ensure trustworthiness. Theoretical inventory, actual inventory, abnormal inventory and normal inventory can be included in the inventory data.
- the preferred method of cryptographically enforced ordering is through a chained distributed set of cryptographically hashed transactions.
- Each set of hashed transactions is referred to a block.
- Each transaction is linked to the prior transaction hash and the parent transaction hash.
- Each block contains a cryptographic hash of the previous block, a time stamp, and transaction data.
- Chaining of each of the blocks can occur in three ways, a “split”, a “direct inherit” and “join” transaction.
- the cryptographic hash can be a symmetric or asymmetric cypher.
- Each type of cypher provides a single unique and repeatable result for each unique string of input data.
- an asymmetric cypher such as RSA or DES
- a public/private key pair is used to encode and decode information from each of the blocks.
- a symmetric cypher such as a fractal cypher
- the inherent strength of the cryptographic encoding is stronger.
- a single seed key is required to encode and then decode information in each of the blocks.
- the hash function is SHA256.
- the SHA256 hash has the capability of encrypting any number of bytes into a unique string of 256 bytes.
- the SHA256 hash is also useful because the likelihood of a collision resulting in 2 data strings with the same hash value is very (very) low.
- the hash function used can rotate between different hash functions for each successive block in the transaction chain.
- the predetermined hash rotation order is simply reversed during the verification process.
- the final chained set of cryptographically hashed transactions is resistant to modification because it can record transactions between two or more parties efficiently in a verifiable and permanent way. Once recorded, the data at any given block cannot be altered retroactively without alteration of all subsequent blocks.
- chain of transactions permits decentralized processing which increases security and efficiency of the computing system without having the disadvantage of requiring many separate computational nodes to agree on legitimacy of a block before it is added to the chain. Further, chained transaction records are considered computationally secure and exemplify a distributed computing system with a high byzantine fault tolerance.
- Tallying of results can be distributed and collected with verifiable assurance of the ordering and completeness of transactions.
- Auditors armed with genesis and apocalypse block addresses can be certain that the ledger of transactions is unaltered and in original order of processing.
- Inventory totaling process can be certain that no transactions were omitted.
- Auditors or other third parties can be certain no transactions took place before generation of the genesis block or after communication of the apocalypse block.
- Transactions may be collected at a central processing location in any order and at any time while preserving the ability to reproduce the entire counting process in the order it was collected and processed.
- FIG. 1 is a schematic diagram of an invention collection system of the prior art.
- FIG. 2 is an example of an inventory tally sheet of the prior art.
- FIG. 3 is a schematic diagram of a preferred embodiment.
- FIG. 4A is a schematic diagram of an example chained transaction record.
- FIG. 4B is a flowchart of a method to create a chained transaction record.
- FIGS. 5A and 5B are a network flow diagram of a preferred embodiment.
- FIGS. 6A and 6B are a schematic diagram of an example chained transaction record.
- FIG. 7 is a flowchart of a method of transaction chain verification.
- FIGS. 8A and 8B are a flowchart of an alternate method of transaction chain verification.
- Administrator device 302 is connected through a wide area network to audit device 308 . Administrator device 302 is further connected through a local area network to server 304 . Server 304 is connected to database 306 .
- Client counting devices 320 , 322 , 324 , 326 and 328 are connected through a wireless network to server 304 .
- Each of the client counting devices is fitted with an optical reader capable of reading bar codes 351 on each of items 350 .
- Each bar code 351 includes data sufficient to identify each item 350 by description and serial number.
- each of client counting device can comprise a smartphone or dedicated optical reader such as a Zebra TC56 Touch Computer, available from Zebra Technologies Corp.
- Server 304 further comprises an operating system and software capable of executing steps sufficient to carry out purposes of the invention.
- the server is a Dell PowerEdge T640, available from Dell Technologies, Inc. of Round Rock, Tex.
- database 306 is a SQL database programmed to respond to typical queries by server 304 .
- Each client counting device is responsible for generating a series of “transaction blocks” for each inventory count for a particular retail item.
- the transaction blocks are communicated to the server which then assembles them into a transaction table which is transmitted to the administrator.
- the administrator transmits the transaction table to the auditor who can use the table to verify details of the inventory count, as will be further described.
- example 400 of inventory transactions assembled into an ⁇ block will be described.
- a single store has two (2) locations.
- One of these locations has two (2) areas. Both locations and both areas include counts of two (2) separate types of items.
- infinite numbers of variations of hierarchies of stores, areas and items are possible and can be accommodated by the invention, applying a set of novel rules for the transaction blocks, splits and joins, as will be further described.
- the server In this example, the initiation of an audit count, the server generates an ⁇ block which will be further described.
- the ⁇ block is split into two parallel transactions, T 1 and T 7 in order to account for the two separate locations.
- Client counting device 320 receives transaction T 1 and proceeds during the inventory count to generate transaction block T 2 .
- the client counting device generates a split of transaction block T 2 into transaction blocks T 3 and T 5 in order to account for the two separate areas in the first store.
- the client counting device then generates transaction blocks T 4 and T 6 during routine counts of inventory goods.
- the second client counting device receives transaction block T 7 from the server. During routine inventory counts, the second client counting device generates and records transaction blocks T 8 , T 9 and T 10 . These blocks each inherit directly from their immediate predecessor.
- transaction blocks T 4 , T 6 and T 10 are sent to the server where they are joined into the ⁇ transaction block.
- the ⁇ transaction block and a transaction table are then communicated to the auditor. Because every transaction (except the ⁇ block) contains the address of its parent and the address of its prior transaction, it is not possible to alter a transaction's contents or to trace from a block end to a block start if transactions are missing or altered.
- the transaction blocks exhibit conform to the following rules and exhibit the following attributes:
- An “address” is a data string resulting from a known hash of an ordered set of parameters.
- ⁇ Genesis Address—The beginning address and parent of all count data.
- the Genesis Address can be public blockchain address/transaction/hash or some other seed that matches a predetermined hash length and which can be fixed in time. For instance, ⁇ the latest Bitcoin block hash.
- ⁇ Apocalypse Address—The final transaction block address which once communicated to a third party, all can be assured no transactions can be subsequently modified, added, or removed within the chain.
- f # A cryptographic hash function (SHA256 for example)
- T ⁇ A pb ,A pt ,t,B name ,I name ,Q ⁇
- Additional data can be included in the transaction, timestamps for instance.
- Each transaction address is the result of the hash function upon its' transaction contents.
- a i f # ⁇ T i ⁇ A pb ,A pt ,t,B name ,I name ,Q ⁇
- Every transaction must have a parent block address (A pb ) and a prior transaction address (A pt ).
- An ⁇ transaction is always a BS transaction.
- the parent of a BS transaction is always a BS transaction
- the parent of a BE transaction is always a BS transaction.
- the parent of an IA transaction is always a BS transaction.
- the parent of a CJ transaction is always a BE transaction.
- CJ transactions are performed to the longest transaction chain within parent block.
- a ⁇ transaction is always a CJ transaction.
- Any given transaction address (A i ) must have a continuous chain of prior transaction addresses back to the ⁇ transaction address.
- Any given transaction address (A i ) must have a continuous chain of parent transaction addresses back to the ⁇ transaction address and from the ⁇ transaction address back to A i .
- the predetermined number is 3.
- a chain join transaction is used to denote that a block end (BE) transaction has been received and processed by the server.
- the CJ transaction has the effect of closing an open side transaction chain back to the main chain and ultimately the ⁇ block.
- the server When the server creates the CJ transaction, it is indelibly tying the side chain to the main chain. If the client process or some bad actor were to subsequently create new transactions or blocks (ostensibly for inclusion in the block which it has already closed) it would not be possible to trace from the ⁇ block to this orphaned transaction or block and therefore it could not be included in the count.
- an ⁇ block address transaction is created, as previously described.
- step 454 block start transaction is created, as previously described.
- step 456 a decision is made as to whether or not the number of stores is greater than one. If not, the method moves to step 458 , if so the method moves to step 468 .
- step 458 a decision is made as to whether or not the number of areas in the store is greater than one. If not, the method moves to step 459 . If so, the method moves to step 477 . At step 477 , a block start transaction is created for area 2 and store 1.
- step 459 block start transaction is created for area 1, store 1.
- step 460 an add item transaction is created.
- step 462 a decision is made as to whether or not all items have been counted. If not, the method returns to step 460 . If so, the method moves to step 464 .
- a block end transaction is created.
- an ⁇ block is created with a chain join transaction.
- step 468 if the number of stores is greater than one, then a store 2 block start transaction is created.
- step 470 the additional areas are created.
- block start transactions for those areas are created, as previously described.
- step 472 for each area, add item transactions are created, as previously described.
- step 474 block end transactions are created for each item count and for each area, as previously described.
- step 476 a chain join transaction is created and the method returns to step 464 .
- step 478 add item count transaction is created.
- step 480 block end transactions are created.
- step 482 chain join transactions are created and the method returns to step 464 .
- ⁇ can be a random seed of defined length that was not known to any parties prior to count start. Alternatively, it can be the most recent bitcoin blockchain hash at the start of count.
- Each transaction address is a hash value based on an input that includes its parent and prior transaction addresses.
- a 1 f # ( A ⁇ ,A ⁇ ,BS,“Store1”,NULL,NULL)
- a 2 f # ( A 1, A 1,BS,“Area1”,NULL,NULL)
- a 1 f # ( A 2, A 2,IA,NULL,“ UPCXXXXXX ”,1)
- a 4 f # ( A 2, A 3,IA,NULL,“ UPCYYYYYYY ”,1)
- a 5 f # ( A 2, A 4,IA,BE,NULL,NULL)
- System 500 comprises administrative device 502 , server 504 and client counting device 506 .
- administrative device 502 is a smart device or PC
- client counting device 506 is a handheld mobile computing device, such as a cellphone or a wireless handheld barcode scanner.
- Administrative device 502 , client counting device 506 , and server 504 are each connected to the internet.
- the administrative device receives a request for a new count.
- the request is transmitted to server 504 .
- server 504 generates an ⁇ block start transaction and creates an active transaction table in the database.
- a single hash function is used to create all address blocks.
- the hash function is one of the SHA256, MD5, RIPEMD256, WHIRLPOOL, TIGER(192) and GOST(256) cyphers.
- a rotating series of hash functions may be used. In this case, different hash functions are used in a predetermined order to encrypt successive blocks.
- the preferred set of rotating hashes is an ordered application of the SHA256, MD5, RIPEMD256, WHIRLPOOL, TIGER(192) and GOST(256) cyphers. Other ordered sets of these and other cyphers may be used advantageously in other embodiments.
- the server pushes the ⁇ block transaction to the active transaction table.
- the server stores the ⁇ block address in the database.
- any block over a communications channel before transmission of any block over a communications channel, it may be encrypted with either a symmetric cypher using a seed key, or an asymmetric cypher, using a public key.
- An example of useful symmetric cypher is a fractal cypher.
- An example of a useful asymmetric cypher is DES.
- the block is decoded by the receiving node before verification by applying the appropriate seed key (for a symmetric cypher) or private key (for an asymmetric cypher).
- step 517 administrative device 502 receives the desired store, department, and area hierarchy.
- step 518 the administrative device transmits the desired store, department, and area hierarchy to server 504 .
- the server generates one or more child block start transactions.
- the server pushes the child block start transactions to the active transaction table.
- server 504 stores the child block transaction addresses in the database.
- client counting device 506 continuously polls server 504 for a count start flag status until it receives a “true” result.
- server 504 will set the count started flag status to “true” upon start of the inventory freeze period.
- client counting device 506 will prompt the user for the hierarchical location.
- the client counting device will receive the hierarchal location input such as store and department. At this step, the identity of the inventory taker is also received.
- the client counting device transmits a request for the corresponding parent block address to the server.
- server 504 will determine the corresponding parent block address.
- the server transmits the corresponding parent block address to the client counting device.
- the client counting device will prompt the user for an area identifier.
- the client counting device receives the area identifier.
- client counting device 506 creates a child block start transaction.
- the child block start transaction is transmitted to the server.
- the server pushes the transaction to the active transaction table.
- client counting device 506 prompts the user for item name and quantity input.
- the client counting device receives the item name and quantity input.
- the item name and quantity can be manually entered, or a client counting device can optically scan a barcode, such as a UPC or QR code, which will auto-populate the item name and an editable quantity count of one (1).
- the client device creates an “item add” transaction.
- the item add transaction is transmitted to the server.
- server 504 pushes the transaction to the transaction table.
- client counting device 506 will prompt the user for a next action.
- the user may select to input a new item name and quantity.
- the available options may consist of entering an additional item name and quantity or end the count. If the client counting device receives a new item name and quantity at step 562 , then the client counting device will repeat steps 554 , 556 , and 558 for each additional item name/quantity input until the area count is complete.
- client counting device 506 receives a close area selection, which will end the area count.
- the client counting device will create a block end transaction.
- the block end transaction is sent to the server.
- Steps 570 , 572 , and 574 comprise the chain join function steps.
- the server will look up the corresponding block start transaction, or parent block.
- each child transaction in turn, is selected from the transaction table.
- server 504 will validate the block. If the block is valid, then the block is chained to the block start (parent block). If server 504 encounters a nested block end transaction, then it calls the chain join function to run for that specific block.
- the server creates a CJ transaction to pin the block to a processing chain.
- the CJ transaction is marked as the most recent transaction replacing the previous transaction.
- server 504 generates an ⁇ block.
- the server transmits a status report.
- the administrative device logs the status.
- FIGS. 6A and 6B an example ledger transaction produced by the invention during an inventory count will be described.
- Block 602 collects the latest block hash from a public blockchain or Audit Firm provides the address. This unique string (A, ⁇ ) is agreed between XYZ, Audit Firm, & Counting Co. as the “count genesis.” Because the count genesis information is not known before the beginning of the count process, it is certain that no transactions were collected early.
- Block 602 is generated according to the format:
- Counting Co. then creates two block start transactions 604 and 606 , one for the east location, and another for the west location.
- the address of these blocks are provided to Counting Co. staff at their respective locations. These blocks are generated according to the format:
- a 1 f # ( A ⁇ ,A ⁇ ,BS,“East”,NULL,NULL)
- a 13 f # ( A ⁇ ,A ⁇ ,BS,“West”,NULL,NULL)
- the parent block of block 604 as indicated by arrow 659 is block 602 .
- the prior block of block 604 is block 602 as indicated by arrow 660 .
- the parent block, as indicated by arrow 680 of block 606 is block 602 .
- the prior block of block 606 as indicated by arrow 681 is block 602 .
- Counting Co. staff at each location use newly created blocks 604 and 606 to begin the count in the floor stock locations, thereby resulting in blocks 608 and 630 as follows:
- a 2 f # ( A 1, A 1,BS,“Floor”,NULL,NULL)
- a 14 f # ( A 13, A 13,BS,“Floor”,NULL,NULL)
- the parent block of block 608 as indicated by arrow 662 is block 604 .
- the prior block of block 608 is block 604 as indicated by arrow 663 .
- the parent block of block 630 is block 606 as indicated by arrow 684 .
- the prior block of block 630 is block 606 as indicated by arrow 683 .
- a 3 f # ( A 2, A 2,IA,NULL,“Zag”,2)
- a 6 f # ( A 2, A 3,IA,NULL,“Zig”,3)
- the parent block of block 610 is block 608 as indicated by arrow 668 .
- the prior block of block 610 is block 608 as indicated by arrow 669 .
- the parent block of block 612 is block 608 as indicated by arrow 667 .
- the prior block of block 612 is block 610 as indicated by arrow 670 .
- Counting Co. sends Audit Firm the latest count (3 zigs and 2 zags) along with the most recent block address. Counting Co. also sends all of their most recent transactions back to XYZ in the form of a transaction table, as will be further described.
- a 4 f # ( A 1, A 1,BS,“Back”,NULL,NULL)
- a 5 f # ( A 4, A 4,IA,NULL,“Zag”,2)
- the parent block of block 614 is block 604 as indicated by arrow 665 .
- the prior block of block 614 is block 604 as indicated by arrow 664 .
- the parent block of block 616 is block 614 as indicated by arrow 627 .
- the prior block of block 616 is block 614 as indicated by arrow 625 .
- the parent block of block 618 is block 614 as indicated by arrow 679 .
- the prior block of block 618 is block 616 as indicated by arrow 629 .
- Counting Co. East staff are finished with this location. They close and join their blocks and transmit the remaining transactions to Counting Co., forming blocks 620 , 622 , 624 , 626 and 628 as follows:
- a 7 f # ( A 2, A 6,BE,NULL,NULL,NULL)
- a 8 f # ( A 7, A 7,CJ,NULL,NULL,NULL)
- a 10 f # ( A 4, A 9,BE,NULL,NULL,NULL)
- a 11 f # ( A 10, A 8,CJ,NULL,NULL,NULL)
- a 12 f # ( A 1, A 11,BE,NULL,NULL,NULL)
- the parent block of block 620 is block 608 as indicated by arrow 666 .
- the prior block of block 620 is block 612 as indicated by arrow 672 .
- the parent block of block 622 is block 620 as indicated by arrow 673 .
- the prior block of block 622 is block 620 as indicated by arrow 674 .
- the parent block of block 624 is block 628 as indicated by arrow 677 .
- the prior block of block 624 is block 622 as indicated by arrow 675 .
- the parent block of block 626 is block 604 as indicated 661 .
- the prior block of block 626 is block 624 as indicated by arrow 676 .
- the parent block of block 628 is block 614 as indicated by arrow 678 .
- the prior block of block 628 is block 618 as indicated by arrow 631 .
- Counting Co. staff in the west have performed their count. For convenience it is assumed that the same results as East location. They close and join their blocks and transmit to Counting Co., forming blocks 630 , 632 , 634 , 636 , 638 , 640 , 642 , 644 , 646 , 648 and 650 , as follows:
- a 14 f # ( A 13, A 13,BS,“Floor”,NULL,NULL)
- a 15 f # ( A 14, A 14,IA,NULL,“Zag”,2)
- a 16 f # ( A 14, A 15,IA,NULL,“Zig”,3)
- a 17 f # ( A 14, A 16,BE,NULL,NULL,NULL)
- a 18 f # ( A 17, A 17,CJ,NULL,NULL,NULL)
- a 19 f # ( A 13, A 18,BS,“Back”,NULL,NULL)
- a 20 f # ( A 19, A 19,IA,NULL,“Zag”,2)
- a 21 f #( A 19, A 20,IA,NULL,“Zig”,1)
- a 22 f # ( A 19, A 21,BE,NULL,NULL,NULL)
- a 23 f # ( A 22, A 22,CJ,NULL,NULL,NULL)
- a 24 f # ( A 13, A 23,BE,NULL,NULL,NULL)
- the parent block of block 630 is block 606 as indicated by arrow 684 .
- the prior block of block 630 is block 606 as indicated by arrow 683 .
- the parent block of block 632 is block 630 as indicated by arrow 688 .
- the prior block of block 632 is block 630 as indicated by arrow 689 .
- the parent block of block 634 is block 630 as indicated by arrow 687 .
- the prior block of block 634 is block 632 as indicated by arrow 690 .
- the parent block of block 636 is block 630 as indicated by arrow 686 .
- the prior block of block 636 is block 634 as indicated by arrow 691 .
- the parent block of block 638 is block 636 as indicated by arrow 692 .
- the prior block of block 638 is block 636 as indicated by arrow 693 .
- the parent block of block 640 is block 606 as indicated by arrow 685 .
- the prior block of block 640 is block 638 as indicated by arrow 694 .
- the parent block of block 642 is block 640 as indicated by arrow 697 .
- the prior block of block 642 is block 640 as indicated by arrow 698 .
- the parent block of block 644 is block 640 as indicated by arrow 696 .
- the prior block of block 644 is block 642 as indicated by arrow 699 .
- the parent block of block 646 is block 640 as indicated by arrow 695 .
- the prior block of block 646 is block 644 as indicated by arrow 603 .
- the parent block of block 648 is block 646 as indicated by arrow 605 .
- the prior block of block 648 is block 646 as indicated by arrow 607 .
- the parent block of block 650 is block 606 as indicated by arrow 615 .
- the prior block of block 650 is block 648 as indicated by arrow 609 .
- Counting Co notes the receipt of the block end transactions for each location. Counting Co. traces the transactions received from a to the block end, (as will be further described) confirming count results, and perform the chain joins, resulting in blocks 652 , 654 and 656 , as follows:
- a 25 f # ( A 24, A 24,CJ,NULL,NULL,NULL)
- a 26 f # ( A 12, A 25,CJ,NULL,NULL,NULL)
- a 27 f # ( A ⁇ ,A 26,BE,NULL,NULL,NULL)
- the parent block of block 652 is block 650 is indicated by arrow 613 .
- the prior block of block 652 is block 650 as indicated by arrow 611 .
- the parent block of block 654 is block 626 as indicated by arrow 651 .
- the prior block of block 654 is block 652 as indicated by arrow 617 .
- the parent block of block 656 is block 602 as indicated by arrow 682 .
- the prior block of block 656 is block 654 as indicated by arrow 619 .
- Counting Co. verifies there are no open blocks to indicate ongoing counts and performs a final chain join. Counting Co. provides the ending address (A ⁇ ) to XYZ and to Audit Firm, resulting in block 658 , as follows:
- the parent block of block 658 is block 656 as indicated by arrow 621 .
- the prior block of block 658 is block 656 as indicated by arrow 623 .
- a transaction table for the preceding example is as follows:
- Counting Co. provides the transaction table and the hash function to Audit Firm and XYZ.
- the transaction table may be used to verify the count.
- each transaction address is the hash of its contents. These contents include its prior and parent transaction addresses.
- the address contained in one transaction is used to “lookup” the corresponding parent or prior transaction address. If the hash value of the transaction matches the address of the current transaction, then the current transaction is unaltered and so is valid.
- the transaction table is only valid if the addresses can be traced from the ⁇ block to the ⁇ block with an addresses valid.
- valid CJ transactions must have a valid BE transaction as parent and have valid BE or CJ as prior transaction.
- BE transactions must have a valid block start (BS) as parent transaction and have a traceable prior transaction path to their parent block start (BS) transaction.
- BS block start
- BS block start
- Valid Block Start (BS) transactions must have a valid block start (BS) or Alpha block as parent transaction and have a traceable prior transaction path to their parent block start (BS) transaction.
- Valid Item Add (IA) transactions must have a valid block start (BS) as parent transaction and have a traceable prior transaction path to their parent block start (BS) transaction.
- the method begins.
- the current transaction in the transaction table is identified. For example, and in most cases, the current transaction chosen is the ⁇ block.
- the transaction prior to the current transaction is identified in the transaction table.
- the hash function is applied to the A parent , A prior , T type , block name, item name, and quantity fields from the prior transaction block in the transaction table. If the hash function is a rotating hash, then the predetermined hash order is reversed to determine which hash function to use to decode the prior transaction.
- the A prior field is identified from the current transaction in the transaction table.
- step 712 the A prior value from the current block is compared to the A prior value from the prior block. If the addresses match, then the method moves to step 716 . If the addresses do not match, then the method moves to step 714 .
- the current transaction block is identified as valid and the method moves to step 722 .
- a decision is made whether or not the current transaction being validated is the Alpha block. If not, the method returns to step 704 where a new current transaction is identified. If so, the method moves to step 724 .
- the transaction table is validated.
- the method returns.
- the current transaction block is set as invalid.
- the transaction table is declared invalid. The method then returns at step 726 .
- method 800 an alternate method 800 of validating a transaction table will be described as method 800 .
- step 801 the method begins.
- step 802 all transactions must be confirmed as unaltered by comparing each transaction address to the SHA256 hash of its payload, according to the following steps:
- step 804 it must be verified whether or not each transaction has a valid prior transaction chain to the ⁇ block, according to the following steps:
- step 806 it must be verified that each transaction has a valid parent transaction chain back to the ⁇ block according to the following steps:
- step 808 it must be confirmed that the transactions are connected to the ⁇ block by ensuring they are included in a chain which is chain joined to the ⁇ block, if they are, any items in the chain may be counted.
- step 809 the user provides an address of a block in the transaction chain.
- the block is examined to determine whether or not it is a CJ transaction. If not, the method moves to step 811 . If so, the method moves to step 812 .
- step 811 an error is declared and the process ends.
- the process looks up the prior block address.
- the process decides whether or not the block at the prior address is a BE transaction. If so, the method moves to step 814 and ignores the transaction. If not, the method moves to step 815 .
- the method marks the block as counted and looks up the parent address.
- the process decides whether or not the block at the parent address is a BE transaction. If not, the method moves to step 818 and concludes. If so, the method moves to step 820 .
- step 820 the block is marked as counted and the method looks up the block with the prior address.
- the method decides whether or not this block is IA transaction. If so, the method moves to step 824 . If not, the method moves to step 828 . At step 824 , the block is marked as counted and the items are added to the inventory count. At step 826 , the method looks up the prior transaction block and returns to step 822 .
- step 828 the process decides whether or not the transaction block is a BS transaction. If so, the method moves to step 830 . If not, the method moves to step 834 . At step 834 , the process decides whether or not it is a CJ transaction. If so, the method returns to step 810 . If not, the method moves to step 836 and an error is produced.
- the process marks the block as counted and looks up the address of the prior block.
- step 832 the process decides whether or not the prior block is a CJ transaction or not. If so, the method returns to step 810 . If not, the method moves to step 838 .
- step 838 the process decides whether or not the current block is a BS transaction. If so, the method moves to step 840 and returns. If not, the method moves to step 842 .
- step 842 the method decides whether or not the block is a BE transaction. If not, the method moves to step 844 and concludes. If so, the method returns to step 816 .
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Economics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Human Resources & Organizations (AREA)
- Quality & Reliability (AREA)
- Finance (AREA)
- Entrepreneurship & Innovation (AREA)
- Accounting & Taxation (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Development Economics (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Power Engineering (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- This application claims priority benefit from U.S. Provisional Application No. 62/789,747, filed on Jan. 8, 2019. The patent application identified above is incorporated here by reference in its entirety to provide continuity of disclosure.
- The technical field of the invention is related to inventory management and tracking systems which preserve details of how inventories are taken of retail store goods.
- Inventory counts of goods in retail locations can be time consuming and error prone. For example, referring to
FIG. 1 , a chain of retail stores may have many locations. In the figure this can be represented bylocation 1,location 2 andlocation 3. Each of the locations is responsible for reporting inventory to an administrator. The administrator in turn reports to an auditor. - Each location during an inventory count “freezes” operations for a predetermined period of time. During this time, inventory takers, represented in the figure by persons 1-6 are responsible for counting items in each location.
- Each location can have different types of retail goods located in different areas of each location. This is represented in the figure by departments 1-12. In this figure, each inventory taker is responsible for counting the items in two separate departments. Each of the departments can have different types of items and different numbers of items. In the figure, these are represented by items 1-12.
- Referring to
FIG. 2 , the inventory takers are responsible for reporting final counts of each item at each location. In this example, the count foritem 1 is four (4) atlocation 1, three (3) atlocation 2 and two (2) atlocation 3. The count foritem 2 is five (5) atlocation 1, six (6) atlocation 2 and seven (7) atlocation 3. The item count foritem 3 is eight (8) atlocation 1, nine (9) atlocation 2 and ten (10) atlocation 3. The item count foritem 4 is one (1) atlocation 1, zero (0) atlocation 2 and one (1) atlocation 3. During the inventory count the totals for each item, hereitem 1, nine (9);item 2, eighteen (18);item 3, twenty-seven (27); anditem 4, two (2), are reported directly to the administrator. The administrator, in turn, is responsible for reporting to an auditor who certifies the counts of the various items for the inventory process. - One of the main problems with the prior art inventory counting methods and systems is that traceability of who took the count, when the count was taken and where the count was taken are lost in the reporting process. For example, existing inventory systems generally require several handheld scanners that are wirelessly connected to a base unit. An example, is the SD62 wireless base station by Honeywell International Inc. When an inventory count is done, the handheld units are capable of only reading bar codes and inventory “counts” of various inventory items. In reporting final counts, the units are technically incapable of organizing or encrypting data related to the inventory count. This is a technical problem because data related where the items are located and when the item count was taken is lost in the final count total. In this example, the administrator may report that there are twenty-seven (27) of
item 3 existing in inventory. However, upon audit, the total number may be different. Neither the administrator nor the auditor can determine which location is short from the total amount reported. Similarly, neither the administrator nor the auditor can determine when the error occurred, or which inventory taker was responsible for the error. - In order for an audit to be complete, traceability is required. For adequate traceability, it is necessary to be certain of the:
-
- order of collection of transactions within locations;
- order of processing of transactions into the total counts;
- that none of the transactions have been tampered with;
- that none of the transactions are missing;
- that all the transactions took place within a fixed timeframe; and,
- ability to verify and reproduce inventory subtotals, inventory taken, identity and item location details.
- The prior art has provided various attempts to solve some of the problems of inventory tracking, with limited success.
- U.S. Pat. No. 10,474,938 to Pigott, et al. discloses a system for cataloging items that are tagged with a unique identifier. The tag can be interrogated in order to accomplish an inventory count, by a number of different tag interrogators. Information from the interrogators is then recorded in a blockchain ledger which includes the interrogation transactions. A computationally disadvantageous agreement between many nodes is required for the Pigott system.
- In “A UAV and Blockchain Based System for Industry 4.0 Inventory and Traceability Applications”, by Fernández-Caramés discloses use of unmanned aerial vehicle to automate inventory in a warehouse environment. Inventory data from the UAV is incorporated into a blockchain to ensure trustworthiness.
- China Publication No. CN 110503362A to Zhao, discloses a warehouse inventory management system using RFID read write devices to perform an inventory and store the results in a traceability center. Inventory results such as start time, end time, video number and video hash code are included in a blockchain certificate to ensure trustworthiness. Theoretical inventory, actual inventory, abnormal inventory and normal inventory can be included in the inventory data.
- U. S. Publication No. 2018/0144292 to Mattingly, et al. discloses a system which detects changes in inventory (like food) in a retail location and then records those changes in a blockchain.
- However, as can be seen, the prior art does not provide for a traceability system which include details of how the inventory was taken nor does it provide for trustworthiness of this detailed data without the requirement of a computational agreement between multiple computational nodes.
- The preferred method of cryptographically enforced ordering is through a chained distributed set of cryptographically hashed transactions. Each set of hashed transactions is referred to a block. Each transaction is linked to the prior transaction hash and the parent transaction hash. Each block contains a cryptographic hash of the previous block, a time stamp, and transaction data.
- Chaining of each of the blocks can occur in three ways, a “split”, a “direct inherit” and “join” transaction.
- The cryptographic hash can be a symmetric or asymmetric cypher. Each type of cypher provides a single unique and repeatable result for each unique string of input data. In the case of an asymmetric cypher, such as RSA or DES, a public/private key pair is used to encode and decode information from each of the blocks. In the case of a symmetric cypher, such as a fractal cypher, the inherent strength of the cryptographic encoding is stronger. For a symmetric cypher, a single seed key is required to encode and then decode information in each of the blocks.
- In a preferred embodiment, the hash function is SHA256. The SHA256 hash has the capability of encrypting any number of bytes into a unique string of 256 bytes. The SHA256 hash is also useful because the likelihood of a collision resulting in 2 data strings with the same hash value is very (very) low.
- In another embodiment, the hash function used can rotate between different hash functions for each successive block in the transaction chain. The predetermined hash rotation order is simply reversed during the verification process.
- The final chained set of cryptographically hashed transactions is resistant to modification because it can record transactions between two or more parties efficiently in a verifiable and permanent way. Once recorded, the data at any given block cannot be altered retroactively without alteration of all subsequent blocks.
- This chain of transactions permits decentralized processing which increases security and efficiency of the computing system without having the disadvantage of requiring many separate computational nodes to agree on legitimacy of a block before it is added to the chain. Further, chained transaction records are considered computationally secure and exemplify a distributed computing system with a high byzantine fault tolerance.
- Tallying of results can be distributed and collected with verifiable assurance of the ordering and completeness of transactions.
- The ordering of transactions collected within blocks and the order of subtotaling is preserved and verifiable by a third party.
- Auditors armed with genesis and apocalypse block addresses can be certain that the ledger of transactions is unaltered and in original order of processing.
- Inventory totaling process can be certain that no transactions were omitted.
- Auditors or other third parties can be certain no transactions took place before generation of the genesis block or after communication of the apocalypse block.
- Transactions may be collected at a central processing location in any order and at any time while preserving the ability to reproduce the entire counting process in the order it was collected and processed.
- In the detailed description of the preferred embodiments presented below, reference is made to the accompanying drawings.
-
FIG. 1 is a schematic diagram of an invention collection system of the prior art. -
FIG. 2 is an example of an inventory tally sheet of the prior art. -
FIG. 3 is a schematic diagram of a preferred embodiment. -
FIG. 4A is a schematic diagram of an example chained transaction record. -
FIG. 4B is a flowchart of a method to create a chained transaction record. -
FIGS. 5A and 5B are a network flow diagram of a preferred embodiment. -
FIGS. 6A and 6B are a schematic diagram of an example chained transaction record. -
FIG. 7 is a flowchart of a method of transaction chain verification. -
FIGS. 8A and 8B are a flowchart of an alternate method of transaction chain verification. - Referring to
FIG. 3 , exemplary architecture diagram 300 of a preferred embodiment will be described.Administrator device 302 is connected through a wide area network to auditdevice 308.Administrator device 302 is further connected through a local area network toserver 304.Server 304 is connected todatabase 306. -
Client counting devices server 304. Each of the client counting devices is fitted with an optical reader capable of readingbar codes 351 on each ofitems 350. Eachbar code 351 includes data sufficient to identify eachitem 350 by description and serial number. In a preferred embodiment, each of client counting device can comprise a smartphone or dedicated optical reader such as a Zebra TC56 Touch Computer, available from Zebra Technologies Corp. -
Server 304 further comprises an operating system and software capable of executing steps sufficient to carry out purposes of the invention. For example, in a preferred embodiment the server is a Dell PowerEdge T640, available from Dell Technologies, Inc. of Round Rock, Tex. - All software in the preferred embodiment is written in C, Python or C++. Of course, other languages will suffice.
- In a preferred embodiment,
database 306 is a SQL database programmed to respond to typical queries byserver 304. - Each client counting device is responsible for generating a series of “transaction blocks” for each inventory count for a particular retail item. The transaction blocks are communicated to the server which then assembles them into a transaction table which is transmitted to the administrator. The administrator transmits the transaction table to the auditor who can use the table to verify details of the inventory count, as will be further described.
- Referring to
FIG. 4A , example 400 of inventory transactions assembled into an Ω block will be described. In this hierarchy example, a single store has two (2) locations. One of these locations has two (2) areas. Both locations and both areas include counts of two (2) separate types of items. However, infinite numbers of variations of hierarchies of stores, areas and items are possible and can be accommodated by the invention, applying a set of novel rules for the transaction blocks, splits and joins, as will be further described. - In this example, the initiation of an audit count, the server generates an α block which will be further described. The α block is split into two parallel transactions, T1 and T7 in order to account for the two separate locations.
Client counting device 320 receives transaction T1 and proceeds during the inventory count to generate transaction block T2. The client counting device generates a split of transaction block T2 into transaction blocks T3 and T5 in order to account for the two separate areas in the first store. The client counting device then generates transaction blocks T4 and T6 during routine counts of inventory goods. - The second client counting device receives transaction block T7 from the server. During routine inventory counts, the second client counting device generates and records transaction blocks T8, T9 and T10. These blocks each inherit directly from their immediate predecessor.
- At the conclusion of the inventory count, transaction blocks T4, T6 and T10 are sent to the server where they are joined into the Ω transaction block. The Ω transaction block and a transaction table are then communicated to the auditor. Because every transaction (except the α block) contains the address of its parent and the address of its prior transaction, it is not possible to alter a transaction's contents or to trace from a block end to a block start if transactions are missing or altered.
- The transaction blocks exhibit conform to the following rules and exhibit the following attributes:
- An “address” is a data string resulting from a known hash of an ordered set of parameters.
- α=Genesis Address—The beginning address and parent of all count data. The Genesis Address can be public blockchain address/transaction/hash or some other seed that matches a predetermined hash length and which can be fixed in time. For instance, β the latest Bitcoin block hash.
- Ω=Apocalypse Address—The final transaction block address which once communicated to a third party, all can be assured no transactions can be subsequently modified, added, or removed within the chain.
- f#=A cryptographic hash function (SHA256 for example)
- A=Block address (the result of cryptographic hash function)
- T=Transaction
- Transactions contain (at minimum):
-
- Apb=Parent block address
- Apt=Prior transaction address
- t=Transaction Type which (at minimum) consist of:
- BS=Denotes a block start transaction
- BE=Denotes a block end transaction
- CJ=Denotes block join transaction to parent chain
- IA=Denotes an item “addition” transaction
- Bname=Block Name/Identifier (any desired identifier string) (May be NULL)
- Iname=Item Name/Identifier (any desired identifier string) (May be NULL)
- Q=Quantity (any real number −∞ to +∞) (May be NULL).
- Transactions (T) take the form:
-
T={A pb ,A pt ,t,B name ,I name ,Q} - Additional data can be included in the transaction, timestamps for instance.
- B=Valid Block consisting of:
-
- A block start transaction (BS) (Required)
- Zero or more item transactions (IA)
- Zero or more valid child blocks (Bchild)
- A block end transaction (BE) (Required)
- A block join transaction (BJ) (Required).
- Each transaction address is the result of the hash function upon its' transaction contents.
- Transaction addresses are created as follows:
-
A i =f #{ T i {A pb ,A pt ,t,B name ,I name ,Q}} - Every transaction must have a parent block address (Apb) and a prior transaction address (Apt).
- An α transaction is always a BS transaction.
- The parent of a BS transaction is always a BS transaction
- The parent of a BE transaction is always a BS transaction.
- The parent of an IA transaction is always a BS transaction.
- The parent of a CJ transaction is always a BE transaction.
- CJ transactions are performed to the longest transaction chain within parent block.
- CJ transactions must always have a BE or CJ as their prior transaction.
- A Ω transaction is always a CJ transaction.
- Any given transaction address (Ai) must have a continuous chain of prior transaction addresses back to the α transaction address.
- Any given transaction address (Ai) must have a continuous chain of parent transaction addresses back to the α transaction address and from the Ω transaction address back to Ai.
- Additional transaction types and data payloads can be added to this fundamental list within any predetermined number blocks to provide flexibility in logging the count activities and to benefit from the immutable ordering and recording of transactions. In a preferred embodiment, the predetermined number is 3.
- A chain join transaction (CJ) is used to denote that a block end (BE) transaction has been received and processed by the server. The CJ transaction has the effect of closing an open side transaction chain back to the main chain and ultimately the Ω block.
- When a client sends a BE transaction it is denoting that there are no further transactions to be included in this block.
- When the server creates the CJ transaction, it is indelibly tying the side chain to the main chain. If the client process or some bad actor were to subsequently create new transactions or blocks (ostensibly for inclusion in the block which it has already closed) it would not be possible to trace from the Ω block to this orphaned transaction or block and therefore it could not be included in the count.
- Referring to
FIG. 4B ,method 450 of creating a series of inventory transactions will be described. - At
step 452, an α block address transaction is created, as previously described. - At
step 454, block start transaction is created, as previously described. - At
step 456, a decision is made as to whether or not the number of stores is greater than one. If not, the method moves to step 458, if so the method moves to step 468. - At
step 458, a decision is made as to whether or not the number of areas in the store is greater than one. If not, the method moves to step 459. If so, the method moves to step 477. Atstep 477, a block start transaction is created forarea 2 andstore 1. - At
step 459, block start transaction is created forarea 1,store 1. - At
step 460, an add item transaction is created. Atstep 462, a decision is made as to whether or not all items have been counted. If not, the method returns to step 460. If so, the method moves to step 464. - At
step 464, a block end transaction is created. Atstep 466, an Ω block is created with a chain join transaction. - Returning to step 468, if the number of stores is greater than one, then a
store 2 block start transaction is created. Atstep 470, the additional areas are created. Atstep 470, if additional areas are created, block start transactions for those areas are created, as previously described. - At
step 472, for each area, add item transactions are created, as previously described. - At
step 474, block end transactions are created for each item count and for each area, as previously described. Atstep 476, a chain join transaction is created and the method returns to step 464. - Returning to step 458, if the number of areas in the store is greater than one, then at
step 478, add item count transaction is created. Atstep 480, block end transactions are created. Atstep 482, chain join transactions are created and the method returns to step 464. - A simple example of a transaction chain is next described.
- First, an α block address is created. α can be a random seed of defined length that was not known to any parties prior to count start. Alternatively, it can be the most recent bitcoin blockchain hash at the start of count.
-
Aα=f #(α,α,BS,“Count1”,NULL,NULL) - Second, the address for the block start transaction representing store one is created. In this case, both the parent and prior transaction addresses are the same (alpha block).
- The α block address (created above) is incorporated into the hash for the A1 address. Hence, the transactions are “linked.” Each transaction address is a hash value based on an input that includes its parent and prior transaction addresses.
-
A1=f #(Aα,Aα,BS,“Store1”,NULL,NULL) - Next, the transaction address for the block
start representing area 1 instore 1 is created. -
A2=f #(A1,A1,BS,“Area1”,NULL,NULL) - Next, the transaction address representing the addition of
quantity 1 of item UPCXXXXXXXX toarea 1 is created. -
A1=f #(A2,A2,IA,NULL,“UPCXXXXXXXX”,1) - Next, another item is added to the count. Note the difference in parent and prior block addresses. This is how the ledger is imbued with hierarchy.
-
A4=f #(A2,A3,IA,NULL,“UPCYYYYYYYY”,1) - Next, the block for
area 1 is ended. -
A5=f #(A2,A4,IA,BE,NULL,NULL) - Referring to
FIGS. 5A and 5B , a network communications diagram of a preferred embodiment of the system for processing inventory data is described.System 500 comprisesadministrative device 502,server 504 andclient counting device 506. - In a preferred embodiment,
administrative device 502 is a smart device or PC, andclient counting device 506, is a handheld mobile computing device, such as a cellphone or a wireless handheld barcode scanner.Administrative device 502,client counting device 506, andserver 504 are each connected to the internet. - Referring then to
FIG. 5A , atstep 510, the administrative device receives a request for a new count. Instep 511, the request is transmitted toserver 504. Atstep 512,server 504 generates an α block start transaction and creates an active transaction table in the database. - In a preferred embodiment, a single hash function is used to create all address blocks. Preferably the hash function is one of the SHA256, MD5, RIPEMD256, WHIRLPOOL, TIGER(192) and GOST(256) cyphers. However, in alternate embodiments, a rotating series of hash functions may be used. In this case, different hash functions are used in a predetermined order to encrypt successive blocks. The preferred set of rotating hashes is an ordered application of the SHA256, MD5, RIPEMD256, WHIRLPOOL, TIGER(192) and GOST(256) cyphers. Other ordered sets of these and other cyphers may be used advantageously in other embodiments.
- At
step 514, the server pushes the α block transaction to the active transaction table. Atstep 516, the server stores the α block address in the database. - In an alternate embodiment, before transmission of any block over a communications channel, it may be encrypted with either a symmetric cypher using a seed key, or an asymmetric cypher, using a public key. An example of useful symmetric cypher is a fractal cypher. An example of a useful asymmetric cypher is DES. In this embodiment, the block is decoded by the receiving node before verification by applying the appropriate seed key (for a symmetric cypher) or private key (for an asymmetric cypher).
- At
step 517,administrative device 502 receives the desired store, department, and area hierarchy. Instep 518, the administrative device transmits the desired store, department, and area hierarchy toserver 504. - At
step 520, the server generates one or more child block start transactions. Atstep 522, the server pushes the child block start transactions to the active transaction table. Instep 524,server 504 stores the child block transaction addresses in the database. - At
step 526,client counting device 506 continuouslypolls server 504 for a count start flag status until it receives a “true” result. Instep 528,server 504 will set the count started flag status to “true” upon start of the inventory freeze period. Atstep 530,client counting device 506 will prompt the user for the hierarchical location. Instep 532, the client counting device will receive the hierarchal location input such as store and department. At this step, the identity of the inventory taker is also received. - At
step 534, the client counting device transmits a request for the corresponding parent block address to the server. Instep 536,server 504 will determine the corresponding parent block address. Atstep 538, the server transmits the corresponding parent block address to the client counting device. - At
step 540, the client counting device will prompt the user for an area identifier. Instep 542, the client counting device receives the area identifier. - At
step 544,client counting device 506 creates a child block start transaction. Atstep 546, the child block start transaction is transmitted to the server. Instep 548, the server pushes the transaction to the active transaction table. - At
step 550,client counting device 506 prompts the user for item name and quantity input. Instep 552, the client counting device receives the item name and quantity input. In a preferred embodiment, the item name and quantity can be manually entered, or a client counting device can optically scan a barcode, such as a UPC or QR code, which will auto-populate the item name and an editable quantity count of one (1). - Referring then to
FIG. 5B , atstep 554, the client device creates an “item add” transaction. Instep 556, the item add transaction is transmitted to the server. Atstep 558,server 504 pushes the transaction to the transaction table. - At
step 560,client counting device 506 will prompt the user for a next action. Atstep 562, the user may select to input a new item name and quantity. In a preferred embodiment, the available options may consist of entering an additional item name and quantity or end the count. If the client counting device receives a new item name and quantity atstep 562, then the client counting device will repeatsteps step 564,client counting device 506 receives a close area selection, which will end the area count. - At
step 566, the client counting device will create a block end transaction. Atstep 568, the block end transaction is sent to the server. -
Steps step 570, the server will look up the corresponding block start transaction, or parent block. Atstep 572, each child transaction, in turn, is selected from the transaction table. Instep 574,server 504 will validate the block. If the block is valid, then the block is chained to the block start (parent block). Ifserver 504 encounters a nested block end transaction, then it calls the chain join function to run for that specific block. - At
step 576, the server creates a CJ transaction to pin the block to a processing chain. Atstep 578, the CJ transaction is marked as the most recent transaction replacing the previous transaction. Atstep 580,server 504 generates an Ω block. - At
step 582, the server transmits a status report. Atstep 584, the administrative device logs the status. - Referring to
FIGS. 6A and 6B , an example ledger transaction produced by the invention during an inventory count will be described. - XYZ Widgets stocks two types of items (zigs and zags) at each of their two locations (east and west). Further, each location stocks items in either a floor or a back stock room area (floor and back). XYZ wishes to hire a third party (Counting Co.) to count all of their items and to provide to results to an auditing firm (Audit Firm).
- Counting Co. collects the latest block hash from a public blockchain or Audit Firm provides the address. This unique string (A, α) is agreed between XYZ, Audit Firm, & Counting Co. as the “count genesis.” Because the count genesis information is not known before the beginning of the count process, it is certain that no transactions were collected early.
Block 602 is generated according to the format: -
Aα=f #(α,α,BS,NULL,NULL,NULL) - Counting Co., then creates two block start
transactions -
A1=f #(Aα,Aα,BS,“East”,NULL,NULL) -
A13=f #(Aα,Aα,BS,“West”,NULL,NULL) - The parent block of
block 604, as indicated byarrow 659 isblock 602. The prior block ofblock 604 is block 602 as indicated byarrow 660. - The parent block, as indicated by
arrow 680 ofblock 606 isblock 602. The prior block ofblock 606 as indicated byarrow 681 isblock 602. - Counting Co. staff at each location use newly created
blocks blocks -
A2=f #(A1,A1,BS,“Floor”,NULL,NULL) -
A14=f #(A13,A13,BS,“Floor”,NULL,NULL) - The parent block of
block 608 as indicated byarrow 662 isblock 604. The prior block ofblock 608 is block 604 as indicated byarrow 663. - The parent block of
block 630 is block 606 as indicated byarrow 684. The prior block ofblock 630 is block 606 as indicated byarrow 683. - Counting Co. staff in the east find 3 zigs and 2 zags in the floor stock location resulting in
blocks -
A3=f #(A2,A2,IA,NULL,“Zag”,2) -
A6=f #(A2,A3,IA,NULL,“Zig”,3) - The parent block of
block 610 is block 608 as indicated byarrow 668. The prior block ofblock 610 is block 608 as indicated byarrow 669. - The parent block of
block 612 is block 608 as indicated byarrow 667. The prior block ofblock 612 is block 610 as indicated byarrow 670. - Audit Firm wishes to check in on the progress of the count. Counting Co. sends Audit Firm the latest count (3 zigs and 2 zags) along with the most recent block address. Counting Co. also sends all of their most recent transactions back to XYZ in the form of a transaction table, as will be further described.
- Counting Co. staff in the east move in counting the back-stock location where they find 1 zig and 2 zags, forming
blocks -
A4=f #(A1,A1,BS,“Back”,NULL,NULL) -
A5=f #(A4,A4,IA,NULL,“Zag”,2) -
A9=f #(A4,A5,IA,NULL,“Zig”,1) - The parent block of
block 614 is block 604 as indicated byarrow 665. The prior block ofblock 614 is block 604 as indicated byarrow 664. - The parent block of
block 616 is block 614 as indicated byarrow 627. The prior block ofblock 616 is block 614 as indicated byarrow 625. - The parent block of
block 618 is block 614 as indicated byarrow 679. The prior block ofblock 618 is block 616 as indicated byarrow 629. - Counting Co. East staff are finished with this location. They close and join their blocks and transmit the remaining transactions to Counting Co., forming
blocks -
A7=f #(A2,A6,BE,NULL,NULL,NULL) -
A8=f #(A7,A7,CJ,NULL,NULL,NULL) -
A10=f #(A4,A9,BE,NULL,NULL,NULL) -
A11=f #(A10,A8,CJ,NULL,NULL,NULL) -
A12=f #(A1,A11,BE,NULL,NULL,NULL) - The parent block of
block 620 is block 608 as indicated byarrow 666. The prior block ofblock 620 is block 612 as indicated byarrow 672. - The parent block of
block 622 is block 620 as indicated byarrow 673. The prior block ofblock 622 is block 620 as indicated byarrow 674. - The parent block of
block 624 is block 628 as indicated byarrow 677. The prior block ofblock 624 is block 622 as indicated byarrow 675. - The parent block of
block 626 is block 604 as indicated 661. The prior block ofblock 626 is block 624 as indicated byarrow 676. - The parent block of
block 628 is block 614 as indicated byarrow 678. The prior block ofblock 628 is block 618 as indicated byarrow 631. - Meanwhile, Counting Co. staff in the west have performed their count. For convenience it is assumed that the same results as East location. They close and join their blocks and transmit to Counting Co., forming
blocks -
A14=f #(A13,A13,BS,“Floor”,NULL,NULL) -
A15=f #(A14,A14,IA,NULL,“Zag”,2) -
A16=f #(A14,A15,IA,NULL,“Zig”,3) -
A17=f #(A14,A16,BE,NULL,NULL,NULL) -
A18=f #(A17,A17,CJ,NULL,NULL,NULL) -
A19=f #(A13,A18,BS,“Back”,NULL,NULL) -
A20=f #(A19,A19,IA,NULL,“Zag”,2) -
A21=f#(A19,A20,IA,NULL,“Zig”,1) -
A22=f #(A19,A21,BE,NULL,NULL,NULL) -
A23=f #(A22,A22,CJ,NULL,NULL,NULL) -
A24=f #(A13,A23,BE,NULL,NULL,NULL) - The parent block of
block 630 is block 606 as indicated byarrow 684. The prior block ofblock 630 is block 606 as indicated byarrow 683. - The parent block of
block 632 is block 630 as indicated byarrow 688. The prior block ofblock 632 is block 630 as indicated byarrow 689. - The parent block of
block 634 is block 630 as indicated byarrow 687. The prior block ofblock 634 is block 632 as indicated byarrow 690. - The parent block of
block 636 is block 630 as indicated byarrow 686. The prior block ofblock 636 is block 634 as indicated byarrow 691. - The parent block of
block 638 is block 636 as indicated byarrow 692. The prior block ofblock 638 is block 636 as indicated byarrow 693. - The parent block of
block 640 is block 606 as indicated byarrow 685. The prior block ofblock 640 is block 638 as indicated byarrow 694. - The parent block of
block 642 is block 640 as indicated byarrow 697. The prior block ofblock 642 is block 640 as indicated byarrow 698. - The parent block of
block 644 is block 640 as indicated byarrow 696. The prior block ofblock 644 is block 642 as indicated byarrow 699. - The parent block of
block 646 is block 640 as indicated byarrow 695. The prior block ofblock 646 is block 644 as indicated byarrow 603. - The parent block of
block 648 is block 646 as indicated byarrow 605. The prior block ofblock 648 is block 646 as indicated byarrow 607. - The parent block of
block 650 is block 606 as indicated byarrow 615. The prior block ofblock 650 is block 648 as indicated byarrow 609. - Counting Co. notes the receipt of the block end transactions for each location. Counting Co. traces the transactions received from a to the block end, (as will be further described) confirming count results, and perform the chain joins, resulting in
blocks -
A25=f #(A24,A24,CJ,NULL,NULL,NULL) -
A26=f #(A12,A25,CJ,NULL,NULL,NULL) -
A27=f #(Aα,A26,BE,NULL,NULL,NULL) - The parent block of
block 652 is block 650 is indicated byarrow 613. The prior block ofblock 652 is block 650 as indicated byarrow 611. - The parent block of
block 654 is block 626 as indicated byarrow 651. The prior block ofblock 654 is block 652 as indicated byarrow 617. - The parent block of
block 656 is block 602 as indicated byarrow 682. The prior block ofblock 656 is block 654 as indicated byarrow 619. - Counting Co. verifies there are no open blocks to indicate ongoing counts and performs a final chain join. Counting Co. provides the ending address (AΩ) to XYZ and to Audit Firm, resulting in
block 658, as follows: -
AΩ=f #(Aα,A27,CJ,NULL,NULL,NULL) - The parent block of
block 658 is block 656 as indicated byarrow 621. The prior block ofblock 658 is block 656 as indicated byarrow 623. - A transaction table for the preceding example is as follows:
-
TABLE 1 Transac- Transac- tion Parent Prior tion Address Address Address Type Area Item Count A1 Aα Aα BS “East” NULL NULL A2 A1 A1 BS “Floor” NULL NULL A3 A2 A2 IA NULL “Zag” 2 A4 A1 A1 BS “Back” NULL NULL A5 A4 A4 IA NULL “Zag” 2 A6 A2 A3 IA NULL “Zig” 3 A7 A2 A6 BE NULL NULL NULL A8 A7 A7 CJ NULL NULL NULL A9 A4 A5 IA NULL “Zig” 1 A10 A4 A9 BE NULL NULL NULL A11 A10 A8 CJ NULL NULL NULL A12 A1 A11 BE NULL NULL NULL A13 Aα Aα BS “West” NULL NULL A14 A13 A13 BS “Floor” NULL NULL A15 A14 A14 IA NULL “Zag” 2 A16 A14 A15 IA NULL “Zig” 3 A17 A14 A16 BE NULL NULL NULL A18 A17 A17 CJ NULL NULL NULL A19 A13 A18 BS “Back” NULL NULL A20 A19 A19 IA NULL “Zag” 2 A21 A19 A20 IA NULL “Zig” 1 A22 A19 A21 BE NULL NULL NULL A23 A22 A22 CJ NULL NULL NULL A24 A13 A23 BE NULL NULL NULL A25 A24 A24 CJ NULL NULL NULL A26 A12 A25 CJ NULL NULL NULL A27 Aα A26 BE NULL NULL NULL - Counting Co. provides the transaction table and the hash function to Audit Firm and XYZ. The transaction table may be used to verify the count.
- Referring to
FIG. 7 ,process 700 of validating the transaction table will be described. - As previously discussed, each transaction address is the hash of its contents. These contents include its prior and parent transaction addresses. When a transaction table is verified, the address contained in one transaction is used to “lookup” the corresponding parent or prior transaction address. If the hash value of the transaction matches the address of the current transaction, then the current transaction is unaltered and so is valid.
- The transaction table is only valid if the addresses can be traced from the Ω block to the α block with an addresses valid.
- For example, valid CJ transactions must have a valid BE transaction as parent and have valid BE or CJ as prior transaction.
- Valid Block End (BE) transactions must have a valid block start (BS) as parent transaction and have a traceable prior transaction path to their parent block start (BS) transaction.
- Valid Block Start (BS) transactions must have a valid block start (BS) or Alpha block as parent transaction and have a traceable prior transaction path to their parent block start (BS) transaction.
- Valid Item Add (IA) transactions must have a valid block start (BS) as parent transaction and have a traceable prior transaction path to their parent block start (BS) transaction.
- At
step 702, the method begins. Atstep 704, the current transaction in the transaction table is identified. For example, and in most cases, the current transaction chosen is the Ω block. - At
step 706, the transaction prior to the current transaction is identified in the transaction table. - At
step 708, the hash function is applied to the Aparent, Aprior, Ttype, block name, item name, and quantity fields from the prior transaction block in the transaction table. If the hash function is a rotating hash, then the predetermined hash order is reversed to determine which hash function to use to decode the prior transaction. - At
step 710, the Aprior field is identified from the current transaction in the transaction table. - At
step 712, the Aprior value from the current block is compared to the Aprior value from the prior block. If the addresses match, then the method moves to step 716. If the addresses do not match, then the method moves to step 714. - At
step 716, the current transaction block is identified as valid and the method moves to step 722. Atstep 722, a decision is made whether or not the current transaction being validated is the Alpha block. If not, the method returns to step 704 where a new current transaction is identified. If so, the method moves to step 724. Atstep 724, the transaction table is validated. Atstep 726, the method returns. - At
step 714, the current transaction block is set as invalid. Atstep 718, the transaction table is declared invalid. The method then returns atstep 726. - Referring to
FIGS. 8A and 8B , analternate method 800 of validating a transaction table will be described asmethod 800. - Referring then to
FIG. 8A , atstep 801, the method begins. - At
step 802, all transactions must be confirmed as unaltered by comparing each transaction address to the SHA256 hash of its payload, according to the following steps: -
For each transaction in transaction table If transaction address is equal to hash of transaction Mark the transaction hash as correct Else: Mark the transaction as hash incorrect - If any of the transactions fail to pass the hash check, then it is concluded that they have been tampered with or corrupted and are dropped from the transaction table.
- At
step 804, it must be verified whether or not each transaction has a valid prior transaction chain to the α block, according to the following steps: -
For each transaction in the transaction table { do while ( this transaction address is not equal to the alpha seed ) { select prior transaction address from the transaction table where transaction address == this transaction address if prior transaction address cannot be found in the table mark this transaction as prior trace failed if prior transaction address is alpha seed mark this transaction as prior trace passed #otherwise, we haven't found the end yet, keep going This transaction address = prior transaction address } } - If any of the transactions fail to pass, then they are not part of the valid count chain and are dropped from the transaction table.
- At
step 806, it must be verified that each transaction has a valid parent transaction chain back to the α block according to the following steps: -
For each transaction in the transaction table { do while (this transaction address is not equal to the alpha seed) { select parent transaction address from the transaction table where transaction address == this transaction address if the parent transaction address does not exist in the table mark the transaction as prior trace failed if parent transaction address is alpha seed mark this transaction as prior trace flag passed #otherwise, we haven't found the end yet, keep going This transaction Address = parent transaction address } } - If any transaction fails to be connected to a valid parent chain to the α block, they are dropped from the transaction table.
- All transactions are now traceable to the α block along their prior and parent paths.
- At
step 808, it must be confirmed that the transactions are connected to the Ω block by ensuring they are included in a chain which is chain joined to the Ω block, if they are, any items in the chain may be counted. - Referring then to
FIG. 8B , atstep 809, the user provides an address of a block in the transaction chain. Atstep 810, the block is examined to determine whether or not it is a CJ transaction. If not, the method moves to step 811. If so, the method moves to step 812. Atstep 811, an error is declared and the process ends. - At
step 812 the process looks up the prior block address. Atstep 813, the process decides whether or not the block at the prior address is a BE transaction. If so, the method moves to step 814 and ignores the transaction. If not, the method moves to step 815. - At
step 815, the method marks the block as counted and looks up the parent address. Atstep 816, the process decides whether or not the block at the parent address is a BE transaction. If not, the method moves to step 818 and concludes. If so, the method moves to step 820. - At
step 820, the block is marked as counted and the method looks up the block with the prior address. - At
step 822, the method decides whether or not this block is IA transaction. If so, the method moves to step 824. If not, the method moves to step 828. Atstep 824, the block is marked as counted and the items are added to the inventory count. Atstep 826, the method looks up the prior transaction block and returns to step 822. - At
step 828, the process decides whether or not the transaction block is a BS transaction. If so, the method moves to step 830. If not, the method moves to step 834. Atstep 834, the process decides whether or not it is a CJ transaction. If so, the method returns to step 810. If not, the method moves to step 836 and an error is produced. - At
step 830, the process marks the block as counted and looks up the address of the prior block. - At
step 832, the process decides whether or not the prior block is a CJ transaction or not. If so, the method returns to step 810. If not, the method moves to step 838. - At
step 838, the process decides whether or not the current block is a BS transaction. If so, the method moves to step 840 and returns. If not, the method moves to step 842. - At
step 842, the method decides whether or not the block is a BE transaction. If not, the method moves to step 844 and concludes. If so, the method returns to step 816.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/737,726 US20200226540A1 (en) | 2019-01-08 | 2020-01-08 | Distributed cryptographic inventory data collection, storage and processing system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962789747P | 2019-01-08 | 2019-01-08 | |
US16/737,726 US20200226540A1 (en) | 2019-01-08 | 2020-01-08 | Distributed cryptographic inventory data collection, storage and processing system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20200226540A1 true US20200226540A1 (en) | 2020-07-16 |
Family
ID=71516380
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/737,726 Abandoned US20200226540A1 (en) | 2019-01-08 | 2020-01-08 | Distributed cryptographic inventory data collection, storage and processing system |
Country Status (1)
Country | Link |
---|---|
US (1) | US20200226540A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220318833A1 (en) * | 2021-04-06 | 2022-10-06 | Zhiji Automotive Technology Co., Ltd. | Blockchain-based method, device and system for processing vehicle driving data |
US20230104585A1 (en) * | 2020-05-20 | 2023-04-06 | New H3C Technologies Co., Ltd. | Method and Apparatus for Monitoring Software License Information, and Server and Storage Medium |
Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6785278B1 (en) * | 1998-12-10 | 2004-08-31 | International Business Machines Corporation | Methods, systems and computer program products for hashing address values |
US20070228068A1 (en) * | 2005-10-12 | 2007-10-04 | Kevin Schneider | Alcoholic beverage management and inventory system |
US20070294496A1 (en) * | 2006-06-19 | 2007-12-20 | Texas Instruments Incorporated | Methods, apparatus, and systems for secure demand paging and other paging operations for processor devices |
US20080109662A1 (en) * | 2006-11-07 | 2008-05-08 | Spansion Llc | Multiple stakeholder secure memory partitioning and access control |
US20140165215A1 (en) * | 2012-12-12 | 2014-06-12 | Vmware, Inc. | Limiting access to a digital item |
US9054876B1 (en) * | 2011-11-04 | 2015-06-09 | Google Inc. | Fast efficient vocabulary computation with hashed vocabularies applying hash functions to cluster centroids that determines most frequently used cluster centroid IDs |
US20160028552A1 (en) * | 2014-07-25 | 2016-01-28 | Blockchain Technologies Corporation | System and method for creating a multi-branched blockchain with configurable protocol rules |
US20160164884A1 (en) * | 2014-12-05 | 2016-06-09 | Skuchain, Inc. | Cryptographic verification of provenance in a supply chain |
US20160212146A1 (en) * | 2008-04-25 | 2016-07-21 | Kelce S. Wilson | PEDDaL Blockchaining for Document Integrity Verification Preparation |
US20160259937A1 (en) * | 2015-03-02 | 2016-09-08 | Dell Products L.P. | Device reporting and protection systems and methods using a secure distributed transactional ledger |
US20160344737A1 (en) * | 2014-06-30 | 2016-11-24 | CloudMode, LLC | Uniqueness and auditing of a data resource through an immutable record of transactions in a hash history |
US20170153847A1 (en) * | 2015-11-30 | 2017-06-01 | Freescale Semiconductor, Inc. | System and method for removing hash table entries |
US20170163733A1 (en) * | 2015-12-02 | 2017-06-08 | Olea Networks, Inc. | System and method for data management structure using auditable delta records in a distributed environment |
US20170236104A1 (en) * | 2016-02-12 | 2017-08-17 | D+H Usa Corporation | Peer-to-Peer Financial Transactions Using A Private Distributed Ledger |
US20180130034A1 (en) * | 2016-11-07 | 2018-05-10 | LedgerDomain, LLC | Extended blockchains for event tracking and management |
US9992022B1 (en) * | 2017-02-06 | 2018-06-05 | Northern Trust Corporation | Systems and methods for digital identity management and permission controls within distributed network nodes |
US20180225640A1 (en) * | 2017-02-06 | 2018-08-09 | Northern Trust Corporation | Systems and methods for issuing and tracking digital tokens within distributed network nodes |
US20180284093A1 (en) * | 2017-03-29 | 2018-10-04 | Innit International S.C.A. | Trusted Food Traceability System and Method and Sensor Network |
US20180343126A1 (en) * | 2017-05-24 | 2018-11-29 | NXM Labs Inc. | System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner |
US10474938B2 (en) * | 2017-04-24 | 2019-11-12 | Flockstock Pty Ltd | Inventory management system |
US11423351B2 (en) * | 2016-12-15 | 2022-08-23 | International Business Machines Corporation | Blockchain-based food product shelf-life management |
-
2020
- 2020-01-08 US US16/737,726 patent/US20200226540A1/en not_active Abandoned
Patent Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6785278B1 (en) * | 1998-12-10 | 2004-08-31 | International Business Machines Corporation | Methods, systems and computer program products for hashing address values |
US20070228068A1 (en) * | 2005-10-12 | 2007-10-04 | Kevin Schneider | Alcoholic beverage management and inventory system |
US20070294496A1 (en) * | 2006-06-19 | 2007-12-20 | Texas Instruments Incorporated | Methods, apparatus, and systems for secure demand paging and other paging operations for processor devices |
US20080109662A1 (en) * | 2006-11-07 | 2008-05-08 | Spansion Llc | Multiple stakeholder secure memory partitioning and access control |
US20160212146A1 (en) * | 2008-04-25 | 2016-07-21 | Kelce S. Wilson | PEDDaL Blockchaining for Document Integrity Verification Preparation |
US9054876B1 (en) * | 2011-11-04 | 2015-06-09 | Google Inc. | Fast efficient vocabulary computation with hashed vocabularies applying hash functions to cluster centroids that determines most frequently used cluster centroid IDs |
US20140165215A1 (en) * | 2012-12-12 | 2014-06-12 | Vmware, Inc. | Limiting access to a digital item |
US20160344737A1 (en) * | 2014-06-30 | 2016-11-24 | CloudMode, LLC | Uniqueness and auditing of a data resource through an immutable record of transactions in a hash history |
US20160028552A1 (en) * | 2014-07-25 | 2016-01-28 | Blockchain Technologies Corporation | System and method for creating a multi-branched blockchain with configurable protocol rules |
US20160164884A1 (en) * | 2014-12-05 | 2016-06-09 | Skuchain, Inc. | Cryptographic verification of provenance in a supply chain |
US20160259937A1 (en) * | 2015-03-02 | 2016-09-08 | Dell Products L.P. | Device reporting and protection systems and methods using a secure distributed transactional ledger |
US20170153847A1 (en) * | 2015-11-30 | 2017-06-01 | Freescale Semiconductor, Inc. | System and method for removing hash table entries |
US20170163733A1 (en) * | 2015-12-02 | 2017-06-08 | Olea Networks, Inc. | System and method for data management structure using auditable delta records in a distributed environment |
US20170236104A1 (en) * | 2016-02-12 | 2017-08-17 | D+H Usa Corporation | Peer-to-Peer Financial Transactions Using A Private Distributed Ledger |
US20180130034A1 (en) * | 2016-11-07 | 2018-05-10 | LedgerDomain, LLC | Extended blockchains for event tracking and management |
US11423351B2 (en) * | 2016-12-15 | 2022-08-23 | International Business Machines Corporation | Blockchain-based food product shelf-life management |
US9992022B1 (en) * | 2017-02-06 | 2018-06-05 | Northern Trust Corporation | Systems and methods for digital identity management and permission controls within distributed network nodes |
US20180225640A1 (en) * | 2017-02-06 | 2018-08-09 | Northern Trust Corporation | Systems and methods for issuing and tracking digital tokens within distributed network nodes |
US20180284093A1 (en) * | 2017-03-29 | 2018-10-04 | Innit International S.C.A. | Trusted Food Traceability System and Method and Sensor Network |
US10474938B2 (en) * | 2017-04-24 | 2019-11-12 | Flockstock Pty Ltd | Inventory management system |
US20180343126A1 (en) * | 2017-05-24 | 2018-11-29 | NXM Labs Inc. | System and method for utilizing connected devices to enable secure and anonymous electronic interaction in a decentralized manner |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20230104585A1 (en) * | 2020-05-20 | 2023-04-06 | New H3C Technologies Co., Ltd. | Method and Apparatus for Monitoring Software License Information, and Server and Storage Medium |
US20220318833A1 (en) * | 2021-04-06 | 2022-10-06 | Zhiji Automotive Technology Co., Ltd. | Blockchain-based method, device and system for processing vehicle driving data |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11599555B2 (en) | Data manifest as a blockchain service | |
US11108863B2 (en) | Tag operating system | |
Malik et al. | Productchain: Scalable blockchain framework to support provenance in supply chains | |
CN111031036B (en) | Block chain-based vaccine information monitoring method and device and computer equipment | |
CN108876364B (en) | Block chain system with annihilation mechanism | |
ES2957843T3 (en) | Verification of data processes in a network of computing resources | |
US8659389B2 (en) | Secure inventory control systems and methods for high-value goods | |
US20210049306A1 (en) | System and method for consensus management | |
CN108615195B (en) | Resource transfer information transmission method and device, storage medium and electronic device | |
CN109829726A (en) | A kind of drug information management method and system based on block chain | |
CN111062690A (en) | User purchase management system based on block chain technology | |
JP2021514510A (en) | Logistics tracking and source identification methods, application servers, blockchain nodes and media | |
CN111507709A (en) | Data traceability system | |
EP2564560A1 (en) | Information tracking system and method | |
CN111984726A (en) | Storage and distributed database of measurement data sets | |
US20200226540A1 (en) | Distributed cryptographic inventory data collection, storage and processing system | |
US20230047625A1 (en) | Method and system for generalized provenance solution for blockchain supply chain applications | |
CN113612741B (en) | Method, device, equipment and storage medium for storing certificate of article circulation record | |
CN118115178B (en) | Quality tracing method, system and equipment based on industrial Internet of things | |
JP7409297B2 (en) | Information management method and information management program | |
CN109903055A (en) | Merchandise control method, apparatus, computer installation and storage medium | |
CN113626421A (en) | Data quality control method for data verification | |
CN117709981A (en) | Tobacco product monitoring method, device and management system | |
CN116596551A (en) | Supply chain product tracing method based on block chain, storage medium and electronic equipment | |
CN110991573A (en) | Product management method, system, client node and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: OMNICOUNTS, LLC, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GRAVES, CHRISTOPHER CARTER;REEL/FRAME:051455/0954 Effective date: 20200108 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: APPLICATION DISPATCHED FROM PREEXAM, NOT YET DOCKETED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |