EP3170136A1

EP3170136A1 - Improvements relating to marking of unique identifiers onto articles

Info

Publication number: EP3170136A1
Application number: EP15753411.6A
Authority: EP
Inventors: Joshua TONKINSON; Neil John BARNES
Original assignee: Enable (marketing&promotions) Ltd
Current assignee: Enable (marketing&promotions) Ltd
Priority date: 2014-07-14
Filing date: 2015-07-14
Publication date: 2017-05-24
Also published as: GB201412505D0; GB2528261A; WO2016009188A1

Abstract

Methods, processors and systems for verified production line marking of a series of unique identifiers are disclosed. A unique identifier of the series is marked onto an article to form a unique identifier mark. Marking feedback data associated with the unique identifier is obtained from said marking and the unique identifier mark is inspected to obtain inspection data associated with the unique identifier. The marking feedback data and inspection data may be stored, logged or processed to aid tracing and marking error diagnosis.

Description

IMPROVEMENTS RELATING TO MARKING OF UNIQUE IDENTIFIERS

ONTO ARTICLES

FIELD OF THE INVENTION

This invention relates to methods and systems for production line marking of a series of unique identifiers. In particular, though not exclusively, this invention relates to the marking and verification of unique codes, such as promotional codes, on a line of articles.

BACKGROUND OF THE INVENTION

Methods and systems for marking of articles for various purposes are known. For example, methods are known for printing identifying symbols and codes on products during production line runs. A run of products may be printed with a Universal Product Code or barcode, identifying for instance the product, a batch number, any expiry date, and the like. These are generic codes, as each product in a run or batch is marked or printed with the same code. In contrast, the printing of unique codes or unique identifiers requires greater control than other forms of code printing on a product. This is because, for example, unique codes linked to a manufacturer's SKU (Stock Keeping Unit) may have an associated (redeemable) value. Consequently, they require stringent control, which is enforced by print producer clients, who pay for each redemption. Clients typically require complete digital traceability on every such code issued to a print producer. Complete digital traceability means that, from the point of receiving codes, through every process, including printing and verification, an unbroken digital record must be maintained of its journey. This introduces a level of digital control not required when printing generic codes.

It is known to print unique codes on articles, such as packaging or the like, as part of intelligent promotion campaigns. Consumers are encouraged to enter such codes online as proof of purchase, e.g. to win a prize. Typically a set of unique codes is pre- generated, for printing by a printer at high speed (one code per article on a moving line). Errors or omissions from the pre-generated set of codes inevitably occur during this printing process, for example due to equipment issues, or during start-up or shutdown of high speed printing. Such errors or omissions, if undetected, undermine the accurate gathering of information about consumer behaviour and limit the usefulness of the codes.

In prior systems addressing generic codes, where attempts are made to solve printing errors, these typically are either cumbersome, or do not directly address errors in the system (for example at a printer head), or they are not sufficiently accurate or reliable for a system in which unique codes are used, where greater digital traceability is required. Furthermore, errors are typically addressed locally, which may not be compatible with the complex management of marking sequences usually required for unique codes.

Furthermore, certain marking protocols require that every code or identifier marked or printed is clearly legible. Unique codes are commonly printed so that they are human- readable. If this cannot be achieved, for codes where human-readability is required, the purpose of printing them may be compromised. Achieving this readability introduces a level of monitoring or verification not required in printing generic codes.

Finally, there are also ever increasing demands on the speed with which unique codes are printed and verified. The present invention aims to address these problems and provide improvements upon the known devices and methods.

STATEMENTS OF INVENTION Aspects and embodiments of the invention are set out in the accompanying claims.

In general terms, one embodiment of a first aspect of the invention can provide a method for verified production line marking of a series of unique identifiers, the method comprising: marking a unique identifier of the series onto an article to form a unique identifier mark; obtaining marking feedback data associated with the unique identifier from said marking; and inspecting the unique identifier mark to obtain inspection data associated with the unique identifier. The marking feedback data may, for example, comprise data indicating a status of the marking and the inspection data may, for example, comprise imaging data of the unique identifier mark. Obtaining data from marking as well as from inspection facilitates accurate verification of the marking of the identifier. In particular, the method provides two sources of data for tracing of the unique identifier. In some embodiments, the data may advantageously be used or combined for corroboration and/or accurate diagnosis of any errors occurring during marking.

The method may be continuous or repeated, for example in order to provide continuous marking and verification in a production line environment. In an embodiment, the method is repeated at least ten times, in particular at least twenty times. The method may have particular value in the context of rapid production line marking. In an embodiment, the method is repeated at least once per second, advantageously at least ten times per second, more advantageously at least fifteen times per second. The invention embraces a suitable routine for such repetition.

In a production line environment the marking and inspection may advantageously occur in series. The method may comprise marking a plurality of unique identifiers of the series onto a plurality of articles to form a plurality of unique identifier marks, obtaining marking feedback data associated with each unique identifier, and inspecting each unique identifier mark to obtain inspection data associated with each unique identifier. The unique identifier may, for example, be a unique code, such as one of a series of unique promotional codes. In an embodiment, the code is an alphanumeric code, or a barcode, a QR code or the like, or an image in a series of unique identifying images. The article to which the identifier is applied may be, for example, a product or item, or a substrate for application to a product or item.

The marking may be achieved in any suitable manner, for example by printing, or stamping, or embossing, or other known marking techniques. In an embodiment, the method comprises passing, or making available, marking data for the unique identifier to a marking device for marking the unique identifier onto the article. The marking device may be any suitable device, for example, a printing, stamping, or embossing device. Conveniently, the marking device may be a printer printing the mark. Suitably, the marking data may comprise a marking command issued to the marking device to mark the unique identifier onto the article. The marking data may comprise information representative of said unique identifier or series of unique identifiers, for example one or more glyphs or features thereof.

