Patent Application
20220391923
The present disclosure generally relates to manufacture of packages for liquid food and, in particular, to generating and storing unique marking codes for such packages.
Every day across the world, billions of litres of water, milk, juice and other liquid foods are consumed. A large proportion of the liquid food is distributed in paper-based packages, also known as carton packages. These packages are produced to protect both the nutritional value and the taste of the liquid food inside. The underlying technology greatly facilitates packaging and distribution of liquid food products across the world.
The present Applicant has identified a need to mark each package with a unique code. The provision of a unique code on each package enables various functionality, such as tracking and tracing the packages throughout the manufacturing and distribution chain, verifying the authenticity of the package, linking to web content related to the package for access by consumers or retail personnel, associating the codes with promotional campaigns and lotteries, causing manufacturing machines to perform automated actions upon detecting the code, etc.
EP3540664 discloses a robust technique for providing marking codes for packages containing liquid food, where the respective marking code uniquely identifies an individual package. The marking code is based on payload data, which uniquely represents the production of the individual package and may be indicative of the time and/or the location of the production. The payload data is encrypted to make it difficult to guess valid codes and generate fraudulent codes. The marking code is formed by combining the encrypted payload data with a non-encrypted header portion. The marking codes are provided on the packages and are also entered in a database, optionally in association with additional data. To enable efficient and fast search in the database, EP3540664 proposes to partition the database based on the time and/or location as indicated by the payload portion, and store the respective marking code in the database partition that matches the time and/or location in the marking code.
Packages for liquid food are produced on an industrial scale for the world market. Huge numbers of packages are produced each year. For example, within the ecosystem of Tetra Pak®, 188 billion (109) packages were produced in 2016. Considering that packaged products may have a shelf life of 6 months to 1 year, or even longer, for example up to 5 years, a huge number of unique marking codes need to be produced and stored in the database. The deployment of the marking codes in such an environment is likely to result in data in excess of 1 PB. This amount of data is difficult to store and manage in a unitary database.
It is thus a challenge to store these and other types of marking codes for packages of liquid food, provided in huge numbers, in a database without excessive resource consumption while enabling fast and efficient storage and search in the database.
It is an objective to at least partly overcome one or more limitations of the prior art.
A further objective is to enable fast and efficient storage and search in a database containing package-related data for individual packages of liquid food.
Another objective is to enable a database which is scalable and enables a storage capacity of package-related data of more than 1 PB.
One or more of these objectives, as well as further objectives that may appear from the description below, are at least partly achieved by a method of generating marking codes, a computer-readable medium, and a system for generating marking codes according to the independent claims, embodiments thereof being defined by the dependent claims.
A first aspect of the present disclosure is a method of generating marking codes to uniquely identify packages for liquid food. The method comprises: obtaining package production data which is unique to each individual package; operating a predefined encryption algorithm on the package production data to generate encrypted package production data; generating a marking code that includes the encrypted package production data; providing the marking code for marking of the individual package; and storing, in a database that comprises a plurality of partitions, package itemization data comprising at least a subset of the marking code and at least a subset of the package production data of the individual package. The storing comprises generating a partition key as a function of the marking code, and operating a controller coupled to the database to determine a selected partition among the plurality of partitions based on the partition key and to store the package itemization data in the selected partition.
In some embodiments, operating the controller comprises operating a predefined mapping function on the partition key, the predefined mapping function being configured to map partition keys to a set of partition identifiers, which comprises a respective partition identifier for each partition among the plurality of partitions, wherein the selected partition is determined based on a current partition identifier generated by the mapping function for the partition key.
In some embodiments, the predefined mapping function comprises a hash function.
In some embodiments, the predefined encryption algorithm is a block cipher.
In some embodiments, the package production data is obtained to represent at least one of a location and a time of producing the individual package.
In some embodiments, the at least a subset of the marking code comprises the encrypted package production data.
In some embodiments, the database is a distributed database.
A second aspect of the present disclosure is a computer-readable medium comprising computer instructions which, when executed by a processor, cause the processor to perform the method of the first aspect or any embodiment thereof.
A third aspect of the present disclosure is a system for generating marking codes to uniquely identify packages for liquid food. The system comprises a code generator configured to operate a predefined encryption algorithm on package production data, which is unique to each individual package, to generate encrypted production data. The code generator is further configured to generate a marking code that includes the encrypted production data and to provide the marking code for marking of the individual package. The system further comprises a storage interface coupled to a database that comprises a plurality of partitions. The storage interface is arranged to receive package itemization data comprising at least a subset of the marking code and at least a subset of the package production data of the individual package. The system further comprises a key generator configured to generate a partition key as a function of the marking code and provide the partition key to the storage interface. The storage interface is configured to, upon receipt of the partition key, determine a selected partition among the plurality of partitions based on the partition key and to store the package itemization data in the selected partition.
Any one of the embodiments of the first aspect may be adapted and implemented as an embodiment of the third aspect.
Still other objectives, as well as embodiments, features, aspects and advantages will appear from the following detailed description as well as from the drawings.
Embodiments will now be described, by way of example, with reference to the accompanying schematic drawings.
Embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure may satisfy applicable legal requirements.
Also, it will be understood that, where possible, any of the advantages, features, functions, devices, and/or operational aspects of any of the embodiments described and/or contemplated herein may be included in any of the other embodiments described and/or contemplated herein, and/or vice versa. In addition, where possible, any terms expressed in the singular form herein are meant to also include the plural form and/or vice versa, unless explicitly stated otherwise. As used herein, “at least one” shall mean “one or more” and these phrases are intended to be interchangeable. Accordingly, the terms “a” and/or “an” shall mean “at least one” or “one or more”, even though the phrase “one or more” or “at least one” is also used herein. As used herein, except where the context requires otherwise owing to express language or necessary implication, the word “comprise” or variations such as “comprises” or “comprising” is used in an inclusive sense, that is, to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments. As used herein, the term “and/or” comprises any and all combinations of one or more of the associated listed items.
As used herein, “liquid food” refers to any food product that is non-solid, semi-liquid or pourable at room temperature, including beverages, such as fruit juices, wines, beers, sodas, as well as dairy products, sauces, oils, creams, custards, soups, pastes, etc, and also solid food products in a liquid, such as beans, fruits, tomatoes, stews, etc.
As used herein, “a package” refers to any package or container suitable for sealed containment of liquid food products, including but not limited to containers formed of cardboard or packaging laminate, e.g. cellulose-based material, and containers made of or comprising plastic material.
Well-known functions or constructions may not be described in detail for brevity and/or clarity. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.
Like reference signs refer to like elements throughout.
In the manufacturing stage 1, a sheet material for the packages is manufactured at a converting factory (plant) 10. The sheet material is typically paper-based and provided to the filling stage 2 in rolls 11. In the illustrated example, stage 1 further involves a dedicated factory (plant) 12 that manufactures caps 13 for the packages, typically of plastic material. If the packages are formed without a cap, the factory 12 is absent from stage 1. It is also conceivable that stage 1 includes additional factories that manufacture specific components for the package.
In the filling stage 2, a filling factory (plant) 14 operates on the sheet material 11, the caps 13 and the liquid food to provide packages containing liquid food. For example, a production line at the filling plant 14 may form the sheet material 11 into a container, fill the liquid food into the container, and seal the container to form the package. The production line may also attach a cap 13 to the container.
It should be understood that the manufacturing chain generally may involve many different converting plants 10, cap plants 12 and filling plants 14, which may be distributed globally. Each of the plants 10, 12, 14 may include a plurality of production lines.
As indicated in
The marking code is generated to be unique to the package 16 within the entire eco-system of plants 10, 12, 14 within the manufacturing chain as exemplified in
Embodiments are related to storing the marking codes and associated data in a database and will be exemplified in the following with reference to implementations of the marking code described in aforesaid EP3540664, which is incorporated herein in its entirety by reference.
Specifically, the marking code comprises payload data which is unique to the production of the individual package and which is encrypted by a predefined encryption algorithm. Generally, the marking code consists of a sequence of values, for example binary values. The payload data, which is denoted package production data (PPD) in the following, may include data elements that identify the location of production and/or the time of production. In a first example, the data elements in the PPD include identifiers of the producer that operates a plant (Producer ID), the plant (Plant ID), the production line in the plant (Line ID), the equipment where the marking code is added to the package (Equipment ID), and the PPD further identifies the current time of production, for example by year, day, hour, minute, second and a sub-second resolution counter (Package Counter), which may or may not be randomized. In a second example, the data elements in the PPD include identifiers of the plant (Production Unit ID), a production batch, and a package within the production batch, where the production batch may be identified by a time period, for example current year and month, and a batch number within the time period (Request Number), and where the package may be identified by a package number within the production batch (Package Counter). The package number may or may not be randomized. The marking code may further comprise a non-encrypted header portion, which may or may not be obfuscated and may contain data enabling decryption and validation of the encrypted PPD.
An example embodiment of a system 20 which is configured for code generation, code storage and marking of packages is schematically shown in
The storage controller 24 is configured to receive the PPD, the marking code (MC), and possibly additional data. Based thereon, the storage controller 24 generates and stores package itemization data, PID, in the database 30. Each PID corresponds to an individual package and forms a data item for storage in the database 30. In some implementations, the data item may, e.g., be a row in a table (SQL database) or a document in a collection (NoSQL database). As understood from the foregoing, a huge volume of data items will eventually be stored in the database 30, which therefore should be scalable, and preferably horizontally scalable for resource efficiency. In one embodiment, the database 30 is a distributed database comprising a plurality of logical partitions, where each logical partition may have a predefined maximum size and is assigned a unique partition identifier (Partition ID). In a non-limiting example, the predefined maximum size is in the range of 0.1-100 GB. A database management system (DBMS) 30A for the database 30 is operated to transparently and automatically distribute the data items among the logical partitions, for example based on a “partition key” (aka “distribution key”) for each data item. The storage controller 24 may provide an interface to the DBMS 30A that allows an operator to set the partition key to be used and that allows for manual or automatic upload of data items for storage in the database 30. The DBMS 30A may be proprietary to the host of the distributed database 30 and may be configured to map the logical partitions, in any suitable relation, to a plurality of nodes, which may include any one of physical servers, virtual servers or virtual LUNs (logical unit number) with access to one or more storage devices, such as hard-disk drives (HDDs) and/or solid-state drives (SSDs), for example to efficiently satisfy scalability and performance needs. As the throughput and storage requirements may increase, the DBMS 30A may move logical partitions to automatically spread the load across a greater number of servers. The DBMS 30A may be any commercially available system, and the distributed database 30 may be implemented as an SQL or a NoSQL database. In one embodiment, the DBMS 30A is a cloud computing platform. In a specific implementation, the DBMS 30A is included in Microsoft Azure Cosmos DB, which is a globally distributed, multi-model database service. In a specific example, the DBMS 30A is set up to operate as a NoSQL Document Database.
The package itemization data, PID, comprises the marking code, or a subset thereof, and at least a subset of the data elements in the PPD. The PID may also include additional data elements associated with the generation of the marking code, the production of the package or the storage in the database. In one non-limiting example, which conforms to the above-mentioned first and second examples of the PPD, the PID includes the marking code (or a subset thereof), Producer ID, Plant ID, Line ID, Equipment ID, year, day, hour, minute, second, Package Counter, Production Unit ID, and Request Number.
When implementing storage of the PID on the above-mentioned Microsoft Azure Cosmos DB, the present Applicant experienced poor performance, for example in terms of resource consumption and speed of search and retrieval. Further analysis of the data storage in the database 30 revealed a substantial non-uniformity in the distribution of data between partitions, also known as “skewness”.
Surprisingly, the present Applicant found that using the marking code as partition key rendered a substantially more uniform distribution of data among the logical partitions in the distributed database. It is presently believed that the encrypted data in the marking code imparts a randomness to the marking code that manifests itself as a substantially non-skewed data distribution among the partitions in the distributed database.
Like in
The storage interface module 24C is configured to receive the partition key, PK, from the key generating module 24B and the PID from the aggregation module 24C. The storage interface module 24C, which is coupled to the database 30, is further operable to cause the DBMS 30A to select a partition among the partitions P1-Pj based on the partition key, PK, and store the PID in the selected partition. In one embodiment, the module 24C comprises a predefined mapping function which is configured to identify a selected partition, for example by the above-mentioned Partition ID. The module 24C may thus operate the mapping function on the partition key to compute a current Partition ID and provide the current Partition ID to the DBMS 30A for identification of the selected partition. In another embodiment, the mapping function is part of the DBMS 30A, which is caused to compute the current Partition ID when the module 24C supplies the partition key to the DBMS 30A. In one embodiment, the mapping function is configured to map all conceivable partition keys onto a set of unique Partition IDs, one for each partition P1-Pj. In one embodiment, the mapping function is further configured to scramble the bits of the partition key to improve the uniformity of the data distribution in the database 30. In one embodiment, the mapping function is a hash function. Any hash function may be used, including but not limited to a cryptographic hash function, a non-cryptographic hash function or a cyclic redundancy check (CRC) function. In one embodiment, the mapping function involves a modulo operation, e.g. modulo division by j or a prime number close to j. In another embodiment, the mapping function extracts a predefined number of bits in the partition key and collates the extracted bits into the Partition ID.
Reverting to the systems 20 in
| Number | Date | Country | Kind |
|---|---|---|---|
| 19209109.8 | Nov 2019 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2020/081886 | 11/12/2020 | WO |
