WO2020145881A1 - Procédé et système de stockage et de gestion de métaux de valeur - Google Patents

Procédé et système de stockage et de gestion de métaux de valeur Download PDF

Info

Publication number
WO2020145881A1
WO2020145881A1 PCT/SG2019/050008 SG2019050008W WO2020145881A1 WO 2020145881 A1 WO2020145881 A1 WO 2020145881A1 SG 2019050008 W SG2019050008 W SG 2019050008W WO 2020145881 A1 WO2020145881 A1 WO 2020145881A1
Authority
WO
WIPO (PCT)
Prior art keywords
parcel
hash
log entry
log
identity
Prior art date
Application number
PCT/SG2019/050008
Other languages
English (en)
Inventor
Gregor Juergen GREGERSEN
Clint Mark Lumantao GONO
Original Assignee
Little Bit Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Little Bit Pte Ltd filed Critical Little Bit Pte Ltd
Priority to PCT/SG2019/050008 priority Critical patent/WO2020145881A1/fr
Priority to PCT/SG2019/050245 priority patent/WO2020145887A2/fr
Publication of WO2020145881A1 publication Critical patent/WO2020145881A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • 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
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis
    • 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
    • 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This invention relates to a method and a system for valuable metal storage and management.
  • Valuable metals include precious metals (e.g. gold, silver, platinum, palladium) and electric vehicle metals (e.g. cobalt, nickel) that are commonly bought and/or traded for wealth insurance and crisis hedging.
  • precious metals e.g. gold, silver, platinum, palladium
  • electric vehicle metals e.g. cobalt, nickel
  • storage and or trading of such valuable metals is provided by storage and/or trading service providers. However, it may not be transparent to owners and potential buyers that the valuable metal they have paid for or intend to pay for even actually exists, is genuine and not plated or made of other materials, is not already encumbered e.g. leased out and sold to another party and so on.
  • a method and system for valuable metal storage and management is now disclosed that immutably and transparently records all events and transactions on actual physical quantities of valuable metal stored in one or more depositories.
  • a record of a new event or transaction associated with any parcel of valuable metal in the one or more depositories is created as a log entry, and each log entry is immutably stored in a database by hashing the entire log entry using a hash algorithm and broadcasting the resulting hash to a public blockchain as immutable evidence of the creation and storage of each log entry.
  • any modification to a log entry in the database can be detected by hashing the log entry and comparing the resulting hash with the hash that has already been broadcast to the public blockchain, since a hash is a unique string generated from a specific body of information and the hash would change if the information being hashed is changed.
  • the method and system are thus eminently adaptable for numerous varied applications of use as each log entry may contain any type of information (including documentation) that may be desired to be recorded, and in effect no limit is placed on the size of the log entry as the log entry is eventually represented by a hash of itself when broadcast to the public blockchain as proof of its creation at a specific point in time. In the method and system, no existing log entry is deleted, amended or overwritten.
  • a method of valuable metal storage and management comprising the steps of:
  • the log entry may include the identity of the tag and a pure mass of the parcel, wherein pure mass of the parcel is computed from actual mass and purity of the valuable metal in the parcel.
  • the method may further comprise generating an image hash comprising a hash of a serialization of a captured image of the parcel and wherein the log entry further includes the image hash.
  • the log entry may further include a prior log hash of a prior log entry stored in the unique log of the parcel.
  • Creating the log entry may comprise one of: scanning the tag with a scanner to obtain identity of the tag and an application programming interface (API) operating with an administrator user interface generating the log entry, and a person inputting an identity of the tag via a service provider user interface operating with the API and the API generating the log entry.
  • API application programming interface
  • the method may further comprise generating a device hash comprising a hash of an identity of the scanner in association with the depository and wherein the log entry includes the device hash.
  • the method may further comprise generating an operator hash comprising a hash of an identity of a person initiating creation of the log entry and wherein the log entry includes the operator hash.
  • the method may further comprise generating an account hash comprising a hash of an identity of an owner of the parcel and the log entry may include the account hash.
  • the log entry may further include information about the event that has occurred for the parcel.
  • the event may comprise a claim made on the parcel.
  • the method may further comprise generating a documentation hash comprising a hash of documentation associated with the claim and the log entry may include the documentation hash.
  • the claim may comprise at least one of: the parcel being collateral in a loan made out to an owner of the parcel, and the parcel being collateral in conjunction with a blockchain-based asset-backed token trading system.
  • the method may further comprise storing a transaction identity and time of broadcasting the log hash to the public blockchain in the unique log.
  • a system for valuable metal storage and management comprising: a depository for storage of parcels therein, each parcel comprising a number of units of the valuable metal; a tag having a unique identity configured to be attached to and associated with each parcel; a scanner configured to scan the tag to obtain identity of the tag; an administrator interface operating with an API configured to automatically create a log entry for each event that occurs for each parcel in association with the obtained identity of the tag; and a database configured to store the log entry in a unique log of the parcel in association with the identity of the tag, wherein the API is further configured to generate a log hash from the log entry and to broadcast the log hash to a public blockchain.
  • the log entry may include the identity of the tag and a pure mass of the parcel, wherein pure mass of the parcel is computed from actual mass and purity of the valuable metal in the parcel.
  • the system may further comprise a service provider user interface operating with the API to allow a service provider to access the unique log, the API further configured to create a log entry in association with the identity of the tag by a person inputting the identity of the tag via the service provider user interface.
  • the system may further comprise a camera configured to capture an image of the parcel, wherein the API is further configured to generate an image hash comprising a hash of a serialization of a captured image of the parcel and to include the image hash in the log entry.
  • the API may be further configured to include in the log entry a prior log hash of a prior log entry stored in the unique log of the parcel.
  • the API may be further configured to generate a device hash comprising a hash of an identity of the scanner in association with the depository and to include the device hash in the log entry.
  • the API may be further configured to generate an operator hash comprising a hash of an identity of a person initiating creation of the log entry and to include the operator hash in the log entry.
  • the API may be further configured to generate an account hash comprising a hash of an identity of an owner of the parcel and to include the account hash in the log entry.
  • the log entry may further include information about the event that has occurred for the parcel.
  • the event may comprise a claim made on the metal in the parcel.
  • the API may be further configured to generate a documentation comprising a hash of documentation associated with the claim and to include the documentation hash in the log entry.
  • the claim may comprise at least one of: the parcel being collateral in a loan made out to an owner of the parcel, and the parcel being collateral in conjunction with a blockchain-based asset-backed token trading system.
  • the system may further comprise a public user interface operating with a public API to allow a user to access information contained in the unique log.
  • the depository may be operated by a storage provider, wherein use of the parcel is managed by a service provider, and wherein the system is implemented for use by multiple service providers and multiple depositories operated by multiple storage providers to store and manage multiple parcels.
  • FIG. 1 is a flowchart of an exemplary embodiment of a method of valuable metal storage and management.
  • FIG. 2 is a schematic illustration of an exemplary embodiment of a system for valuable metal storage and management.
  • FIG. 3 is a photograph of an exemplary parcel having a tag attached thereto.
  • FIG. 4 is a schematic illustration of an exemplary implementation of the method and system of valuable metal storage and management for multiple storage providers and multiple service providers.
  • a method (100) and system 200 for storage and management of valuable metal will be described below with reference to FIGS. 1 to 4.
  • the same reference numerals are used throughout the figures for the same or similar parts.
  • Reference numerals relating to the method (100) are indicated in brackets for ease of distinction from reference numerals relating to the system 200.
  • the term“parcel” is used to refer to a uniquely identifiable parcel comprising a known quantity of a valuable metal, such as gold, silver, platinum, palladium, cobalt, nickel, and so on.
  • Each parcel may contain one or more units of the valuable metal.
  • a unit of valuable metal may comprise a piece of bullion (e.g.
  • gold, silver platinum, palladium that can be of any known form: such as a bar, an ingot or a coin, for example, or a unit may comprise granules of a certain weight and purity of a precious metal, or a unit may comprise one or more pieces of jewellery containing precious metal of a certain grade of known weight and purity, or a unit may comprise a drum or barrel (e.g. cobalt) or a bulk bag (e.g. nickel) of the valuable metal, and so on.
  • Each parcel may be of any desired actual mass (grams) and purity (percent) of the valuable metal in the parcel.
  • a depository 210 operated by a storage provider is provided for storage of parcels 300 therein.
  • the method (100) and system 200 operate independently of any proprietary IT (information technology) system of the depository 210.
  • the depository 210 comprises a vault 210, but in other embodiments the depository may also comprise a secured warehouse, a strong room or any other appropriate storage place.
  • the system 200 includes a database 220 configured to store a unique log 222 of each parcel 300 in the vault 210.
  • the database 220 may comprise one or more servers, including outsourced servers provided by commercial storage services and servers for file storage of images and documents.
  • the unique log 222 of a parcel 300 comprises a number of chronologically added and immutable log entries 280 unique to the parcel 300, and will be described in greater detail below.
  • a parcel comprising one unit of a gold bar weighing 11.74 kg or 11,740 g and having a purity of 98.4% would have a pure mass of gold of 11,552.16 g.
  • a parcel comprising five units of silver bars each unit weighing 3.11 kg or 3,110 g and having a purity of 99.99% would have a total actual mass of 15.56 kg and pure mass of silver of 15,548.45 g.
  • a parcel comprising pieces of jewellery made of 18 karat gold (75% purity) weighing a total of 1.2 kg would have a pure mass of gold of 900g.
  • Knowing the pure mass of valuable metal in each of the parcels 300 is an important feature as it allows each parcel of valuable metal to be fairly and equally valued regardless of its type or purity. In this way, fungibility of the valuable metal managed using the present method (100) and system 200 goes beyond high purity bullion to include jewellery and other forms of what is commonly referred to as“junk gold” in the bullion industry, and provides a transparent and detailed holding inventory of different valuable metal types that may be stored in the vault 210.
  • the system 200 includes tags 230 that are each configured for attachment to and association with each of the parcels 300 stored in the vault 210 (120).
  • Each tag 230 has a unique identity and is configured to be machine-readable and to associate a parcel 300 connected to the tag 230 with its unique log 222 in the database 220.
  • the tag 230 should remain attached to the parcel 300 for as long as the parcel 300 is stored in the vault 210.
  • the tag 230 is preferably tamper-evident such that it will be destroyed in an attempt to detach the tag 230 from the parcel 300, thereby preventing unauthorized substitution of the parcel 300 with another item from going undetected while the parcel 300 is in the vault 210.
  • association of the identity of the new tag with the identity of the old tag may be established via association of both the new tag and the old tag with a unique serial string that has been generated for the parcel 300.
  • the unique serial string may preferably comprise an alphanumeric string with no spaces containing the metal type, Actual Mass, Brand (i.e. name of manufacturer), number of units, type of unit and assigned serial number of the parcel 300.
  • the tag 230 may comprise a radio frequency identification (RFID) or near-field communication (NFC) tag that is insulated from interference by metal of the parcel 300.
  • RFID radio frequency identification
  • NFC near-field communication
  • the tag 230 has a thin form factor so as not to be easily damaged by storage of tagged parcels 300 in close proximity with each other.
  • the tag 230 preferably also has a small surface area such that important visible markings on the parcel 300 (such as its assigned serial number 301) are not obstructed by the tag 230.
  • the parcel 300 comprises a number of relatively small pieces of bullion 302, as shown in FIG.
  • the tag 230 may be provided on an inner surface of a tamper evident bag 231 within which the parcel 300 is sealed, preferably behind where the serial number 301 of the parcel 300 is shown on the bag 231 for ease of locating the tag 230, so as to minimize damage to the tag 230.
  • the bag 231 serves to attach the tag 230 to the parcel 300, and also serves to protect the parcel 300 from damage by physical contact with other objects while facilitating handling of multiple parcels 300 by vault staff.
  • the tag 230 may simply be directly adhered to the metal bar.
  • the system 220 includes a scanner 240 configured to scan and obtain the identity of each tag 230 (140).
  • the scanner 240 is preferably an ultrahigh frequency (UHF) RFID or NFC reader that may be handheld, but may alternatively be of a fixed configuration.
  • the scanner 240 is a secured device having a unique Device Identity associated with the vault 210 and requiring a staff member of the vault (hereinafter referred to as“parcel handler”) having a unique Operator Identity to log in with a user login and password so that only authorized persons may use the scanner 240.
  • the scanner 240 is preferably wirelessly connected (e.g. via Wi-Fi or 3G) to a secured application programming interface (API) 270 that will be described in greater detail below.
  • API application programming interface
  • the system 220 also preferably includes a camera 250 configured to capture (150) an image 251 of each of the parcels 300.
  • the image 251 of the parcel 300 preferably comprises a view of the parcel 300 that shows its serial number and/or any other relevant data.
  • An administrator user interface 260 provided on a client machine (such as a tablet, smart phone, or computer, for example) is included in the system 200 and operates with the API 270.
  • the administrator user interface 260 is configured to communicate with the database 220 via a wireless connection, e.g. Wi-Fi.
  • the scanner 240, camera 250 and administrator user interface 260 are configured and provided for use by storage providers operating depositories 210 for storage of the valuable metal therein.
  • Use of the administrator user interface 260 is preferably secured and accessible only via user names and passwords of a small number of staff of the storage provider, which are preferably separate from the login and password of the scanner 240.
  • the camera 250 may be provided with the administrator user interface 260 (for example when the client machine is a tablet or smart phone having a in-built camera) and the scanner 240 may be separately provided and configured to send identity of a scanned tag to the administrator user interface 260 via a wireless (e.g. Bluetooth®) or wired (less preferred) connection, as shown in FIG. 4.
  • the scanner and the camera may be configured as one instrument and configured to send identity of a scanned tag and captured image to a separately provided administrator user interface via a wireless (e.g. Bluetooth®) or wired (less preferred) connection.
  • the scanner, the camera and the administrator user interface 260 may be together provided in a single instrument.
  • the scanner, camera and administrator user interface 260 may each be separately provided and configured to communicate with each other via a wireless (e.g. Bluetooth®) or wireless (less preferred) connection.
  • the secured API 270 is preferably configured to automatically load preselected fields of existing parcel characteristics of a parcel 300 into the scanner 240 whenever the tag 230 attached to the parcel 300 is scanned (140).
  • the preselected fields may comprise basic data about the parcel 300 such as its Brand, Item Type (e.g. bar, coin, ingot), Serial Number, Metal Type, Actual Mass, Purity and Pure Mass, and also an image hash 252 of the parcel 300 if an image of the parcel 300 has already been captured (described in greater detail below).
  • the scanner 240 is preferably configured to allow the preselected fields to be optionally modified via the scanner 240.
  • a change may be made to any of the preselected fields via the scanner 240 and all the preselected fields in the scanner 240 may be then submitted to the database 220 to create a new plaintext log entry 280 (160).
  • Any data fields of parcel characteristics in the new log entry 280 beyond those already submitted from the scanner 240 are preferably auto-populated with relevant data from an immediately prior log entry 280 in the unique log 222 of the parcel 300, if a prior log entry 280 exists.
  • the relevant data not already submitted from the scanner 240 may comprise status data entered by approved third parties detailing an encumbrance or claim on the parcel 300.
  • the auto-population may be performed by the secured API 270 copying the relevant data from the prior log entry into the present log entry 280.
  • each plaintext log entry 280 may comprise twenty data fields, with twelve of these twenty data fields being configured to be automatically loaded to the scanner 240 when a tag 230 is scanned and being modifiable via the scanner 240.
  • a tag 230 attached to a parcel 300 is scanned, a new log entry 280 is generated for the parcel 300 in association with identity of the tag 230 using the twelve data fields submitted from the scanner 240 while the remaining eight data fields in the log entry 280 are obtained from a prior log entry 280 associated with the tag 230.
  • the present method (100) and system 200 allows different devices and different parties to update common data logs 222 for specific parcels 300 consistently.
  • the secured API 270 is preferably also configured to prompt for input (161) if such input is required or preferably included in order for the generated log entry 280 to be finalized and saved.
  • the parcel handler may be prompted to enter his or her user login and password, and to enter basic data about the parcel 300 if the log entry 280 being generated is a first log entry for the parcel 300 (e.g. when the parcel 300 is a new parcel 300 that is being added to the vault 210 for the first time).
  • the system 200 preferably also includes a service provider user interface 225 operating with the secured API 270 on a client machine to allow a service provider to access the unique log 222, preferably via the Internet.
  • the service provider may be a valuable metal storage and management / trading service provider who uses the present method (100) and system 200 as a client of the storage provider to manage storage of valuable metal and other transactions for their customers.
  • the service provider user interface 225 and secured API 270 are preferably configured to allow the service provider to view existing log entries 280, view the parcel image(s) 252, and also create new log entries 280, e.g. to record a claim on the parcel 300.
  • authentication by the service provider is required, e.g.
  • a new log entry 280 may then be created, including entering a specific tag identity via the service provider user interface 225 in order to associate the new log entry 280 with the specific tag 230.
  • the secured API 270 is further configured to permanently write or save (162) the finalized log entry 280 (completed with input from the parcel handler or service provider where relevant) into the database 220 by chronologically adding this log entry 280 to the unique log 222 of that parcel 300.
  • all information associated with each parcel 300 in the depository 210 is recorded and kept as a series of chronological log entries 280 making up a unique log 222 of the parcel 300.
  • “master” table of information associated with the parcel in the database 220 as such a“master” table can be amended or overwritten, thereby destroying past data regardless of whether such past data was correct or incorrect.
  • the secured API 270 is also configured to automatically hash (190) each plaintext log entry 280 using a Secure Hash Algorithm (e.g. SHA-256), thereby obtaining a unique log hash 290 for each plaintext log entry 280 in the unique log 222 in the database 220.
  • the secured API 270 is additionally configured to broadcast (199) the log hash 290 of each plaintext log entry 280 into a new block of an existing public blockchain 299 (e.g. Ethereum, Bitcoin) when the log entry 280 and its log hash 290 have been generated.
  • the public blockchain 299 serves to provide immutable proof of the contents and date of creation of the log entry 280.
  • every plaintext log entry 280 in the database 220 becomes tamper-evident as any changes to any plaintext log entry 280 in the database 220 would result in a different log hash 290 being generated that would not accord with the log hash 290 already written to the public blockchain 299 for that particular plaintext log entry 280.
  • the log hash 290 is stored together with the log entry 280 in the unique log 222 in the database 220.
  • a blockchain broadcast transaction identity and time of submission are preferably also stored together with the log entry 380 as evidence to show that the log hash 290 was indeed broadcast to the public blockchain 299 and to facilitate search of the log hash 290 in the public blockchain 299.
  • the secured API 270 is preferably further configured to generate (170) the image hash 252 of an image 251 that has been captured of the parcel 300 using the camera 250.
  • Generating the image hash 252 may comprise serializing the captured image 251 (for example into a base64 string) and hashing the variable obtained by the serialization (172) using a Secure Hash Algorithm (e.g. SHA-256).
  • the image hash 252 may be used as at least part of the file name of the image 251 that is stored in the database 220, preferably in JPEG file format, so that the image 251 may be readily retrieved and verified against its hash 252 for a match.
  • the image hash 252 is preferably included as plaintext in each log entry 280 that is created for a given tag 230.
  • the captured image 251 of the parcel 300 is advantageously permanently and securely linked with its basic data so that neither the basic data nor the captured image can be changed for any log entry 280 without resulting in a detectable change in the log hash 290.
  • Including an image hash 252 of the parcel 300 in its unique log 222 advantageously allows reliable verification of the brand, purity and mass data of the parcel 300 in each log entry 380 with the actual data that can be seen in a label on the parcel 300 in the captured image 251 stored in the database 220.
  • each log entry 280 in the database 220 may, in some embodiments, be made publicly available to allow anyone to verify the log hash 290 of that log entry 280 by re hashing the plaintext of that log entry 280.
  • a public user interface 272 operating with a public API 278 on a client machine may be provided to allow users (such as customers owning parcels under the management of the service provider) to access information contained in the unique log 222 for each parcel 300 in the database 220, preferably via the Internet.
  • the public user interface 272 may allow parcels 300 in the vault 220 to be shown, and the public API 278 may be configured to generate reports and allow the display of parcels to be filtered in order to search for a specific parcel in the database.
  • the latest event associated with the tag attached to the parcel may be shown, including the captured image of the parcel (preferably including information as to when, where and how the image was captured).
  • An event history for the parcel 300 may also be displayed, essentially allowing information from the log entries 280 in the unique log 222 of the parcel 300 to be viewed.
  • the public blockchain transaction details and links are shown in order to prove submission of the verifiable log hash 290 of each log entry 280 to the public blockchain.
  • customers can know exactly the situation of any parcels they own and are also able to independently verify the accuracy of events that have been logged for their parcels.
  • the API 270 may be further configured to hash such sensitive or private information (e.g. using SHA-256) so that only their hashes are recorded and shown in the log entry 280 (as shown in the list of key fields of the log entry below).
  • sensitive or private information may include Account Identity (i.e. identity of parcel owner), Device Identity, Operator Identity, Lock Details (e.g. information on any claim(s) that may be made on the parcel, and may even include supporting documentation, such as a scan of an executed contract or a scan of a test certificate).
  • each item of sensitive or private information may have a salt or randomly generated alphanumeric string added to it by the secured API 270 before hashing and the resulting hash included in the log entry 280.
  • the salt may be created using a cryptographic Random Number Generator (RNG) using the implementation provided by a cryptographic service provider (CSP)).
  • RNG cryptographic Random Number Generator
  • CSP cryptographic service provider
  • Service providers may use provider-specific salts to further secure sensitive or private information before hashing and writing these hashes into the log entries.
  • hashing sensitive or private information provides privacy by hiding the nature of the information from unauthorized members of the public
  • the resulting hashes that are made publicly available also provide incontrovertible proof to authorized persons who have access to the unencrypted sensitive or private information that the exact version of that information has been immutably recorded in the unique log 222 of the parcel 300.
  • a prior log hash 290n-i that had been obtained by hashing the prior log entry 280n-i (where available) for a given tag 230 may be automatically included by the API 270 in the plaintext of a current log entry 280 n that is being generated.
  • the log hash 290 n of a current log entry 280 n includes as its input the prior log hash 290n-i of the prior log entry 280n-i, so that any missing or modified plaintext log entry 280 under a given tag 230 becomes apparent when a data hash check is performed.
  • each log entry 280 associated with a parcel 300 may at least partially include some or all of the following items:
  • o Tag Identity comprising identity of the tag associated with and attached to the parcel
  • Event Date and Time preferably in Coordinated Universal Time (UTC)
  • UTC Coordinated Universal Time
  • Event Type which serves to denote the purpose of the entry, and may be in full text format
  • o Initiator Identity comprising the identity of the storage provider or service provider
  • o Device Hash comprising a hash of the Device Identity that preferably recorded for tracking and auditing purposes
  • Operator Hash comprising a hash of the Operator Identity (e.g. login and password) that is preferably recorded for tracking and auditing purposes
  • Storage Provider Identity comprising details of the storage provider, and may be in full text format
  • o Item Type e.g. bar, coin, bulk bag, barrel
  • the service provider manages ownership of the parcel using the present method and system with the aid of components such as account hash, lock status code and lock detail hash that are described in greater detail below
  • Account hash comprising a hash of an Account Identity which identifies the owner or claimant of a given parcel.
  • the account hash may be made known to the owner or claimant to allow them to check on their parcels using the internet, and is essentially a strong anonymous account identifier
  • o Lock Status Code comprising information on whether the parcel is encumbered or subject to a third party claim and the type of claim placed on the parcel.
  • a parcel could be used as collateral for a loan paid out to the owner or claimant or as collateral in conjunction with a blockchain-based asset-backed token trading system
  • o Lock Detail Hash comprising a hash of a soft copy (e.g. pdf scan) of supporting documentation associated with the event (e.g. as a documentation hash).
  • the event comprises a loan using the parcel as collateral
  • the executed loan contract and any other supporting documentation could be combined into a single file that is serialized and the serialization hashed, and the resulting documentation hash is shown in the log entry as the Lock Detail Hash while the hardcopy documents are preferably retained by the service provider.
  • evidence of the loan and contract terms are also made tamper-evident as a hash of the entire log entry including the Lock Detail Hash is broadcast to a public blockchain
  • a new tag 230 is attached to the parcel 300 and associated (120) with the parcel 300.
  • the new tag 230 is then scanned by the scanner 240 and the secured API 270 consequently automatically generates a first log entry 280 for the parcel 300 in association with the identity of the tag 230 attached to the parcel 300.
  • the pure mass of the valuable metal in the parcel 300 is computed (130) and the secured API 270 may prompt the parcel handler to enter basic data about the parcel 300 (such as its brand, type (e.g. bar, coin, ingot), serial number, metal type, mass, percentage purity and computed pure mass).
  • such basic data may be automatically obtained and/or generated using image recognition software that can process a captured image of a label provided on the parcel 300 that contains such basic data.
  • the parcel handler also captures (150) an image 251 of the parcel 300 using the camera 250.
  • the first log entry 280 is then saved in the database 220, thereby creating a unique log 222 of the parcel 300 in the database 220, the unique log 222 containing only one log entry 280 at this time.
  • the first log entry 280 is also automatically hashed (190) by the secured API 270 and the generated log hash 290 is broadcast (199) into a new block of the public blockchain 299 to effectively lock in the contents and date and time of creation of the first log entry 280.
  • Confirmation of addition of the parcel 300 to the inventory of the vault 210 is preferably then transmitted to a service provider who has control or ownership over the parcel 300 as a client of the storage provider.
  • a logistics department of the storage provider may send a vault statement to the service provider listing the parcels that have been inventoried according to the storage provider’s IT system.
  • the vault statement is a document that serves as a foundation for a“claim” event which gives the service provider authority to lock or use parcels under the management of the service provider.
  • This authority is documented by uploading a softcopy or scan of the vault statement, hashing the scanned vault statement and including the resulting hash as one of the fields in a log entry 280.
  • the log entry 280 itself (including the resulting hash of the vault statement) is subsequently also hashed and the resulting log hash 290 broadcast to the public blockchain.
  • Providing the vault statement to the service provider also functions as a quality check as the service provider will have an incentive to verify (via the service provider user interface 225) that the parcel image 252 and parcel basic data have been entered correctly (as an existing log entry 280 in the unique log 222 of the parcel 300). Should there be an error, the service provider will inform the storage provider, and vault personnel using their assigned scanner and login and password can then create a new log entry 280 that is added to the unique log 222 and that shows the corrected data, without modifying the earlier log entry that contained the error.
  • An exemplary subsequent event that may occur for a parcel 300 after its addition to a depository 210 may comprise a metal genuineness test requested by the service provider from the storage provider, which may be particularly desirable for precious metals.
  • Test results may be recorded as a new log entry 280 using the scanner 240 and administrator user interface 260.
  • the API 270 may also be configured to compare the test results with a tolerance database to determine if the parcel is within an acceptable tolerance specific to the type of valuable metal of the parcel 300.
  • a test certificate may be issued after completion of the genuineness test (e.g. as a hard copy and also pdf soft copy), and a documentation hash of the soft copy of the test certificate may be included in the log entry 280.
  • the service provider can decide whether or not to make the test certificate public by including a link to the original plaintext format of the test certificate that may be stored on a server.
  • the tag 230 is scanned (140) and a new log entry 280 is created (160) by the secured API 270 (with input from a parcel handler where applicable) or the new log entry 280 may be created (160) by entering a specific tag identity via the service provider user interface 225 in order to associate the new log entry 280 with the specific tag 230.
  • the new log entry 280 is chronologically added to the unique log 222 in the database 220 for the parcel 300, the new log entry 280 being automatically populated with basic data (and preferably also the image hash 252 of the parcel 300) that are contained in the previous log entry 280, and any other relevant information as described above and given in the list of fields that may be included in the log entry 280.
  • some fields in each log entry 280 may be automatically populated by the secured API 270 without requiring manual entry or selection from dropdown lists by a parcel handler or service provider.
  • identity of the vault 210, time of log entry creation etc. may be automatically provided by the secured API 270, and as mentioned above, basic data and image hash 252 may be obtained by the secured API 270 from a prior log entry 280 in the unique log 222 of the parcel 300.
  • no log entry 280 in the unique log 222 can ever be deleted or amended or overwritten without changing its hash 290. If a prior log hash is 290 also included as part of a particular plaintext log entry 280, then changing that log entry 280 in any way not only changes its hash 290 but also invalidates all subsequent hashes of subsequent log entries 280 in the unique log 222. If any error is detected in an existing one or more log entries 280 for a parcel 300, correction comprises simply scanning the tag 230 associated with the parcel 300, creating a new log entry 280 with the corrected information, and writing the log hash of the new log entry to the public blockchain 299.
  • the erroneous one or more log entries 280 continue to remain in the unique log 222 as a historical record of the error and is never removed or amended or overwritten. For example, it may be possible that some basic data about the parcel 300 was incorrectly entered in the first log entry 280 generated for the parcel due to human error. If the error is not subsequently detected, the error will be perpetuated into subsequent log entries created for the same parcel, due to the basic data from each prior log entry being automatically copied by the secured API 270 into each subsequent new log entry that is created. When the error is eventually detected, as mentioned above, a new log entry is created that corrects the error in the basic data of the parcel. Going forward, the next log entry that is created for the parcel would copy the correct basic data from the prior (correct) log entry. Subsequent log entries will also continue to be automatically populated with the correct basic data from each of their prior log entries.
  • the present method and system thus faithfully preserve past records to the very second of their creation, and provides a truly immutable system that is exceedingly compatible with the writing of the log hash of each log entry to the public blockchain to further secure the system.
  • the present method and system also allow for efficient retrieval of system status at any point in time using arbitrary time values. For example, an exact system status as of December 5, 2018 as of 15:34 and 34 seconds can be obtained with no loss of performance whatsoever.
  • the method and system may appreciably be implemented for multiple depositories operated by multiple storage providers, and also by multiple service providers using the storage services provided by multiple storage providers at the same time to store and manage multiple parcels, as shown in FIG. 4.
  • the system is readily customizable to provide each service provider with their own brand-specific service provider user interface and public user interface. In this way, without requiring substantial modification of the system and method, different service providers and their customers may experience different user interfaces respectively, the user interfaces being designed to appear unique according to the brand style of each service provider while the system is supporting different service providers at the same time.
  • parcel logs 222 can be readily filtered or categorized by service provider identity. In this way, no mix-ups occur when one vault stores parcels managed by multiple service providers.
  • data in the unique logs 222 of the parcels 300 can also be easily filtered across time, events and entities, thereby allowing complex permission requirements to be elegantly handled.
  • the method and system therefore allow valuable metal assets stored at different storage providers to be transparently digitized, and allow different service providers to offer their brand-specific services that require transparent asset collateralization, such as peer-to- peer lending, metal testing, and asset-backed token trading. Whilst there has been described in the foregoing description exemplary embodiments of the present invention, it will be understood by those skilled in the technology concerned that many variations and combination in details of design, construction and/or operation may be made without departing from the present invention.