In an embodiment, the marking feedback data comprise data indicating a status of the marking of the unique identifier. For example, the marking feedback data may indicate whether the marking was completed or not, information on any error or malfunction affecting the marking, or simply details required for logging the marking. In an embodiment, the marking feedback data comprise information about a state of a marking device instructed to mark the unique identifier. For example, possible states may be on/off, functioning/ malfunctioning, or one or more error states.

The inspection data may in principle be any data obtained by inspection of the unique identifier mark. Inspection of the unique identifier mark may, for example, comprise imaging, in particular optical imaging, of the unique identifier mark. Accordingly, the inspection data may comprise imaging data, in particular optical imaging data. Suitably, inspection of the unique identifier mark may comprise using an imaging device, for example an optical imaging device, to generate the inspection data. Conveniently, the imaging device may be a camera.

Advantageously, the inspection data may comprise a continuous image stream. Suitably the inspection data may comprise an image stream, e.g. having a frame rate of at least 20 frames per second (fps), or advantageously at least 100 fps, or even at least 200 fps or at least 250 fps. This facilitates high-speed gathering of inspection data, in particular for a plurality of unique identifiers. Suitably, the method may comprise adapting a lighting condition for the article during inspection in dependence on a determined characteristic of the article. For example, certain articles may require stronger or weaker lighting to enhance the usefulness of the inspection data. Determined characteristics of the article may include, for example, the colour or reflectiveness of the article. ln an embodiment, the method comprises storing, logging and/or processing the marking feedback data and/or inspection data for the unique identifier. In an embodiment, the method comprises processing the inspection data to obtain an inspection result associated with the unique identifier.

Suitably, the method may comprise comparing the inspection data to expected data associated with the unique identifier to obtain an inspection result.

Advantageously, the expected data may relate to an inspection appearance, e.g. visual appearance of the unique identifier mark. The inspection appearance may include, for example, one or more of size, shape, colour and orientation of the unique identifier mark. In an embodiment the expected data comprises a glyph or feature associated with the unique identifier.

The expected data may in principle be determined in any suitable manner to obtain an inspection result. For example, matrix matching and feature extraction techniques are known in the art for obtaining inspection results by optical character recognition. In an embodiment, the method comprises subjecting the inspection data to character recognition to obtain an inspection result.

Processing of the inspection data to obtain the inspection result involves processing capacity and processing time, which together amount to a processing demand.

Processing demand may be considerable, particularly where optical character recognition is employed. Excessive processing demand can affect the speed of production line marking and/or reduce the accuracy of the inspection result.

To reduce processing demand, the method may advantageously comprise determining or defining, in particular limiting, the expected data in dependence on data associated with the unique identifier. In an embodiment, the data associated with the unique identifier comprise or consist of an expected inspection appearance, e.g. a glyph or feature, or one or more glyph or feature combinations, of the unique identifiers in the series. In an embodiment, the data associated with the unique identifier comprise or consist of an expected inspection appearance, e.g. a glyph or feature, or one or more glyph or feature combinations, of the unique identifier.

Limiting the expected data can greatly reduce processing demand by restricting the amount of expected data to be parsed, e.g. compared to conventional optical character recognition. Determining the expected data based on data associated with the unique identifier can also facilitate recognition of the unique identifier mark in a continuous image stream, as is desirable in rapid production line marking. In particular, the unique identifier mark may be more quickly identified in the inspection data. Accordingly, a greater amount of inspection data, such as continuous image stream, can be processed. Therefore the need for triggers to begin and end the collection of inspection data can be avoided. In an embodiment, the method comprises obtaining a continuous image stream, and stitching together portions of the image stream to obtain the inspection data.

Conveniently, the data associated with the unique identifier may comprise, consist, or be determined in dependence on, marking data for the unique identifier, i.e. data which may also be passed or made available to a marking device for marking the unique identifier onto the article. Thus, in an embodiment, the method comprises: marking a unique identifier of the series onto an article to form a unique identifier mark, the marking comprising passing, or making available, marking data for the unique identifier to a marking device for marking the unique identifier onto the article; obtaining marking feedback data associated with the unique identifier from said marking; and inspecting the unique identifier mark to obtain inspection data associated with the unique identifier, wherein the method comprises comparing the marking data to expected data associated with the unique identifier to obtain an inspection result, the expected data comprising, consisting of, or being determined from, said marking data.

In an embodiment, the expected data comprise, consist of, or are determined in dependence on the marking feedback data. Thus, in an embodiment, the method comprises: marking a unique identifier of the series onto an article to form a unique identifier mark; obtaining marking feedback data associated with the unique identifier from said marking; and inspecting the unique identifier mark to obtain inspection data associated with the unique identifier, wherein the method comprises comparing the marking data to expected data associated with the unique identifier to obtain an inspection result, the expected data comprising, consisting of, or being determined in dependence on, said marking feedback data.

Particular advantages stem from determining the expected data in dependence on marking feedback data. In particular, such determination allows not only for efficient processing but also enables corroborative monitoring and verification of marking. In the example of a marking failure, the expected data determined based on the relevant marking feedback data may reflect that no marking has taken place. Accordingly, the inspection result can confirm that no marking has taken place, whereas without determination of the expected data by the marking feedback data the inspection result would indicate an error and/or require additional processing to recognise a marking failure. Such error recognition and corroboration is of particular value in a rapid production line environment, in the interest of avoiding unnecessary stoppages. In an embodiment, expected data may comprise, consist of, or be determined in dependence on both marking data and marking feedback data.

