A SYSTEM FOR VIRTUAL CURRENCY BASED ON BLOCKCHAIN ARCHITECTURE AND PHYSICAL MARKING

20200184465 ยท 2020-06-11

    Inventors

    Cpc classification

    International classification

    Abstract

    Methods and system for management of transactions of marked objects are disclosed. In an embodiment, a method for recording a marked object includes: determining specific and unique marking of the object by a reader unit; and communicating encrypted data indicative of the marking and data indicative of the marked object to at least one server system, for generating at least one record of the object and its marking thereat. The at least one server system may be a distributed blockchain system including: at least one blockchain service module adapted for recording transactions of objects in a blockchain; and at least one management service module adapted for authorization of each transaction of an object based on authentication of the transaction by: providing a reader unit with a certain reading scheme/parameters that authorize/enable the reader unit to correctly read the specific marking on the object; and obtaining from the reader unit in response, a reading data indicative of the marking being read using the reading scheme, and authenticating the object based on a match between the reading data and stored data of the object's marking which is stored by the at least one server. In turn, before carrying out a request for recordation of a transaction for the object in the blockchain, the blockchain service module is adapted to await authorization of the transaction from the management service.

    Claims

    1. A method for recording marked object comprising: using a reader unit for determining specific and unique marking of the object to provided data indicative of said marking; using a computing device for communicating with at least one corresponding server system and transmitting data indicative of the marking, and data indicative of the marked object using an encryption key; thereby enabling generation of at least one record of said transmitted data by said at least one server system.

    2. The method of claim 1 wherein said at least one server system includes said at least one record on a public, semi-public or private database.

    3. The method of claim 1 or 2 wherein said at least one server system includes a management service; and wherein said communicating includes providing data indicative of the object to said management service and receiving in response data indicative of reading parameters authorizing said reader unit to operate with a certain reading scheme for carrying out said determining of the specific marking of the object.

    4. The method of claim 3 wherein said reader unit provides said data indicative of said marking to said management service and said management service compares said data of the marking with recorder data of the marking stored thereby to determine authenticity of the object.

    5. The method of any one of claims 1 to 4 wherein said at least one server system comprises a blockchain service adapted for recording transactions of said objects in a blockchain and a management service adapted for authorization of each transaction by determining authenticity of the transaction before its recordation by blockchain service; whereby: said management service determines said authenticity of the transaction by carrying out the following: providing said reader with data indicative of reading parameters for authorizing said reader unit to operate with a certain reading scheme determining of the specific marking of the object; obtaining from the reader unit, in response, data indicative of the marking being read utilizing said reading parameters; comparing said received data indicative of the marking with stored data indicative of the marking on the object and authenticating said object based on a match between the stored- and received-data of the marking; and wherein said upon request for recordation of a transaction for an object stored in the blockchain service, said blockchain service awaits/requests said authorization of the transaction from the management service.

    6. The method of claim 5 wherein said management service is implemented by one or more severs as secured system, and said blockchain service is implemented as at least one of public, semi-public, and/or private blockchain servers.

    7. The method of any one of the preceding claims, further comprises transmitting, to one or more server system, a request for reading marking of one or more objects, receiving in response data indicative of one or more reading parameters enabling reading of the corresponding object's marking, and using the reader unit utilizing said one or more reading parameters for reading marking of the object.

    8. The method of claim 7, wherein said one or more reading parameters comprise data indicative of suitable reading protocol for locating said specific unique marking of the object.

    9. The method of any one of the preceding claims, wherein said communicating with at least one corresponding server system and transmitting data indicative of the marking comprises transmitting reading data to one or more management related servers in response to data about reading parameters, said one or more management related servers in response being configured for validating said marking data and transmit corresponding validation data for generating said at least one record of said transmitted data.

    10. The method of any one of the preceding claims, wherein said reader unit system is an X-Ray Fluorescence (XRF) system; said one or more reading parameters comprise data indicative of suitable reading protocol for locating said specific unique marking of the object, said reading protocol comprises data about one or more of: filter type, emission tube current or voltage, calibration scheme and geometrical configuration for at least one of scanning and reading of said marking.

    11. The method of any one of the preceding claims, further comprising assigning specific value to the object.

    12. A method for use in transaction of ownership rights of a marked object comprising: using a computing device communication with at least one server system and transmitting data indicative of a request for updating object record, said data comprises at least existing owner validation data, and data to be updated; processing at least one copy of public record associated with said object for validating said owner validation data and said object marking data and upon successful validation, generating at least one record of said transmitted data to be added corresponding record; and displaying the at least one updated record on a public database.

    13. The method of claim 12, further comprises, receiving, in response to said request for updating object record, data indicative of one or more reading parameters enabling reading of the corresponding object's marking; using a reader unit for reading a unique marking of the objects and transmitting corresponding marking data to said one or more server systems for validating said object marking data.

    14. The method of claim 12 or 13, wherein said transmitted data further comprises data indicative of value of transaction; the method further comprises, effecting a transfer of corresponding currency in public record between existing owner public record and new owner public record.

    15. The method of any one of claims 12 to 14, wherein said transmitted data comprises data indicative of a portion of ownership being transferred.

    16. A method for generating a virtual currency from data indicative of physically marked objects thereby generate a virtual currency attached to a physical object, the method comprises: using a reader unit for determining specific and unique marking of the object to provided data indicative of said marking; using a computing device for communicating with at least one corresponding server system and transmitting data indicative of the marking, and data indicative of the marked object using an encryption key; communicating said transmitted data and generating at least one record of said transmitted data; and displaying the at least one record on a public, semi-public or private database; wherein the data indicative of the marking is hashed using cryptographic functions such that the data indicative of the marking will be kept hidden; and the virtual currency is generated using cryptographic functions from the cryptographically hashed data indicative of the marking and permanently stored in a database.

    17. A blockchain system storing records of ownership of two or more virtual currencies, each of the two or more virtual currencies is associated with a physically marked object; wherein ownership of a virtual currency or a part of a virtual currency can be changed and recorded in the blockchain system using a public key encryption scheme.

    18. The blockchain system of claim 17 wherein the marking of physically marked objects can be detected by XRF analysis.

    19. A distributed blockchain system comprising: at least one server system comprising: at least one blockchain service module adapted for recording transactions of said objects in a blockchain; and at least one management service module adapted for authorization of each transaction of an object by determining authenticity of the transaction of the object before the recordation of the transaction by the at least one blockchain service module; whereby: said object is being marked by a certain specific marking readable by a reader unit; said management service module is configured and operable for determining said authenticity of the transaction by carrying out the following: authorizing said reader unit for reading said marking by communicating the reader unit with data indicative of reading parameters by which to read said marking by operating with a certain reading scheme for determining of the specific marking of the object; obtaining from the reader unit, in response, data indicative of the marking being read utilizing said reading parameters; comparing said received data indicative of the marking with stored data indicative of the marking on the object and authenticating said object based on a match between the stored- and received-data of the marking; and wherein said upon request for recordation of a transaction for an object stored in the blockchain service, said blockchain service is configured and operable to await authorization of the transaction from the management service.

    20. A reader unit for reading unique marking physically coupled to an object to provided data indicative of said marking of the object; said reader unit is configured and operable for initiating communication with a predetermined management server before carrying out an operation of reading said marking for receiving from said management server authorization data indicative of reading parameters for operating the reading operation for reading said marking; and determining a signature of said unique by carrying out said reading operation with the received reading parameters.

    Description

    BRIEF DESCRIPTION OF THE DRAWINGS

    [0061] In order to better understand the subject matter that is disclosed herein and to exemplify how it may be carried out in practice, embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:

    [0062] FIG. 1 schematically illustrates a data block associated with a marked object according to some embodiments of the invention;

    [0063] FIG. 2 illustrates a general communication topology according to some embodiments of the invention;

    [0064] FIG. 3 illustrates a flow chart exemplifying method of generating object related data entry according to the embodiments of the invention; and

    [0065] FIG. 4 illustrates a flow chart exemplifying method for use in transferring object rights and updating object data entry according to some embodiments of the invention.

    DETAILED DESCRIPTION OF EMBODIMENTS

    [0066] As indicated above, the present invention provides a platform and technique enabling secured creation and updating of a dedicated database with respect to data associated with objects identifiable using secure physical marking In some preferred embodiments, the technique utilizes a blockchain-type database in the form of a distributed database such as a blockchain or blockchain-type database.

    [0067] The present invention allows for a one-to one association of a marked object with a corresponding virtual/electronic record, such that the virtual record and/or the physical marking are configured to eliminate, or at least significantly reduce possibility of duplication, forging and/or changes by hacking, without proper authorization. The technique of the invention thus provides a secure platform supporting registration, maintenance, transactions and other changes in ownership or partial ownership of marked object while establishing suitable tracing between existing record and history of the object and enabling identification of the object in accordance with its corresponding record (and vice versa). The invention thus provides confidence in registered data, enabling users to be assured that for each virtual record there is one and only one marked object wherein the record cannot be hacked and the marking on the object cannot be removed without or tampered without leaving a trace which can be detected once the marking is read.

    [0068] Reference is made to FIG. 1 schematically illustrating a data record (block-) chain associated with an object according to the present invention. As shown, an initial data entry 100 may be generated for the object upon providing suitable certificates and object parameters as will be described in more details further below. The database entry includes several data pieces associated with the relevant object. Such data pieces include object indication, e.g. title, corresponding object description, data indicative of unique object marking, data about object ownership, and may also include data about mark reading parameters.

    [0069] The database structure is preferably configured to be history-preserving. More specifically, when data about the object is updated, e.g. in response to changes of one or more object parameters, e.g. ownership, the update data pieces are added to an additional/new data block 110, linked to the previous data. Further, the data blocks, as well as updated data pieces are generally stored in at least one public record, enabling tracing of object history and accordingly limiting, or preferably preventing, copying and/or false registering of object related data.

    [0070] In this connection, the present technique relates to maintaining data relating to specific marked objects. Such objects may typically be valuable items, such as jewelry, precious stones, art pieces etc., which are embedded with specific and unique object-signature corresponding to a secure physical marking of the object. Data associated with an object may generally include ownership data (e.g. identified via a code such as personal public encryption key) and may also include additional parameters of the object.

    [0071] Generally, reading of the unique marking signature of various objects may require use of specific reading parameters. Accordingly, the object data block of the present technique may also include data indicative of a way the object-signature is read (i.e. detected or measured). This data may include data indicative of authorized reader units and a corresponding address for actual reading parameters stored in one or more management related server systems, or encrypted or open copy of the reading parameters. The actual reading parameters may include specific reading technique, reading calibration data, or other parameters. This may provide correspondence of the object-signature to secure physical markings type, which may generally be holograms, QR codes, UV or IR taggants, RFID tags, and X-ray signatures based of XRD or XRF. As well as required analyzer parameters (e.g. for XRF analysis) that may include the set of parameters of the reading and possibly information corresponding to the calibration of the reader (that corresponds with the types of objects).

    [0072] In this connection, the blockchain-type database may include public accessible data including. However, in some embodiments, the accessible data may be encrypted in way that is irreversible, i.e. processing actual reading data to establish that it corresponds to the publicly accessible data is simple, but identifying what would be the reading data based on the blockchain data may be impossible, or at least a very difficult processing task. To this end, a suitable copy of the object related data may be stored in a management database associated with one or more management related servers as exemplified in FIG. 2. More specifically, while the blockchain-type public record may include data about the object marking, the management database may be configured to encrypt the object marking data to the publicly accessible version thereof. Additionally, according to some embodiments, the management related server system may include/store parameters required for reading of the object and be configured for authenticating readout data in accordance with pre-stored marking data.

    [0073] For example, the blockchain database stores, in its one or more corresponding servers, details of ownership and ownership history (e.g. including a public key identifying the owner), additional details relating to the object, the owner, reading history (e.g. when was the object examined by a reader system in the past and possibly reader system identification) and additional data. This is while the management database stores, in one or more corresponding management related server systems, reading data and reading parameters. The reading data relates to the actual object signature and reading parameters relate to suitable reading technique enabling an authorized reader system to provide correct and suitable reading data from the object. The selection between open and encrypted/hidden data pieces, which are available to the public on the blockchain data base may be set by the owner. Namely, the ownership record available to the public may by default may include only the public key of the owner while additional data may become available to the public or to defined users in accordance with permissions from the owner. As indicated above, object related data record 100 may generally include data pieces associated with Ownership data (typically provided as owner related code or public encryption key); unique marking signature data, e.g. data indicative of XRF reading based on natural or embedded signature. As indicated above, additional data may include reading/scanning parameters and/or object value.

    [0074] The signature reading parameters may include parameter values for use by XRF reader (such as tube-current, tube-voltage, type of filters), as well as selected calibration parameters corresponding with object or XRF object-signature, to obtain and identify the correct XRF-signature. Accordingly, as indicated above, such reading parameters may be directly stored in the public data record, or stored in a corresponding management database record accessible by designated reader unit. In this connection, some specific XRF signatures may only be read, providing reliable data, using specific XRF reader types. Measuring so-marked objects with a different reader or with the designated reader but without using the exact parameters may provide false or incorrect XRF signature.

    [0075] Generally, XRF, or any other object signature may be hidden, encrypted or covert such that the marking is invisible and configured to be hidden from unauthorized reading. In some other configurations, the marking may be visible, but encrypted, or fully visible, using added dye, ink etc. Such XRF signature may utilize small amounts of marker materials (i.e. materials which can be identified or measured by XRF analysis) providing the actual signature marking. For example, reading of the XRF signature may utilize signal processing, filtering and enhancing such as in the method described in PCT/IL2016/05340 incorporated herein by reference. The XRF signatures may be applied or added to the surface of an object as a continuous film or coating in localized areas. An XRF marking may be also incorporated within an object (i.e. in the bulk material of the object). An advantage of XRF marking is that it can be applied to or incorporated in an object without harming the object or affecting its physical, chemical, electrical and/or magnetic properties.

    [0076] Object values may be determined in any type of currency being centrally controlled or decentralized (virtual) currency. The object value may be set in accordance with owner input, or periodically updated, for object types being in frequent trading. As indicated, the object related database according to the present technique may be a blockchain type database, and may be associated with one or more decentralized currency database architecture, enabling immediate trading when ownership data is being updated.

    [0077] Reference is made to FIG. 2 exemplifying a general communication topology according to some embodiments of the invention. As shown, maintaining database for marked object may utilize communication network platform based on a distributed blockchain-type database 300 operating on a plurality of server systems, a management database 200 operated by at least one of the following: one or more secured server systems, a local computing unit 400 configured for mitigating data between a reader unit 500 and the management 200 and blockchain-type 300 databases/servers (in case the management database 200 is implemented in the block chain servers it is typically implemented as restricted/secured section of the blockchain which is not open to the public). The blockchain-type database 300 is typically based on public, linked, records. This is while the management database 200 is generally secured and not public.

    [0078] In this regards, the blockchain servers implement a blockchain data structure per each object that is managed/recorder therein to thereby record the data indicative of the transaction history and/or owner data and/or other parameters of the object (e.g. data indicative of the signature, such as spectral response and/or other elementally coded symbols physically implemented by the marking that is embedded/included in/on the object). The management database/server (which as indicated above may be implemented as a part (e.g. secured and/or non-public part) of the blockchain servers and/or in independent servers, carries/stores data indicative of the markings (e.g. XRF mark and/or other marks) that is implemented/embedded in/on the object itself and even more specifically, it stores/recodes data indicative of the way such marking should be read. Such data may be associated with particular reader/reader-types which should be used to read the marking on the object, and/or with particular configuration of the reader (e.g. angle of illumination/detection and/or illumination radiation wavelengths and/or intensity) and reading parameters which should be used in order to obtain the correct marking signature from the marking on the object.

    [0079] A reader for reading XRF marking (i.e. XRF analyzer) which may be used for the purposes of the present invention is described in International Patent Application Publication WO2018/051353, which is incorporated herein by reference.

    [0080] To this end, whereby the blockchain servers implement a blockchain data structure recording the transaction history of the object, according to some embodiments of the present invention, each new transaction (e.g. each new block in the blockchain data structure of the object) should be authorized by reading the correct signature of the marking that is embedded/implemented in/on the object. However, as indicated above, the reading parameters by which correct reading of the marking is enabled are stored in the secured/non-public management servers. Therefore, in order to obtain/read the signature of the marking (which is required before committing a transaction to the blockchain) the reading parameters should be obtain from the management servers/service. To this end, during or before the reading operation, the reader unit 500 and/or the operator of the reader, should be authorized to access the management servers and obtain in secured (e.g. encrypted manner) the reading parameters. In this way, only authorized reading operations are enabled by the management server, thus eliminating the risk of recording false/counterfeit transaction (not authentic transaction) of the marked object in the blockchain servers. This is because according to the technique of the present invention, not only that the marking of the object should be read, the reading operation itself should be authorized (e.g. carried out by an authorized reader/operator), while unauthorized reading is restricted/not enabled in the absence of the correct reading parameters and/or reading authorization. Accordingly, the invention provides secured block chain transaction recording technique in which registering/recording each block/transaction of the block chain requires secured physical authentication of the marking of the object being the subject of the transaction.

    [0081] It should be noted that in some embodiments a distinction is made between the actual signature data of the object's mark that is stored in the management servers and the optional marking data indicative of the object's mark that is stored in the blockchain record. The first, the signature data, may be data indicative of the actual signature of the object (possibly encrypted coded data). The second, being the marking data indicative of the object's mark which may be stored in the blockchain record, may be data that is only obtainable via a one way encoding of the actual signature data. In other words, once having the actual signature data and the encoding scheme, one may theoretically obtain the marking data which is stored in the blockchain server, however, not vice versa. The actual signature data cannot be obtained from the marking data. In such embodiments, only after the reading operation is completed, the management servers process the actual signature data that was read by the authorized reader/reading parameters, and restores therefrom the marking data that is stored in the block chain servers. Then, only in case the correct marking data is restored (by the management server), this data is provided for comparison with the marking data stored in the blockchain server to authorize the transaction (the new block in the block chain) in case the read marking data matches the stored marking data or otherwise not authorize the transaction (the new block). This adds another security layer making the marking data that is stored in the blockchain server (which may be public data) completely useless for use for counterfeiting transactions of the object (even by using fake management servers), since the marking data in the blockchain servers cannot be used to restore the actual signature data of the marking (due to the on way encoding).

    [0082] In other embodiments the optional marking data that may be stored in the blockchain servers may be similar or indicative of the actual signature obtainable from the object marking, provided the suitable reading parameters.

    [0083] In yet other embodiments the marking data may not be stored altogether in the blockchain servers, but instead each new transaction may require the authorization/authentication of the management servers/service, which in turn authorizes the actual reading of the marking on the object and verifies that the correct signature is obtained by the correct reading parameters and/or by the authorized reader unit, before authenticating and/or before providing authorization to the transaction.

    [0084] Nevertheless, in all three above described embodiments of the present invention (whether the marking data is recorded in the blockchain servers, and/or matches the actual signature data or not), still secured transaction is obtained since reading authorization with the correct reading parameters and/or authorized reader requires the authorization of the management server. In turn no counterfeit transaction can be performed/registered in the blockchain servers without obtaining authorization/transaction-authenticity indication from the management servers. The later (transaction authenticity would only be obtain upon actually reading of the actual object by an authorized reader (and/or authorized reading operator) and/or with the correct reading parameters.

    [0085] In this regards, generally, the reader unit 500 itself may be configured to eliminate, or at least significantly reduce security risks and data leaks from the system. More specifically, the reader 500 may be authorized, by the management database 200 to perform reading of specific objects or markings, and configured to not allow access to any data which may lead to exposing the markers (and their concentration) marking the object. The reader 500 and is configured to access the management database 200 via a corresponding computing device 400 to provide the management database 200 with data indicative of the alleged identity/type of the object which is to be read, and receive in response from the management database 200, data indicative of measurement/reading parameters (reading data) by which to read the object. In turn, the management database 200 stores records of each object being marked by the system whereby the record of each object (or of each object type) the reading parameters of the object and/or possibly data indicative of the signature of the marking obtained from the object in response to reading it with the respective reading parameters. As indicated above the reading parameters may include one or more of the following: the serial-numbers and/or types and/or any other reader identification data indicating the reader units which are authorized to read the object/object-type; the reading configuration parameters such as angles of illumination/detection; wavelengths and/or other parameters of the reading operation. In this regards it should be noted that at the first time an object is recorded in the system (e.g. in the management servers/service 200 which may and may not be integral part of the blockchains servers), the reading parameters of the marking on the object (as indicated above) are recorder in the management servers, as well as possibly the actual signature (e.g. spectral response; and/or coded symbols) of the marking of the object which is obtainable by those reading parameters. To this end, the present invention, in some of its embodiments, provide a technique for verifying that the physical measurement/reading of the correct object is performed before any transaction of the object can be committed/recorder to the block chain servers. This reduces, and practically eliminates the risk of recording any one of the following in the blockchain servers: counterfeited transactions of particular object; and duplicate registration of the same physical object in more than one blockchain structure. This also provides for verifying that any transaction committed to the blockchain is linked to the physical authentic object being the subject of the transaction, since the secured and authorized reading of the object is required.

    [0086] Further, the reader computing device 400 may be configured to transmit data indicative of a reading to one or more servers of the blockchain database, such data may include indication of reading, location and time, typically without including reading data.

    [0087] In the specific example of X-Ray fluorescence (XRF) object marking, the object may be marked with one or more additional materials providing unique XRF signature. Further, the actual object marking may be hidden between distracting reading data. Accordingly, a reader unit may be configured for receiving reading parameters indicating one or more of the following: XRF filters, current and/or voltage (energy) for X-ray emission source, calibration type (calibration data or type of calibration from a list stored in the reader), and/or reader type. Further, the reader 500 may provide raw reading data and transmit them using the local computing device 400 to at least one server of the management database for processing and authentication.

    [0088] According to some embodiments, the reader 500 may be configured to maximize the amount of X-ray radiation that reaches the sample and is absorbed by the sample, and in particular the portion/fraction of that radiation that is absorbed by the element/marker that is to be measured, and to maximize the portion of the secondary radiation emitted from the measured element (the radiation emitted in response to the radiation incoming from the source) that reaches the detector.

    [0089] The reader may be associated with a control system for controlling operational conditions of an XRF system for measuring on a sample. The control system is typically a computer system including data input and output utilities (software/hardware), memory utility, and data processor and analyzer module. The latter is preprogrammed for receiving input data including marker-related data about the marker(s) that is/are to be measured, processing the received input data to determine optimal geometrical characteristics of the XRF system defining optimal operational conditions of the system for measuring said marker(s), and generating corresponding output data for adjusting the geometrical characteristics of the XRF system.

    [0090] The reader 500 may be configured as an X-ray Fluorescent (XRF) system for use in detection of at least one marker carried by a sample, the XRF system may include: an X-ray source for emitting primary radiation towards a sample plane; a detector for detecting secondary radiation from the sample; and a controller; wherein said controller is configured and operable for receiving operational data and adjusting geometrical characteristics of the XRF system may include at least one of the following: a distance between a primary radiation emitting plane of the X-ray source and a sample plane; a distance between a detection plane of the detector and a sample plane; angular orientation of an irradiation channel defined by the X-ray source; and angular orientation of a detection channel defined by the detector.

    [0091] The reader 500 may be designed to obtain the data parameters for reading object marking from the management database 200, Once the measurement is done and the results sent to the database 200 the reader may generally be configured to go back into a standard state and delete the information retrieved and the outcome of the measurement (the spectrum and any information obtained from the spectrum) so that no information can be gained by opening the reader. For example, the mechanism setting the filter goes back to its initial standard state once the emitter stops radiating so the filter used in the measurement cannot be found. Further, the reader unit 500 may be configured to transmit a request for reading parameters, associated with a specific object (based on object id and owner id, to verify object identity). The request may be processed by one or more server systems associated with the management database 200, and reading parameters may be sent only to authorized reader units.

    [0092] The reader 500 may also be configured to be locked in a closed housing, physically preventing a user from opening the housing of the reader and/or the housings of components inside the reader such as the emitter. For example, the physical security means may ensure that by applying physical force to the reader it breaks in such a way that the geometrical configuration of the emitter and the detector would not be revealed.

    [0093] Data communication may typically be controlled by the local computing device 400 (may be associated with a control unit of the reader 500). The local computing device may generally be configured for encrypted communication with the management database 200 (or servers associated therewith). Such encryption may include the use of public key encryption, so that communication intercepted would not provide/reveal information about the reading parameters and/or reading results.

    [0094] In an example, reader 500 may be assigned an ID, and may include means for verifying its location (e.g. a GPS). Every reading taken by the reader is recorded and documented in the management database and possibly at the blockchain database. That is, reader ID and reading location and time may be transmitted to the management database 200 and the blockchain database 300 indicating time and place of the reading and additional information such as the type of the object, the identity (or coded identity) of the owner of the object, the ID of the (authorized) person operating the reader, the purpose of the reading (for example, recording a new object, making a transaction or change of ownership, or checking whether the object is marked). The management database 200 may also record the outcome (the measured spectrum) of the reading, while providing an irreversibly encrypted version thereof to the blockchain database 300. The blockchain database 300 may thus record a coded version of the reading or a part of the reading data, for example be using one or more cryptographic means such as: cryptographic hash functions, public key encryption. For example, various strings of data associated with the marking and the reading of the mark on the object, such as the parameters of the reading and the signature of the object may be hashed separately and then combined or merged and hashed by a an additional hash function or otherwise encrypted by an additional encryption scheme. Additionally, partial or full homomorphic encryption schemes may be used to encrypt signature and reading data stored on the blockchain database allowing some mathematical operations to be carried out on the encrypted data.

    [0095] Additionally, in some embodiments, the authorized reader units may include a hardware/software encryption component, configured for encrypting measurement results immediately upon reading. The encryption component may also be used for encryption of any other communication signals transmitted to or from the reader unit to thereby secure various software components against hacking, e.g. preventing from an unauthorized user to obtain source code data stored in storage utility associated with the reader unit 500.

    [0096] Generally, hardware encryption components may be a removable component connected to the reader for example via USB wherein the reader may take a measurement only when connected to the encryption component thereby enabling operation by authorized users and preventing unauthorized reading.

    [0097] As described above, according to some embodiments of the present invention, reading data, measured by authorized reader unit, may be encrypted and protected already at the electronic circuity of the reader unit 500. This may be embodied in a detector utility of the reader unit, configured for detecting electromagnetic radiation signals associated with one or more marker elements (e.g. heavy metal atoms) in/on the object. Generally, suitable electromagnetic signals detector utilities (e.g. Silicon Drift detectorSSD) are configured for transmitting one or more analog electrical pulses (originating from the detected electromagnetic signal) received and sorted to corresponding different channels by a Multi-Channel Analyzer (MCA). The MCA further sorts the analog signal to one of multitude of channels according to the signal's amplitude which corresponds to the signal's frequency (and energy). The measured spectrum may thus be constructed from the number of counts in each channel (i.e. number of count vs. frequency). The MCA may be configured for encrypting the detected spectrum data by addition and/or mixing of channels such that the frequency corresponding to a given channel (and thus the correct spectrum) cannot be obtained without suitable decryption, e.g. by reversing the mixing scheme.

    [0098] As indicated above, the management database 200 may be operated by one or more secured server system (management server) configured to set and manage permission policy to one or more reader units 500. For example, only some reader units may have the permission to record a new object in the blockchain database while other reader units may be prevented from recording new objects, and may only be used for updating objects' data. Alternatively, some reader units may only be allowed to validate object data while not updating/changing it. The permission policy may also depend on additional factors such as: reading location, time, requirement of owner encryption key, owner identity, operator of the reader and other. For example, the management database 200 may allow to record a new object only during daytime; or require that for a specific owner or object the reading should be carried out by specific operators or readers. In another example recording of a new object of a certain type or belonging to a certain owner may be permitted in a certain location (e.g. store, distribution center). For example, in a case of a manufacturer who marks and records the manufactured products, recording the products may be permitted only in the manufacturing site. For example, a certain set of markings may be assigned to a specific line of manufactured objects (e.g. watches, jewelry, or any other items). The corresponding markings may be embedded in the objects upon, or after manufacture, by the manufacturer, or once distributed to private owners by selling. Accordingly, registering of objects in the database according to the present technique may be associated with validating the uniqueness of the marking such that once certain marking is assigned to an object, no additional objects can be registered using the same marking Generally, the technique of the invention may utilizes a plurality of separated management databases associated with different types of marked objects (e.g. by manufacturer). The different management servers (databases) may be configured to operate with the same or different set of reader units 500 while utilizing a common public blockchain-type database 300.

    [0099] Reference is made to FIG. 3 illustrating a technique for registering marked object according to some embodiments of the present invention. As shown, for generating data block associated with an object, data associated with the object marking are provided to an authorized reader unit 1010, e.g. by providing manufacturer data. Additionally, certain data about the object are provided 1015, such as a text document including object description and value. To identify the actual/physical object, the object (its marking) is read/scanned 1020 by a suitable reader unit, which utilizes a local computing device for transmitting reading data 1030 (typically encrypted) to one or more servers of the management database. Typically, the local computing device may also transmit indication of reading to one or more servers of the blockchain database 1050 to provide indication of reading. To this end the object is scanned/read with a certifies reading system capable of identifying the object unique signature and providing data indicative of the signature to a computing system capable of communicating with one or more server systems associated with database storage. Typically, the additional data about the object is provided 1015 including ownership data and various other data parameters of the object.

    [0100] The so-processed data is transmitted, typically using a computing system, to at least one server system 1040 associated with management database, for authenticating data integrity. The management server system may generate object code data 1044 (e.g. encrypted data of reading) and possibly corresponding public and private encryption keys 1046. The management server transmits the relevant data to one or more blockchain serves, which upon receiving authentication from the management server 1040 and indication of reading 1050 is configured for generating an object related block in the data base 1060. When the corresponding data block is stored and, if needed, further authentication is performed, the block data is displayed in at least one public database record 1070.

    [0101] Generally, the at least one server system, and/or a computing system configured for transmitting object data (including signature related data) may be assigned with unique management authority. More specifically, an object block having no links to previously existing (in public database record) block may only be generate with one or more specific management encryption keys, at specific location(s) or using specific reading permissions as described above. Alternatively, the at least one server may be any server associated with the distributed database, and owner key and certified object signature readout is sufficient for generating a block with no previous links

    [0102] Furthermore, in order to record a new object on the database the object should be marked. Such marking may be embedded in the object by a manufacture when assembling/constructing the object; the object may be marked by distributer, using suitable marking technique; or it may be marked by the owner. Generally, the unique marking of the object may be required to follow certain required properties enabling high verification data about the object. Typically, such markings provided by an authorizing/management party having access to marking system and suitable reader units. For example, when an object's owner wants to record an object in the database, the owner contacts the management party and provide the object for marking and inspection with a unique (e.g. XRF) signature.

    [0103] In some examples, in order to record the object in the database the reader may connect to a cloud-based management database that manages and assigns signatures. Namely, the marking of the object may be done according to information stored on the management database and the reader (and possibly a marking device) communicates with the management database. Typically, the actual signature data may only be stored in the management database, and only data indicative, and irreversibly encrypted, thereof is provided in the object block database.

    [0104] In this example, the reader communicates solely with a computing system associated with management-database. The computing system may then communicate with the at least one server storing data of the object block database to transmit data about the object for public registration.

    [0105] According to some other examples, the object blocks database is internally managed according to a distributed management protocol and marking of selected objects may be provided by representative of the manufacturer or the seller of the object. For example, the owner of an expansive watch can carry-out marking in the store where the watch was purchased. Namely, the object may be marked in the store and the marking can be read by a designated reader in the store that then communicates with at least one server system associated with the database as described above.

    [0106] As indicated above, the so-generated data blocks are publicly accessible, with required encryption for all or some of the data fields, and distributed to provide tracing of complete block update history. Thus, data records are known to be associated with existing objects having the unique marking and can be used, to some extent, as decentralized currency or tradable items. Specifically, ownership data of an object may be traded by generating suitable update to the database, where such update generally required at least usage of owner encryption key for preventing theft.

    [0107] It should be noted, and as indicated above, a reader unit may generally transmit data indicative of a request for reading parameters from one or more servers associated with the management database. Such reading parameters' request may include data about the object to be read, reader unit identity and location. Generally such reading request may be processed in accordance with reading authorities scheme, e.g. certain object markings may only be read at designated locations, by authorized reader units. Accordingly, reading parameter may be transmitted to authorized reader units, or denied from unauthorized reader units in accordance with predetermined authorizing parameters.

    [0108] An exemplary process of updating object data is exemplified in FIG. 4. In this example, object update may require authentication of the object by proper reading/scanning As exemplified. A request for object update may be generated 2010, e.g. by object owner. The request may be transmitted to at least one blockchain server and at least one management server 2015. Accordingly, data indicative of object reading/scan parameters may be readout from the corresponding data field at the management database 2020 if such data field is stored with specific reading parameter. The parameters are to be provided to a suitable scanning system/reader unit, e.g. XRF reader, to enable scan/read of the object signature 2030. Upon reading object marking, the reader unit may utilize local computing device form transmitting marking data to at least one management server 2040 for processing. The management server receives the data update request and reading output data 2050 and authenticate the reading data 2050 with respect to existing record of the object marking If the reading data and owner key match the data in the management database, a corresponding indication is transmitted to one or more blockchain servers for generating 2060 object record with the updated data and linking it to the existing record of the object.

    [0109] In an example, the indication that the reading data is authentic may be sent from the management server to the one or more blockchain servers via the reader or its local computing device such that the data updating process may not require direct communication between the management database and the blockchain system. In this case the management server may provide information to the reader which may be transmitted to the blockchain system proving that the reading data was inspected and authenticated by the management database.

    [0110] The block may generally be updated using the current owner private encryption key to ensure certified update of parameters such as ownership. The desired update, e.g. complete or partial ownership transfer, may be registered an in updated record and linked to the object history record for integrity. As indicated, the transferred data is typically encrypted, and in this specific example it may be encrypted using current owner private encryption key.

    [0111] Upon determining that the transmitted update request is valid and generating an updated data record 2060 linked to the previously existing record associated with the object. The so-generated data block is than transmitted to be distributed in the peer-to-peer database and displayed in the public record associated thereto 2070.

    [0112] Thus, transfer of object ownership may be associated with a peer to peer agreement while note requiring any dedicated management. More specifically, when two parties agree to change ownership and transfer an object between them (including transfer of the actual object from one party to another), a reading of the object's signature may be requested to ensure validity of the transfer. Alternatively, in cased there is no request for signature reading, a use of owner private encryption key may be suitable for registering transfer of ownership.

    [0113] It should be noted that an update request may or may not include actual update data for changing object data, e.g. ownership. An empty update request 2010 may be transmitted and used for reading/identifying object without any change in object data stored in one or more database servers. Accordingly, this may be done for verifying originality of an object, e.g. to demonstrate object, indicate against counterfeit suspicions etc. generally, any reading of an object marking, with or without data update may be recorded in a linked object related record and stored in the one or more servers of the blockchain-type database.

    [0114] Such changing of ownership may, in some embodiments, be recorded first in a buffer and only upon receiving the object and reading the mark the change of ownership will be finalized and recorded in a block of the database. Alternatively, ownership changes may not require actual transferring the object itself, e.g., when the actual object is safely stored in a safe, transfer of partial ownership etc. The change in ownership may be recoded once the transaction agreed.

    [0115] Generally, a signature reader unit suitable for providing signature data according to the present technique may be associated with one or more specific parameters ensuring validity of the read and uniqueness of the signatures. Typically, such reader unit may be configured for receiving readout parameters through an associated computing device, communicating with at least one server associated with the database. As indicated, the actual readout signature may typically not be transmitted as is, to prevent mark forging.

    [0116] Once the measurement is done and the results sent to the database the reader may be configured to go back into a standard state and delete the information retrieved and the outcome of the measurement (the spectrum and any information obtained from the spectrum) so that no information can be gained by opening the reader. For example, the mechanism setting the filter goes back to its initial standard state once the emitter stops radiating so the filter used in the measurement cannot be found.

    [0117] Thus, the present technique provides for a secure and distributed technique enabling validation, trading and maintenance of rights associated with uniquely marked objects. Such technique enables tracing of object history and identifying original/current owner of objects with or without presence of the object or the owner. Typically the technique utilizes decentralized database maintaining history data and having certain publicly accessible record, thus allowing error/theft corrections.

    [0118] The use of the above described database may enable actual and virtual trading of marked objects utilizing an online virtual-currency type system (e.g. bitcoin-type payment system). Specifically, the invention enables trade with actual objects, possibly a trade which defines a virtual currency system. Furthermore, the invention allows one to trade with shares or partial ownership of marked objects. For example, to buy or sell a fraction of a work of art, or an expansive watch (just as one can buy or sell a fraction of a bitcoin, enabling one to invest, for instance, in Rolex watches without purchasing an actual watch).