WO2021255668A1

WO2021255668A1 - A computer implemented method for the generation and management of codes.

Info

Publication number: WO2021255668A1
Application number: PCT/IB2021/055318
Authority: WO
Inventors: Fabio GUGLIETTA; Nicoletta Bianchi
Original assignee: Bringing Innovation Into Technology 256 Srl
Current assignee: Bringing Innovation Into Technology 256 Srl
Priority date: 2020-06-18
Filing date: 2021-06-16
Publication date: 2021-12-23
Anticipated expiration: 2022-12-18

Abstract

Method implemented using at least one computer for the generation and/or management of codes, preferably to be used for tracing products or batches of products or pallets of batches/products, characterized by the fact that it includes the following steps : - on the basis of a set of predefined rules, a plurality of unique original codes are generated in binary format, at least a portion of each of said original codes contains bits representative of information necessary to reconstruct a storage address (URI) in which the the code itself and/or the data associated with it, each of said unique original codes is generated in such a way as to include: - a base portion containing the bits that define an identifier of a predefined set of rules used for the generation of the corresponding code, - at least one meaning-carrying portion which contains bits representative of information necessary to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code, - at least a non-meaningful portion which is generated randomly and which contains unnecessary bits to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code, to make said code not predictive, - these original codes are encrypted by means of predefined encryption rules, thus obtaining corresponding encrypted codes, - a coding of said ciphered codes is carried out, thus obtaining corresponding public coded codes to be applied/associated each, preferably by means of a physical label, to a product or batch of products or pallets of batches/products to be traced, said coding phase involves subdivide each encrypted code into a sequence of blocks of at least two bits and, on the basis of predefined encoding rules based on a predefined encoding system in which each character of said encoding system is uniquely identified by a specific sequence of bits having the same length of said blocks, a corresponding character of said predefined coding system is associated with each block of the encrypted code, thus obtaining a corresponding public coded code of non-positional type which is constituted by a number of characters of said predefined coding system which is lower than the number of bits of the corresponding original code e/or the corresponding encrypted code.

Description

A COMPUTER IMPLEMENTED METHOD FOR THE GENERATION AND MANAGEMENT OF CODES.

FIELD OF THE TECHNIQUE The present invention relates to a method and a system for the generation of secure and non-predictive codes suitable, in particular, for the serialization of individual products for the purposes of their traceability. This method allows to arrive in the correct database, shard or partitioned table where the requested data resides, always with the same number of hops, regardless of how much this may be architecturally complex and/or geographically distributed; it allows to simplify the database architecture; it allows to reduce the number of servers specialized in clustering; allows you to address queries on databases of different technologies while using the same application; allows you to implement mixed databases (in the cloud and on-premises); allows you to maximize the performance of databases in terms of storage and speed of execution. STATE OF THE TECHNIQUE

In today's society, attention to the consumer is becoming the most effective weapon for a Customer Retention and a Customer Acquisition that are not volatile. Among the techniques used to give attention to the consumer, there is that of being able to give a guarantee of authenticity on the product and that of being able to dialogue with the consumer, exploiting the object that the latter has in his hand.

To fulfill these tasks, the manufacturer must be able to track all of its products. To achieve this, the first step is the unique identification of the individual products.

By inserting these concepts in a totally globalized market, there is therefore the need to introduce new systems for the management of traceability. In the past it was sufficient to trace the production batches, while currently this is no longer enough, and therefore there is a need to move from the tracking of individual batches to that of individual products. This change involves an important economic and managerial effort as the numbers and information to be checked are 2, 3 or 4 orders of magnitude higher.

Furthermore, the advent of increasingly refined technology has encouraged and facilitated the counterfeiting of products. In particular, counterfeiting ranges from jewelry products, drugs, food and fashion accessories. Some situations involve only monetary losses, while in some situations it is life itself that can be endangered.

Finally, the ability to track and monitor individual objects is increasingly required to prevent fraud caused by fake objects sold online, as well as the need to track and monitor the distribution of sensitive objects (e.g. weapons, raw material for medicines, spirits, spare parts etc.). All these situations make the traceability of individual products increasingly necessary.

As the objects to be tracked increase, the data and the size of the databases increase accordingly. A solution proposed by database suppliers is the possibility of horizontally scaling databases by creating a cluster architecture where the single database is divided into several parts that can also be geographically distant. The management of these clusters has become increasingly sophisticated, having to guarantee the unity of the database itself, solve synchronization problems, continuity of service and performance. This well-known solution (ie database clustering) allows the management of large amounts of data but, at the same time, requires particularly high levels of sophistication, very expensive and, moreover, increases the points of possible fault. In any case, with the known solutions, as data increases, database performance decreases.

US2017/0286717 describes a solution to reliably and securely record and archive all personal identification attributes. In particular, this solution provides for the use of a distributed database and also provides for the use of cryptographic keys and digital signatures to access the data.

OBJECTIVES OF THE INVENTION

The object of the present invention is to propose a method and/or a system, implemented by computer, for the generation and/or management of codes, preferably to be used for tracing products or batches of products or pallets of lots/products, which allows to overcome, at least in part, the drawbacks present in the traditional technique.

Another object of the invention is to propose a method and/or a system which is particularly fast and efficient, in particular in terms of search speed.

Another object of the invention is to propose a method and/or a system which is easily and quickly adaptable according to the needs of the user.

Another object of the invention is to propose a method and/or a system that is highly secure and robust from an IT point of view.

Another object of the invention is to propose a method and/or a system that is easily adaptable in environments in which data storage is multi-technology, allowing a considerable saving of hardware and therefore economic resources.

Another purpose of the invention is to propose a method and/or a system which is an improvement and/or alternative to the traditional ones.

Another object of the invention is to propose a method and/or a system with an alternative characterization, both in functional and implementation terms, with respect to the traditional ones. Another object of the invention is to propose a method and/or a system which is simple, easy and intuitive to use.

Another object of the invention is to propose a method and/or a system that allows a lower consumption of resources by the hardware devices involved and/or a lower use of the band occupied by the network.

Another object of the invention is to propose a method and/or a system which can be implemented in a simple, rapid and low-cost manner.

Another object of the invention is to propose a method and/or a system that is highly scalable and adaptable.

All these objects, considered both individually and in any combination thereof, and others which will result from the following description, are achieved, according to the invention, with the method having the characteristics indicated in claim 1.

Other characteristics of the present invention will emerge from the description which follows, from the dependent claims and/or to the drawings and diagrams incorporated herein.

DESCRIPTION OF THE INVENTION

In particular, the method according to the invention implemented by computer (ie "a computer-implemented invention") for the generation and/or management of non-predictive codes, preferably to be used for tracing products or batches of products or pallets of lots/products, is characterized by the fact that it includes the following steps:

- on the basis of a set of predefined rules, a plurality of unique original codes are generated in binary format, at least a portion of each of said original codes contains bits representative of information necessary to reconstruct a storage address in which the code itself is stored and/or the data associated with him,

- an encryption of said original codes is carried out, thus obtaining corresponding encrypted codes,

- a coding of said coded codes is carried out, thus obtaining corresponding public coded codes to be applied/associated each to a product or batch of products to be traced.

Preferably, said method is also characterized by the fact that the public coded code is applied/associated to a product or to a lot of products or to a pallet of lots or products.

Conveniently, the rules of a predefined cryptographic map are used/applied to it to encrypt the original code.

Conveniently, to encode the encrypted code, the rules of a predefined map/coding system are used/applied to it, such as for example an alphanumeric comprising numeric characters and/or letters of the alphabet and/or punctuation marks or other special characters. Advantageously, said method is also characterized by the fact that a part of each of said generated original codes is stored in a dedicated computer medium, in order to have a list of the codes used and associated/applied to a product or lot or a pallet of products/lots to track.

Advantageously, said method is also characterized by the fact that the coded public codes are stored in a dedicated computer medium, in order to have a list of the codes used and associated/applied to a product or batch of products to be traced.

Advantageously, said method is also characterized in that at the beginning the number of unique original codes to be generated is input.

Advantageously, said method is also characterized in that said set of predefined rules for the generation of a plurality of unique original codes is selected from a plurality of predefined rule sets, different from each other, for the generation of said codes.

Advantageously, said method is also characterized in that at least one set of rules for the generation of said univocal original codes in binary format is provided as input.

Advantageously, said method is also characterized in that each set of rules for generating said unique original codes in binary format comprises at least one of the following data:

- the total number of bits of said code,

- the number of portions of which this code is composed,

- the number of bits of each of the portions (Versionl D and Chunk) that make up said code,

- the type of information, and therefore the meaning, of each of the portions of said codes which are necessary to reconstruct a storage address in which the code itself and/or the data associated with it are stored

Advantageously, said method is also characterized by the fact that an identifier (Version ID) is associated with each set of rules for generating said codes and by the fact that said identifier is input as a key to thus retrieve the corresponding set of rules associated with said identifier.