Suitably, the expected data, for example a plurality of potential inspection appearances for the unique identifier, may be stored in a look-up table and mapped against associated marking data or marking feedback data values. For example, a first appearance for the unique identifier may be associated with error-free marking of the unique identifier and a second appearance may be associated with failed marking of the unique identifier. The method may comprise querying a lookup table based upon the marking data or marking feedback data to determine expected data to be compared with the inspection data to obtain an inspection result.

The method may comprise determining a verification status associated with the unique identifier, based upon the marking feedback data and/or the inspection data. Suitably, the verification status may reflect whether or not the unique identifier has been acceptably marked. Additionally or alternatively, the verification status may reflect whether or not a serious error has occurred that requires a stop of production line marking. The verification status may be determined based upon an inspection result as hereinabove described. In an embodiment, said inspection result is obtained by a comparison of the inspection data with expected data determined in dependence on marking feedback data. Such an inspection result advantageously takes into account both marking feedback data and inspection data. A further comparison of the inspection result with marking feedback data to obtain an advantageously corroborated verification status may hence be unnecessary. However, corroboration may also be achieved by comparing inspection data or an inspection result with the marking feedback data to obtain the verification status.

Advantageously, the method may comprise determining and optionally performing one or more actions based upon the verification status.

In an embodiment, the method comprises discarding the article in dependence on a verification status, e.g. a status reflecting a marking error, and/or illegibility and/or absence of marking. This facilitates continuous production line marking without unnecessary stoppages and may be achieved, for example, by blowing the article off production line. Advantageously, the discarding of any articles may be logged and/or inspection data associated with such articles may be stored.

In an embodiment, the method comprises storing the inspection data in dependence on a verification status, e.g. reflecting a marking error. This enables further analysis of errors, e.g. by an operator, whilst allowing other data to be deleted to save storage space.

In an embodiment, the method comprises stopping further production line marking in dependence on a verification status, e.g. a status reflecting a serious marking error that indicates a fault requiring repair or maintenance. This can prevent continued marking until the error can be checked and resolved.

As aforesaid, the method is suited to rapid production line marking. To enhance the speed of marking the method may comprise adapting or modifying a marking device for rapid marking. In an embodiment, the method comprises overriding a buffering routine of a marking device instructed to execute the marking to enable more rapid marking. In an embodiment, the method comprises reconfiguring a baud rate of a marking device instructed to execute the marking to enable more rapid marking.

Processing of the marking data, marking feedback data and inspection data may be performed by a processor. The processor may be configured to implement the methods described herein. Advantageously, the processor may be a controller configured for controlling the marking and/or inspection. The processor or controller may be linked to one or more data storage memories, as may be required. The invention embraces a processors configured to perform the methods described herein. One embodiment of a second aspect of the invention can provide a processor for verifying and/or controlling production line marking of a series of unique identifiers, the processor comprising: a marking device interface for receiving marking feedback data associated each of a plurality of unique identifiers from a marking device; and an inspection device interface for receiving inspection data associated with each said unique identifier from an inspection device.

One embodiment of a third aspect of the invention can provide a system for verified production line marking of a series of unique identifiers, the system comprising: a processor; a marking device co-operable with the processor, the marking device being configured for marking unique identifiers onto articles to form unique identifier marks and sending marking feedback data associated with each of a plurality of unique identifiers to the processor; and an inspection device co-operable with the processor, the inspection device being configured for inspecting the unique identifier marks to obtain inspection data associated with each unique identifier, the processor being configured to receive the inspection data from the inspection device. The system may suitably comprise a transport means, e.g. a conveyor, for carrying articles from the marking device to the inspection device. To assist selective discarding of articles, the system may comprise a line blower.

The unique identifiers, marking device, marking feedback data, inspection device and inspection data may be, for example, as hereinabove described. The processor or system may be configured to implement any of methods described hereinabove. The processor or controller may be linked to one or more data storage memories.

Advantageously, the processor may be a controller configured for controlling the marking device and/or inspection device. In an embodiment, the controller is configured to send marking data to the marking device, e.g. as hereinabove described. In an embodiment, the controller controls one or more system modules, for example a transport means or a line blower.

The processor may advantageously be configured to store or log the marking feedback data and the inspection data. In an embodiment, the processor is configured to process the inspection data to obtain an inspection result associated with each of the unique identifiers. Such processing may advantageously be as hereinabove described.

In an embodiment, the processor is configured to determine a verification status associated with each unique identifier, based upon the marking feedback data and/or the inspection data. Such determination may advantageously be as hereinabove described. In an embodiment, the processor is a controller configured for performing one or more actions based upon the verification status, e.g. as hereinabove described.

Any processor or controller described herein may suitably comprise a control unit or computational device having one or more electronic processors. Thus there may be a single processor or controller or alternatively different functions of the processor or controller may be embodied in, or hosted in, different control units or controllers. As used herein the term "controller" or "processor" will be understood to include both a single control unit or processor and a plurality of control units or processors collectively operating to provide any stated functionality.

To configure a processor or controller, a suitable set of instructions may be provided which, when executed, cause said control unit or computational device to implement the techniques specified herein. The set of instructions may suitably be embedded in said one or more electronic processors. Alternatively, the set of instructions may be provided as software to be executed on said computational device. In an embodiment, the processor comprises a server system. In an embodiment, the processor comprises a marking device controller and/or an inspection device controller. In an embodiment, the processor comprises an optical character recognition module. Further aspects of the invention comprise computer programs, computer program applications or computer program code which, when loaded into or run on a computer or processor, cause the computer or processor to become a system, or to carry out methods, according to the aspects described above. The above aspects and embodiments may be combined to provide further aspects and embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will now be described by way of example with reference to the

accompanying drawings, in which:

Figure 1 is a diagram illustrating steps of a method for verified production line marking according to an embodiment of the invention; and

