WO2018128539A1

WO2018128539A1 - A method for checking and/or updating information relating to assets

Info

Publication number: WO2018128539A1
Application number: PCT/MY2017/050069
Authority: WO
Inventors: Rene F BERNARD; Jeffrey Thomas MCDONALD
Original assignee: Bernard Rene F; Mcdonald Jeffrey Thomas
Priority date: 2017-01-08
Filing date: 2017-11-01
Publication date: 2018-07-12

Abstract

A method for checking and/or updating information relating to assets using a multisignature asset account on a blockchain to which messages are sent to update information, transfer ownership, and/or provide authenticity of the asset, subject to approval of the owner of the multisignature asset account.

Description

A METHOD FOR CHECKING AND/ OR UPDATING INFORMATION

RELATING TO ASSETS

Field of Invention

The invention relates to a method for checking and/or updating information relating to assets.

Background

At present when a person buys an asset such as a watch or other product, they may be given a certificate of authenticity by the manufacturer. The watch may be stamped with a serial number which corresponds to the same number printed on the certificate.

However, unless the person registers their details with the manufacturer, the manufacturer tends to lose track of the product after it is sold. Even if the person has registered their details on purchase, they are often not updated if the person changes address, or sells the product to a third party.

In addition, high- value goods in particular are often the subject of counterfeiting, which causes losses to manufacturers.

As a result, it can be difficult for someone purchasing a product second-hand to verify the authenticity of the watch and the identity of the seller as the rightful owner, which is a particular issue if the product was lost or stolen. An aim of the invention therefore is to provide a method for checking and/or updating information relating to assets which overcomes the above issues.

Summary of Invention

In an aspect of the invention, there is provided a method for checking and/or updating information relating to assets comprising the steps of:

creating a seed for an asset account on a blockchain by combining the asset's unique identifier with other details;

hashing the seed and generating an asset account on a blockchain therewith; converting the asset account to a multisignature asset account;

wherein a message can be sent to the multisignature asset account to update information and/or the owners of the multisignature asset account can be edited to transfer ownership of the asset, subject to approval of the owner of the multisignature asset account, and/or said information may be used to verify the authenticity of the asset.

Advantageously the method allows a manufacturer to create a digital certificate of an asset using an account in a blockchain. Initially the account is owned by the manufacturer, but when the asset is sold to a dealer, the account is transferred to the dealer. Similarly, the account is transferred to a user when the asset is sold to that user. Blockchain technology ensures immutability of data, and public auditability when required. Therefore as blocks cannot generally be retrospectively altered, the user can check the authenticity of the asset through the public key of the blockchain. A further advantage is that the information is stored within the blockchain itself - updates are stored as new transactions. If a central ledger (containing the information) linked to the blockchain via the hashes was used instead, the information would be lost if the ledger, or authority controlling it, became unavailable. In one embodiment the blockchain includes On-Chain-Multisignature properties such as found in the NEM blockchain project. So called 'Mosaics' as for example found in NEM are essentially named digital assets on the blockchain, and not on a secondary layer. These can represent any kind of asset that a company would like to issue. They can have customizable names, descriptions, divisibility, quantities as either fixed or mutable, and transferability restrictions if necessary, and can have levies applied to them or be levies themselves on other mosaics.

In one embodiment the multisignature asset account can be signed by m of n account signatories. Typically m and n are any number from 1-32.

Unlike other blockchain solutions, the multisignature asset account is not created by combining public keys from other accounts. Instead, a pre-existing and funded address is converted into a multisignature account and the cosignatories are assigned to it. The cosignatories can be assigned in any m-of-n combination where both the m and n can be any number of 1-32. This includes 1-of-l as the account being turned into a multisignature account has its private key nullified; meaning it no longer has any power to initiate transactions. Only a cosignatory's private key can initiate transactions on the multisignature account's behalf - by analogy this can be thought of as parent/child accounts, where the parent accounts are the cosignatories and can make the child account make any transaction. As such a dedicated account representing a blockchain notarization can receive messages to update the blockchain notarization, and can receive assets/mosaics sent to the dedicated account locking in value or adding status to the blockchain notarization. In addition, the dedicated blockchain notarization account can be transferred from person to person. This means that the account is no longer "just an account" but instead is a certification account representing the state of the underlying content to which it is linked. In one embodiment the asset manufacturer creates the seed and the unique identifier. Typically a token, message, or cryptocurrency is sent to the asset account to verify that the asset is genuine.