Landscapes

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

Abstract

L'invention concerne un procédé et un système de stockage et de gestion de métaux de valeur, lequel système enregistre de manière immuable et transparente tous les événements et toutes les transactions sur des quantités physiques réelles de métal de valeur stockées dans un ou plusieurs dépôts. Un enregistrement d'un nouvel événement ou d'une nouvelle transaction associé(e) à tout paquet de métal de valeur dans le ou les dépôts est créé sous la forme d'une entrée de fichier journal, et chaque entrée de fichier journal est stockée de manière immuable dans une base de données par hachage de l'intégralité de l'entrée de fichier journal à l'aide d'un algorithme de hachage et par diffusion du hachage résultant à une chaîne de blocs publique en tant que preuve immuable de la création et du stockage de chaque entrée de fichier journal. De cette manière, toute modification d'une entrée de fichier journal dans la base de données peut être détectée par hachage de l'entrée de fichier journal et comparaison du hachage résultant avec le hachage qui a déjà été diffusé à la chaîne de blocs publique, étant donné qu'un hachage est une chaîne unique générée à partir d'un corps spécifique d'informations et que le hachage change si les informations qui sont hachées sont modifiées.
PCT/SG2019/050008 2019-01-07 2019-01-07 Procédé et système de stockage et de gestion de métaux de valeur WO2020145881A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/SG2019/050008 WO2020145881A1 (fr) 2019-01-07 2019-01-07 Procédé et système de stockage et de gestion de métaux de valeur
PCT/SG2019/050245 WO2020145887A2 (fr) 2019-01-07 2019-05-02 Cryptomonnaie adossée à des actifs

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2019/050008 WO2020145881A1 (fr) 2019-01-07 2019-01-07 Procédé et système de stockage et de gestion de métaux de valeur