Figures 2 and 3 are diagrams illustrating systems and apparatus for verified production line marking according to embodiments of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the invention can provide methods and systems used to print, verify and manage unique identifiers, in particular unique codes, on articles. They address the needs of both the print producer and their clients by providing ease of use, improved information and control, together with digital traceability of codes. No system known to the inventors provides a complete and integrated solution as in embodiments of the invention. These innovative processes ensure greater accuracy in the printing of unique codes.

Generally, embodiments of the invention use a (pre-generated) set of codes for printing by a print head on a plurality of articles; obtain as marking feedback data from the print head information on the codes actually printed on the articles; and inspect the printed codes with an inspection device in the form of an image recognition system comprising a camera.

Data is obtained from the print head and the inspection. This data may be stored and/or processed. The availability of two sources of data aids accuracy in verifying and tracing the marking of codes, since corroboration is possible.

In previous methods where a generic code is printed, a verification system need merely identify errors in the same code, over and over again; a relatively simple task. No feedback is required from the print head, as it is assumed the printing is the same each time, unless the verification system picks up an error. However, in the case of a sequence of unique codes, the code to be verified is different each time. Therefore expected data is supplied to the image recognition system to enable the inspection to proceed efficiently. The provision of expected data to the image recognition system enables the handling of complex sequences of codes, in particular by reducing processor demand.

The expected data provided to the image recognition system may simply be the set of codes supplied to the printer. Advantageously, in some embodiments of the invention, the expected data is determined based upon the marking feedback data. Because the marking feedback data from the print head provides information as to what was in fact printed, inspection can then be based on a more accurate set of references, and is therefore itself more accurate and efficient. For example, a code may fail to print. This could lead to high processing demand in the image recognition system to recognise that a code has failed to print. Such processing can be reduced by limiting expected data in the processing step to a list of codes supplied to the printer. However, even more advantageously, if marking feedback data is obtained, the failure can be reported to the image recognition system via the marking feedback data, and instead of the missing code leading to intensive processing culminating in an error report, it can be confirmed during inspection that the code was not printed, and the relevant article can be removed from the production line. The nonprinting of the code can be logged for traceability, and the code may, for example, be reused. ln one basic embodiment of the invention, the print producer receives unique codes from their client (or another source), which are stored and formatted on a secure digital coding (SDC) Server, which acts as a controller/processor. The codes are issued to a production-line which prints them on product in accordance with client specifications. The status of each code is fed back to the SDC Server. The server may be configured simply to store this information. However in particularly advantageous embodiments, the server may update each code's status on its database. The server also issues or makes available the codes to an Optical Character recognition (OCR) interface. This interface verifies, via an imaging device in the form of an OCR camera, that the correct code has been printed, that it is legible, and in the correct order. Advantageously, the codes made available to the OCR interface may be codes that have been updated with the status from the printer, i.e. the OCR interface may be provided with expected data determined on the basis of marking feedback data received from the printer.

The OCR Interface feeds back its own status for each code to the SDC Server. Again, the server may be configured simply to store this information. However in particularly advantageous embodiments, the server may update each code's status on its database based on the status received from the OCR.

The server is configured to determine a verification status that takes into account the status from the printer and the status from the OCR interface.

In this manner, each code is tracked throughout the process such that complete digital traceability is achieved, as well as ensuring legibility of codes. In addition to achieving these two primary objectives, the system simplifies the management of codes, as well as the printing process. Additionally, as all information is digitally recorded, reporting and analysis is substantially enhanced.

Figure 1 is a diagram illustrating steps of a method for verifying production line marking according to an embodiment of the invention. First, the system obtains a series of unique identifiers to be marked on the production line articles (100). This may be, for example, a set of unique promotional codes to be applied to a run of products. The codes may be alphanumeric, for example a 10 digit or letter string. The unique identifiers/codes are made available to a marking device and an inspection device (102). This can be done by a central server, over a network of which the marking and inspection devices form a part. The codes may be presented in a sequence, in batches, or in an on-going updated sequence monitored by each device.

The marking device then marks (104) the respective unique identifiers onto articles. The marking may be achieved by printing, for example by any of the known ink-jet, laser or other printing methods. The substrate may be anything sufficient to allow marking for the article - board may be embossed to be marked, various materials, textiles and papers may be readily printed upon. For example, in a conveyor production run, the codes may be printed in the presented sequence, by a print head onto each article as it passes the print head on the conveyor.

At the time of printing each code, marking feedback data is collected for that marking step (106); this may be any kind of feedback which may be relevant for the system to assess efficiency, errors or the like. For example, the feedback may simply be a notification that the printing took place. The feedback may comprise data on when the printing was done, to monitor and corroborate timing with later devices. The feedback may note printing errors, such as lack of a substrate to print on, a partial mis-print, or a malfunction of the print head. The feedback is returned to the server and is used to update the list of codes available to an inspection or verification device (102). The inspection or verification device, which has access to the sequence of codes, inspects each unique identifier mark as it passes on the line (108). For example, a camera may be set up to view each article printed earlier on a conveyor, with the camera taking images of passing substrates on the conveyor. The inspection device determines inspection data for each mark - i.e. for each printed code (or even a non-printed substrate, where one is expected), feedback is provided.

An assessment of the inspection data (1 10) is made by an inspection processor.

Assessment of the inspection data may, for example, indicate whether the code is present or not, whether the inspection has been made or not, or a more complex assessment of any possible error, such as smudging or partially missing code. A comparison is made between expected data (e.g. an image of the code, or an OCR reading of the code determined from the unique identifier information made available by the server) and the result assessed. An error report may be logged where a difference is found.

