MANAGEMENT

FIELD

This invention relates to a method and a system for valuable metal storage and management.

BACKGROUND

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. Currently, 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. For example, even banks have been known to have sold precious metal bullion to customers and charged storage fees for safekeeping of the bullion on their customers’ behalf, when the banks had not actually purchased any bullion and were not in fact keeping any bullion in storage. The customers had thus been paying for purchase and storage of “phantom” bullion, and had effectively only bought non-interest- bearing bonds in the precious metal, as opposed to a physical quantity of the precious metal itself. There is thus a demand for a method and system for valuable metal storage and management and/or trading that immutably and transparently digitizes the valuable metal and allows service providers to offer services that require transparent asset collateralization.

SUMMARY

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. In this way, 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. Any error in an earlier log entry is allowed to remain as such and correction simply comprises the creation of a new log entry containing the corrected information without modifying the erroneous earlier log entry in any way. The method and system thus provide an incontrovertible record of all events and transactions associated with any parcel of valuable metal in the one or more depositories, thereby minimizing any possibility of fraud or disputes.

According to a first aspect, there is provided a method of valuable metal storage and management, the method comprising the steps of:

(a) creating a log entry for each event that occurs for a parcel stored in a depository, the parcel comprising a number of units of the valuable metal, the parcel having a tag attached thereto and associated with an identity of the tag, wherein the log entry is created in association with the identity of the tag;

(b) storing the log entry in a unique log of the parcel in association with the identity of the tag;

(c) hashing the log entry to obtain a log hash of the log entry; and

(d) broadcasting 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 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.

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.

According to a second aspect, there is provided a system for valuable metal storage and management, the system 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.

BRIEF DESCRIPTION OF FIGURES

In order that the invention may be fully understood and readily put into practical effect there shall now be described by way of non-limitative example only exemplary embodiments of the present invention, the description being with reference to the accompanying illustrative drawings.

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.

DETAILED DESCRIPTION

Exemplary embodiments of 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. Throughout this application, 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. For example, 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.

In an exemplary embodiment of the method (100) and system 200 as shown in FIGS. 1 and 2, a depository 210 operated by a storage provider is provided for storage of parcels 300 therein. Notably, the method (100) and system 200 operate independently of any proprietary IT (information technology) system of the depository 210. In the exemplary embodiments described below, 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.

In the method (100), pure mass (i.e. mass of pure elemental metal) in each parcel 300 is computed (130) from the actual total mass of the valuable metal in the parcel 300 and its percentage purity, using equation (1) below:

Pure mass (g) = Number of units x Actual Mass of each unit (g) x Purity (%) x 0.01 - (1)

For example, 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.

In another example, 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.

In a further example, 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. In the event that a tag 230 is damaged or needs to be replaced for whatever reason, 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. In an exemplary embodiment, 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. Preferably 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. In an exemplary configuration where the parcel 300 comprises a number of relatively small pieces of bullion 302, as shown in FIG. 3, 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. In another example where the parcel 300 comprises a single metal bar (not shown) that is not contained in a bag, 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. Preferably, 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.

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. Preferably, the administrator user interface 260 is configured to communicate with the database 220 via a wireless connection, e.g. Wi-Fi. As indicated by the dash-dot line in FIG. 2, 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.

In a preferred embodiment, 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. In another embodiment (not shown), 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. In a further embodiment, the scanner, the camera and the administrator user interface 260 may be together provided in a single instrument. In an alternative embodiment, (not shown), 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). For example, 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. In a preferred embodiment, 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. For example, 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. When 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. In this way, 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. For example, 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).

As shown in FIG. 2, 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. Preferably, authentication by the service provider is required, e.g. by entering a service provider login and password via the service provider user interface 225, similar to authentication by the parcel handler. 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. In this way, 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. Thus, there is no so-called“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. In this way, 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. In an exemplary embodiment, 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). In an exemplary embodiment, 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. In this way, 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.

Notably, the plaintext of 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. For example, 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. Upon selection of a specific parcel among the displayed parcels, 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. Preferably, 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. Via the public user interface 272, 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.

As added security to prevent unauthorized third parties from using publicly available hashes to guess at sensitive or private information in the plaintext log entries 280, 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). For example, 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). Furthermore, 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)). Service providers may use provider-specific salts to further secure sensitive or private information before hashing and writing these hashes into the log entries. Notably, while 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.

As a further layer of security to the unique log 222 for every parcel 300 in the database 220, 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. In this way, 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.

In an exemplary embodiment, the fields in each log entry 280 associated with a parcel 300 may at least partially include some or all of the following items:

• Key fields:

o Tag Identity, comprising identity of the tag associated with and attached to the parcel

o Parcel unique serial string as described above

o Prior log hash (if available)

• Event fields:

o Event Date and Time, preferably in Coordinated Universal Time (UTC) o 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

o Operator Hash, comprising a hash of the Operator Identity (e.g. login and password) that is preferably recorded for tracking and auditing purposes

• Parcel fields:

o Storage Provider Identity, comprising details of the storage provider, and may be in full text format

o Item Quantity, comprising the number of units of valuable metal in the parcel o Actual Mass o Purity

o Pure Mass

o Metal Type

o Brand, comprising the brand name of the manufacturer

o Item Type (e.g. bar, coin, bulk bag, barrel)

o Serial Number

o Image Hash

• Usage fields:

o Service Provider Identity. 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

o 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. For example, 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). For example, where 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. In this way, 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

As an example of use of the method (100) and system 200 described above, when a new parcel 300 is first added to the vault 210, 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). Alternatively, 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. Preferably, when a new parcel 300 is first added to the vault 210, 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. For example, 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.

For each event that subsequently occurs for every parcel 300 that has already been added to the vault 210, either 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. As described above, 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. It should be noted that 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. For example, 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.

The examples above show the elegance of the present method (100) and system 200, as event information together with supporting documentation where relevant may be added to the unique log 222 of each parcel 300, either as plaintext or as a hash, while requiring little to no changes to be made to the system 200 itself. New additions do not impact old records and the nested hashes of documents and log entries provide incontrovertible evidence in case of disputes that may be taken to a court of law.

Appreciably, using the method (100) and system 200 disclosed above, 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. In this way, 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.

Although the above embodiments have been described with reference to a storage provider operating a depository (such as a vault) and a service provider using the depository to store parcels therein as a client of the storage provider, 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. Furthermore, by including fields in the log entries 280 such as entity identity to identify the service provider who manages each parcel, 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. In the present method and system, 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.