Publications (1)

Publication Number Publication Date
WO2020145881A1 true WO2020145881A1 (fr) 2020-07-16

Family

ID=65033640

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/SG2019/050008 WO2020145881A1 (fr) 2019-01-07 2019-01-07 Procédé et système de stockage et de gestion de métaux de valeur
PCT/SG2019/050245 WO2020145887A2 (fr) 2019-01-07 2019-05-02 Cryptomonnaie adossée à des actifs

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/SG2019/050245 WO2020145887A2 (fr) 2019-01-07 2019-05-02 Cryptomonnaie adossée à des actifs

Country Status (1)

Country Link
WO (2) WO2020145881A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115456802A (zh) * 2022-09-22 2022-12-09 中航信移动科技有限公司 一种基于数字货币的保险事件处理系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220309489A1 (en) * 2021-03-23 2022-09-29 David Brener Kahn System and method for valuing and regulating a data asset backed cryptocurrency
WO2022225840A1 (fr) 2021-04-22 2022-10-27 Fueltrust, Inc. Analyse chimique basée sur l'apprentissage machine et un nœud multi-locataires sur un réseau privé de bases de données distribuées, vérifiables et immuables
US20220351119A1 (en) * 2021-04-29 2022-11-03 Texas High Tech Holdings, Inc. Non-Fungible Tokens for Tracking Fungible Assets
WO2023225088A1 (fr) * 2022-05-18 2023-11-23 Schorr Paul Carl Iv Procédés et systèmes pour fournir une réserve à une plateforme tokénisée

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018064645A1 (fr) * 2016-10-01 2018-04-05 3Dpp, Llc Emballage activé par chaîne de blocs & fabrication distribuée
WO2018064329A1 (fr) * 2016-09-30 2018-04-05 Chronicled, Inc. Registre ouvert pour l'internet des objets comprenant des matériaux scellés

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018064329A1 (fr) * 2016-09-30 2018-04-05 Chronicled, Inc. Registre ouvert pour l'internet des objets comprenant des matériaux scellés
WO2018064645A1 (fr) * 2016-10-01 2018-04-05 3Dpp, Llc Emballage activé par chaîne de blocs & fabrication distribuée

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115456802A (zh) * 2022-09-22 2022-12-09 中航信移动科技有限公司 一种基于数字货币的保险事件处理系统
CN115456802B (zh) * 2022-09-22 2024-01-26 中航信移动科技有限公司 一种基于数字货币的保险事件处理系统