The inspection processor may, for example, be an OCR Interface for comparing an image with an expected image, or with details of the identifier sequence provided to the inspection device. Additionally or alternatively, the inspection processor may be part of the central server such that assessment of the inspection data is left to a central server, with the marking and inspection devices merely reporting their respective tasks and the data associated with them.

Lastly, a verification status is determined (1 12). The verification status may be a consequence of the inspection result and reflects whether or not the unique identifier has been acceptably marked, as well as whether or not a serious error has occurred that requires a stop of production line marking.

The server is further configured to determine and perform one or more actions based upon the verification status. The server discards articles on which a marking error has occurred by activating a line blow module. The server also logs and stores inspection data for such articles. Where a serious marking error that indicates a fault requiring repair or maintenance has occurred, the server stops further production line marking. In certain specific embodiments of the invention, there are three major components to the system.

1. The Management Software which controls the entire process, from receiving codes, their formatting, printing and verification, to exporting completed sets back to clients, with full traceability.

2. A Printer Interface, to enable printing devices to buffer sufficient codes, print at higher speeds, print more accurately, query print status (so that code status can be updated) and provide a universal interface for the different printing devices. 3. An OCR Interface, to support high visual recognition rates, as well as providing the facility to record errors and predefined events (e.g. a winning code.)

These three components will be described individually in more detail below.

Figure 2 illustrates a single print-line installation. The SDC server (202) is connected to a printer interface (204) and to an OCR interface (206). The printer interface is connected to the printing device (205); these may be considered the marking device. The OCR interface is connected to the OCR camera (208), and to the illumination device (214), here an LED lighting device. These components can be considered the inspection device. The system also includes production line warning lights (212), line blowing devices (216), speed controllers and conveyor stop/start actuators (218), and a wireless network access point. A user print management device (210) can be used to control the network, and to assess the function of the server and the devices, via the wireless network access point.

Figure 3 illustrates a multiple print-line configuration. The same components are present, but duplicated for each line, where necessary. A single server (302) manages the network, and each line has its own printer interface (304) and printing device (305), OCR interface (306) and OCR camera (308) and lighting.

In embodiments of the invention, the Management Software comprises software and firmware for controlling and managing the entire system, as described earlier, thereby contributing to controller and processor functionality. Additionally, the software improves security by protecting codes through the elimination of unsafe procedures, and restricting access to codes on a "need-to-know" basis. The software also supports complete digital traceability of codes.

The functions and aims of the software are:

To receive, store and issue codes to be printed and visually verified; to update status of each code at each stage of the process and then, on completion of the print campaign, to transmit codes, with associated history, back to clients, in a secure manner; To provide an Administrative interface that is easy and intuitive to use, which will enable Administrators to manage codes and campaigns more effectively and efficiently;

To remove all physical handling and manipulation of codes, by Administrators, through the automatic deciphering and allocation of codes to campaigns and the reformatting of codes according to specific printer requirements, which substantially reduces risk introduced through manually handling codes;

To allow Administrators to setup campaign details, which will contain all relevant information about it, and will control the print and verification process in accordance with these parameters;

To provide an Operations interface that is easy and intuitive to use, which will enable factory-floor operatives to: initiate a print-run, start a print-run, stop a print-run, restart a print-run, end a print-run, provide error reports and real-time warnings, whilst recording all the above actions and timings taken by the operative, including their staff details;

To pass relevant codes to the Printer Interface (connected to a printing device) to print, and to receive back its status, to be stored in a database, recording times, campaign and print job details;

To pass the a set of codes passed to the Printer Interface, and optionally updated with marking feedback data, to the OCR Interface to verify the correct codes have been printed and that they are legible;

To receive back from the OCR Interface the status of codes read, compared to codes passed to the interface, and to record these on the database, together with times and other pertinent information;

To provide reports and analysis of specific print-lines and campaigns through the provision of software capable of extracting and formatting relevant data held on the database;

To securely transmit campaign code details, with all associated codes and their relevant information, onto clients;

To eliminate risks associated with the manual handling, preparation and transmission of codes to print-lines;

To minimise the exposure and access to codes by factory-floor operators;

To eliminate the use of actual codes while initiating print runs, only issuing actual codes once the print-run starts; To reduce manual processes and reports, thereby reducing errors and improving productivity;

To improve the availability, accuracy and reliability of data;

To provide complete digital traceability of every code received from the client.

The software necessary to run the system resides on the SDC Server. Firmware and software to run both the Printer and OCR Interfaces are found on these devices. The SDC Server and its two associated Interfaces are hardwired into a network. The Administrator connects to the network via a Wi-Fi connection and downloads the Administration suite of programmes, comprising three main sections, listed below, onto a PC (or similar device) in their office:

a) Receiving / transmitting codes,

b) Campaign Management,

c) Reports & Analysis.

Factory-floor operators use a dedicated Print Management Device (which comprises an iPad, or similar touch-screen device,) located on the factory floor, and connected to the SDC Server through a fast Wi-Fi connection. They interact with this device in performing their duties. It in turn, records all their actions, which are stored on the SDC Server. A set of warning lights are placed near the production-line. These are directly connected to the SDC Server. In the case of a printing or reading error these errors are returned to the SDC, where they are recorded. The SDC Server then submits the error code to the production-line warning lights, which then display an appropriate warning. This alerts the factory-floor operative to the problem, so that they may take action.

Certain errors can result in the print-line being stopped, as setup under the Campaign Management section, by the Administrator. The ability to stop the line and eject product from it are controlled through the OCR Interface, as it is directly connected to the Line- Blower (the device to blow product off the line) and the Speed Adjuster Control (which controls the speed of the line.)