In one embodiment the seed is converted into a private key by hashing it with a proven hashing function e.g, SHA256 and declaring the digest (or a truncated version of it) as the asset account's private key. Typically repeated hashing processes are used to generate the public key and asset account network address. This approach ensures future easy retrieval of the asset's blockchain account address (and it's public and private key), which can be useful for tracing information about any given asset solely based on knowledge of the item's properties e.g. manufacturer, name, serial number. Reproducibility of the hashing process must be ensured with the operational business policy for syntaxing assets for hashing, The reproducibility for creating asset accounts can be processed in varying levels of encryption so that they may be designed to be fully auditable by the public or only revealed with the publication of a salt or additional password.

In one embodiment the seed that is hashed to create the private key can also be written in plain text, as a message in the account made by that seed, making it auditable by anyone. In one embodiment the messages are time-stamped in the blockchain. Typically the messages include the address of sender. Advantageously this creates a transparent and auditable record of the message senders. In one embodiment the asset manufacturer can register an exclusive domain name on the blockchain using a Namespace, which resolves to the manufacturer's account address on the blockchain. Advantageously this allows a third party to authenticate the product by identifying the manufacturer (or its brand) associated therewith. In one embodiment a public blockchain is provided. In another embodiment a permissioned blockchain is provided. Typically, anchoring technology can be used to link public and/or permissioned blockchains to each other.

In one embodiment, the owner of the multisignature asset account can transfer ownership thereof to a third party. Typically the third party is the new owner of the asset.

In one embodiment ownership is transferred by editing the multisignature asset account to remove past owners and add new owners, or to split ownership of the multisignature account asset.,

In one embodiment authenticity of the asset is verified using the information used to create the multisignature asset account and/or memos added thereto.

In one embodiment the messages can include information relating to the history of the asset. For example the information could include maintenance records for machines represented in certification accounts, warranty information for consumer products, road tax paid where the asset account represents cars, and the like.

In a further embodiment the asset may be a contract. Multiple parties make a multisignature asset account together, create the contract, jointly sign it andjointly upload its fingerprint onto the blockchain to the contract's account from their shared multisignature asset account. This acts as proof that all parties agreed to the contract at the time it was signed. The most elegant solution is for each party to own their own unique namespace, so that they may sign the contract with a registered account, but that is not a requirement.

Typically the information may be encrypted, unencrypted, or a combination of both.

In one embodiment the manufacturer is maintained as a signatory on the multisignature asset account irrespective of the ownership, to enable the manufacturer to track movement of the asset through a second-hand market. In one embodiment the manufacturer can provide information about assets to the point- of-sale which checks the corresponding blockchain so that purchasers of the assets can be notified of any issues. Therefore if an asset is subject to a recall, the purchaser can be notified when they attempt to buy it. In one embodiment the information includes details of the certifier of the asset. This may be the manufacturer or an authorised third party, and will help ensure that the certifiers do not certify counterfeit assets as they can be traced through the immutable blockchain.

Brief Description of Drawings

It will be convenient to further describe the present invention with respect to the accompanying drawings that illustrate possible arrangements of the invention. Other arrangements of the invention are possible, and consequently the particularity of the accompanying drawings is not to be understood as superseding the generality of the preceding description of the invention.

Figure 1 is a block diagram illustrating certification of a manufacturer's identity in a blockchain.

Figure 2 is a block diagram illustrating the process of registering a product's unique identifier in a blockchain.

Figure 3 is a block diagram illustrating transfer of a multisignature asset account. Figure 4 is a block diagram illustrating the update of information on a multisignature asset account

Figure 5 is a block diagram illustrating authentication of assets

Figure 6 is a block diagram illustrating backup methods (a) using a direct process; (b) using the private keys; (c) via conjoint owner.

Detailed Description

With regard to Figure 1, the manufacturers can register an exclusive domain (name) on the blockchain using a Namespace. This exclusive domain resolves to the manufacturer's account address on the blockchain. The domain then represents the manufacturer's 'brand' which will be useful for consumers to identify the real manufacturer of a particular product through the Verification process described herein.

Manufacturers are encouraged to publish their account address and Namespace to the public using any general means e.g. on their website in order to allow consumers to easily identify themselves as being the authenticated manufacturers holding the given (branded) account on the blockchain.

In order to provide enhanced verifiability of the manufacturer's blockchain account genuinity, they can request an endorsing party to endorse the legitimacy of the account and or domain name (namespace) allocation. The endorsing party should preferably be a publicly trusted entity (e.g. government business registry) to credibly confirm the valid endorsement. The endorsement is conducted through the endorsing party sending messages to the manufacturer certifying the manufacturer as the legitimate manufacturer, the entity it claims to be. The messages could potentially include business registration number, date of incorporation or any info of relevance to external parties in verifying the manufacturer in question. Obviously, in order for the transaction of messages to happen, the endorsing party, as well as the manufacturer, must both have an account on the blockchain. The process of sending any messages to the manufacturer could potentially require some transaction fees, depending on how the blockchain is set up. With reference to Figure 2, there is illustrated the process of creating a hierarchical deterministic account for a digital certificate on the blockchain, in order to register a product's unique identifier such as serial number to the blockchain. This process starts at the manufacturing level where usually the product manufacturer is tasked to put a form of unique identifier (i.e. ID) to the aforementioned product, which is already an existing process for some current products.

From this identifier (usually in the form of numbers), the manufacturer which already has an account on the blockchain will combine certain information as preferred to be used as a 'seed' in generating a new account on the blockchain. The manufacturer's account or any personal account is created on the blockchain through the general account creation process and undergoes common account backup measurements. The 'seed' will be hashed to generate an 'Asset Account'. The Asset Account, like any other account on the blockchain, will have a public key and a private key. In most cases, in order to make this account known to the blockchain, a token, message or a cryptocurrency must be sent to the Asset Account. This task is usually done by the manufacturer in order to leave an audit trail for consumers (potential owners of the product) to verify that the product is genuinely added on the blockchain by the manufacturer in the Verification process. The Asset Account will then be converted into a multisignature account by the manufacturer who has the keypair of the Asset Account. The multisignature process is highly recommended to be done using a blockchain with an on-chain multisignature functionality. The converted Asset Account, known as Multisigged Asset Account (MAA) will lose its ability to make transactions, thus making the private key obsolete. The manufacturer who owns an (potentially Namespace) account on the blockchain, will be the sole signatory (1-of-l multisignature) of the account thus being the only account who can initiate transactions on behalf of the Multisigged Asset Account. The ownership of an MAA represents the ownership of the product the MAA is representing, hence in this context; the current owner of the product is the manufacturer.

With regard to Figure 3, transfer of the MAA happens in a straight-through transaction process between two parties, namely in this context Person A and Person B. Person A could be the manufacturer in this case who created the MAA, or could be another person who has already received MAA from a prior transfer transaction, Person B is a new party which has created an account and would like to receive the MAA. The current owner of the MAA, Person A, which owns a personal account on the blockchain that has 1-of-l control of the MAA will transfer the 1-of-l control to Person B. This will result in Person A to lose control of the MAA hence losing ownership of the asset the MAA represented. Person B, which now has full control (1-of-l multisignature ownership) of the MAA is considered the new rightful owner of the product the MAA is representing. The transaction process can happen for multiple parties with multiple ownership of the product. Hence, it is possible for the transfer of ownership to be m-of-n (representing Party A) to a different m-of-n (representing Party B), where m and n can be a combination of any number. These combinations would highly depend on how the account ownership is structured as a particular MAA might have multiple cosignatories including the manufacturer (for customer service purposes), manufacturer or third-party backup cosignatory services and conjoint owners.

With respect to Figure 4, one of the advantages of the invention is ability to update new information to the Multisigged Asset Account, thus making information of a particular product updatable throughout the lifetime of the product. This feature is particularly important for products like cars which will likely to undergo multiple repairs and maintenance throughout its lifetime, a feature highly beneficial for potential buyers of the product to know. All new information of a particular product can be directed to the product's MAA which will make all this new information properly organized with time- stamped messages from a (potentially known) sender on the blockchain. In handling potential spam messages to a particular account (especially MAA), the system can be structured to only display messages from authorized participants, differentiated through different means such as Namespace, or assets created by official namespaces giving rights to others to update an MAA.

The process of updating a MAA account with new information is a direct process that requires minimal steps to be completed. Party A is the owner of the MAA (through m-of- n multisignature ownership) while Party B (i.e. mechanic, manufacturer, etc) is a party that is potentially interested or tasked to add in new updates to the account. In this process, Party B just needs to send a message/messages to MAA, where the address and/or public key of the MAA are known by Party B. In order to send messages, Party B might incur transaction fees depending on the blockchain used. The messages sent by Party B could be openly auditable or have varying levels of encryption depending on the preference of the parties involved. As reiterated previously, all messages sent to the MAA are properly time-stamped to the blockchain including the address of the sender, hence creating a transparent and auditable record of the sender of messages.

With regard to Figure 5, the Verification / Audit process is an important feature that materializes the value of having a Multisigged Asset Account (MAA) which represents a real product. The process of verification requires a two-way interaction of Party A which owns the product and Party B which is interested to know the authenticity or any claims by Party A regarding the product. In order to do this, Party A needs to provide Party B with relevant information that allows Party B to identify the MAA on the blockchain. This information might also include encryption password for the messages in the MAA. Party B which gains all the relevant information to identify the MAA on the blockchain can audit the claims (such as ownership) of the MAA of Party A. As MAA could potentially contain information that is highly relevant in the lifetime of the product it is representing (especially involvement / existence of the manufacturer), this provides greater transparency and trust for Party B regarding claims made by Party A for that particular product.

With reference to Figures 6a-c, The backup process is a highly recommended but optional process to ensure greater user experience for the consumers of the product. The process ensures that if the real owner of the product which owns a personal account controlling a Multisigged Asset Account through multisignature loses its private key, the owner has multiple means of claiming ownership of the MAA thus the product itself. Four methods to backup and recover users/owners private key, are suggested below.

1. Unannounced signed and encrypted transaction (transferring ownership to manufacturer's recovery centre or owners' new account)

Figure 6a illustrates a direct process where Party A which owns a personal account on the blockchain will create and sign a transaction and retain it for future transmission into the blockchain network. The unannounced transaction should contain instructions to transfer the ownership of the MAA to a different account (that could be owned by the manufacturer, the owner's new account, etc). Party A can potentially retain and store the transaction announcement by any means either personally (for example, storing the announcement in a USB drive), on a blockchain (encrypted and stored for a later announcement) or with the product's manufacturer (customer service). The structure for the instruction of the unannounced transaction can be determined based on the preference of the owner or the manufacturer. In recovering the ownership of the MAA, the owner just needs to have access to the unannounced transaction and transmit the announcement transaction to the blockchain. The announcement of the transaction will transfer the ownership of the MAA to a new account such as the owner's new uncompromised account, the manufacturer's customer service account or any other potential account that could transfer the ownership of the MAA to the rightful owner of the real asset.

2. Encrypted backup of owners' private keys (for example messaging the encrypted private key to the account itself) Figure 6b illustrates the simple and straightforward process of backing up an account owner's private keys. This process allows the owners to easily recover the private key of their account which controls or partially own the Multisigged Asset Account (MAA) on the blockchain. In order to do the backup, Party A which is the owner of a personal account that controls a MAA on the blockchain, must encrypt and store the account's private key on the blockchain. It is highly recommended that the private key is stored inside the MAA for easier identification of the owner. The storing process involves messaging the encrypted private key, to the blockchain (for example, messaged to the Multisigged Asset Account) . In order for the owner to recover the ownership of the MAA, the user just needs to have access to the blockchain and decrypt the encrypted private key located on the blockchain (i.e. on the MAA).

The clear advantage of implementing this process is the owner can simply execute them without involving the manufacturer throughout the backup and recovery process. This process is highly useful in ensuring a perpetual backup can be potentially and constantly made throughout the lifetime of the product, and beyond the lifetime of the manufacturer.

3. Conjoint ownership structure through any m-of-n combination

Figure 6c illustrates a tailored solution that would depend on the needs and preference of the parties involved (i.e. manufacturer, consumer, etc). Leverage on the multisignature functionalities can be done on a blockchain to create different channels of backup with multiple accounts. These accounts would have a 1-of-n ownership/control of the MAA, hence making it possible to execute transfer of ownership of the MAA without the main account held by the owner.

A potential structure for this conjoint ownership process is the owner, Party A, which owns the real asset and controls the MAA that backs the asset, creates and own a backup account which also has control of the MAA. The backup account can be made using the brainwallet model, where the owner can choose a passphrase and use it as a seed to generate the private key of the backup account. Additionally, in case the owner lose access to both main personal account and backup account, the manufacturer which still has l-of-n control of the MAA can still perform a transaction to return the MAA to a new account owned by Party A, the rightful owner.

4. Main private key generated from salted passphrase

In this process, a user (i.e. consumer) creates an account on the blockchain through the channels provided by the manufacturer (i.e. from downloading the app of the manufacturer or using the manufacturer's web portal). Next, the user creates or is given a multiple word passphrase that is used to generate an account through the general passphrase process. A salt could potentially be added to the passphrase in this process for enhanced security. Similar to the general account creation process through passphrase, an account address is derived from a public key, while a public key is derived from private key and a private key is derived from a passphrase. Depending on the structure, the user can choose to opt-in or automatically enrolled to a backup recovery services provided by the manufacturer or a recognized and trusted third party. Passphrase information stored with the backup recovery services is encrypted with a salt co-created by the manufacturer and the user (i.e. consumer). In recovering the passphrase the user or manufacturer can later use this information to regain ownership/control of the MAA. As indicated above, there are multiple ways to backup the ownership of the MAA and this backup process can be done concurrently based on the needs and preference of the parties involved (i.e. owner, manufacturer, etc). It is highly recommended that the backups are done on a public blockchain to ensure a greater perpetual propensity of the backup, which in turn benefits the owner the most.

A specific example use of the invention, referred to as LuxTag, is described below in connection with a luxury item, in this case a watch.

1. Manufactures ("M") holds a branded (registered with the namespaces service and confirmed on their publication materials) account

2. M creates real world asset (the item, the watch)

3. M creates digital representation account of the item on the blockchain, known as the "asset account".

4. M converts that asset account into 1-of-l multisig, where the asset account's private key's functionality is invalidated through the multisig contract and the only party allowed to operate the asset account (e.g. send messages from it) is the custodian (=owner).

5. M is owner of that digital asset as well as the real world asset

6. M sends a plaintext blockchain message from their account to the asset account (e.g. "Today we created the watch Sample Manufacturer Model Sample Watch 2016 S/N 123123".)

7. M ships to dealer (D)

8. M adds ownership of the dealer in real life and on the blockchain (via transfer of ownership and change of multisig-rules allocation for the asset account). M adds D's account to the multisig contract and makes it a l-of-2 co-signing ownership account.

9. D is new co-owner of the watch

10. D sells watch to first buyer, consumer (Gl) D asks C 1 to install mobile app or create an ownership account via web app CI chooses backup seed passphrase which hierarchically divulges into a full account.

D also asks CI to sign up for M's recovery service (Mx) for extra security. D adds Mx and removes M from the multisignature account.

D transfers ownership to CI by removing itself and adding CI as a cosigner on the asset account along with giving the realworld watch. (*)

Dx (Dealer x, who holds a registered account on the blockchain and is entitled to do repairs, e.g. authorized by manufacturer) repairs the consumer product.

Dx sends a message to the asset account with information about the repair. CI and (every subsequent future owner) can see information about such repair(s) Watch is stolen

CI calls his insurer and registers the stolen asset.

CI (using his app) transfers ownership of the watch to the insurer and sends a message to the asset account stating the fact that the item was stolen and if applicable, adds the police report number.

(When applicable) Insurer pays contracted insurance fulfilment sum to CI Thief (T) attempts to pawn the stolen watch using his identity

Pawn shop (P) verifies the asset via LuxTag Blockchain technology

P looks up hash syntax at manufacturer's website (or straight away uses manufacturer web app to verify watch data).

P hashes watch data to get watch account no.

P checks information about the watch on the blockchain and confirms it is enrolled to the LuxTag system.

P sees the message about recent theft and police report no.

P asks customer T whether he is ready to transfer ownership via his app and/or login to the manufacturer's web app in order to pawn it.

T doesn't have a clue.

P tries to win time and keep T in his shop.

P calls police

T gets detained by police for questioning minutes later.

Watch can be returned to its owner, the Insurer - or the legal owner CI .

Transfers of ownership CI - C2 are possible at any time, 36. Manufacturer M can trace all events which happen to the item for which they initially created the blockchain asset account using his blockchain account explorer app (data can be populated as operationally required) ("Big Data" analysis of second-market transactions and events related to the item)

(*) The account is now a l-of-2 multisig account with CI and Mx being the two signers. CI is the owner of the watch and its paired asset account. If CI loses access to the seed passphrase and app, they can contact the manufacturer and use Mx to restore the asset account on a new phone.

Modelled on the above example mentioning Luxury items, LuxTag can be applied to consumer electronics items to assure genuinity, track legal ownership and record warranty repairs, etc. via blockchain messaging to the notebook PC's dedicated account on the blockchain.

LuxTag can also be applied to private and commercial vehicles. VIN Nos. can be the seed for private key, public key and account creation. Road Tax, insurance information, maintenance, and the like can be communicated directly via blockchain messaging to the vehicle's account and verified e.g. by police using account data lookup. Second-hand buyers of private cars could trace the maintenance history of cars and further verify the seller is the legitimate owner.

In addition LuxTag can be used for tagging heavy machinery and e.g. gas turbines. Maintenance conducted would be recorded on the turbine's blockchain account and manufacturers can control the use of their products through maintaining a co-signing ownership over the item. Or, manufacturers can restrict certain use cases for dual-use products by prohibiting their transfer to non-authorized owners,

It will be appreciated by persons skilled in the art that the present invention may also include further additional modifications made to the system which does not affect the overall functioning of the system.

Claims

A method for checking and/or updating information relating to assets comprising the steps of:

hashing the seed and generating an asset account on a blockchain therewith; converting the asset account to a multisignature asset account; wherein a message can be sent to the multisignature asset account to update information and/or the owners of the multisignature asset account can be edited to transfer ownership of the asset, subject to approval of the owner of the multisignature asset account, and/or said information may be used to verify the authenticity of the asset.

The method according to claim 1 wherein the multisignature asset account signed by m of n account signatories.

3. The method according to claim 1 or 2 wherein a manufacturer of an asset creates the seed and the unique identifier.

4. The method according to any preceding claim wherein a manufacturer of an asset is maintained as a signatory on the multisignature asset account irrespective of the ownership.

5. The method according to any preceding claim wherein a token, message, or cryptocurrency is sent to the asset account to verify that the asset is genuine.

6. The method according to any preceding claim wherein the seed is written in plain text, as a message in the account made by that seed, making it auditable by anyone.

7. The method according to any preceding claim wherein the seed is converted into a private key by hashing and declaring the digest (or a truncated version of it) as the asset account's private key.

8. The method according to claim 7 wherein repeated hashing processes are used to generate the public key and asset account network address.

9. The method according to any preceding claim wherein the messages are time- stamped in the blockchain.

10. The method according to any preceding claim wherein the messages include the address of sender.

11. The method according to any preceding claim wherein the messages can include information relating to the history of an asset.

12. The method according to any preceding claim wherein the asset is a contract.

13. The method according to any preceding claim wherein a manufacturer of an asset can register an exclusive domain name on the blockchain.

14. The method according to any preceding claim wherein the owner of the multisignature asset account can transfer ownership thereof to a third party.

15. The method according to any preceding claim wherein a manufacturer of an asset can provide information about the asset to the point-of-sale which checks the corresponding blockchain so that purchasers of the asset can be notified of any issues.

16. The method according to any preceding claim wherein the information includes details of the certifier of an asset.

17. The method according to any preceding claim wherein the blockchain includes On- Chain-Multisignature properties such as found in the NEM blockchain project.