Also Published As

Publication number Publication date
WO2020145887A2 (fr) 2020-07-16

Similar Documents

Publication Publication Date Title
WO2020145881A1 (fr) Procédé et système de stockage et de gestion de métaux de valeur
US8432257B2 (en) Merchandise-integral transaction receipt and auditable product ownership trail
US20120059693A1 (en) System and method for inventory and return of lost items
CN108573741A (zh) 业务数据记录方法、装置、设备和存储介质
US20040153650A1 (en) System and method for storing and accessing secure data
CA2567285A1 (fr) Procede et dispositif de suivi de documents de securite
US11526860B1 (en) Mobile cash deposit system and method
US20150066797A1 (en) System and method for enhancing delivery security and preventing fraud
JP7085687B2 (ja) 個人情報管理システム、個人情報管理装置、および個人情報管理方法
US20200051092A1 (en) System and method for product recall using blockchain
JP6483754B2 (ja) 取引管理システム、取引管理方法、及びそのプログラム
JP5412876B2 (ja) 預かり物管理システム、当該預かり物管理システムに供するサーバ及びプログラム
JP2008525890A (ja) 金融上のトランザクションに関する資金リソースを検証するための装置及び方法
US20140379381A1 (en) Method for Allowing Consumer Control Over Personal Healthcare Information
US20230325838A1 (en) Systems and methods for validating an instrument
US20170161754A1 (en) Counter fraud systems
US20230325839A1 (en) Systems and methods for evaluating legitimacy of interactions to reduce fraud
JP5179201B2 (ja) 確認サーバ、取引端末、プログラム、取引システム及び本人確認方法
JP6130888B2 (ja) 個人情報保護営業支援システム
CN114026585A (zh) 通信系统、通信方法以及传感器单元
US11756127B1 (en) Systems and methods for managing financial transaction information
JP6925496B1 (ja) 情報処理装置、プログラムおよび情報処理方法
US20220198167A1 (en) Method and system for registering and authenticating items
US20220343419A1 (en) Method and product for tracking currency transfer
AU2017100000A4 (en) QuodR is a software package designed to prevent insurance fraud and the trade of stolen goods in our communities, World-Wide.

Legal Events

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

Ref document number: 19700851

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19700851

Country of ref document: EP

Kind code of ref document: A1