On receiving an order from the client, the print producer's Administrator will access the system's Administrator section and set up the campaign, responding to screen prompts requesting all relevant information. The Administrator will then download client codes in an encrypted format and allocate them to a campaign. The system will then decrypt the codes internally and perform a checksum calculation on the file to ensure the files uniqueness, eliminating the possibility of duplicate files being sent by the client. This may be important because code / file splitting is carried out by the Management Software and cannot usually be compromised, as there is no manual intervention by the print producer's Administrator. They have no need, or ability to open files, completely removing the risk of error from manually handling and manipulating codes.

The system then formats the codes into a standard format. Once production has started and the details of the printing-device which will print the codes is known, the system reformats the codes according to printing-device specifications. Sometimes products are available for printing before their codes have been issued (by the client), but because codes are allocated to SKU (Stock Keeping Units) unused codes from other SKUs cannot be used. However, to help reduce costly production delays, the SDC Management Software provides "transfer rules", setup in the Campaign

management section, where the rules for transferring codes from one SKU to another are declared. When transferring to another SKU, its original allocation is recorded, thus providing complete traceability.

Codes are transferred directly from the SDC Server, where they are stored, to the Printer Interface, ready for printing. Factory-floor operatives are exposed to very few codes, only the starting and ending codes of a print-run, thereby reducing security risks associated with code exposure.

Print-runs may be stopped and unprinted codes reallocated to another print-line and printing- device. All the management of codes is carried out by the system, with no duplicates being printed and full traceability of codes maintained.

When the factory is ready to print, an operative on the factory-floor, using a Print Management Device enters a job and campaign number. Details of the print-run are displayed. If correct, the operative signs on the screen to confirm the details. The system records the signature and details of the operative. This provides the ability to query codes (at a later date) and compare statistical data on different print-runs, by any criteria recorded in the system. A PDF copy of the signed job is recorded and forwarded to the Administrator.

The operator now goes through a "Make Ready" stage where they verify that printing components are ready to print, checking ink levels, heating up the ink and checking on calibrations, for both printing-device, high-speed camera and LED lighting device. Most of these settings are done automatically by the system, although fine adjustments may be required. The entire process is controlled and monitored from the Print Management Device. As it is controlled from a single device, significant reduction in setup times are achieved.

During this "Make Ready" phase sample codes are printed on the product using the full character set of the campaign, to ensure legibility. Actual codes will only be used once the operator is satisfied with results from their testing, and they start the print-run. In this manner no wasted codes are produced, which introduces the added problems of managing and accounting for them, which is time consuming and a manual process, open to error and risk. It also breaks the digital traceability link.

During the "Make Ready" phase the SDC Server downloads codes ready for printing, so that when the operator is ready, printing can commence with no delays.

Once printing has commenced and should an error be detected, either as a result of a printing or reading error, the production warning lights next to the print-line will illuminate, indicating the type of error. The Operator, using their Print Management Device can ascertain codes affected and take action quickly without risking the waste of further product. The Printer Interface is a physical box containing hardware, firmware and software, used as an interface between the SDC Server and the printing device. It is placed on, or in close proximity to, the printing device. There is one Printer Interface for every printing device. The functions and aims of the printer interface are:

To provide a universal interface which can be used with different printing devices, as significant differences exist between manufacturers and models, in terms of communication protocols and print speeds;

To manage the printing device, issuing instructions as to what to do, overriding the manufacturer's management controls, thereby, providing a standard print

management interface, irrespective of manufacturer and model differences;

To improve the print quality through improved management of the printing device;

To enhance printing speeds by dynamically reconfiguring manufacturer set baud rates to achieve optimal rates, depending upon the communication protocol used to connect with the printing device. For example, using a RS232 protocol, the system configures the baud rate to 38,400 baud per second, the maximum achievable using RS232 protocols;

To receive and buffer large quantities of unique codes, to be issued to the printing device, so as to achieve high print outputs;

To interrogate the printing device's buffer by monitoring the timing of electrical signals. The system detects different states, which it uses to update the code's status (e.g. "printed correctly") and / or provide actionable responses (on errors), such as ejecting product from the line;

To ensure the printing device receives codes correctly and that no duplicate codes are printed. In the case of power loss, the system knows it has sent a code to the printing device (as all codes are managed in the Printer Interface through firmware.) If no status is returned, the system records an "assumed printed" status. It returns this to the SDC Server, where it is recorded. The status of this code is updated by the information feedback by the OCR Interface;

To pass the status of each code passed to the printing device for printing, back to the SDC Server where it is recorded.

The Printer Interface is hardwired into the network, which connects it to the SDC server. It connects with the printing device through a variety of different ports, supporting different communication protocols. The Printer Interface driver is downloaded from the SDC server which provides updates made available from a cloud server. The Printer Interface can digitally update its driver, port configuration and key properties and components, making it a universal interface. The Printer Interface is managed using a Print Management Device (which comprises an iPad, or similar touch-screen device,) preferably located at a fixed position on the factory floor, although it can be located anywhere. It connects to the SDC Server through a fast WiFi connection. The management of the printing device is controlled through the Printer Interface, which in turn is managed and controlled by the Print Management Device utilizing specially developed software.

The Print Management Device can control multiple Printer Interfaces, which connect to one printing device. The standard configuration of the SDC Server supports up to 24 Printer Interfaces, although this can be extended through hardware and network upgrades on the server.

Once the Printer Interface is plugged into an available port on the printing device a command is sent to the printing device to request details of its serial number, together with software and hardware information, which are held in the memory of the printing device. This information is sent back to the SDC Server. Every time a new printing device is added to the system the SDC Server checks for the latest "software drivers" from the supplier, thereby ensuring current versions are up-to-date. The SDC Server then downloads appropriately modified printer software and installs it on the printing device.

Printing devices can be replaced during print runs within a few minutes due to the Printer Interface's ability to reconfigure them with no lengthy setup procedures. It also allows print suppliers to respond rapidly to requests to print unique codes, simply by attaching the Printer Interface to a printing device.