Advantageously, said method is also characterized in that at least a portion of each of said generated original codes contains the bits which define said identification (Version ID) of the set of rules used for the generation of the corresponding original code.

Advantageously, said method is also characterized by the fact that said original code is generated in such a way as to include:

- a base portion containing the bits that define said identification (Version ID) of the set of rules used for the generation of the corresponding code,

- at least a remaining portion of said code which has at least one bit different with respect to the corresponding portions of the other original codes generated. Advantageously, said method is also characterized in that each original code is generated in such a way that at least one bit is added to all said remaining portions of said code with respect to the corresponding portion of the last generated original code.

Advantageously, said method is also characterized in that said other/remaining portions of said code comprise:

- at least a meaning-bearing (ie significant) portion containing bits representative of information necessary to reconstruct the storage address of said original code and/or of the data associated with said original code,

- at least a non-meaningful (ie non-significant) portion, to render said code non-predictive, containing bits that are not necessary to reconstruct the storage address of said original code and/or of the data associated with said original code.

Advantageously, said method is also characterized in that the number of significant portions of said code depends on the technology of the storage database used.

Advantageously, said method is also characterized in that, in addition to said base portion containing the bits that define said identifier of the set of rules used for generating the corresponding code, the remaining portions of said code comprise, in any order, the following servings:

- a first significant portion that contains the bits that define the identifier of the node of a database,

- a second significant portion that contains the bits that define the identifier of a Collection or a Table of a database,

- a third significant portion that contains the bits that define the identifier of a position in a Collection or a Table of a database

- an insignificant portion that contains the bits that define a random number (Random).

Advantageously, said method is also characterized in that, in addition to said base portion containing the bits that define said identifier of the set of rules used for the generation of the corresponding code, the other/remaining portions comprise, in any order, the following portions:

- a significant portion that contains the bits that define the identifier of a server,

- a significant portion that contains the bits that define the identifier of a database,

- at least one further significant portion which contains the bits necessary for the composition of the path necessary to identify the storage location of the code within said database, and

- at least a non-significant portion that contains the bits that define a random number (Random), to make said code non-predictive, once it has been encrypted and encoded. Advantageously, said method is also characterized by the fact that it is stored in a dedicated computer support, preferably in a database:

- a significant portion containing the bits that define the identifier of a database, and

- at least a further significant portion which contains the bits necessary for the composition of the path necessary to identify the storage location of the code within said database.

Advantageously, said method is also characterized by the fact that the set of rules for generating a plurality of unique original codes defines the number of bits that make up said base portion, each of said significant portions and said at least a non-significant portion, preferably random.

Advantageously, said method is also characterized in that said encryption step is performed by changing the position, according to predefined encryption rules, of each bit of said generated original code, or of groups of bits of said generated original code.

Advantageously, said method is also characterized in that said encrypted code has the same length in bits as said generated original code.

Advantageously, said method is also characterized in that said encrypted code is in binary format.

Advantageously, said method is also characterized in that said encryption step provides for changing, according to a predefined scheme, the order of the bits of said generated original code.

Advantageously, said method is also characterized in that said coded code is constituted/defined by a number of characters (symbols and/or letters and/or numbers) lower than the number of bits of the encrypted code and/or of the original code.

Advantageously, said method is also characterized in that said coded code is constituted/defined by a number of characters (symbols and/or letters and/or numbers) equal to or greater than the number of bits of the encrypted code and/or of the original code.

Advantageously, said method is also characterized by the fact that said coding step is configured in such a way as to associate a determined character to each of the bit blocks into which each encrypted code is divided, said blocks having a predefined length of at least two bits and equal among all. said blocks.

Advantageously, said method is also characterized by the fact that said coding step involves dividing each encrypted code into a sequence of blocks of at least two bits and, on the basis of predefined encoding rules based on a predefined encoding system in which each character ( letter and/or symbol and/or number) of said coding system is uniquely identified by a specific sequence of bits having the same length as said blocks, a corresponding character of said predefined coding system is associated with each block of the encrypted code, thus obtaining a coded code which is expressed with the characters of said predefined coding system. Conveniently, said predefined coding system is a compression coding system since each character is defined by blocks of two or more bits. Preferably, said coding system comprises a human-readable alphanumeric alphabet, preferably it is an alphabet which comprises the codes of the ASCII table.

Advantageously, said method is also characterized in that said coding step provides for dividing each encrypted code into a sequence of blocks having a length in bits which corresponds to a submultiple of the length in bits of the original code generated.

Advantageously, said method is also characterized in that said coding step provides for dividing each encrypted code into a sequence of blocks having a length in bits which depends on the number of characters that said public coded code must have.

In a possible and preferred embodiment, said method is also characterized by the fact that said predefined coding system consists of 64 characters, each of which is uniquely identified by a corresponding 6-bit block.

Advantageously, said method is also characterized in that said original code and said cipher code are expressed in a positional binary numerical system, while said coded code is expressed according to a predefined and non-positional coding system.

Advantageously, said method is also characterized in that each of said public coded codes has a length in terms of number of positions and number of characters (ie digits and/or letters and/or symbols) which is lower than the number of bits of said generated code and/or said encrypted code. Preferably, each of said public coded codes is a non-positional code and consists of a number of characters which is lower than the number of bits of the corresponding original code and/or of the corresponding cipher code. Preferably, said coded code is compressed with respect to said cipher code and/or with respect to said original code.

Conveniently, said coded code is of a human readable type (ie "human readable") and compressed with respect to said encrypted code and/or with respect to said original code. Preferably, the coded code comprises letters or symbols which are represented with "n" bits, where n is equal to or greater than 2.

Advantageously, said method is also characterized in that it is stored in a dedicated computer medium, preferably in a database, the part of each original code generated which is formed by said base portion and by said significant portions.

Advantageously, said method is also characterized in that each of said public coded codes is stored in a dedicated computer medium, preferably in a database.

Advantageously, said method is also characterized by the fact that, to search - starting from said public coded code which is associated and/or applied to a product or batch of products - the storage address in which the original code is stored in binary format corresponding to said public coded code and/or the data associated with said original code, preferably to read and/or modify said data, the following steps are carried out:

- you acquire the public coded code that is applied/associated with a product,

- decoding (DECODING) said expanded coded code, thus obtaining the corresponding cipher code,

- decrypt/decrypt (DECRYPTION) the compressed encrypted code, thus obtaining the corresponding original code,

- (VERSION ID EXTRACTOR) is reconstructed from said original code thus obtained, and on the basis of known and predefined extraction rules, the identifier (Version ID) of the set of rules used for the generation of the corresponding original code,

- extract (QUERY AL VERSION’S RULES LEDGER & CHUNK MEANING) the set of rules associated with said identifier (Version ID),

- (CHUNK EXTRACTOR) in said original code, on the basis of the extracted set of rules, the significant portions that make up said original code and the relative meanings,

- on the basis of the values of said portions and the relative meanings, as identified, the storage address (URI) of said original code and/or of the data associated with said original code is reconstructed.

Advantageously, said method is also characterized by the fact that on the basis of the values of said significant portions and the relative meanings, as identified, the storage address (URI) is reconstructed, obtaining for each of said significant portions a corresponding physical addressing part which composes said storage address (URI) in which said original code and/or of the data associated with said original code is located/stored.

Advantageously, said method is also characterized in that said encoded code is decoded, thus obtaining the corresponding encrypted code, on the basis of predefined decoding rules, preferably obtained by inverting known and predefined encoding rules.

Advantageously, said method is also characterized in that said encrypted code is decrypted/decrypted, thus obtaining the corresponding original code on the basis of predefined decryption rules, preferably obtained by inverting known and predefined encryption rules.

Advantageously, said method is also characterized in that said known and predefined extraction rules include:

- the number of bits that make up that original code,

- the number of bits of the base portion of said original code, said base portion containing the bits defining the identifier of the set of rules used to generate said original code, - the position of the base portion within the original code,

- the position and length in bits, within the original code, of each insignificant part;

- the position and length in bits, within the original code, of each non-significant part, in particular of the random type. Advantageously, said method is also characterized by the fact that, once a public coded code has been acquired, its formal correctness (SYNTAX SCANNER) is checked, in particular by checking whether the characters of said acquired code belong to said predefined coding system and whether number of characters of said acquired encoded code corresponds to that expected in a predefined set of rules. Advantageously, said method is also characterized by the fact that, once the original code has been obtained and the identifier has been reconstructed, in order to filter load attacks on databases and/or servers (for example of the DDoS or Flood type) if said identifier corresponds to a set of rules and/or if said identifier is used to create a set of codes.

Advantageously, said method is also characterized in that said decoding step performs the reverse operation/function with respect to that performed in said coding step.

Advantageously, said method is also characterized in that said decryption step performs the reverse operation/function with respect to that performed in said encryption step.

