METHOD AND SYSTEM TO CONTROL THE PRODUCTION OF CODED IMAGES USING SIGNATURES OF IMAGES
FIELD OF THE INVENTION The invention relates, in general, to the protection, against counterfeiting, of printed and digital documents, packaging material and other printed materials, and more particularly to the secure production of coded images for use in measurements of protection against counterfeiting. BACKGROUND OF THE INVENTION The falsification and alteration of valuable documents and the sales on the black market of counterfeit articles are significant problems faced with increasing regularity in the current world. Every year millions of dollars are lost for the fraudulent use of non-authentic documents and branded items. The growing sophistication of optical scanners, copying machines and other devices used to replicate items continues to increase the ability of counterfeiters to produce fraudulent documents and other imitations that are of sufficient quality to pass often undetected. One method to provide increased security against unauthorized copying, alteration or forgery, is to apply an encoded image to the article
REF .: 161104 that is going to be protected. This image may include a visually apparent image (visible image, together with a non-visible or hidden image, incorporated in the visible image in a way that is difficult or impossible to see without an optical or digital decoder, configured specifically to view the image The application of these encoded images, to documents and other articles subject to falsification, allows the authenticity of these articles to be easily verified by any person who has an appropriate decoder.The content of the encoded images can be very variable and It can be changed on a regular basis, the content can be even linked specifically to the individual article to which it is applied, in which case it must be generated very quickly in order to be considered a practical safety measure. encoded images should be flexible and preferably available at s users in a short time. It is therefore advantageous to make the production of coded images readily available to individual users. However, doing so increases the concern that the encoded images themselves may be altered or produced by unauthorized users for the application to counterfeit items or altered documents. Another concern is that 'the authorized user can use the encryption software for unauthorized purposes, such as protecting printed material that is not allowed to code. Accordingly, sophisticated control measures are required to ensure that the encoded images are produced only by authorized users and to ensure that those authorized users produce only authorized encoded images.
BRIEF DESCRIPTION OF THE INVENTION The embodiments of the present invention satisfy the need for additional control in the production, transfer and use of encoded images used to protect documents and other materials, against unauthorized reproduction, against forgery or against other misuse. . An illustrative aspect of the invention provides an automated method for authorizing and controlling the production of optical encoded images. The method comprises receiving, from a user data processor, an authorization request to produce an encoded image. The authorization request includes data supplied by the user, comprising at least one authentication image file. The method further comprises determining whether or not the user is authorized to produce an encoded image using the data supplied by the user. In response to a determination that the user is authorized to produce an encoded image using the data supplied by the user, an authentication image signature is generated from at least one authentication image file using an image signature algorithm. , and a positive authorization response is returned to the user's data processor. The positive authorization response includes the authentication image signature.
BRIEF DESCRIPTION OF THE FIGURES The invention can be understood more fully by reading the following detailed description together with the accompanying figures, in which similar reference indicators are used to designate similar elements, and in which: Figure 1 illustrates a exemplary encoded image, formed from primary and secondary authentication images; Figure 2 illustrates the use of a lenticular lens decoder to decode the coded image of Figure 1; Figure 3 is a schematic representation of an automated system for the validation of encoded images, in accordance with one embodiment of the invention; Figure 4 is a schematic representation of another automated system for the validation of encoded images, in accordance with one embodiment of the invention; Figure 5 is a flowchart of a method for controlling a process for the production of encoded images, in accordance with one embodiment of the invention; Figure 6 is a schematic representation of an automated system for the validation of encoded images, in accordance with one embodiment of the invention; Figure 7 is a flow diagram of a method for controlling a process for the production of encoded images, in accordance with one embodiment of the invention; Figure 8 is a flowchart of a method for controlling a process for the production of coded images, in accordance with one embodiment of the invention; and Figure 9 is a flow diagram of a method for controlling a process for the production of encoded images, in accordance with one embodiment of the invention.
DETAILED DESCRIPTION OF THE INVENTION Modalities of the present invention provide methods for controlling the production, transfer and use of encoded images. As mentioned above, these coded images are used to discourage or prevent the falsification and misuse of documents and other materials to which the coded images are applied. As used herein, the term "encoded image" (or "optical encoded image") refers to a variation that is woven, scrambled, or otherwise manipulated, of one or more authentication images that, when inserted in a document, or in another printed background or source image, can not be distinguished from the material of the base document or other background or source image, without the use of a decoding device. An encoded image can be generated from an authentication image using a particular set of features that include encoding parameters that correspond to certain characteristics of the decoding device. When the encoded image is printed, the placement of the decoding device on top of the encoded image, printed, in a predetermined orientation, reveals the authentication image. Without the decoding device, part or all of the encoded image may be visible, but it can not be deciphered or distinguished from the background with the naked eye. It will be understood that images encoded in optical form can be digital images that can be decoded by an optical decoding device, if they are printed, but can also be decoded in their digital form using a digital decoding device such as a decoder based on software. The encoded, digital images include encoded images that still have to be printed or applied in physical form, as well as digital images that have been scanned or reproduced from printed encoded images. It will also be understood that images encoded in optical form can be printed or applied in such a way that they can be decoded only by the use of incident light in the non-visible spectrum or by the use of scanning devices that function to see light in the spectrum is not visible. These encoded images include those printed with a medium that emits or reflects light at non-visible wavelengths (eg infrared) or that emits or reflects light when illuminated by light at non-visible wavelengths (eg, ultraviolet) .
As used herein, "authentication images" includes any image used in the production of an encoded image. Therefore, an authentication image may be an image provided for use as a visible background image or a secondary image provided for uses as a hidden image incorporated into a visible image. The encoded images, of particular interest for the present invention, are those that are configured to be decoded in optical form using a lenticular lens. These images are described in Alasia, U.S. Patent No. 5,708,717 ("patent? 717"), which is incorporated herein by reference in its entirety. These images take advantage of the lenticular lens's ability to select image content based on the frequency of the lens lenticule. These images are typically encoded by one of several methods that involve establishing a regularized periodic pattern having a frequency corresponding to that of the lenticular lens to be used as a decoder, and then introducing pattern distortions that cause the image to be difficult to discern at a glance. Figures 1 and 2 illustrate the use of a lenticular lens to decode an encoded image. Figure 1 shows an enlarged view of an image encoded in optical form 10. The encoded image 10 was constructed from a primary image of a human face and a secondary image of the letters "SI". The primary image was plotted with a particular frequency and selection angle. The secondary image was inserted into the primary image by introducing variations in the weft lines in sites corresponding to the content of the secondary image. The result, as shown in Figure 1, is an encoded image 10 in which the primary image is easily seen but the secondary image can not be distinguished. As shown in Figure 2, when a lenticular lens 20 having a line frequency corresponding to the selection frequency is placed on top of the coded image 10 in the correct orientation a, the secondary image (SI) can be observed . As discussed above, if the encoded image 10 is stored as a digital image or is inserted into a digital document, a digital decoder with functionality similar to that of the lenticular lens 20 can be used to decode the encoded image. If the encoded image 10 has been printed, an image acquisition device, such as a scanner or camera, can be used to create a digital version of the encoded image 10. The digital encoded image can then be decoded using software configured to extract the authentication image of the digital encoded image. The encoded images of this and another type are constructed from digitized authentication images, using a set of coding parameters. These parameters can determine the configuration and orientation of the decoding device used to decode the encoded image. For images that are to be decoded by an optical decoding device, some or all of the coding parameters may correspond to certain optical characteristics of the decoding device. For example, for images that are to be decoded by a lenticular lens, the coding parameters may include a selection frequency, corresponding to the number and spacing of regular selection segments into which an image is divided and the number and spacing of images. the lenticules of the lens. The coding parameters may also include an angular orientation of the selection segments, which determine the orientation with which the decoding device must be placed, relative to the image, in order to decode the image. In the following analysis, the encoded images that can be decoded by means of optical decoding devices, lenticular, are used to illustrate the embodiments of the invention. Those skilled in the art will understand, however, that any method of encoding images, having a set of definable image characteristics, and coding parameters, can be used in conjunction with the methods of the present invention. As discussed in the co-pending applications, U.S. Application No. 10 / 847,943 and U.S. Application No. 10 / 847,952 (collectively "Alasia Copending Requests"), both of which are the which were presented on May 18, 2004 and are incorporated herein by reference in their entirety, some and all of the encoding parameters and authentication images used to construct an encoded image, may be supplied by a user and some or all may be supplied by a separate party that actually performs the construction of the encoded image or that acts as a controller of the production of the encoded image. Also, some of the parameters of content or coding of the image can be determined from the content of a document to which an encoded image is to be applied or in which an encoded image is inserted. As also discussed in the Alasia Copending Applications, the encoded images can be constructed using multiple sets of authentication images and sets of coding parameters. Each of these sets can be formed from different combinations of information supplied by the user and supplied by the controller (i.e. image and / or coding parameters). For example, a first encoded image or portion of an encoded image may be constructed based on an authentication image administered by the user and coding parameter supplied by the user. A second encoded image or portion of the same encoded image can be constructed based on an authentication image provided by a controller and based on encoding parameters supplied by the controller. The use of images supplied by the controller and / or encoding parameters allows a central controller to control part or all of the encoded image. The encoded image itself can be constructed by a central image coding processor (which can be located in conjunction with the central controller) and transmitted to the user's processor or can be built into the user's processor after authorization by the user. a central control processor. Figures 3 and 4 illustrate systems for controlling the production of coded images that require a user to obtain validation / authorization before an encoded image occurs. With reference to Figure 3, the automated system for the validation of encoded images 100 comprises a data processor for the user, connected to a validation server 140 through a network 160. The network 160 can be, by way of example , a local area network connecting a jointly located validation server 140, to a plurality of data processors 110. Alternatively the validation server 140 may be remotely located in relation to the data processor 110, and where the two are located. connected or can be connected through the Internet or another wide area network. In any case, the user data processor 110 may be one of a plurality of user data processors and may be connected to a user interface 120 and a printer 130. The encoded image validation system 110 may also include a device. of authentication control (not shown) connected or in communication with the user's data processor 110. As described in the Copending Alasia Applications, those devices may include a separate processor or an electronic security key that controls the local processing of the software in the user's processor 110. The automated document authentication system 100 may be used to carry out some or all of the aforementioned actions to build a coded image. It will be understood that these actions can be divided so that some or all of the actions are carried out as part of an interactive transaction performed between the user data processor 110 and the validation server 140. It will also be understood that one or more of the actions of the methods of the invention may be carried out by the user data processor 110 while one or more additional actions are carried out by the validation server 140. In an exemplary embodiment, an interactive session may be established between the user data processor 110 and the validation server 140. As part of this transaction, the user may present to the validation server 140 one or more authentication images and / or one or more coding parameters supplied by the user. These can then be used by the validation server 140 to produce an encoded image that is returned to the user data processor 110, wherein the encoded image is inserted into a document and stored or printed to produce a printed, authenticated document. Authentication images not supplied by the user, additional, and / or encoding parameters, may be incorporated into an encoded image by the validation server 140. In another exemplary embodiment, the user may present a complete document to the validation server 140, which creates and inserts an encoded image into the document and returns it to the data processor 110 for printing or storage. Along with the document, the user can present one or more authentication images and / or one or more encoding parameters supplied by the user, for the validation server 140 for use in the creation of the encoded image. In some embodiments, some or all of the actions required to produce an encoded image can be produced by a second server. This allows the separation of the tasks of validation and coding of images and also allows multiple levels of authorization and control. With reference to Figure 4, an automated system for the validation of encoded images 200 includes a first validation server 140 connected to a user data processor 210 through a first network 260. The first network 260 may be, for example, example, a local area network, and the first validation server 240 may be located jointly with the data processor 210. Alternatively the first validation server 240 may be remotely located in relation to the data processor 210. In any case , the user data processor 210 may be one of a plurality of user data processors and may be connected to a user interface 220 and a printer 230. An authentication control device 250 may also be connected to the data processor of the user 210 or may be in communication with it. The user data processor 210 may be adapted to carry out one or more of the actions associated with the coding of an image. However, the user data processor 210 can perform these actions only upon receiving authorization from one or both selected between the first validation server 240 and a second validation server 270. The first validation server 240 can be programmed to monitoring and controlling the processing of coding actions in the user data processor 210. For example, the first validation server 240 may be configured to receive from the user data processor 210 a request to encode an image using certain encoding parameters supplied by the user and / or authentication indices. The first validation server 240 may be further programmed to verify that the user and the user data processor 210 are authorized to carry out the coding process using these coding parameters and indices. This verification is done using a first set of authentication criteria that can be established, at least in part, by the administration entity controlling the first validation server 240. Upon concluding that the request meets the first authorization criteria, the first validation server 240 can return an authorization approval to the data processor of the user 210. The user data processor 210 may then send the request, or a modified form of the request, to the second validation server 270 through the second network 280. Alternatively the first user data processor 240 may send the application or a modified form of the request, directly to the second validation server 270. The second validation server 270 is in communication, or selectively in communication with, one or both of the user data processor 210 and the first validation server 240 through the second network 280. It will be understood that the second network 280 may be the same network as the first network 260 or that it can be a different network. In an illustrative embodiment, the first network 260 is a local network, while the second network 280 is the Internet. In another embodiment, the user data processor 210, the first validation server 240 and the second validation server 270, are all interconnected through the Internet. The second validation server 270 can be programmed to receive and evaluate coding authorization requests, from any of a plurality of user data processors 210 and validation server first 240. The second validation server 270 can have a variety of authorization criteria associated with the user or associated with the client, which may be compared with the data received in an authorization request of a user data processor 210 or first validation server. The second validation server 270 may be adapted to verify that the user and the user data processor 210 are authorized to carry out the coding process using the coding parameters and indices presented in the authorization request. This verification can be carried out using a second set of authentication criteria that may be based on the terms of any agreement of use established with the entity or organization of use. These criteria may include limits on the coding parameters that may be used, limits on the number of times the coding software may be used, or how long it may be used (based on an expiration date, for example), limits of the number of encoded images, which can be produced, and limits of the contents of authentication indices supplied by the user. Upon concluding that the request meets the second authorization criteria, the second validation server 270 can return an authorization approval to the user's data processor 210 and / or to the first validation server 240. At the same time, the second server validation 270 may provide certain encoding parameters not supplied by the user and / or authentication indices that are to be used by the user's data processor in the construction of the requested, coded image. It will be understood that the different coding actions of the authentication methods described previously can be divided so that some or all of the actions are distributed between the user data processor 210 and the first and second validation servers 240, 270. It will also be understood that one or more of the actions of the methods of the invention can be carried out by the user's data processor 210 while one or more additional actions are carried out by the validation servers 240, 270 as part of the verification / authentication process, or in conjunction with it. Figure 5 illustrates a general method for controlling the production of an encoded image in accordance with one embodiment of the invention. The method starts at S105, and in S110, coding parameters and variable indices are received by the data processor executing the authentication software. These may include any combination of authentication image indices and / or encoding parameters, supplied by the user and not supplied by the user. In S120 and S130, a verification is carried out to determine if the coding parameters requested and / or provided by the user fall within the previously established authorization criteria. These criteria may include, for example, predetermined limits of the coding parameters that the user may present. For example, a user may be allowed to select only a certain frequency of selection or orientation of an authentication image. The verification criteria can be established d on terms of use agreed by the user. In addition to the limits of the encoding parameters or authentication indices, the verification criteria may include a limit on the number of uses of the authentication software or the number of encoded images that may be produced. In any case, a real number of uses or images may be increased each time the software is used. Alternatively, a time-d limit such as an expiration date may be included. The authentication software may be configured in such a way that an attempt by a user to exceed the limits of use or to use coding parameters or indices that are outside the terms of use for that user, result in An error message will be displayed on S135. The error message could be displayed, for example, if the user requests an encoded image that has a selection frequency outside the range assigned to the user, if the actual number of uses exceeds the user's usage limit, or if the image Authentication does not satisfy predetermined criteria related to its content or resolution in dots per inch. When determining that the authorization criteria have not been met, the method can be finalized. Alternatively, the user can be instructed to provide an entry that meets the authorization criteria. If the authorization criteria are met, the coding procedure is authorized in S140. Subsequently, the authentication indices can be used to establish an image (or images) of digitized authentication in S150. If necessary, some or all of the authentication indices can be made into a digitized image. The authentication images may also include authentication indices not supplied by the user. In S160, the coding parameters are assembled into a set of coding parameters, which can be used to encode the authentication image (s) in S170. The set of coding parameters may include coding parameters not supplied by the user, in addition to the coding parameters supplied by the user. The resulting encoded image can be stored or inserted into a document as previously analyzed. The method ends in S195. 1 As mentioned above, the steps of the validation and coding process can be divided among multiple processors that include a user data processor and one or more validation servers. Figure 6 illustrates an exemplary coded image validation system 300, which is similar to system 100 of Figure 3. The validation system 300 has a user data processor 310 that can be selectively connected to the validation server 340 through a network 370. As illustrated in Figure 6, the validation methods of the invention can be carried out using three main software modules: a client software module 312, a validation module 342, and a coding module 314. These modules may themselves comprise one or more sub-modules for executing particular functions within a module or interfacing with other modules. In the illustrated embodiment, the client software module 312 and the coding module 314 reside in the user data processor 310 and the validation module 342 resides in the validation server 340. It will be understood that the coding module 314 can be reside alternately in a separate coding processor in communication with the user's data processor 310 through the network 370 or through a different network. The client software module 312 may be configured to receive a user input and is typically executed from the user data processor 310. The client software module 312 may be adapted to use a graphical user interface through the user interface. which user can enter data for the transmission and operation by the software of the server and the coding modules 314, 342. The user input could include the authentication images that the user wishes to use as visible and / or hidden images in the creation of an encoded image. It may also include encoding parameters specified by the user, such as the frequency of selection or resolution of the original images and the desired encoded image. The client software module 312 may be adapted to accept user input and make a request for authorization, in order to produce an encoded image based on that entry. This request can be transmitted to the validation server as described in the validation methods previously analyzed. The client software module 312 may also be adapted to compress the authentication image files, which have been identified for use in the creation of the encoded image. The compression of an authentication image produces a compressed or "thumbnail" authentication image. The original authentication image (and the resulting compressed image) can be any type of image file, such as bitmap images, JPEG, TIFF or GIF. The miniature authentication images may be transmitted to the validation server 340 together with the coding validation request, and as will be discussed in more detail later herein, it may be used by the validation module 342 to generate a signature of image that can be used in a second level of verification. In the validation system 300 the client software module 312 requests authorization from the validation module 342 and subsequently calls the coding module 314 to create an encoded image using the authentication images and coding parameters approved by the validation module 342. It will be understood that although the client software module 312 may reside in the user data processor 310, and be executed by the user, it may alternatively reside in a remote server (which may be the validation server 340) to which the user accesses the server. user from a web browser or a client software module, dedicated. In this case, the software executed in the user data processor 310 may be limited to a user interface used to present information for requesting the validation and construction of a coded image. Figure 7 illustrates a flowchart of a process for obtaining a coded image from the perspective of the user's data processor and, in particular, the customer's software module. The process starts at S205. In S210, information related to the desired image coding of a user is received through a user interface. The user can also provide user credentials, such as a username and password, which may be optionally requested in order to obtain authorization of a coded image. The information provided by the user can identify one or more authentication images that will be used for the encoded image. These images can be stored in image files identified in any typical way to select a file from any data storage medium. The user information may also include encoding parameters that may be used to encode the authentication image (s). In S220, the one or more authentication images are obtained by the client's software module. Images will typically be obtained by retrieving them from storage, based on information provided by the user. Alternatively, they can be provided by the data offered by the user. The authentication images can then be compressed to produce thumbnails in S230. The thumbnails, together with the user's credentials (if required) and the encoding parameters are then transmitted as a coded image authorization request, to the validation server, at a site that may be remote to the user's processor. Those of ordinary skill in the art will understand that the images sent with the encoded request could alternatively be sent in an uncompressed form. However, it has been found that there are significant advantages in processing and transmission speed when using compressed image files. As discussed in more detail later, the validation module in the validation server checks the user's credentials and coding parameters, and returns an authorization response. If an encoded image is authorized, the validation module may also return one or more image signatures generated from the authentication image and encoding parameters received in the request. In some modalities the validation module will also return coding parameters not supplied by the user, for use in the construction of the encoded image. In some of these embodiments, the validation module may also provide an authentication image not supplied by the user, for use in encoding an additional encoded image, over which the user has no control. In S250 and S260 the client software module receives the authorization response from the validation server. If the authorization response is negative, an error message is generated in S265 and returned to the user. This message may inform the user about the authorization because the authorization was negative and / or may indicate that the user will be given another opportunity to request authorization for the creation of the image. If the authorization response is positive, in S270, the signature (s) of the image can be received from the validation module. The client software module then calls the coding module and passes to it, at S280, the image signatures received from the validation module together with the authentication, uncompressed, original image files, the coding parameters designated by the client before requesting authorization and, if appropriate, any of the encoding parameters or authentication images received from the validation module. As will be discussed in more detail later, the coding module executes a final validation procedure and, if the result is positive, constructs the requested, coded image. The process ends in S295. The validation module can be configured to receive and validate encoded image requests. Validation can include verifying that the user is an authorized user of the encoded images, generally, and if the user is or is not authorized to receive or produce the encoded image, requested. It will be understood that the functions of the validation module can be executed by a single validation server or can be disseminated through a plurality of servers, some or all of which can be remote to the user's data processor. The validation server (s) can be hosted by an application such as a Microsoft Internet Information Server, for example. Figure 8 illustrates a flow chart of a process for validating a coded image request, from the perspective of the validation server, and in particular, from the perspective of the validation module. The method starts in S300. In S310, a coded image request is received from a coded image requestor, through the user's data processor. The encoded image request may include identification information of the applicant, such as the user name and password, as well as image information related to the image or images encoded, requested. As discussed above, the information of the images may include either authentication images provided by the user or coding parameters supplied by the user. By using information from a user database, the applicant's identification information can be used to verify that the applicant is a valid user of the system in S320 and 330. If the username and password are not valid, a negative validation response is returned to the applicant at S345. If the user name and password are valid, a set of predetermined validation criteria is retrieved, for the requestor, from the data storage in S350. In S360 the images and coding parameters received from the applicant are compared with the validation criteria. If the requested coding parameters are not within the ranges specified in the validation criteria, a negative validation response is returned to the requestor in S345. If the requested coding parameters are within the ranges specified in the validation criteria, the creation of the coded, requested image will be authorized and a positive validation response will be returned to the requester in S380. For purposes of future verification, the validation module may store a record of each user activity in the user database. As shown in the exemplary system 300 of Figure 6, a user database 352 can be established in a separate database server 350 such as an SQL server. As mentioned above, the positive validation response may also include authentication images not supplied by the user and / or encoding parameters not supplied by the user, which will be incorporated into the coded, requested image. As an additional security precaution to prevent further attempts, by the applicant, to change the authentication images or the coding parameters after authorization, the positive validation response sent to the requester in S380 may include an image signature generated in S370 from the authentication images passed to the validation module in the coded image request. As used herein, "image signature" means any unique numerical calculation or graphic representation that is calculated or constructed from an image using a predetermined signature algorithm and that can be used to compare the content of an image. with the content of another image. In the method of the present invention, the image signatures generated by the validation module using a particular signature algorithm can be passed to the requesting user's processor, where they will be received by the client software module and forwarded to the coding module. As will be discussed, the coding module uses the same signature algorithm to generate comparison signatures from the authentication images it receives from the client's software module. You can then compare the comparison signatures with the signatures received from the validation module, to determine if the authentication images and / or coding parameters have been changed. The coding module is the portion of the system that is executed to create an encoded image using the authentication images and the coding parameters. The coding module may perform the execution locally with respect to the client software module, such as through software installed on the user's computer. Alternatively, the coding module can perform the execution remotely, such as on the computer used to host the validation module. The determination that the coding module should perform the execution locally or remotely, may depend on the size of the encoded images created. The system can create coded images that are both high resolution and low resolution. A local execution of the coding module could be preferable when the encoded image is to be produced from high resolution authentication images. In those cases, remote execution would require that the original and encoded images be transmitted over a network, which would result in the user experiencing long times to send original images and receive encoded images. High resolution, coded images used in exemplary embodiments of the invention can be up to 1 GB or larger.
In this way, remote encoding can involve prohibitively high processing times. However, if the data transfer rate is not a problem, or if the bandwidth is sufficient to quickly transfer even larger files, then remote creation of an encoded image can be a desirable alternative. Client and validation modules are typically developed using interpreted languages such as Java, or managed code, such as Microsoft .NET, which can not allow sufficient data processing speed and security against decompilation. Because of this, the coding module preferably uses a set of image processing functions, highly optimized, previously compiled, of the image processing code, written in C, C ++ or assembly language, and which could be additionally wrapped in an envelope. security, such as one provided by Aladdin Systems. This can allow for higher processing speeds during the process of creating coded images, as well as allowing additional security against attempts made to decompile the image processing code. An exemplary method for producing a coded, validated image, from the perspective of the coding module, is presented in Figure 9. The method starts at S400 and at S410, the coding module receives the signatures of images passed from the module. validation, together with the real, original (uncompressed) images identified by the user as the authentication images that will be used to create the encoded image. The coding module also receives the coding parameters validated and / or provided by the validation module when the creation of the encoded image was authorized. Upon receiving the image and the information of the coding parameter, the coding module can optionally retrieve the stored validation criteria locally, to which the user does not have access. In cases where the coding module is located in a user's data processor, the validation criteria can be stored, for example, in a hardware key attached to the user's data processor. The hardware key can have a separate memory that can be accessed by the computer to verify that the encoding parameters are within the criteria stored in the hardware key. This ensures that the coding parameters are not altered after validation by the validation module. The hardware key may also include limits on the use of the coding module based on a predetermined number of uses available to the user or on the basis of an expiration date. The validation module retrieves the validation criteria stored locally in S420 and validates the coding parameters against these criteria in S430. If this validation step is not successful, an error message is returned in S435. If the validation is successful, the coding module independently calculates, in S440, a signature (or signatures) of comparison images, from the original image passed to the coding module by the client module. The comparison image signature is calculated using the same algorithm used by the validation module to calculate the image signature for the images sent to the validation module. The signature (s) of images, created by the coding module, are then compared in S450 against the pass (s) to the coding module from the validation module. If the signatures do not match within a certain predetermined tolerance, an error message is returned in S465. If the 'signatures match within the predetermined tolerance, then the final authorization is granted to create the coded image and the coded image is created in S470. In S480, the newly created encoded image can then be stored in a data storage medium, such as on a disk, to achieve later access in the creation of the printing plates. Alternatively or additionally, the encoded image can be displayed or printed immediately. The method ends in S495. If the images supplied to the validation module, for validation, are provided in the compressed format, the tolerance interval for signature matching must be established in order to take into account the differences between an image signature created from a original image file, against one created from a compressed image file, such as image signatures created by the validation module. Alternatively, the coding module may include the additional step of compressing the authentication images before calculating the comparison signatures. Another alternative is to have the client software provide compressed images to the coding module along with the uncompressed images. The coding module would use the compressed images to calculate comparison signatures, and the uncompressed images to produce the encoded image. The system 300 of Figure 6 may also include a database monitoring module 360. To achieve increased security, the database monitoring module 360 may be a stand-alone module external to the call functions that connect the software of the client, the server software, and the coding modules 312, 314, 342. The database monitoring module 360 can be executed by a single work station or through a secure local network which in each case has a preference access only to the database of the server to keep the database monitoring module 360 separate from the other portions of the system 300. The database monitoring module 360 can be used by a different party to the user, to achieve accessing and updating the information stored in the server database 352, such as adding or expanding authorized coding parameters, for a particular user, and other useful directive functions in the service provided to the database 352. The system 300 can be established in any development environment, such as for example Java or Microsoft.NET. Likewise, the programming model can use any available model, although the three widely available options include ASP.NET, .NET Remoting, and Web Services. For example, a model built with ASP.NET or Web Services may be preferred if a large number of coding requests and many client access points are anticipated in various computer systems. However, .NET Remoting may be preferred for custom-built, smaller volume, more controlled applications that are typically associated with high resolution images for packaging protection, money bills, stamps, tickets, etc. Each module of the system may comprise one or more sub-modules designed to carry out certain functions within a particular module of the system. For example, the client software module 312 may include a user interface module 315, a remote client module 316, and a coding interface module 317. The user interface module 315 may be a user graphical interface. . This interface is the portion of the system observed by the client on the screen of your computer and used to collect coding and communication parameters. The encoding parameters may include the number or orientation of the encoded images to be created, while the communication parameters may adjust the way in which the client software module connects to the validation module 342 to authorize the creation of the encoded images. The remote client module 316, of the client software module 312, handles communications with the validation module 342. Similarly, the coding interface module 317 communicates with the coding module 314 and is responsible for passing information to the coding module 314 received by the software module of the client 312 from the validation module 342 as well as the information coming from the software module of the client 312 itself. You can also send information from the coding module 314 back to the client software module 312, such as coding progress information, or error messages in the coding. The validation module 342 may include sub-modules such as a remote module of the server 344 that manages the communications to and from the client software module 312 and a database interface module 346 that manages the communications with the database of the server 352 for recording the activity of the clients in the validation server 340. The validation module 342 may also include a data processing module 348 that processes information received by other modules and sub-modules of the system 300. If a module is used of 360 database monitoring, it can also include several sub-modules. Typical sub-modules may include a user interface module 362 for use by the party that gains access to the monitoring application module to observe the records in the database, customer reports, and other stored information. A database interface module 364 manages communications with the database 352 to retrieve information provided to the user interface module 362. A database management module 366 can be used to handle administrative functions, such as the storage of user names and passwords, to perform database backups and other administrative functions, useful for the maintenance of the database 352. The functions of the primary software modules, analyzed above, can be executed in several combinations in different computers, to create a multifurred system that separates software modules into client and business applications. It will be understood that one or more users can access the system through computers connected to the Internet. It should be noted that although the Internet can be the network to which access can be obtained most easily, through which the system modules are communicated, any computer network can be used. As previously discussed, if the user's computers include the encryption module, the computers may also have an attached security key, such as the HASP key available from Aladdin Systems. The user's computers that carry out the methods of the invention can be connected to a web server through the Internet by a first wall of fire. The network server can then access information that is found in a database server through a second fire wall to obtain and / or record information. The database server can also be connected to a monitoring module that can include one or more workstations and a useful exchange server to gain access to the database server, to monitor the status of incoming and outgoing communications , of the database server. The systems and methods of the invention that provide multiple levels of security with respect to the prevention of unauthorized use by a forger or to prevent a user from creating encoded images outside of the authorized coding parameters, can be carried out in various ways . Additional protection can be established through the use of a hash function to create the signatures of images described, for the images that the user intends to use in order to create the encoded image. A hash function assigns a compact signature or compendium to the transmitted data, which can then be compared against an independently created signature, to analyze whether or not the data was altered during the transmission. Some examples of Hash functions known in the art are MD2, MD4, MD5, SHA, and SHA-1. As discussed above, in some embodiments of the invention, an authentication image designated by the user is transmitted to the software module of the server in miniature (ie compressed) form. During verification, the server software module produces a signature for the transmitted image and returns it to the user along with the verification. The coding module independently produces a signature for the same image but not compressed, which can then be compared against that returned by the server software module. If the image that the user tries to use to create an encoded image, is not the same as the one authorized by the server, the signatures will not correspond and the system will not process the request to create the encoded image. Any signature algorithm can be used in the methods of the present invention. However, there are certain characteristics of signatures that improve the performance in security and processing speed of the invention. When handling high-resolution images, for example, an image signature is preferred that does not change significantly when the image is subjected to strong and / or poor fidelity image compression. Such compression is often desirable in order to reduce the amount of information that must be exchanged by a network during the remote verification process. The calculation of the signature also preferably has a high execution speed to avoid unnecessary delays in the reception of the server response, delays in the calculation of the signature prior to coding or in comparison of the signature created in the software module of the server No matter how much the above characteristics are desired, the signature algorithm must be sensitive enough to allow the detection of significant changes in the images. The hash functions mentioned above can be extremely sensitive to any modification of the protected image, but they also have little tolerance to poor compression algorithms. Signatures based on image content descriptors, including but not limited to morphological characteristics, color and brightness histograms, etc., can be constructed to withstand significant levels of compression, and still be sensitive enough to detect even a small modification from image. Signatures can be constructed as transformations that are either reversible or irreversible, although the use of the latter tends to improve the speed of the overall process. The objectives of the signatures, mentioned above, can be achieved by constructing the signatures of images using projection of images on the specified axis. The image is first taken to a threshold and the number of pixels in the foreground is calculated for each point on the given axis, thus creating a signature. To make the signature more robust in relation to compression losses, the image can be divided into a predefined number of strips and the number of foreground pixels is then calculated for each strip, rather than for each point on the axis. The calculated values are normalized to preserve the shape of the signature regardless of the size of the image. To improve the sensitivity to the modification of the image, projections can be used on several different axes. The signature of the image calculated by the server software module can be based on compressed images received from the client software module, which in some embodiments of the invention can be compressed JPEG images. The signature of the image calculated by the coding module uses original, uncompressed files. This can result in reduced processing time and simplified communication between the user interface, remote code, and image processing code, which creates the encoded image. This can also result in a small difference in the values between the signatures generated by the client and the server, which have to be taken into account 'during the comparison of signatures. The absolute value of the error is calculated for each value of the signature. These error values are normalized afterwards and the mean is calculated. If the average error is greater than the predefined tolerance level, the images are "considered corrupted or changed." This results in the validation step failing and an error message being returned In some embodiments of the invention, the images In miniature they are sent to the server software module and can be packaged together in a single data structure, before being sent by the client's software module, which ensures that the digital information is received completely by the server. Similarly, the signatures created by the validation module for all the images can be packaged together, in a data structure, before being sent back to the user's computer. server software determines that a request is not valid, the validation module can assign a default signature, such as zero, that does not match c on any signature created by the coding module. This results in the encoding module denying any processing of the encoded image. . "_ - The use of a security key in some modes may allow the use of symmetric key encryption in the transfer of information through the network. This can be advantageous in providing faster communications while keeping the data encrypted. Yet another level of protection that can be instituted individually or in combination with the other security features analyzed, is a secure Internet connection, such as a Secure Receptacle Layer, to provide secure communications between the client software module and the module. of validation. Additional security features can be implemented, such as the use of two separate servers to carry out the functions of the validation module. For example, a first server can be a network server, separated from all client modules (the client's software module and in some cases the encryption module) by a wall of fire. The network server is the initial server with which the client software module communicates when a remote verification request is sent. The network server can also be used to add new records to the database. The network server can then be connected to a second server through another wall of fire. The second server is the database server that provides the primary data storage, used to verify and authorize the creation of encoded images, by the client. Although the use of two servers may be advantageous in some circumstances, it will be understood that this is not required and that the database server and the network server could in fact be a single computer without firewall between them. It will be understood that the communication channel and the data formatting for remote data transmission may vary depending on the desired functionality of the system. Typical data transmission protocols include HTTP and TCP. The use of TCP can result in significantly faster transmission, although third-party or client firewalls, and proxy servers, can prevent or block TCP communications, so that HTTP can be an acceptable or even preferred alternative in Internet environments. Data formatters can include SOAP, binary or custom made formatters. Those skilled in the art will readily understand that the present invention is susceptible of wide utility and application. Many embodiments and adaptations to the present invention, other than those described herein, as well as many variations, modifications and equivalent arrangements, will be apparent from the present invention, or will be reasonably suggested from the same, and also from the foregoing description. of the same, without departing from the substance or scope of it. Although the foregoing illustrates and describes exemplary embodiments of this invention, it will be understood that the invention is not limited to the construction described herein. The invention can be incorporated into other specific forms without departing from the spirit or essential attributes. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.