The Printer Interface is control by software accessed through the Print Management Device found on the factory floor in close proximity to the printing device. Operatives use the Print Management Device to: prepare for the print run, start the print run, interrupt the print run, restart print runs, monitor and manage printing errors, end print runs.

The above functions are described in more detail under the section "Management Software", above. ln an embodiment, the interface operates to override a buffering routine in the printer to enhance the speed of the printer. This can be performed by a dedicated control module in the printer interface, either in firmware or in software.

Software passes relevant information from the SDC Server to the Printer Interface and the Print Management Device to facilitate printing. It also gathers relevant data pertaining to print runs to compile reports, thereby allowing in-depth analysis of print runs. The features of this software are described in more detail under the section "Management Software", above.

If an error occurs during the printing or reading of a code, an error status is sent to the SDC Server. The SDC Server records this and then forwards the error onto the production-line warning lights, which displays the appropriate lights according to the error detected.

The factory-floor operative, on seeing the production lights activated will go to their Print Management Device and by pressing a single key the device will display error details. The OCR Interface is a physical box containing hardware, firmware and software, used as an interface between the SDC Server and camera. It is used to store and compare images taken of printed codes by the camera, with codes passed from the SDC Server about codes recently printed by the printing device. This is to ensure the correct codes are printed and that they are legible.

The results of this verification process are then fed back to the SDC Server, where they are stored. Should an error occur, the OCR Interface will initiate appropriate procedures, as set up by the Administrator under "Campaign Details" (refer "Management Software" section.) This may involve triggering warning lights next to the production line, ejecting product from the line, stopping the line, or a combination of these actions.

This interface also incorporates specialised lighting to support the high speed verification process. These lights are interfaced with, and controlled by, the OCR Interface. The functions and aims of the OCR interface are:

To receive an identical set of codes passed to the Printer Interface. To hold these codes and verify them against images taken of codes passing under a high definition, high speed camera, specially lit by LED lights to facilitate high speed processing;

To support high speed processing; matching the high-speed printing process with equally high and reliable visual verification, incorporating accuracy and legibility;

To read a continuous image stream and to stitch these images together to form codes which can be compared to those received from the SDC Server. A continuous image stream is used as there are no triggers to activate the camera. This continuous stream of images also ensures that no code passes through without being verified. There are numerous variations to line, or print speeds, as well as ROI (Region Of Interest, i.e. the region the camera needs to scan) which vary according to product and campaign. These differences in settings, plus others, are passed to the OCR Interface during the "Make Ready" phase (refer "Management Software" section.) Software in the OCR Interface adjusts for these variations automatically, thereby providing great flexibility of application;

To control the LED Lights, housed in a cover/hood positioned either side of the camera, and used to illuminate the ROI to provide constant and consistent illumination of the correct intensity for the material/substrate used in the printing process. These LED lights are necessary to "block" adverse lighting effects from the factory / production environment and ensure no light "seepage" from the LEDs onto the factory-floor. The OCR Interface controls lighting intensity variations to best suit the material and substrate that is being printed on. This is done automatically through software;

To compare a "stitched image" with those passed from the SDC Server and to pass the results back to the server where the results are stored;

To store the image when an error occurs, or to record images of other predefined events, such as winning codes, or quality assurance requirements. These storage requests are set up by the Administrator using the Management Software and its Campaign Management section;

To convert error images into PDF files and to transfer them, together with other pertinent production data about the recording (e.g. date, time, production line, etc.) to the SDC Server to form part of the print campaign results;

To initiate procedures such as, sending an error flag to the SDC Server on detecting a problem with a code, or initiating the ejection of the product from the line, or in severe cases, stopping the line completely. The OCR Interface is directly connected to "line-blowers" to eject product and to the production line "speed adjuster control", which it can switch off, thereby stopping the line. In an embodiment, the region of interest (ROI) may be sub-divided, in order to enhance the speed of code reading. For example, the OCR camera may be configured to image several different areas of an incoming article or substrate at once. For instance, the ROI may be split into three parts; for a linear code this may be a beginning, a mid-section, and an end portion of the code. For a nine letter code, each section may comprise three letters. In this case, the codes will continue to pass through the imaging area and scroll past the camera; the imaging system will maintain the constant image stream for later stitching, but more duplicates will have to be removed in the stitching stage (or used for additional corroboration of the matching results). The OCR Interface is hardwired into the network, which connects it to the SDC server. It connects directly with the high speed, high definition camera and LED lighting devices. It also connects directly with the production "line-blower" and "speed adjuster control". There is one OCR Interface, one camera and two LED lighting devices per production line.

The OCR Interface is managed and controlled using a Print Management Device, the same device mentioned earlier to control the Printer Interface, as both the Printer and OCR Interface form part of the same production-line and process. Once the print run is initiated by the factory-floor operative, using the Print Management Device, the SDC Server downloads production-line, camera, and LED light settings to the OCR Interface.

These settings include production-line speed settings, which the OCR Interface controls. Campaign and SKU character set tolerances, which the OCR Interface uses to accept or reject characters that don't fall within set parameters. Preset image requirements (i.e. images it must take and store, such as winning codes and quality assurance codes.) During the "Make Ready" phase (the phase where outputs and settings for "live" production are tested and set) the software analyses the images and provides verification on the printed characters and their legibility. Also during the "Make Ready" stage first automatic and then manually adjustments are made to the lighting level to achieve optimum results. The OCR software controls and adjusts the lighting levels to provide the appropriate illumination for the material being used. For example, reflective material such as metalised foil can react badly to intense lighting so a lower lighting level is used to illuminate the material correctly. However, sometimes manual intervention in adjusting illumination levels is required. The factory- floor operative will adjust settings until they have achieved optimum illumination.