Advantageously, said method is also characterized by the fact that: - the base portion containing the bits that identify/correspond to the value of the identifier

(Version ID) of the set of rules used for the generation of the corresponding code is identified within said original code, on the basis of known and predefined extraction rules original,

- once the bits of said base portion have been identified, the value corresponding to said bits and which defines said identifier (Version ID) is calculated,

- from a corresponding database (VERSION'S RULES LEDGER DATABASE) in which a plurality of predefined rule sets are stored, the corresponding set of predefined rules associated with the value thus calculated is extracted.

Advantageously, said method is also characterized by the fact that: - the bits that form the significant portions of said code are identified within said original code, on the basis of said set of predefined rules extracted,

- once the bits of each of said significant portions have been identified, the number corresponding to the bits of each significant portion is calculated,

- for each significant portion, the meaning of each significant portion and the value associated with said calculated number of each significant portion are extracted from a corresponding database (CHUNK MEANING DATABASE), - the calculated values and meanings associated with each of said significant portions are used (SEEKER) to compose the storage address (URI) in which said original code and/or the data associated with it is stored.

Advantageously, said method is also characterized by the fact that, once the significant portions (CHUNK) that make up said original code have been identified, it is checked, in order to filter load attacks on databases and/or servers (for example of the DDoS or Flood type), if a meaning is associated with each significant portion of the code, according to the corresponding set of rules associated with the identifier reconstructed by said code.

Advantageously, said method is also characterized in that said meaning, which is associated with each portion, is defined and depends on said set of predefined rules.

Advantageously, said method is also characterized in that the reconstruction of the storage address (URI) of said original code and/or of the data associated with said original code is carried out in run-time.

Advantageously, said method is also characterized in that, on the basis of said set of predefined rules, each portion of said original code is associated with a specific field or tag of the storage address (URI) to be valued.

Advantageously, said method is also characterized in that said meaning, which is associated with each portion, is used to compose a search string (query-string).

Advantageously, said method is also characterized in that said value, which is associated with the number calculated for each portion, is used to compose a search string (query-string).

Advantageously, said method is also characterized by the fact that:

- said meaning, which is associated with each portion, defines a corresponding field or tag of a query-string,

- said value, which is associated with the number calculated for each portion, defines the value with which to value said corresponding field of said search string.

The present invention also relates to a system, which is implemented by means of at least one computer, for the generation and/or management of codes, preferably to be used for tracing products or batches of products or pallets of batches/products, characterized by the fact to comprise a module that is configured to implement the steps of the method according to one or more of the characteristics described above.

Advantageously, said system is also characterized in that it comprises a module for identifying the storage address (URI) of a code and/or data associated with it, said module being configured to implement the steps of the method according to one or more of the features described above. Advantageously, said system is also characterized by the fact that said code generator module is connected to a module (VERSION’S RULES LEDGER) in which a plurality of predefined sets of rules for the generation of the code and/or said rules of encryption/decryption and said encoding/decoding rules.

Advantageously, said system is also characterized in that said code generator module receives as input the quantity of unique original codes to be generated and an identifier of the set of rules for the generation of said codes.

Advantageously, said system is also characterized in that it comprises a module for identifying the storage address of a code and/or data associated with it.

Advantageously, said system is also characterized in that said module for identifying the storage address (URI) of a code and/or data associated with it is connected with:

- a module (VERSION’S RULES LEDGER) in which a plurality of predefined sets of rules for the generation of the code and/or said encryption/decryption rules and said encoding/decoding rules are stored/contained,

- a module (CHUNK MEANING) in which, for each set of rules, said meanings and said values are stored which are associated with the numbers identified by each significant portion of the original code.

Advantageously, the method and the system according to the invention are configured for the generation of non-predictive codes, optimized for databases and suitable for the serialization of products and their certain identification for the purposes of product traceability.

Preferably, the method and the system provide for the generation of a plurality of codes. Preferably, each code of this plurality is determined by an overall length thereof, expressed in bits, determined by the length of each of its portion (Chunk). Preferably, each portion (Chunk) that composes a code has length and meaning associated dynamically through a service/support register (database) which is hereinafter referred to as the “VERSION’S RULES LEDGER & Chunk Meaning”. Preferably, said register is used by the Code Generator to derive the information necessary for the formation of the codes that it will generate, such as the total length of the code and the lengths of the individual chunks. Conveniently, in said register, the association is also stored, for each value that a portion (chunk) can assume, with its meaning (meaning). Conveniently, this information is also used when decoding the code. Preferably, the code assumes its meaning dynamically according to the Version ID it belongs to. Appropriately, each product code is unique for each item. Advantageously, the intrinsic meaning of the code can vary even after this has been affixed to the product to be traced without affecting its function. Advantageously, the method and/or system can also provide for the use of these codes to address the requests for information of the products, of which these codes represent their serialization. Conveniently, in this example the same code can, at different times, direct requests to databases of different technologies. Suitably, the structure of the code is capable of handling, the addressing migration of interrogation requests, only by way of example from a base of MSGL data to a ledger distributed as those of blockchain or a NoSGL database

The present invention also relates to the methods and equipment that execute these methods, including the computer systems that execute them, as well as computer-readable media that, when executed on dedicated computing systems, cause the systems to execute those methods.

Other features of the present invention will appear from the drawings and diagrams incorporated herein and from the following Detailed Description of the invention. DESCRIPTION OF THE FIGURES The present invention is further clarified hereinafter in a preferred embodiment thereof reported for purely illustrative and non-limiting purposes with reference to the attached figures, in which:

Figure 1 shows an example of the logic flow of how a code could be constructed in accordance with one of the possible examples of the method according to the invention,

Figure 2 shows a step by step example of how a code could be generated in accordance with one of the possible examples of the method according to the invention,

Figure 3 shows a graphic example of the "VERSION’S RULES LEDGER & Chunk Meaning" for the "Version ID" equal to "0",

Figure 4 shows a textual example of the "VERSION’S RULES LEDGER & Chunk Meaning" for the "Version ID" equal to "0" and "Version ID" equal to "1",

Figure 5 shows an example of an original code created with the method according to the invention tion,

Figure 6a shows an example of a default cryptographic map, Figure 6b shows an example of the map/coding system (compression), Figure 7 shows the steps of encryption and encoding of the original code of Fig. 5 respectively by means of the cryptographic map of fig. 6a and the coding map of fig. 6b, Figure 8 shows the logical flow of the steps that are carried out from the moment in which an enabled device reads the code applied to a product, up to the moment in which this code is accessed in the database,

Figure 9 shows in more detail the logic flow of fig. 8, Figure 10a shows with a block diagram a server architecture for the implementation of the method according to the invention,

Figure 10b shows in greater detail the block diagram of fig. 10a.

DETAILED DESCRIPTION OF THE INVENTION

The concepts proposed below are illustrated by way of example. More in detail, what is illustrated in the drawings and/or diagrams attached hereto is a non-limiting representation of the Method and System and represents only one of the many possible implementations of the Method.

At least some examples in this document concern a method and a system for the generation of optimized codes for non-predictive databases, aimed at the serialization of products, their certain identification and their traceability.

The following descriptions and drawings/diagrams are for illustrative purposes only and should not be construed as limiting. Numerous specific details are disclosed to provide a thorough understanding of the disclosure but, in some cases, details well known to the state of the art and/or to the skilled in the art, or conventional, are not disclosed to make the disclosure more intelligible. References to a particular version or to a generic version of this method and system in this document may refer, but not necessarily, to the same version but, in any case, to at least one.

Reference in this document to "an exemplification" (whether understood in a specific or generic sense) means that a particular functionality, structure or feature described in connection with the exemplification is included in at least one exemplification of this Method and System. The wordings of the phrase "in an exemplification" at various points in the description do not necessarily all refer to the same exemplification, nor are they separate or alternative examples that are mutually exclusive from other examples. In addition, various functionalities or features are described that may be used by some examples but not by others. Likewise, various requirements are described which may be requirements for some examples but not for others.

The examples contained in this document include methods and systems for the coding of products by means of a generation of optimized codes for non-predictive databases, aimed at the serialization of products, their certain identification and their traceability, as well as methods and systems for their quick access to any database they are archived. In one version, the method according to the invention comprises the generation of a plurality of product codes or batches of products or pallets of batches/products (hereinafter referred to as codes or codes), where each code being individually unique for each item or batch of items. Another version of the method according to the invention provides for quick access to the generated codes, stored in any database, by exploiting the information entered in the structure of the code itself, after it has been decoded and decrypted.

In one example, the plurality of product codes is generated in the cloud of a subject acting as a "supplier/provider of code generation services". In addition or alternatively, the product codes can be generated by the entity that produces and/or manages and/or markets the products on which the codes are then intended to be applied.

Fig. 1 illustrates an example of the logic flow of how a code could be constructed in accordance with one of the possible examples of the method according to the invention.

Fig. 2 illustrates a step by step example of how a code could be constructed in accordance with one of the possible examples of the method according to the invention.

In particular, as can be seen from the example of Fig. 2, when the generation of a batch of codes is requested, the Code Generator starts its generation using the input data provided by the Applicant. The data provided as input, in a version of the Method and System, must be at least the quantity of codes to be generated and from which Version ID these codes must inherit their structure.

By way of example, the generation of a Code is illustrated, according to the data sent by the Applicant.

Preferably, the input data are: request to generate a code that must belong to the “Version ID” equal to “0”, hereinafter also “Version ID 0”, by structure and generation.

In an example, the Code Generator retrieves from the Service/Support Registry - preferably organized in a database - the "Version Rules and the Meaning of Sections/Blocks" (hereinafter also referred to as "VERSION’S RULES LEDGER & Chunk Meaning") , in accordance with the Version ID provided, all the rules necessary to generate the codes for that Version ID. Conveniently, as will become clearer later, said Register can be divided into two parts containing respectively the "Version Rules" (also called "Version's Rules Ledger") and the "Meaning of the portions/blocks" (also called "Chunk Meaning DB "). In particular, said register contains (in particular in the "Version Rules" part) at least one set of predefined rules for the generation of a plurality of unique original codes in binary format and also contains (in particular in the part "Meaning of the portions/blocks ") The meaning of each significant portion (ie of each portion bearing a meaning, that is, useful/necessary information for the reconstruction of the storage address of each code and/or data associated with it) and also the values which are associated with the numbers which are defined/calculated by the bits of each significant portion, as will become clearer below. In an example, the “VERSION’S RULES LEDGER & Chunk Meaning” contains the fields illustrated in Figures 3 and 4, as well as - preferably - also contains the information for the encryption and encoding of the codes. These fields are used by way of non-limiting example in the attached drawings and diagrams, in which the same elements are identified with the same reference numbers. In particular, Fig. 3 illustrates a graphic example of the "VERSION’S RULES LEDGER & Chunk Meaning" for the "Version ID" equal to "0", hereinafter "Version ID 0".

The letter "n" in Fig. 3 represents the n-th instance of its category. The letter "n" therefore represents, in this example of implementation of the "VERSION’S RULES LEDGER & Chunk Meaning", infinite rows to allow infinite version IDs and infinite columns to allow infinite length parameters, that is, the infinite subsets of which it is composed a code.

Fig. 4 illustrates a textual example of the "VERSION’S RULES LEDGER & Chunk Meaning" for "Version ID" equal to "0" and "Version ID" equal to "1".

In the example of Fig. 2, the applicant sends the request to generate a code that must belong to the set of Version ID 0 codes.

In the first step of the example of Fig. 2 (henceforth an example of a generation), the Code Generator collects the two input data (quantity of codes to generate and Version ID) and consults the "VERSION’S RULES LEDGER & Chunk Meaning".

As can be checked from Fig. 4, relative to Version ID 0, the generator extracts the following data:

- Total length of the code, which in the example is 90 bits,

- Composition and length of the portions (also called "Chunk") that make up the code; in the specific case, the code is composed of five portions (Chunk), namely:

- Version ID, which in the example has a length of 10 bits;

- ChunkO, which in the example has the meaning of "Node ID" and length of 16 bits;

- Chunkl, which in the example has the meaning of "Collection ID" and a length of 3 bits;

- Chunk2, which in the example has the meaning of “Position ID” and a length of 31 bits;

- Chunk3, which in the example corresponds to a “Random” portion and has a length of 30 bits.

Once this data has been collected, the Code Generator is then able to build the 90- bit long container that it will fill with the code values, divided by individual chunks.

In the second step of generating a code, the Code Generator will fill the 90-bit container prepared in the previous step with the corresponding correct values. These values are given by the requester for the Version ID and by the VERSION’S RULES LEDGER & Chunk Meaning for the parameters of the other chunks, as explained in more detail below.

Once the container of the right size has been built (see step 5 of Fig. 1), one of the methods to obtain the correct values of the chunks is to see if codes have been generated before. We assume for ease of explanation that no code has yet been generated and that the code generation method is, by way of example, the increasing one.

From the input data of the Applicant, the Code Generator is configured to fill the chunk corresponding to the Version ID with the value 0 (see step 6 of Fig. 1). Since the Version ID Chunk is 10 bits long, the generator will write ten zeros. The Version ID Chunk is filled in.

Since no code has been generated previously, the other Chunks (ChunkO, Chunkl , Chunk2) assume a value of zero. Differently, if codes had been generated previously, the Generator would have continued adding the correct value required for each Chunk.

More in detail, as represented by steps 7 to 9 of Fig. 1 , the Code Generator fills:

- with a zero each of the 16 bits of ChunkO, which represents the ID of the instance that assumes the Node ID for that given generation;

- with a zero each of the 3 bits of Chunkl , which represents the ID of the instance that assumes the Collection ID for that given generation;

- with a zero each of the 31 bits of Chunk2, which represents the ID of the instance that assumes the Position ID for that given generation.

Here ends the phase of generating the significant part of the code.

In one example of code generation, it is the part produced so far that is stored in the database. In another example of the generation of codes, to optimize the storage space of the database, it is possible to store this part of the code, excluding its Version ID.

Advantageously, the following steps concern security and usability issues of the code.

In step 10 of Fig. 1, the Code Generator fills with random values (between 0 and 1) each of the 30 bits of Chunk3, which is precisely the random portion of the code for that given generation.

The code in its original version (also called "Plain") is thus generated. In particular, the original exemplary code thus created is illustrated in Fig. 5 in which the "Bit" column represents the container created by the generator with the information received as input and, in the "Values" column, the relative generation values are indicated. The bits of all chucks are all zero, except for the random chunk which is 30 bits long. In the following steps, in the example of a generation, the Plain Code is encrypted and encoded in such a way as to have the characteristic of non-predictivity and that of usability by the end user.

In this code generation example, the code is a concatenation/sequence of 90 binary numbers. Preferably, to encrypt this code, mixing rules are used according to a predefined cryptographic map. For example, this Map can be the one illustrated in Fig. 6a.

In particular, Fig. 6a indicates an example of how the bits of the Plain Code which is composed, for this example, of 90 bits can be encrypted. More in detail, according to the table of Fig. 6a, the first bit of the Plain Code (the one that is in position 0) is shifted to position 70; the second bit (the one that is in position 1) is shifted to position 51; the third bit (the one that is in position 2) is moved to position 6 and so on, following the order in the table. In the last column of the table of Fig. 6a, it is possible to see the original code that was encrypted according to the encryption rules of the map defined in the two intermediate columns of Fig. 6a. Respectively, the columns of the table of Fig. 6a indicate: the original code (Plain Code) of departure, the encryption rules and the Encrypted code with said rules.

The encrypted code is still a 90-bit sequence. This sequence is inconvenient to manage for the tracking of goods as the binary number is not easily readable by a human being or by a device (PDAs, tablets, smartphones, etc.) and, advantageously, for this reason, the encrypted code is then encoded and, preferably, it is mapped on a coding system which, preferably, is defined by an alphanumeric alphabet, such as for example the one which includes the characters of the ASCII standard. Advantageously, instead of using a UTF8 encoding system which implies the use of 16 bits for the representation of a single character, the Code Generator can use for example only 6 bits (or in any case 2 or more bits) to represent a single character ( letter and/or symbol), according to the scheme of Fig. 6b, which is illustrated below, in which, for example, an encoding system of 64 characters is used, each of which is defined by a specific sequence of 6 bits.

To encode the encrypted code, the latter is divided into 6-bit blocks and each block is assigned the corresponding letter according to the map/coding system (for example defined by an alphanumeric alphabet - human readable - with letters, numbers and special and/or punctuation characters) of Fig. 6b.

The result (s4bqXPKLksDb4L $) is visible in Fig. 7 where all the columns described in Fig. 5 and 6a are also represented, in order to have in a single figure all the elements necessary to follow the encryption and coding steps of the original code.

The coded code thus obtained is a public code that is intended to be applied/associated with a product or batch of products to be traced.

In one example of the method, the public coded code can be stored in a database. The generation of subsequent codes is obtained by repeating the generation cycle described above and increasing the various chunks one unit at a time, from right to left.

Advantageously, the code generation cycle considered as one of the possible examples of the method according to the invention is able to uniquely identify a number of products or batches of products or pallets of batches/products corresponding to the number which is obtained by multiplying the possible permutations of the chunks among themselves, excluding the random ones. In particular, in the example of the generation of codes adopted in this disclosure, the possible number of univocally identifiable and traceable products/lots/pallets, having been used binary numbers, is equal to the 2^{N ° bi}tversⁱon^iDx 2 ^{N 0} ^bit^Chun^kOx 2 ^{chunk1 bi}t number c 2 Chunk2 ^bit number, _wh_|Ch expressed IP numbers IS equal to 2¹⁰ X

2¹⁶ X 2³ X 2³¹ = 2⁶⁰ = 1.152.921 .504.606.846.976. Since the Version ID is 10 bits long, it is calculated that for each Version ID it is possible to identify and trace 2⁵⁰ = 1 .125.899.906.842.624 products or lots of products or pallets of lots/products.

Conveniently, in the example considered here for purely explanatory purposes, the code composed of 90 bits can be stored in different ways within the database, and in particular it can be stored:

- the original code generated without the Random component (see step 9 of Fig. 1), i.e. only the first 60 bits are stored, or

- the original code generated without the Random portion and without the portion that defines the Version ID, ie only the 50 bits ranging from the bit in position 10 to the bit in position 59 are stored; or

- the complete 90-bit code, encrypted and encoded (see step 13 of Fig. 1).

Conveniently, in the exemplary embodiment illustrated and described herein which stores the original code generated without the Random portion and without the portion that defines the Version ID, this code generation system/method is able to manage a code consisting of 15 characters alphanumeric (see step 13 of Fig. 1) using exclusively, in the example of the generation of a code we are examining, 50 bits against the 240 bits that would be needed in a traditional system to represent the same 15 alphanumeric characters in UTF8. Advantageously, regardless of how the generated code is stored in the database, the code that should be used to uniquely identify the objects for the purposes of secure traceability, is the public one (i.e. first encrypted and then coded) which in an example is consistent in its structure with that obtained at the end of the generation process (see step 13 of Fig. 1) and exemplified in Fig. 7. Basically, regardless of how the generated code is stored, it is the coded public code that is applied/associated with the various products or batches of products or pallets of batches/products to be uniquely identified. Through one of its/their possible implementation forms described and illustrated above, the Method and the System according to the invention allow to optimize the storage space in the databases.

In particular, the encoding of each cipher code by means of a compression coding system - that is, a coding system in which each character is uniquely identified by a specific sequence of two or more bits and, preferably, by a sequence of bits equal to the number of bits of each block into which the encrypted code itself is divided - combined with the fact that not all the portions that make up the original code are stored (for example, the latter is stored at least without the Random component) is particularly advantageous as saves storage space. More in detail, for example, a code of 15 alphanumeric characters in the UTF8 encoding system requires 240 bits of storage space, while a code of 15 alphanumeric characters in the method according to the invention requires 50 bits of storage space, thus obtaining a saving 190 bits. Furthermore, considering that with 15 characters it is possible to manage 1,125,899,906,842,624 storage addresses (where each address indicates a code and therefore a product within a database) and considering the aforementioned saving of 190 bits for each address/code, thus obtaining an overall saving of the total storage space (i.e. to store all the addresses) which is equal to 1.125.899.906.842.624 * 190 bits = 2.490 368 x 107 Gigabytes (i.e. almost 25 million gigabytes), while maintaining all the security of reverse engineering given by the fact that only the public coded code is disclosed externally.

In the example below, it is also illustrated how the Method and/or the System according to the invention improves/improve the speed and recovery times of the code and also manages/succeeds in solving problems relating to the management of complex databases architectures of such as synchronization problems between servers that have physically stored the code and servers that keep only the indexes of the latter. For example, in the case of a database with tables spread across multiple servers, normally one of them also has the pointing indexes for each server and for each table. At present, if these indexes become damaged it is not possible (for many database technologies) to rebuild them without stopping the database itself and, therefore, the servers are redundant. Advantageously, the method according to the invention instead allows to overcome these redundancies and also allows to avoid the need to have an index that connects the tables to the server since the storage location of the code is substantially contained in the code itself.

In particular, when managing object traceability applications or in any case when large amounts of data have to be managed (for example collating loT sensor data) and these must be made available to remote applications, the best configuration according to the state of the art is that of dividing the tables into several tables as otherwise the latter would be enormous. However, this configuration has physical limits which, when reached, force these tables to be "scattered" in multiple databases residing on different servers (eg database clustering). In particular, this configuration is based on a server (called "index server") which knows, for each single data, on which cluster server the data itself resides and this in order to be able to recover it. This index server then stands between the application server that requests the data and the database server that contains the table in which the data is contained. The index server, which is the only one to have total data mapping, is by its nature redundant on other servers because its failure would inevitably lead to the loss of the mapping between each data and the database/table in/in which each data is stored. All this complicates the architecture of the database, increases the so-called "total cost of ownership" (TCO) and, moreover, causes a performance degradation due to the fact that part of the hardware resources are consumed by service activities such as the continuous synchronization of the single Database Server of the cluster with the primary Index Server and of the latter with the Secondary Index Servers (which are redundant replicas). Last but not least, the fact that, according to this traditional architecture, the request path for a data by the Application Server until it is returned to the latter is particularly fragmented, requiring a plurality of queries between the various servers (in fact when the Application Server requests data, the Index Server performs a first query on its index database to know on which Database Server the data resides, a second query is performed by the Database Server - identified by the first query - to understand which partitioned table the data resides and, finally, a third query is performed to extrapolate the data from the table identified by the second query).

On the contrary, with the method and/or system according to the invention there is no provision and no architecture which provides for the use of the Index Server and Database Clustering, and this advantageously allows: - a significant simplification of the database infrastructure as everything is reduced to a single instance of a database without the need to provide intermediate and redundant servers,

- an increase in infrastructure performance given that part of the infrastructure resources are not used for the management of the Index Servers and the double synchronization between them and with the Data Cluster Servers,

- optimization (preferably obtaining at least a halving) of the query procedure since the Application Server is able to directly query the right Database Server and the right table, both of which are known a priori as they are contained and encoded within of the same code, - no longer depending on a single architecture that contains all the data, but directly addressing the query on the database of interest, the system object of the invention allows to scale the number of databases to an enormously greater number than that allowed by any database architecture Clustering and, contrary to this, without any performance degradation as the number of servers increases,

- a significant reduction in the "total cost of ownership" (TCO). More in detail, the Method and/or the System also allow to technically solve the problems of addressing data in different databases, in order to optimize queries or to keep the data in the infrastructures of those who generated them, also maintaining a Software application approach as a Service (hereinafter “SaaS”) overall, also known as Hybrid Multicloud Strategy. This allows to decouple the application part from that of data storage and this is particularly advantageous as it allows to have an architecture in which there is at least one provider - even unique among several subjects (for example companies) - which offers application services for the generation of the code and/or for the management of the query (ie to search for the storage address in which the original code corresponding to the public coded code is stored), even in a single platform for several subjects, in the Software as a Service mode (hereinafter "SaaS"), while the possession of the data, and their storage medium, may remain completely in the physical infrastructures of the single subject or in any case managed by the latter, regardless of the database technology used.

In particular, according to the present invention, the original code comprises a base portion containing the bits that define an identifier of the set of predefined rules to be used for the generation and interpretation of the corresponding code and which, in essence, indicates the database technology and determines thus the way in which the SaaS application connects to the database of interest with the correct methodology envisaged for that given technology. For example, a user of the SaaS service requests access to the data of three different parties (for example three companies) who, for reasons of privacy and data security, have decided to keep their data on-premises (ie at their headquarters). In particular, the data are thus located in geographically different sites from where the SaaS service for creating and managing codes is provided and, moreover, the three subjects did not have to modify the database technology already in use in order to use the SaaS service for code creation and management. Conveniently, the SaaS application which is based on the method/system according to the invention, is able to manage this heterogeneity of technologies because it derives the location of the data and the method of connection to the database from a part of the same original code that is generated with the method and/or system according to the invention, and this part is then elaborated in its meanings by a dedicated module (ie the module called "Ledger of Versions' Rules & Chunk Meaning"). Basically, the method according to the invention provides that the original code contains:

- a base portion containing the bits that define an identifier of the set of rules used for generating the corresponding code, - at least one meaning-carrying portion that contains bits representative of information necessary to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code, and, therefore, it is the same original code that contains both the mode (set of rules) to interpret the bits of which the same format code, and this in order to be able to extract from the code the information to reconstruct the address (URI) - also contained in the same code

- at which the data is stored.

Therefore, if a certain subject were to change the data storage technology, it is not necessary to create new codes, but it is sufficient to give a different meaning (ie update the meaning) of the existing codes and this is done by updating/modifying the set of rules which are associated with the identifier - which remains the same - which is defined by the bits of the base portion of said codes. In particular, this is possible because the original code includes a base portion containing the bits that define an identifier of the set of rules used for the generation of the corresponding code and, moreover, because there is a management database (ie the "VERSION’S RULES LEDGER & CHUNK MEANING ") that associates/matches a set of rules to an identifier that is defined by the base portion provided for in each original code and which, therefore, is contained/present within each code that is generated. Furthermore, the Method and/or the System allows you to easily change the servers where the codes are stored (for example for an upgrade or a change of provider), taking advantage of the decoupling of the chunks with their value which is managed with a view to key-value. Once the servers have been switched, this method allows for real-time redirection of code search queries just like an IP change in a Domain Name Server (DNS).

In particular, Fig. 8 shows an example of the logical flow of the method according to the invention to search - starting from said public coded code which is associated and/or applied to a product or to a batch of products - the address of storage (URI) in which the original code in binary format corresponding to said public coded code and/or the data associated with said original code is stored, preferably to read and/or modify said data. More in detail, Fig. 8 shows the logical flow of an example to explain the steps that are carried out from the moment an enabled device reads the code applied to a product, up to the moment this code is accessed within the database. The same diagram contains the names of the components that perform the tasks and the three spam filter points, which are used to eliminate irrelevant queries as much as possible. This filtering serves to get only the "clean" queries to the servers, maximizing the hardware resources of the servers, thus improving the performance of response times.

Fig. 9 illustrates in greater detail an example of the flow of steps of how an encrypted and coded code can be interrogated by an applicant and the steps used to arrive in the section of the database of interest.

In an example, the plurality of product codes is marked on the product labels at the time of their insertion in the packaging (generally the primary one), so that each product unit has a different product code. Product codes may be associated with products at the manufacturer's site or at any other site the manufacturer deems suitable.

In one example, when a Applicant wants to find the storage address of a code associated with a product to read and/or modify the data associated with it, he activates a request for the acquisition of the public coded code using an enabled device. Appropriately, by enabled device we mean any device, for example a smartphone, capable of reading the public code appropriately coded (for example in the form of a QR Code), which is associated/applied to the product or to a batch of products, and in able to send a corresponding request via the Internet to the system access server.

In an example, advantageously the first step that is taken once a request is activated, in order to avoid brute force attacks on the server (or servers), is the analysis of the public coded code to verify its formal correctness. This analysis is carried out by the "Syntax Scanner" which controls eg. the right length of the code and/or the correct coding system of which it is composed. If the syntax is correct, the process moves on to the next stage. If the syntax is wrong, the system reports the error and stops the process.

In one example, when the Syntax Scanner process finds no errors, the code is passed to the "Version ID Extractor".

Conveniently, the management of the codes in the Method and/or System according to the invention is completely parametric, ie by changing the ID of the version, it is possible to change the length and the meaning of all the portions (chunks) that make up the code. All chunks can be modified in their length and meaning.

What in this example remains constant between the codes generated with the same set of predefined rules is:

- total number of bits that make up the code;

- number of bits representing the Version ID;

- position within the original code (Plain Code) of the Version ID;

- method of encryption and coding.

Conveniently, therefore, the “Version ID Extractor” needs a fixed and known a priori rule to extract the Version ID from a code. In one example, the "Version ID Extractor" decodes and decrypts the code and extracts its Version ID. To decode and decrypt the code, steps are taken that are the reverse of those described above to generate the public code. Appropriately, these steps are described in more detail below. In one example, the "Version ID Extractor" starts to manage the following public code: “s4bqXPKLksDb4L $”. Using the encoding map of Fig. 6b the "Version ID Extractor" starts analyzing the first character: it is a lowercase "s" and, in the encoding map, the lowercase s corresponds to the value 000000 in the Bit column it is "4" which in the coding map corresponds to the value 000001 , then the third character "b" which corresponds - again according to the coding map in Fig. 6b - to the value 001000 and so on until all the characters of the public code are analyzed. Once all 15 characters of the public code have been analyzed, we will obtain the fully decoded and expanded code which is composed of 90 bits.

In one example, once the "Version ID Extractor" has decoded the public 15- character key into the 90-bit encryption key, it starts decrypting it. The "Version ID Extractor" in accordance with the rules of Fig. 6a performs the inverse of the encryption function performed in the step of generating the encrypted code. In this way, therefore, the "Version ID Extractor" decrypts the encrypted code and thus obtains the original code (Plain Code).

In an example, the “Version ID Extractor”, on the basis of a set of known and predefined rules, knows that the first 10 bits of the Plain Code represent the value of the Version ID and, therefore, proceeds to calculate it. In the current disclosure of the exemplification, the calculated value is 0 since the first 10 bits of the Plain Code are all zero.

In one example, the calculated Version ID value is passed to the "VERSION’S RULES LEDGER & Chunk Meaning" along with an envelope containing the undifferentiated Plain Code. Conveniently, in an example, in accordance with the flow of Fig. 8, the register

(preferably organized in a database) of service/support "VERSION’S RULES LEDGER & Chunk Meaning" can be divided and named respectively "Version's Rules Ledger" and “Chunk Meaning DB”, depending on the role it plays in the flow. Advantageously, the "VERSION’S RULES LEDGER & Chunk Meaning" database can also be physically split when, in an example, the person who owns or manages the data does not want to reveal some values to the application service provider. The "Chunk Meaning DB" can therefore be either in the same database as the "Version's Rules Ledger" or separate from it, and located on the customer's premises.

Advantageously, for additional security reasons, the "Chunk Meaning DB" can be hosted at the headquarters of the company that requests/uses the tracking system and, appropriately, in this way, the conversion data contained in the "Chunk Meaning DB" they are totally unknown to those who generate the code.

In an example, the “Version's Rules Ledger”, from now on the VRL, receives the envelope with the Plain Code and the indication to which Version ID that Plain Code belongs. Advantageously, in order not to tire the servers with useless queries (brute force attacks, floods, etc.), the VRL checks whether that Version ID has ever been published. If it has never been published, the VRL blocks the process and reports the error. If, on the other hand, the Version ID has been published, then, the VRL extracts the rules and applies them on the Plain Code, to delimit the length of each chunk of which the Plain Code itself is composed.

In an example, in the VRL, each Version ID is associated with the rules through which each Plain Code belonging to that Version ID was generated. With reference to the example of Fig. 3 and 4, with regard to the Version ID corresponding to "0", the corresponding set of rules provides for breaking the Plain Code of 90 bits into five portions (chunks) of which a first portion (which defines the "VersionID") is 10 bits long, the next portion (which defines the "ChunkO") is 16 bits long, the next portion (which defines the "Chunkl") is 3 bits long, the penultimate portion (which defines the " Chunk2 ") is 31 bits long and the last portion (which defines" Chunk3 ") is 30 bits long;

In one example, the VRL sends to the Chunk Extractor an envelope containing the Plain Code and the set of rules associated with the reconstructed/identified Version ID. The Chunk Extractor applies the rules received together with the Plain Code and derives the individual chunks from them. For each chunk, the Chunk Extractor analyzes its meaning and, for significant chunks (ie non-random ones), calculates the corresponding number. These numbers are used to query the Chunk Meaning DB (hereinafter also referred to as "CMDB") for Version ID O.

For each chunk, its n-th value represents the key of its n-th instance to which it corresponds, to its time, a given value. This value is the one used to construct the path that locates the code in the database. Advantageously, therefore, there is a decoupling between the value/number of each chunk expressed in the original code (Plain Code) and the value of its (n-th)instance.

In an example, if the n-th value of the chunk for that Version ID should not have a corresponding key <-> value pair, in order not to overload the servers with useless queries (brute force attacks, floods, etc.), the CMDB blocks the process and reports the error.

With reference to the example of Fig. 3 and 4, for the Version ID 0 we have that the “ChunkO” represents the “Node ID”. Furthermore, since the sequence/set of bits of "ChunkO" defines the number "zero", in the list of instances of "ChunkO", the value associated with the key is extracted which is equal to 0. In particular, in the example of Fig. 3 and 4, this value is:

“https: // anywayTolndicateAServer: port/api”.

The same procedure applies to Chunkl In particular, for Version ID 0 we have that “Chunkl” represents the “Collection ID”. Furthermore, for Version ID 0 with NodelD 0, the instance of Chunkl corresponding to the number "zero" (which is defined by the set/sequence of bits of Chunkl in this example) takes the value "Collection! D # 0".

The same procedure applies to Chunk2. In particular, for Version ID 0 we have that “Chunk2” represents the “Position ID”. Also, for Version ID 0 with NodelD 0 and Collection! D 0, the instance of Chunk2 corresponding to the number "zero" (which is defined by the set/sequence of bits of Chunk2 in this example) takes the value "0".

Chunk 3 is not taken into consideration because it is the random portion of the code.

In one example, the values and meanings of the Chunks, thus extracted, are sent to the Seeker. The Seeker then receives and uses a series of key-value pairs that are defined by the chunk meaning (Meaning) and its value, for example: NodelD - https: // anywayTolndicateAServer: port/api Collection! D - Collection! D # 0 Position - 0. By analyzing the keys and their values, the Seeker is able to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code, and in particular it reconstructs the position (Position) that has the code sought, within which Collection (Collection! D) and within which Server (NodelD), to build a query that points directly to the desired address in which said original code and/or data is stored associated with said original code.

Conveniently, for other data storage technologies, for example those of the SQL type, the meaning that the Chunks can assume will be for example RawlD, TablelD, DatabaselD, Served D, so that the Seeker can arrive directly in the desired row (RawlD) of the table (TablelD) of the Database (DatabaselD) of the desired Server (Served D). Advantageously, the method and system according to the invention allows, in one example, to increase or decrease the number of bits that make up the Plain Code in order to calibrate the maximum number of identifiable objects necessary for a given traceability project in the lowest possible number of bits. In the example described and illustrated, the length of the Plain Code is 90 bits. Conveniently, it is also possible, by increasing or decreasing the size of the random Chunk, to increase or decrease the number of objects to be traced safely. For example, in the example described/illustrated, the 90-bit Plain Code is made up of 60 significant bits and 30 random bits. This means that a maximum of 2⁶⁰ can be identified and tracked in this example products/lots/pallets. If in a project it is necessary to identify a maximum of 2⁵⁰ products/lots/pallets, it is sufficient to extend the length of the random Chunk from 30 to 40 bits and leave the Plain Code 90 bits long to obtain another possible example that is online with the new requirements.

Advantageously, it is possible to decrease the number of products/lots/pallets to be traced by increasing the length of the random Chunk and maintaining however the length of the original code (Plain Code) at 90 bit. Conveniently, this allows to obtain other significant advantages: the first advantage is that by increasing the length of the random portion, the security relative to the non-predictivity of the code increases; the second advantage is that space is saved in the database because, in accordance with what has been said above, in an example, it is possible to store only the significant part of the code in the dedicated database and, therefore, being this decreased by 10 bits, 10 bits for each code generated in terms of data storage space can be saved; the third advantage is that, if for one reason or another you make a mistake in evaluating the maximum number of objects to be traced and you realize that you have to trace a greater number of objects, it is sufficient, by changing the version, to reduce the length of the Random chunk. This methodology allows you to significantly change the meaning of the Chunks or increase their ability to identify products, and this is achieved without changing anything in the application part since these changes are obtained through configurations of the "VERSION’S RULES LEDGER & Chunk Meaning". Conveniently, what has been said also applies if the number of objects to be traced must be increased by decreasing the length of the random Chunk.

Advantageously, any part of this method and system according to the invention is parametric:

- the total length of the original code (plain code) is a purely arbitrary decision and can be adapted to the size of the traceability project;

- the number of portions (chunks) within the original code (plain code) can vary from 1 to a number equal to that of the bit length of the original code (plain code)

- the chunks of the plain code can have any semantic meaning,

- in an example it is possible to configure the Seeker in such a way that, by reading the meaning assigned to the portions (chunk), it is able to autonomously build the query string conforming to the technology of the database to be queried,

- the encoding rules (ie "encoding map") can vary as to the number of bits, and in particular each subdivision block can be from 2 bits to "n" bits long; the choice of this length is a parameter that can be determined by the designer, - the encoding rules (ie "encoding map") may vary in the association between groups/blocks of bits and the coding system used,

- the encoding rules (ie "encoding map") may provide for the use of any alphanumeric encoding system, including or not special characters or punctuation characters,

- the cipher table can vary in its length (and suitably corresponds to the length of the original code) and in its scrambling combination.

The method according to the invention comprises:

- a storage address (URI) in which each code and/or data associated with it is stored,

- a register/database for the "Version Rules" (also called "Version's Rules Ledger") in which a plurality of sets of rules are stored for the generation of a unique original code and in binary format,

- a register/database for the "Meaning of the portions/blocks" (also called "Chunk Meaning DB") in which, for each set of rules, the meanings of each of the portions - of the generated code with a corresponding set of rules - are stored which are carriers of meaning, ie of at least one information useful/necessary for the reconstruction of the storage address (URI) of each code and/or of the data associated with it within said register/database; in addition, in the register/database for the "Meaning of the portions/blocks", the sequences of characters that define the storage address (URI) of each code and/or the data associated with it are also stored and, in particular, are stored within said register/database so that each sub-sequence of characters that defines said storage address (URI) is associated with a number (which thus acts as a key) which is defined by the sequence of bits of a corresponding portion bearer of the meaning of said code; in other words, the register/database for the "Meaning of the portions/blocks" includes sets of "key-value" pairs where the "key" corresponds to the number defined by the sequence of bits of a corresponding portion carrying the meaning of said code , while the respective value corresponds to a sub-sequence of characters that defines the storage address (URI) of said code,

- a further register/database in which the generated codes are stored and, in particular, in which they can preferably be stored:

- only the portions bearing the meaning of each original code that is generated, possibly with the addition of the base portion (ie the portion that contains the bits defining the identifier of the set of rules used to generate said original code), and/or

- the public code (ie the original code encrypted and then encoded) that is applied and/or associated with each product or batch of products.

Advantageously, the register for the "Version Rules" and the register for the

"Meaning of portions/blocks" can be combined in a single register, preferably a database, thus defining the "VERSION’S RULES LEDGER & Chunk Meaning", or they can remain separate and distinct.

Advantageously, it is sufficient to correctly combine the meaning and value of the chunks, so that the number of operations necessary to identify any record/document is always constant regardless of how huge the database may be and how many shards or subdivisions in clusters/partition tables it can to have. The constant number of operations translates into linear access time in any database, of any size, in any record. This is because the parametric system of chunks (ie the portions of which the code is made up) works exactly like a database index, but is external to it.

Advantageously, given that the index is configured in such a way as to directly retrieve the single record and/or data associated with the original code, the Method and the System allow to avoid necessarily having to resort to architecturally complex database systems such as shard, cluster, partition of tables, etc. Furthermore, by keeping the infrastructure simpler, it makes it both more resilient, as the points of failure decrease, and cheaper in terms of configurations, number of servers and maintenance.

In an example of the Method and System, it is possible in a logical way, to divide the processes into two families. The first represents the family of processes necessary for the generation of codes to be applied to products/lots/pallets of products and, the second, contains the processes that arise from the query of a public code associated with a product/lot of products that is in the market, until its (and/or the data associated with it) is found in a database or a portion thereof.

This example can be implemented at a logical level with server blocks according to the architecture illustrated in Fig. 10a in which two users 21, 24 request through devices enabled for surfing the net 23, 22 and 25 respectively, one for the creation service and the another is the code search service. In particular, both requests end up in a server 26 in which all the processes/steps of the method according to the invention take place.

In the architecture of the system of Fig. 10b, the block diagram is illustrated in greater detail.

In one example, logic blocks can be developed using the Javascript language. This language simplifies the development of this Method and System. Each logical component can assume, with respect to another, both the role of client and server (this is closely related to the business decisions of those who use the Service). The Javascript language, being able to intelligently manage both the server side and the client side, is the one recommended to date, although it is not binding for the correct functioning of the Method and the System. A possible embodiment is that in which the on-premises installation of a part of the VERSION’S RULES LEDGER & Chunk Meaning database is required. In one example, the recommended technology to use for the VERSION’S RULES LEDGER & Chunk Meaning database is a multidimensional, schema-free database organized into documents. While this is the technology that helps the developer most, in other examples, the VERSION’S RULES LEDGER & Chunk Meaning, can be developed with any other known database technology.

In particular, the requesting devices 22 and 25, acting for example as clients, communicate through a telecommunications network 23 with the Server 26 to access the information relating to the code.

The Server 26 can be managed by a person who offers information retrieval services relating to the code generated through this Method and System, to one or more users 21 and/or 24. For example, the user 21 having multiple production sites and/or packaging can be served by different Servers 26 as needed. Alternatively, Server 26 can serve a variety of users 21 associated with different companies with similar or different products. Server 26 can also serve various sites of the same company In Fig.10b the network (Network) 23, through which the devices 22 and 25 communicate with the server 26, can be an open network, such as the internet (but not only), or a private network, such as an intranet (but not only). In one example, the communications to and from the Server 26 are made through any type of secure communication protocol, such as (but not limited to) SSL/TLS or SECOQC. The present invention has been illustrated and described in some of its preferred embodiments, but it is understood that executive variations may apply thereto in practice, without however departing from the scope of protection of the present patent for industrial invention.

Claims

C L A I M S

1. Method implemented using at least one computer for the generation and/or management of codes, preferably to be used for tracing products or batches of products or pallets of batches/products, characterized by the fact that it includes the following steps : - on the basis of a set of predefined rules, a plurality of unique original codes are generated in binary format, at least a portion of each of said original codes contains bits representative of information necessary to reconstruct a storage address (URI) in which the the code itself and/or the data associated with it, each of said unique original codes is generated in such a way as to include: - a base portion containing the bits that define an identifier of a predefined set of rules used for the generation of the corresponding code,

- at least one meaning-carrying portion which contains bits representative of information necessary to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code, - at least a non-meaningful portion which is generated randomly and which contains unnecessary bits to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code, to make said code not predictive,

- these original codes are encrypted by means of predefined encryption rules, thus obtaining corresponding encrypted codes, - a coding of said ciphered codes is carried out, thus obtaining corresponding public coded codes to be applied/associated each, preferably by means of a physical label, to a product or batch of products or pallets of batches/products to be traced, said coding phase involves subdivide each encrypted code into a sequence of blocks of at least two bits and, on the basis of predefined encoding rules based on a predefined encoding system in which each character of said encoding system is uniquely identified by a specific sequence of bits having the same length of said blocks, a corresponding character of said predefined coding system is associated with each block of the encrypted code, thus obtaining a corresponding public coded code of non-positional type which is constituted by a number of characters of said predefined coding system which is lower than the number of bits of the corresponding original code e/or the corresponding encrypted code.

2. Method according to claim 1 , characterized by the fact that said at least one meaning carrying portion of each generated original code is stored in a dedicated computer medium, thus collecting the information necessary to reconstruct the storage address (URI) of the original codes and/or the data associated with said original codes.

3. Method according to one or more of the preceding claims, characterized in that for each original code generated, in addition to said at least one meaning-bearing portion, said base portion is also stored in a dedicated computer medium containing the bits that define an identifier of the set of rules used for generating the corresponding code.

4. Method according to one or more of the preceding claims, characterized in that for each original code generated, only: - said base portion containing the bits that define an identifier of the set of rules used for the generation of the corresponding code.

- dictates at least one meaning-carrying portion which contains bits representative of information necessary to reconstruct the storage address (URI) of said original code and/or of the data associated with said original code.

5. Method according to one or more of the preceding claims, characterized in that:

- said set of predefined rules for the generation of a plurality of unique original codes is selected from a plurality of predefined rule sets, different from each other, for the generation of said codes,

- each set of rules for the generation of said unique original codes in binary format includes at least one of the following data:

- the total number of bits of each of said codes to be generated,

- the number of portions of which each of said codes to be generated is composed,

- the number of bits of each of the portions that make up each of said codes to be generated, - the type of information, and therefore the meaning of each of the portions of said codes to be generated, which are necessary to reconstruct a storage address (URI) in which the code itself and/or the data associated with it are stored.

6. Method according to one or more of the preceding claims, characterized in that the following is provided as input: - the number of unique original codes to be generated, said number being defined on the basis of the number of products or batches of products or pallets of batches/products to be tracked, and

- at least one set of said predefined rules, and by the fact that each original code is generated in such a way that at least one bit is added to all said remaining portions of said code with respect to the corresponding portion of the last generated original code.

7. Method according to one or more of the preceding claims, characterized in that the coded public codes are stored in a dedicated computer medium, in order to have a list of the codes used and associated/applied to a product or batch of products to be traced.

8. Method according to one or more of the preceding claims, characterized in that said at least one meaning-carrying portion comprises: - a first significant portion that contains the bits that define the identifier of the node of a database,

- a second significant portion that contains the bits that define the identifier of a Collection or a Table of a database, - a third significant portion that contains the bits that define the identifier of a position in a

Collection or a Table of a database.

9. Method according to one or more of the preceding claims, characterized in that said at least one meaning-carrying portion comprises:

- a significant portion that contains the bits that define the identifier of a server, - a significant portion that contains the bits that define the identifier of a database,

10. Method according to one or more of the preceding claims, characterized in that said step of encrypting is performed by changing the position, according to predefined encoding rules, each bit of said original code generated, or groups of bits of said original code generated.

11. Method according to one or more of the preceding claims, characterized in that said encoding system is a man-readable alphanumeric alphabet, is preferably an alphabet which includes the codes of the ASCII table.

12. Method according to one or more of the preceding claims, characterized in that, to research - starting from said public encoded code that is associated with and/or applied to a product or a batch of products or batches of pallets/products - the storage address (URI) in which the original code in binary format corresponding to said public coded code and/or the data associated with said original code is stored, preferably to read and/or modify said data, the following steps are carried out :

- the public coded code that is applied/associated with a product is acquired/read,

- said coded code is decoded, thus obtaining the corresponding cipher code,

- the encrypted code is decrypted, thus obtaining the corresponding original code,

- from said original code thus obtained, and on the basis of known and predefined extraction rules, the identifier (Version ID) of the set of rules used for the generation of the corresponding original code,

- the set of rules associated with said identifier (Version ID) is extracted,

- the portions bearing the meaning that make up said original code and the relative meanings are identified in said original code, on the basis of the set of extracted rules, - on the basis of the values of said portions bearing meaning and of the relative meanings, as identified, the storage address (URI) of said original code and/or of the data associated with said original code is reconstructed.

13. Method according to one or more of the preceding claims, characterized in that:

- the bits that form the meaning-bearing portions of said code are identified within said original code, on the basis of said set of predefined rules extracted,

- once the bits of each of said meaning-carrying portions have been identified, the number corresponding to the sequence of bits of each meaning-carrying portion is calculated,

- for each meaning-carrying portion, the meaning of each meaning-carrying portion and the value associated with said calculated number of each significant portion are extracted from a corresponding register/database,

- the calculated values and the meanings associated with each of said meaning-bearing portions are used to compose the storage address (URI) in which said original code and/or the data associated with it are stored.

14. Method according to one or more of the preceding claims, characterized in that it comprises a database/register (VERSION'S RULES LEDGER DATABASE) in which a plurality of known and predefined extraction rules sets are stored, each set of known extraction rules and predefined being identified by a corresponding identifier, each set of rules comprising:

- the number of bits that make up that original code,

- the number of bits of the base portion of said original code, said base portion containing the bits defining the identifier of the set of rules used to generate said original code,

- the position of the base portion within the original code,

- the position and length in bits, within the original code, of each non-significant part, in particular of the random type.

15. Method according to one or more of the preceding claims, characterized in that:

- the base portion containing the bits that identify/correspond to the value of the identifier (Version ID) of the set of rules used for generation is identified within said original code, on the basis of a set of rules of said known and predefined extraction of the corresponding original code,

- from a corresponding register/database (VERSION'S RULES LEDGER DATABASE) in which a plurality of predefined rule sets are stored, the corresponding set of predefined rules associated with the value thus calculated is extracted.

16. Method according to one or more of the preceding claims, characterized in that it comprises an additional database/log (CHUNK Yards DATABASE) in which, for each bearer of meaning portion of each of the default rule set, it is stored:

- the meaning that is associated with each meaning-carrying portion in terms of the storage address,

- a value that is associated with the number that is defined on the basis of the bits that make up the corresponding meaning-carrying portion.

17. Method according to one or more of the preceding claims, characterized in that

- said meaning, which is associated with each portion, is used to compose a search string (query-string),

- this value, which is associated with the number calculated for each portion, is used to compose a search string (query-string).

18. Method according to one or more of the preceding claims, characterized in that:

- the bits that form the significant portions of said code are identified within said original code, on the basis of said set of predefined rules extracted,

- for each significant portion, the meaning of each significant portion and the value associated with said calculated number of each significant portion are extracted from said corresponding further register/database (CHUNK MEANING DATABASE),

- the calculated values and meanings associated with each of said significant portions are used (SEEKER) to compose the storage address (URI) in which said original code and/or the data associated with it is stored.

19. Method according to one or more of the preceding claims, characterized in that on the basis of the values of said significant portions and the relative meanings, as identified, the storage address (URI) is reconstructed, obtaining for each of said significant portions a corresponding physical addressing part which composes said storage address (URI) in which said original code and/or of the data associated with said original code is located/stored.

20. Method according to one or more of the preceding claims, characterized by the fact that that decoding (DECODING) said encoded code, thus obtaining the corresponding encrypted code on the basis of predefined decoding rules, preferably obtained by inverting known and predefined encoding rules.

21. Method according to one or more of the preceding claims, characterized by the fact that it decrypts/decrypts (DECRYPTION) said encrypted code, thus obtaining the corresponding original code on the basis of predefined rules decryption, preferably obtained by inverting encryption rules known and predefined.

22. System implemented through at least one computer for the generation and/or management of codes, preferably to be used for the tracking of products or batches of products or pallets of batches/products, characterized by the fact that it includes:

- a software module which is configured to implement the method steps according to one or more of claims 1 to 11 , and

- a software module which is configured to identify the storage address (URI) of a code and/or data associated with it, said module being configured to implement the steps of the method according to one or more of claims 12 to 21.

23. System according to the preceding claim, characterized in that said software modules are connected and communicate with:

- a module comprising said register/database (VERSION'S RULES LEDGER DATABASE) in which a plurality of predefined rule sets for the generation of said original codes and/or rules for the encryption/decryption of said codes and/or rules of encoding/decoding of said codes, and

- a module comprising said further register/database (CHUNK MEANING DATABASE) in which, for each set of rules, the meanings of each portion carrying the meaning of each original code are stored and said values which are associated with the numbers defined by the sequence of bits of each portion carrying the meaning of each original code.