Once the factory-floor operative starts the "live" production using their Print Management Device and should an error be detected, either as a result of a printing or reading error, the production warning lights next to the print-line will illuminate, indicating the type of error. The Operator, using their Print Management Device, can ascertain codes affected and take action quickly without risking the waste of further product.

The camera takes a continuous stream of images, which the OCR Interface software then stitches together to form a single code which it then compares to codes from the SDC Server of codes recently printed, and which it should expect to read in a specific order.

If the code is legible, expected and in the correct order, the OCR Interface transmits this together with date and time of verification to the SDC Server, where the data is stored.

If the code does not meet the criteria mentioned under point 7 above, an error has occurred and this is also transmitted to the SDC Server to be recorded. Appropriate error handling and warning procedures are also initiated according to the severity of the error. These errors are immediately displayed on the production-line warning lights. The factory-floor operative can then view details of the error on the Print Management Device. It will be appreciated by those skilled in the art that the invention has been described by way of example only, and that a variety of alternative approaches may be adopted without departing from the scope of the invention, as defined by the appended claims.

Claims

1. A method for production line marking of a series of unique identifiers, the method comprising:

marking a unique identifier of the series onto an article to form a unique identifier mark;

obtaining marking feedback data associated with the unique identifier from said marking; and

inspecting the unique identifier mark to obtain inspection data associated with the unique identifier.

2. The method of claim 1 wherein the marking feedback data comprises data

indicating a status of the marking step and the inspection data comprises imaging data of the unique identifier mark.

3. The method of claim 1 or claim 2 comprising, storing, logging or processing the marking feedback data and the inspection data for the unique identifier.

4. The method of any preceding claim comprising processing the inspection data to obtain an inspection result associated with the unique identifier.

5. The method of any preceding claim comprising comparing the inspection data to expected data associated with the unique identifier to obtain an inspection result.

6. The method of claim 5, wherein the expected data relates to a glyph or feature associated with the unique identifier.

7. The method of claim 6, wherein the expected data is limited to a glyph or feature, or one or more glyph or feature combinations, of the unique identifiers in the series.

8. The method of claim 6, wherein the expected data is limited to a glyph or feature, or one or more glyph or feature combinations, of the unique identifiers.

9. The method of any one of claims 5 to 8 wherein the expected data are determined in dependence on marking data for the unique identifier passed or made available to a marking device for marking the unique identifier onto the article.

10. The method of any one of claims 5 to 9, wherein the expected data are

determined in dependence on the marking feedback data.

1 1 . The method of any preceding claim comprising determining a verification status associated with the unique identifier, based upon the marking feedback data and the inspection data.

12. The method of claim 1 1 wherein the verification status reflects whether or not the unique identifier has been acceptably marked.

13. The method of claim 1 1 or claim 12 wherein the verification status reflects

whether or not a serious error has occurred that requires a stop of production line marking.

14. The method of any one of claims 1 1 to 13 wherein the verification status is

determined based upon an inspection result obtained by a comparison of the inspection data with expected data determined in dependence on the marking feedback data.

15. The method of any one of claims 1 1 to 13 comprising comparing the inspection data with the marking feedback data to obtain the verification status.

16. The method of any preceding claim comprising determining and optionally

performing one or more actions based upon the verification status.

17. The method of claim 16 comprising discarding the article in dependence on the verification status.

18. The method of claim 16 or claim 17 comprising storing the inspection data in dependence on the verification status.

19. The method of any one of claims 16 to 17 comprising stopping further production line marking in dependence on the verification status.

20. The method of any preceding claim comprising overriding a buffering routine of a marking device instructed to execute the marking to enable more rapid marking.

21 . The method of any preceding claim comprising reconfiguring a baud rate of a marking device instructed to execute the marking to enable more rapid marking.

22. A processor for verifying and/or controlling production line marking of a series of unique identifiers, the processor comprising: a marking device interface for receiving marking feedback data associated each of a plurality of unique identifiers from a marking device; and an inspection device interface for receiving inspection data associated with each said unique identifier from an inspection device.

23. A system for verified production line marking of a series of unique identifiers, the system comprising: a processor; a marking device co-operable with the processor, the marking device being configured for marking unique identifiers onto articles to form unique identifier marks and sending marking feedback data associated with each of a plurality of unique identifiers to the processor; and an inspection device co-operable with the processor, the inspection device being configured for inspecting the unique identifier marks to obtain inspection data associated with each unique identifier, the processor being configured to receive the inspection data from the inspection device.

24. The system of claim 23 comprising a transport means for carrying articles from the marking device to the inspection device and optionally a line blower for discarding of articles.

25. The processor or system of any one of claims 22 to 24 wherein the processor is configured to store, log or process the marking feedback data and the inspection data for the unique identifier.

26. The processor or system of any one of claims 22 to 25 wherein the processor is linked to one or more data storage memories.

27. The processor or system of any one of claims 22 to 26 wherein the processor is a controller configured for controlling the marking device and/or inspection device.

28. The processor or system of any one of claims 22 to 27 wherein the processor is configured to process the inspection data to obtain an inspection result associated with each of the unique identifiers.

29. The processor or system of any one of claims 22 to 28 wherein the processor is configured to determine a verification status associated with each unique identifier, based upon the marking feedback data and the inspection data.

30. The processor or system of any one of claims 22 to 29 wherein the processor comprises a server system.

31 . The processor or system of any one of claims 22 to 30 wherein the processor comprises a marking device controller and/or an inspection device controller and/or an optical character recognition module.

32. A media device storing computer program code adapted, when loaded into or run on a computer or processor, to cause the computer or processor to become a system or processor, or to carry out a method, according to any preceding claim.