ES2348012T3 - METHOD FOR PRODUCING TRANSACTION CARDS. - Google Patents

Abstract

A method for producing a transaction card corresponding to an account of a client and carrying an image defined by said client, including the method: associating an optically readable identifier with a user-defined image to be applied to the transaction card ; read said optically readable identifier and reconcile said optically readable identifier with a corresponding identifier (405) associated with customer account information (407, 604) to be applied to the transaction card; where said customer account information (407, 604) is provided by a card issuing authority (401, 603) by a secure link to a card finishing center (403, 606) and where only said customer account information (407, 604) is transferred from said card issuing authority (401, 603) to said card finishing center (403, 606); and produce a transaction card that carries said user-defined image and said customer account information (407, 604).

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of PCT Application serial number PCT / GB2004 / 000626, filed on February 17, 2004, entitled "Method and apparatus for manipulating images", published as WO 2004 074961 or EP1847964 (prior art according to art. 54 (3) EPC); and of Application GB serial number 0407042.1, filed on March 29, 2004, entitled "Safe Production Center", unpublished priority of this application.

TECHNICAL FIELD

This invention relates to a method and apparatus for producing transaction cards; and in particular to a method and apparatus for producing transaction cards that have a personalized appearance.

BACKGROUND

There is a growing tendency to customize the appearance of consumer items sold in series, as seen, for example, in the use of custom designs and ringtones for mobile phones.

However, before the present invention, the appearance of the means of access to financial accounts remained uncustomized; perhaps due to the anticipated difficulties of allowing the user to personalize the appearance of an item such as a credit card, while also maintaining the appropriate security of the user's private financial information.

United States Patent Publication No. 2002/078146, entitled "Internet Link of Audio and Image Content," by G. B. Rhoads describes steganographically encoding address information in audio or graphic data, and decoding it to allow the link to the Internet. The feature of transferring only customer account information on the secure link is missing. In EP 1847964 this feature is present only in the embodiment of Figure 12, which, however, does not describe that the identifier is optically readable.

SUMMARY

The present invention is defined in claims 1 and 30. Other embodiments are set forth in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present invention, and to show how it can be put into practice, reference will now be made, by way of example only, to the accompanying drawings, in which:

Figure 1 is a block diagram of a typical prior art technique for producing a means of accessing a financial account, such as a credit card, which is not personalized in appearance.

Figure 2 is a block diagram of a technique for producing a means of accessing a financial account that is personalized in appearance, according to an unclaimed example.

Figure 3 is a block diagram of a technique for producing a financial account access means that is personalized in appearance, using a card printer located in a card manufacturing center, according to an unclaimed example.

Fig. 4 is a block diagram of a technique for producing a means of accessing a financial account that is personalized in appearance, in which encryption modules are located in a card issuer and a card personalization center, according to one embodiment. of the invention.

Figure 5 is a block diagram of a technique for producing a financial account access means that is personalized in appearance, in which a read / write module is located in a card personalization center, according to an unclaimed example .

Figure 6 is a block diagram of a technique for producing a means of access to a financial account that is personalized in appearance, in which encryption modules are located in a card issuer and a card personalization center, and in the that a read / write module is located in a card personalization center, according to an embodiment of the invention.

Figure 7 is a block diagram of a technique for producing a financial account access means that is personalized in appearance, in which a unique identifier is placed based on the position of a chip embedded in the account access medium. financial, according to an unclaimed example.

Figure 8 illustrates a computer system for remote image manipulation, according to an unclaimed example.

Figure 9 illustrates a method of operating a computer system for remote image manipulation, according to an unclaimed example.

Figures 10-17 show screens of a credit card design web page, operated according to an embodiment of the invention.

Figure 18 illustrates a method of operating a computer system for remote image manipulation, using a unique customer identifier, according to an unclaimed example.

Figure 19 illustrates a method of operating a computer system for remote image manipulation, using a hash value to avoid the need to create and maintain a unique customer identifier during the request and the card printing cycle, according to an example no claimed.

Figure 20 illustrates a system according to an embodiment of the invention, in which an image is designed using a card issuing kiosk or instant card issuing system.

And Figure 21 illustrates a system in which a database is used to store information between user image selections and back end image production, according to an embodiment of the invention.

DETAILED DESCRIPTION

In one embodiment according to the invention a method is provided for producing a means of accessing a financial account, such as a credit card or other financial card, which has a personalized appearance. The embodiments of the invention allow the production of said means of access to a financial account that has a design selected by the user, while also maintaining an appropriate security of the user's private financial information; in a way that can also be integrated economically in conventional card production techniques. The embodiments of the invention are relatively easy to implement by a card issuer, with few changes in the current systems; and allow the cardholder to customize their entire card, including even the issuer's logos and holograms.

Figure 1 is a block diagram of a typical prior art technique for producing a means of accessing a financial account, such as a credit card, which is not personalized in appearance. A card issuer 101, such as a bank, transmits financial information 102 of the cardholder via a secure network link 103 to a card personalization center 104, which applies the financial information of the cardholder to credit cards. The financial information of the cardholder may include, for example, data such as each name of the credit card holder, credit card number, expiration date of the card, etc., to be embossed and, for Some data, print magnetically on a credit card. A card manufacturer 105 prints the credit card cards 106 to which the financial information of the cardholder 102 will be applied, and securely passes the cards 107 to the finishing center 104, for example, in a security van. At the card finishing center 104, a card finishing unit 108, such as a Datacard 9000, embosses the cards, encodes their magnetic strips, and optionally combines them with letters or envelopes intended for mail delivery. The result is a set of conventional finished cards 109 that are not custom-looking. It should be noted that the term "card personalization unit" in the sense that it is used in the prior art refers to the finishing unit 108 for applying financial information from each cardholder to a card, and not to a unit that personalizes the card's appearance according to the cardholder's preferences.

Figure 2 is a block diagram of a technique for producing a means of accessing a financial account that is personalized in appearance, according to an example. In common with other examples or embodiments of this report, the security of financial information is guaranteed by having to pass all the financial information of the cardholder through a secure network 209; thus, no financial information is passed to the card graphics hosting center 203. The cardholder graphics hosting center passes a card design identifier 202 that is unique to the cardholder, but cannot be traced to the holder card by third parties

parts; This guarantees more security.

However, as will be seen below, the example of Figure 2 has drawbacks, in some aspects, in comparison with subsequent embodiments of the invention, because integration with conventional card production techniques is more difficult. In the example of Figure 2, a card issuer 201 passes a unique non-sequential digital identifier 202 for each cardholder that will customize the appearance of its card, to a card graphics hosting center

203. Digital identifier 202 has no other meaning than that of joining the image to be created and the person who will design the card. The card graphics hosting center 203 may include, for example, a web server, with which the cardholder interacts to design a card. Upon completion of the card design, the card graphics hosting center 203 returns 204 to the card issuer 201 a digital identifier for each cardholder who has successfully designed a card, as confirmation that the card design has been successfully completed The card graphics hosting center 203 passes 205 the digital identifier of each cardholder, and the associated digital image of the card design for said cardholder, to a card finishing center 206. The card finishing center 206 also receives 207 credit cards from a 208 card manufacturer; and, by a secure network link 209, the financial information 210 of each cardholder together with the digital identifier given 202 to the card graphics hosting center to identify the card design of each cardholder.

Using financial information and digital identifiers 210; the associated digital images and digital identifiers 205; and cards 207; The card finishing center 206 of the example in Figure 2 creates a credit card that is personalized in appearance. Digital card design images and associated digital card identifiers are stored in a card graphics store 211, and 217 is passed to a card graphics print server 212. Print server 212 acts as a server for a card printer 213, which can be, for example, an artist card printer. The card printer 213 prints on a card material 207 taking 218 an image and associated digital identifier of the print server 212; and also encodes the card magnetic stripe with the digital card design identifier. The card with magnetic digital identifier is then passed 219 to a card finishing machine 214, such as a Datacard 9000, which reads the magnetic stripe on the back of the card, and uses the digital identifier to obtain the appropriate financial information 210 to emboss the card and prepare it for mailing. The card finishing machine 214, after obtaining the financial information and the associated digital identifier 210, can pass the digital identifier 215 to the card printer to indicate that the card design should be produced next. In addition, the card finishing machine 214 (in this example and other embodiments) may include a barcode reader or other optical reader, in addition to or instead of a magnetic stripe reader. The result of the process is a 216 finished card with financial information from a cardholder and its own personalized design.

The example in Figure 2 has several potential disadvantages. As can be seen by comparing the card finishing center 206 of Figure 2 with the card finishing center 104 of the conventional card production technique in Figure 1, the example of Figure 2 requires a lot of extra equipment and processed in The card finishing center. There must be an extra 213 card printer, which can cost up to US $ 250,000, at each card finishing center. Since some card finishing facilities produce only a small number of cards, the requirement of an extra card printer at each center increases the cost of card production. The card printer has a high cost in consumables per card (for example US $ 0.25 per card). In addition, the use of extra printing equipment at each card finishing center requires more staff training. In addition, there are problems of registration and alignment between the image placed on the card printer 213, and the elements already present in the card material 207, such as a hologram and some logos. From the point of view of the data, the card graphics hosting center 203 has to transfer images to each of potentially many card finishing centers 206, which is difficult and expensive to do reliably and safely. And since the images to be printed are required locally, each card finishing center 206 must have equipment to store the images locally. In addition, a card printer 213 that can be used in a card finishing center, such as an Artist printer, cannot print gold, ultraviolet ink, or Pantone-compliant colors; and you cannot print with sufficient quality by placing card association marks. Finally, reissuing a card, in case it is lost, can be difficult for a card issuer; the preferred card images of the cardholder would have to be stored and retrieved for reissue, in one system, also combining the reissued images with new cards to be printed on

a given day

These potential disadvantages of the example of figure 2 are solved with the example of figure 3, which makes it possible to customize card designs in a card manufacturing center, safely. In the example of Figure 3, a card issuer 301 passes a unique non-sequential digital identifier 302, for each cardholder that will customize the appearance of their card, to a card graphics hosting center 303, similar to the one in the example in the figure

2. The digital identifier is returned 304 to the card issuer 301 as confirmation that a design has been successfully completed, for example, by a user interacting with a card graphics web page 305. The card issuer 301 returns to the center of personal graphics hosting 303 the digital identifiers 307 of the cardholders who have completed the design of their card, and whose credit has been approved. The card issuer 301 may add to the file 307 the digital identifiers of the cards that have to be reissued due to loss, expiration or other factors. The card issuer 301 also associates the successful digital identifiers 307 with financial information of the cardholder 309, and passes them through a secure network link 310 to a card finishing center 311. The card graphics hosting center 303 associates 306 the digital identifier of each cardholder with the digital image of the completed cardholder card design, and stores them in a card graphics storage module 308 which can be a backup image storage center. In one example, the card graphics hosting center 303 associates 306 the digital identifier with its corresponding image by converting the digital identifier to an optical format, using, for example, a barcode, text, micropoint, microtext, invisible ink, or other technique; and embedding the optical format identifier as part of the digital image to be applied to the card; for example printing the optical identifier on the image itself. The digital identifier can also be printed in two

or more different optical formats, or multiple times in the same format, so that the identifier can be read in case of a defective scan.

The example in Figure 3 below uses the list of approved digital credit IDs 307 to take the relevant images from the card graphics store 308; and passes the digital images with embedded 312 optical identifiers to a card graphics print server 314 at a card manufacturer

313. The card graphics print server 314 may be, for example, an offline short-term image storage center, designed to optimize images for the associated printer. Since the digital identifiers have been optically embedded in the digital images, only the images 312 have to be passed to the card maker 313, without the need for the digital identifiers to be transmitted separately. The digital image with embedded optical identifier 315 can then be passed to a digital printer 316, which simply prints all the cards whose images have been passed to the print server 314. The digital printer 316 can be, for example, an HP Indigo printer, or similar system. More generally, it can be a high quality commercial digital press designed to digitally print financial cards. For example, printer 316 may be a machine that conforms to Pantone and prints at more than 800 dpi; that can put logos, brands, optical identifiers, and card designs in a single process, quickly and economically; and that you can also print each card, on a sheet of cards, with different information. Preferably, the printer 316 can print various colors, all in ink; including at least four visible colors and two others (one ultraviolet and one metallic, fluorescent, or similar). Next, the printed card 317 with optical identifier embedded in its printed image is passed to a read / write module 318, which reads the optical identifier of each card and encodes it in the card magnetic stripe, thereby making the identifier digital of each card is magnetically readable by a card finishing machine 319. Cards with magnetic identifiers 320 are sent through the conventional channels of the card maker 313 to the card finishing center 311. A card finishing machine 319 (such as a 9000 Datacard or other machine), you can then read the magnetic identifier of each card and use it to associate the printed card with the correct image with the associated financial information of the cardholder, provided by link 310. Then you can produce a finished 321 card, which has user financial information as well as a personalized look.

The example in Figure 3 has several advantages. First, no additional equipment is needed at each card finishing center 311; the equipment is the same as that required in each card finishing center 104 the conventional card production technique of the example of Figure 1. Next, a large volume of digital images is passed to a small number of card manufacturers 313, and between two components 305 and 308 of the card graphics hosting center 303; instead of switching to a potentially large number of card finishing facilities 311, as in the example of Figure 2. This means that a fast dedicated line can be mounted to transmit digital images 306 and 312. Also, given that the identifiers digitals are optically embedded in 312 digital images, there is no need to send the digital IDs separately to the card maker

313. This means that only one type of file (the type of digital image file) needs to be passed to the card maker 313, in one direction; thus, the dedicated line for transmitting data 312 can be easily blocked in a firewall. In addition, the process of Figure 3 makes it easier for a card issuer 301 to request the reissue of a card; the card issuer 301 simply sends the digital identifier of the card to be reissued in the same list 307 of digital identifiers as that sent 309 to the card finishing center 311. On the printing side, the example of Figure 3 uses a single printing process of a digital printer 316 to be able to print elements such as card logos and personalized images against each other, without alignment or registration problems. The increase in printing cost, compared to the example in Figure 2, is very low; and the print quality is high (for example, the digital printer 316 can print at 800 dpi, instead of the 300 dpi that the 213 card printer achieves). The processes of each entity are also direct: neither the card issuer 301 nor the card finishing center 311 have to process bulky digital images; the processes at the 311 card finishing center are completely online; and there is little change in the process at the 313 card manufacturing center.

The embodiment of Figure 4 is similar to the example of Figure 3, with some modifications that may be useful for card issuers. In particular, the embodiment of Figure 4 differs by including an encryption module 402 in the card issuer system 401, and an encryption module 404 in the card finishing center 403. The encryption module 402 is used to apply an encryption function to some of the unique, personal financial information of each cardholder, in order to produce the digital identifier 405 that will be used to identify the cardholder's card design. Encryption can be performed using a unidirectional encryption function, such as an MD5 hash function or other hash function, that encodes cardholder information in a non-reversible manner. Since the encryption function is used to produce the digital identifier 405, it is not necessary for the card issuer to pass a digital identifier through a secure network link 406, together with the financial information of the cardholder 407. Instead, it you can use an encryption module 404 in the card finishing center 403 to apply the same encryption function to the same portion of the financial information of the cardholder 407 as that applied by the encryption module 402. Therefore, the The output of the encryption module 404 is the same digital identifier 405 for the cardholder as produced by the encryption module 402 in order to reconcile a cardholder card design with its financial information. However, as opposed to the embodiment of Figure 3, it is not necessary for the card issuer 401 to pass a digital identifier together with the financial information 407 over the network 406. This means that the card issuer systems 401 to send information Financial 407 does not have to be modified (compared to its conventional transmissions 102 of Figure 1), which can be advantageous for the card issuer compared to the embodiment of Figure 3.

In another example, depicted in Figure 5, the example in Figure 3 has been modified by moving the read / write module 318 of the card maker 313 to the card finishing center 311. As shown in Figure 5, a manufacturer of cards 501 sends a printed card with an embedded optical identifier 502 to the card finishing center 503. A read / write module 504 then reads the optical identifier 502 and writes it on the card magnetic stripe, so that it can be read by the card finishing machine 505 in a manner similar to the finishing machine 319 of figure 3. Compared to the example of figure 3, the example of figure 5 has the advantage that no additional equipment is required in the 501 card maker center. In addition, the processes at the 503 card finishing center are still online. Potentially, however, the example in Figure 5 could have the disadvantage, compared to the example in Figure 3, that the size and type of optical identifier printed on the card 502 depends on the read / write equipment 504 used at the card finishing center 503. Since this equipment may be less sophisticated than a read / write module 318 used by a card manufacturer, there is a possibility that the 502 optical identifiers are large or not very aesthetic, possibly leading to to have the card rejected at the point of sale.

In another embodiment according to the invention, shown in Figure 6, the modifications of the embodiment of Figures 4 and the example of Figure 5 are combined. Specifically, the embodiment of Figure 6 uses a pair of encryption modules 601 and 602 to avoid the need for the card issuer 603 to send digital identifiers along with financial information 604 (similar to the embodiment of Figure 4). In addition, similar to the example in Figure 5, a read / write module 605 is moved to the card finishing center 606, instead of being located in the card maker 607. Therefore, the embodiment of the figure 6 combines the advantages and disadvantages of Figures 4 and 5: no additional equipment is required in the card manufacturer 607; the processes at the 606 card finishing center are online; and there is no need to transmit any digital identifier together with financial information 604, so that the systems of the card issuer 603 do not have to be adjusted to do so. However, as with Figure 5, the use of a read / write module 605 in the card finishing center 606 may produce the possibility that the optical identifier may be large or not very aesthetic, if the read / write module is of a less sophisticated type than that used by a card manufacturer.

Another example, represented in Figure 7, puts a barcode (or other unique identifier) based on the position of a chip embedded in the means of accessing the financial account. First, a user registers in 701 at an e-banking site, or otherwise requests a means of accessing a financial account. A server 702 of the card issuer receives the user's request to personalize his card, and passes a unique identifier, to associate the user with the personalized card design, to a card graphics hosting center 703. The server 702 of the issuer of cards also passes 704 user financial records (in relief) to a card office 705, along with the unique identifier that was passed to the card graphics hosting center. In the 703 card graphics hosting center, which can be implemented as a web page, the user designs his card with reference to a graphic template indicating the relief and logos that appear on a standard card of the card issuer; and the 703 card graphics hosting center checks the acceptability of the user's card design. Next, the example in Figure 7 has the advantage that the card will have an embedded chip placed in position 706 on the card, placing a barcode, which will be used to identify the user associated with the card design, in the Same position 706 that the chip will be added later. This allows the use of a larger or more visible barcode, because the barcode will not be seen in the final card design once it is covered with the embedded chip. The card graphics hosting center 703 then sends the final image of the user with the unique user identifier encoded in the barcode, to a 707 card manufacturer. The card maker 707 prints the card, using a card printer such as, for example, an HP Indigo Press. A barcode is included in the image printed on the card, in the position that the embedded chip will subsequently occupy; and on the image are placed the card issuer logos, and logos of card associations such as Visa or Mastercard. The card is then sent 708 to the card office 705, by means of secure standard distribution. At the card office 705, a read / write unit 709, such as a Datacard 5000 card reader, reads the bar code on the card, and writes the unique user identifier in the card's magnetic stripe. The read / write unit 709 also removes the plastic from the card, and puts an embedded chip in place of the barcode. The card is then placed 710 in a 9000 Datacard, or similar 711 card embossing unit; and the user relief record is requested 712 from a database of embossed stamp records 713, using the unique user identifier maintained in the card magnetic stripe. The card embossing unit 711 then embosses and sends the card, producing a finished card 714 in an envelope with the user's address.

Next, an embodiment according to the invention will be described which allows the user to manipulate an image through a browser interface, and is divided into two software portions, here referred to as front end software and rear end software. The front end software operates fully within an Internet browser and in most cases does not require a download, because it accepts the limitations of the browser. In one embodiment, the forward end software executes Flash software, which can be obtained from Macromedia Inc. of 600 Townsend Street, San Francisco, CA 94103, United States of America, or equivalent software. The front end software is a pure graphical user interface (GUI), and allows the user to design and edit graphics on their screen in order to create a representation of a desired image. Representations of stock images (initials) can be presented to the user in a library of on-screen images and / or created by the user on demand. The desired image for output can be formed by one or more representative components, each of which has its position defined in relation to an origin, and can be manipulated based on a set of predetermined standards, such as, for example, rules that allow resizing, rotating, turning, reflecting and moving the image or its components in relation to other components. Representative graphic components can be used, for example, to create relatively complex designs consisting of a plurality of different layers and / or transparencies constructed using Flash scenes.

When the design is completed, in an embodiment according to the invention, instructions on the appearance of the final image are sent to the back end software, which runs on a server. In the preferred embodiment, these instructions are sent together (simultaneously) after finishing the manipulation, and take the form of a text string for each component of the image. For example, the makeimage.aspx text string for a graphic component could be:

id + = 030, x = 182, y = 32.3, flip = yes, rotate = 270, scale = 190.6, user = 230 Where id is an image identifier; x e y defi

in the position of a component in relation to a predetermined origin; flip, rotate, and scale define manipulations of types generally known in the art; and user is a number that identifies the user. Those skilled in the art will appreciate that in this way a range of image manipulations can be defined. A resulting image can be represented by one or more graphic components. Thus it is possible that a plurality of text strings, or an extended text string, define an image formed by a plurality of separate graphic components. The graphic components used, for example, in Flash movie scenes are generated and manipulated with a minimum of computing resources; and designs built as a result can be re-created on the back end (server) side using the relevant (and usually much larger) image files. Relatively complex designs can be achieved using two or more image components with separate image identifiers. Image identifiers for graphic components of the same image may have a common characteristic. According to embodiments of the invention, the instructions included in the text string defining the manipulations necessary to create the resulting image, not all have to be included in a single text string; instead, a series of text strings can be transmitted separately to carry the same plurality of instructions. In addition, manipulations on the remote server do not have to wait for the reception of all series of text strings, but instead can be performed in stages when each string in the series is received. Regardless of the number of text strings used, an advantage of an embodiment according to the invention is that a smaller emulated version of the image can be manipulated by the user with a minimum of computing resources, and the instructions can be efficiently transferred as strings. of text; instead of requiring the inefficient (and slow) transfer of large image files, or portions of them, between the client and an image production server. In addition, the need to communicate a change of image to a server every time a single manipulation is also overcome.

The back end software is responsible for generating the final image, according to an embodiment of the invention, interpreting the manipulations applied to the representation (defined in the or in each text string file) and applying corresponding manipulations to a

or several stock images kept in a remote storage of images. The images used in the front-end software are representations that require less computational resources than those maintained on the server. As a result, the back end software can make image transformations that accurately reflect the views on the client machine. Once the desired image has been created with the back end software, the image can be sent to the device that is needed, such as a device for printing the image on a custom consumption item. In this way, the graphic representation is visualized and manipulated in the user interface by means of the Flash software, and only a minimum amount of information regarding the image and the manipulations applied to it have to be transferred to the remote image processor.

As mentioned earlier, the front end software can use Macromedia Flash, or another product. For example, the software could instead use HTML and Java-script (DHTML) without downloading, even if the GUI is relatively poor. The use of Flash software (or equivalent) is advantageous because it does not allow full access to the user's local files, so there is no risk of transmitting computer viruses to the user's machine. Use of Flash software also does not require the user to install software other than the Flash plug-in, which has a high penetration in the browser market.

An embodiment according to the invention thus allows the manipulation of images online by emulating browser-based transformations (such as resizing or overlapping images), made by the user in a representation of the image, on the server so that the images produced can be Used for creating custom products.

The manipulation of images online is allowed by creating a two-level architecture, in an embodiment according to the invention: there is a program that allows the manipulation of images on the screen in front of a user; and a second program on a server that emulates these manipulations, so that the images can be sent for the creation of customized products. In the preferred embodiment, the rear end process,

or elements thereof, can be performed in a secure calculation environment; and custom images can be printed on a real product under very high security (for example, bank security). In this way, a user with Internet access can design personalized images to print on a remote product that requires a secure treatment, such as bank security. For example, anti-fraud and anti-theft measures mean that the production of credit cards, and other types of transaction cards, is carried out in secure positions. Thus, it is possible to customize the designs applied to such cards, using preferred embodiments, without the need to give the user direct computer access to the secure environment.

An online image editing tool uses the HTML and Macromedia Flash navigation environment as a graphical user interface for remote software that emulates the actions performed on the client's machine, in an embodiment according to the invention. This allows a quick user experience and a high quality final product. However, manipulation by enabling the client-side, browser-based environment does not necessarily have to be Macromedia Flash. Any equivalent software tool capable of providing the required functionality could be used, for example, any tool capable of generating a representation of an image, applying manipulations, and transferring the results through a set of commands to the server-side software, such that an image processor on the server side can emulate the actions of the front end and create a resulting image that can be saved on the server. The front-end software will allow images to be loaded from the user's computer to the server, so that the user's own images can be manipulated and overlapped with “stock” images and borders. Then, communicating with the back end software, it is possible to produce customized items for a user. Such personalized items may include, for example, credit cards, debit cards, cell phone covers, jugs, shirts, gift cards, and framed printed copies.

An embodiment according to the invention has the advantage that high quality images do not have to be uploaded to the client's browser during the manipulation process, because light, network-enabled formats are used instead of those used for the user experience , making the system quick and easy to use. However, when the information is transferred, the original high quality images are used to obtain high quality printing results. An embodiment according to the invention also allows the provision of light, but fast, manipulation of graphics, without the complication of downloading programs. In addition, a user interface according to the invention is not constantly calling the server; Thus, the interface is fast and pleasant to use, and Internet bandwidth is used efficiently. Another advantage of an embodiment of the invention is that the original image is not transferred over the Internet in the manipulation stage, so that the chances of hacking the image are greatly reduced. In addition, since the interface extends within the Macromedia Flash environment, the interface is platform independent. In addition, since the final image can be created on a server controlled by a single company, the final image sent can be made to have a standardized size and resolution. This allows easy integration with printers, simplifies the production of a customized product, and simplifies billing based on image.

As an example, Figures 8 and 9 describe the production of a credit card, according to an example.

In the example of Figure 8, a customer accesses software according to the invention, after having requested a credit card through a web page 801 of a card issuer (such as a bank). In the first step, the card issuer sends the customer a unique identifier number 803 that is passed to an image compilation server 808, which can be operated (or not) by a company other than the card issuer. The card issuer associates the unique customer identifier 803 with the financial information of the customer 804. This association can be made in a financial account association table 824 maintained in an environment that is secure from the user interface. The associated client identifier 803 and the financial information 804 are passed to a print server of the bank (or other card issuer) 809 by means of an 802 firewall. Next, the client enters the front end software 805, which can be operated by a web server or other front end server. The client chooses an image 807, in Figure 8, of the hard disk drive of the client computer 806, and the load on the image compilation server 808. The image 807 could come from any suitable source, such as a library of images, maintained by an operator of the image compilation server 808. The back end software 810, which runs on the image compilation server 808, now introduces the original image into a database and generates a smaller copy Web 811 compatible to send to the 805 front end software. The client now performs image manipulations 812 (such as resizing, rotation, and image placement), as desired by the client. The back end software 810 associates the client image selection, and subsequent manipulations and selections, with the unique client identifier 803. Next, the client chooses another image 813 to superimpose it on the first image 807, and puts the image 813 as you wish. The overlay image 813 can be, for example, a transparent decorative frame for the loaded image 807, and can be maintained on an image server 814. The rear end software 810 transmits a smaller, web-compatible version of the image 815. superimposed 813 to the client, for use when creating a combination 816 of the original image manipulated 807 with the superimposed image

813. Once customer approval 817 of the final design 816 is achieved and the front end software 805 is instructed, the front end software 805 transmits a user manipulation data chain 818 to the image compilation server 808 This 818 chain encapsulates the client's image selections and manipulations. Upon receiving this chain 818, the rear end software 810 accesses the original copies of the images from an image library and performs the exact operations that the customer has chosen in the front end software 805 for the final design of the customer. In this way, the rear-end software 810 emulates manipulations at the user's end according to the information transferred in the text string (also referred to herein as the result script). At this point, the back end software 810 can send the resulting image 819 to a print server 820, which can operate through a firewall 821. The resulting image 819 and the associated client identifier 803 can then be passed to the server. Print 809 of the bank (or other card issuer), which, in turn, accesses the table of association of financial accounts 824 to obtain the associated secure financial information of the client 804. The financial information 804 and the resulting image 819 can then sent to an 822 credit card printer, which prints a custom 823 credit card. All images used by the customer in the front end software 805 are sent using the back end software 810. The only information that passes to the rear-end software 810 from the front-end software 805 (apart from the image requests) are data about the appearance of the image before the client. This information can be easily encrypted for added security. The number of images combined in a design is not limited to one or two (such as images 807 and 813) - the script can be easily modified in many more layers. In addition, transparent frame image layers do not have to be selected and manipulated before a non-transparent image layer; Image layers can be designed in any order. You can also add text to the image through similar replication. The output image can be sent to any type of machine and thus the possible applications are very wide-ranging: the software can be applied not only to the payment card market, but also to non-payment and telephone cards. In some examples, layers can be used as templates and / or marks, referred to herein as transparencies. In one example, the final image displayed on a card may be limited to a selected predefined area, such as a "window" on a payment card (or other means of accessing a financial account), leaving the rest of the card free to functional characteristics of the card, such as a bank logo, a payment card hologram or type indicator (such as, for example, the "Visa" or "MasterCard" logos). Alternatively, some image layers can be placed within said selected window on the card; while other image layers (such as transparencies) are placed outside the selected window, but surrounding the functional characteristics of the card (such as the bank logo, payment card hologram, etc.). In addition, the bank logo or other financial element can act as a fixed template, behind which the user can move the image to a desired position.

In the example of figure 9, in a first step 931, a customer 951 has requested a credit card online (or another card issuer) online, or is already a customer who is offered the opportunity to make A new card for an existing account. In step 932, the customer clicks on a link that redirects the user to a web page (which can be operated by a company other than the card issuer) to design the credit card, which arrives with a unique identifier that refers to the client's account and that will go with the client for as long as the client is on the site. In step 933, the client identifier is used to enter; alternatively, the customer could enter separately at this point and collect the customer ID. Since the design website uses only the client identifier to identify the client, it does not obtain any of the client's financial details. In step 934, the client chooses to load an image from the client's own computer 952, such as a scanned or photographed image. In step 935, the image is uploaded to an image server, and can be maintained in a database 953 for convenience. In step 936, the client enters image manipulation software based on browser 954. In step 937, the image manipulation software requests a series of images in web compatible formats from an image resizing tool 955 of so that the process is fast and fast to use. In step 938, the image resizing tool requests the original image from database 953; In step 939, the original image is returned and resized to a web-compatible format and size; and in step 940, a set of web-compatible images is returned to image manipulation software 954 (these are graphic representations of the original images in which manipulations can be performed). Once the client has achieved the desired effect by manipulating the required series of images, 941 image manipulation orders associated with an image manipulation emulator 956 are sent. Image manipulation orders may include, for example, rotation, new dimensions, placement, turning, scale, brightness control, reduction of redness of eyes, opacity levels, and other manipulations. In step 942, the image manipulation emulator 956 then requests the original images from the image server so that the best quality image is used. Upon receiving the images in step 943, the emulator 956 then repeats all the client transformations and creates an image that emulates the one created online, but uses the original graphics of higher quality. In step 944, this image, and the associated customer identifier, is sent to the bank printer 957. The financial data corresponding to the customer identifier is obtained, through a secure connection 958 with the bank (or other card issuer) ; and the printing process begins.

In an embodiment according to the invention that puts personalized images on plastic cards of the type of credit cards, a very high level of security must be ensured. Therefore, in circumstances where there are already user financial records, the architecture receives a unique non-sequential customer identifier, which corresponds to a set of financial records, from the credit card issuer. This client identifier is passed through each system element and is returned with the generated image file. Thus, in an operation of the "mail merge" type, the client's personalized image can be matched with the client's financial and personal records, so that the correct image is placed on the card. At no time does the front end or the back end software have any financial information. The customer identifier can be used in an automated entry process. In this way, the software (both the front end and the back end software) can know if the user is new or not. Thus, a visitor who returns may be presented with images uploaded on a previous visit.

The system architecture includes two distinct elements, in an embodiment according to the invention. The front end element, the element with which the user interacts, is built in Macromedia Flash. This element allows the user to design a card by manipulating (through scaling, rotation, or performing other manipulations such as those indicated above) the loaded image and then superimposing the image with frames that can contain transparent sections. Since Flash does not have “local permissions” on the client machine, since it is a browser-based interface, it is not able to save the final design. Therefore, it sends an instruction string to the second server side element. The second server side element can be written in C #, although Java, C, C ++, or any other suitable language would be equally capable. The instruction string can be sent as a "querystring", that is, as part of the URL; for example, the string could be formatted as:

(createpage.aspx? here_areelthe_string_

of_instructions & rotate = 90 & flip = yes ...)

Other methods can also be used to transmit user design manipulations, such as using an HTML-style "form" or writing the information to a Cookie and then re-reading the information. Alternatively, the HTTP “POST” and HTTP “GET” hypertext transfer protocol commands can be used to pass data from the user session to the server. HTTP “POST” operates identically to a standard web page form; while HTTP "GET" operates by changing the URL. For example, an HTTP “GET” could change a URL, in order to transfer a rotation, scale, and other user selections, that says:

http://vvww.personalcard.net/saveinfo.aspx?rotate=90

& flip = no & scale = 2328 (x = 232 & y = 128 (y2 = 3438 (x2 = 333 etc.

This list of techniques for transmitting manipulation results is not intended to be exhaustive. Alternative techniques that are developed in the future will also be suitable.

The client identifier can be passed using the session state (the web server session object) or passed as part of the "querystring", according to an embodiment of the invention. HTML "forms" could achieve the same ends.

According to an embodiment of the invention, an image can be loaded as JPEG, GIF, Bitmap, PNG, Tiff, etc .; although it will be appreciated that almost any digital image can be loaded or sent. From the original image loaded the system creates four separate versions:

one.

 A miniature version (such as a JPEG) - see the screenshots interface, below. The image has a file size of approximately 1 to 2k.

2.

 A larger version, but still optimized for the web (it is scaled to be able to enlarge the image to the maximum available by the interface - such as a 250% scale - and still have one-to-one pixel matching (i.e.

image is 241 x 250% wide if possible). This is the image used on the screen to design the card.

3.

 A Bitmap image at the same scale as the original image. A Bitmap image can be used, for example, in a system that uses C #, which is a Microsoft language and uses Bitmap as the default image type.

Four.

 The output design, which can be sized in proportion to a credit card. This design could be of any software format that is useful for the printer used, such as BMP (Bitmap) or PNG (Portable Network Graph). The original images can be placed in a ba

It is data once it has been loaded. In one embodiment, each image request requires returning to the original version to be used; however, this does not have to be this way, because once another image version has been created (for example, a miniature version), the system can also store this version so that processing is reduced (although memory would increase busy). A key benefit of an embodiment according to the invention is that the larger image does not have to be passed back and forth through the web from the client to the server, except for the initial loading of images. However, when the final edited design or image is generated, the highest quality image is used.

In an embodiment according to the invention, the user designs, on screen, an image that looks the same physical size as a credit card using the screen resolution of 72 dpi. This is because a computer monitor cannot present images at a higher resolution. However, the output of a printer can be at higher resolutions, typically 300 dpi or more, increasing the quality. Although the front end software uses the low resolution images, the final design is compiled by the back end software using a full-scale bitmap version of the original loaded image. This can be achieved using a "virtual canvas" inside the back end software that is larger than the design canvas inside the front end software. Thus, the design created by the back end software is placed in a larger size background than in the front end software (while maintaining 72 dpi resolution). Thus, if the size of the credit card in pixels is 241 by 153, by placing the image on a “virtual canvas” credit card from 1050 by 672 to 72 dpi, the resolution can be increased to approximately 300 dpi when the card Credit is finally printed (the reverse at 3.3 inch by 2.1 inch). This method ensures that the maximum attainable dpi (at the maximum printer value) is sent from the back end software, but only the necessary resolution is sent to the front end software. This reduces the memory requirements of the client machine and Internet traffic. This operation could also be carried out by changing the resolution of an image from 72 dpi to 300 in the original size.

In order to use transparencies, in an embodiment according to the invention, images containing a transparent layer (generally frames or borders) must be converted to Flash "movies." This process can be manual, but it can also be automated to be able to import “on the fly” images with transparencies (such as bitmaps or PNG) to the front end software. The back end software can use the original PNG or BMP image to generate the credit card image.

Figures 10-17 show screens of a credit card design web page operated in a series of steps according to an embodiment of the invention. Figure 10 represents a first screen, with a standard library of images assigned to the specific card issuer using the credit card design web page, to the left of the screen. Figure 11 represents a screen that allows users to enter to upload new images to the library on the left side. This can be automated in live versions. In figure 12, the upload allows the user to search with his own computer for images to load. Figure 13 depicts a screen with a new library including both user images and a set of stock images. On the screen of figure 14, by clicking on the thumbnail image on the left side, the larger image is loaded, but still optimized for the web. At this point you can climb, flip, turn, or experience other manipulations; and card details can be seen or hidden. In the screen of figure 15, frames can be added. These are Flash files (.swf) that allow transparency. Again you can flip, scale, turn or experience other manipulations; and card details can be hidden. On the screen of figure 16, by clicking on the red Back button or on the Step 1 tab, the user can return to a previous screen. At this point, the image is represented as "active", but you can also see the frame. The screen in Figure 17 represents the final version of the credit card before being sent to the back end software to be created.

According to another example, represented in Figure 19, a bank or other card issuer does not have to create a unique identifier for a customer, and pass said identifier through the card issuer's own system. Given the complexity of banking systems, avoiding the need to create such an identifier can

Be an advantage.

Before illustrating the alternative of Figure 19, Figure 18 first illustrates an example that may be useful for some card issuers, in which a unique identifier is created for each customer. In this example, a unique identifier is created for each client that asks to design a card 1801, and 1802 is passed to the rear end server 1803. The rear end server 1803 creates an image corresponding to the unique client identifier; and card issuer 1804 passes the unique identifier through the card issuer's own system. An office 1805 that creates the end card can then make a software call to the back end server 1803 using the unique identifier, so that the account details received from the card issuer 1804 can be associated with the image.

In more detail, the example in Figure 18 works as follows. When a customer asks a card issuer 1804 to design a personalized card 1801, the card issuer 1804 creates a unique identifier and passes the identifier 1802 to the back end server 1803. Once the customer designs the card 1806, the user and the corresponding unique identifier are returned 1807 to the card issuer, and the back end server saves 1825 the client image and the unique identifier. The information that the customer has requested a new card is then sent 1808 to the card issuer's systems, along with the unique identifier; and a register and unique identifier for the customer are stored 1809 in the card issuer systems. The card issuer then passes the unique identifier to the back end server in 1810, to notify it that the new card may be created and embossed. The rear end server 1803 and / or the card issuer 1804 can then perform an image verification procedure 1811 and 1812, to ensure that the image designed by the customer is acceptable for production. If the image does not pass the image verification of the rear end server 1811, the unique identifier and the reason for the rejection of the image are then sent to the card issuer 1813; and the 1814 customer is invited to redesign the card. Once the image has been accepted, the card issuer converts 1815 the registration and the unique identifier of the customer to an embossed record, which is sent 1816 to the office 1805 that will create the card. The back end server labels image 1817 to be sent to office 1805 in the next batch of images; and when an adequate number of images has been prepared, it sends 1818 the image and the unique identifier associated with the office 1805. The office 1805 then keeps 1819 the embossed register and the unique identifier of the customer, obtained from the card issuer 1804; and also keeps 1820 the unique identifier and the image, obtained from the rear end server 1803. Once this is done, the office 1805 can now create the finished card, first obtaining 1821 the customer record provided by the card issuer 1804; and also using 1822 the unique identifier to obtain the associated customer image and provide it to a blank card printer. The blank card printer can then print the image on the blank card in 1823, and encode the card's magnetic stripe. Based on the information present in the magnetic stripe, the embossed register and the printed card can then be joined together 1824 to create a finished card.

In contrast to the process of Figure 18, the example of Figure 19 allows a card issuer to obviate the need to create for each customer a unique identifier that must be passed through the card issuer system. Instead, the card issuer creates a "hash value," such as a compendium of messages, or other unidirectional code, based on some individual account details, so that the card issuer can pass account information from the client to the back end server in a way that is completely secure. With reference to Figure 19, the process is similar to that of Figure 18, with a card issuer 1904, a rear end server 1903, and an office 1905 that perform analogous steps (1901 et seq.) To those of Figure 18 (1801 and following). However, there is a main difference in steps 1902, 1907, 1910, 1913, 1926, and 1927 of Figure 19, why a "hash value" (or other unidirectional code) is passed between the card issuer 1904 and the rear end server 1903, instead of the card issuer having to create a unique identifier for each client, as in figure 18. First, in step 1902, a hash of a unique part of the registry of the card is created customer (such as the name of the customer). A unidirectional hash, such as the MD5 hash, is a process that takes arbitrary-sized input data (such as a customer name and account number), and generates a fixed-sized output, called a hash (or hash value) . A hash has the following properties: (i) it must be computationally unfeasible to find another input string that generates the same hash value; and (ii) the hash does not reveal anything about the input that was used to generate it. This means that the hash function used in the example of Figure 19 allows the card issuer 1904 to pass at least part of the customer account information to the back end server 1903 in a completely secure manner. As seen in steps 1902, 1907, 1910, 1913, 1926, and 1927, a hash value can be passed between the card issuer 1904 and the back end server 1903, without the need for the card issuer 1904 to create a Unique identifier and pass it through your system.

In more detail, the example in Figure 19 works as follows. When a customer asks a card issuer 1904 to design a custom card 1901, the card issuer 1904 creates a hash value of a unique part of the customer record 1902 and passes the hash value 1926 to the back end server 1903. Once the customer designs the card 1906, the user and the corresponding hash value are returned 1907 to the card issuer, and the back end server saves the client image and the hash value 1925. The information that the customer has requested a new card is then sent 1908 to the card issuer's systems; and a customer record is stored 1909 in the card issuer's systems. The card issuer then recreates 1910 the hash value that is based on the unique part of the customer's record, and passes it 1927 to the back end server 1903, to notify you that the new card can be created and embossed. The rear end server 1903 and / or the card issuer 1904 can then perform an image verification procedure 1911 and 1912, to ensure that the image designed by the customer is acceptable for production. If the image fails the image verification of the back end server 1911, the hash value and the reason for rejection of the image are then sent to the card issuer 1913; and the customer 1914 is invited to redesign the card. Once the image has been accepted, the card issuer converts 1915 the customer record into an embossed record, which is sent 1916 to the 1905 office that will create the card. The back end server labels image 1917 to be sent to the 1905 office in the next batch of images; and when an adequate number of images has been prepared, it sends 1918 the image and the hash value associated with the 1905 office. The 1905 office then keeps the embossed record of the customer, obtained from the card issuer 1904; and it also saves 1920 the hash value and the image, obtained from the back end server 1903. Once this is done, the 1905 office can now create the finished card, first obtaining 1921 the customer record provided by the card issuer 1904; and also using 1922 the hash value to obtain the associated customer image and provide it to a blank card printer. The blank card printer can then print the image on blank cards in 1923, and encode the magnetic stripe of the card. Based on information present in the magnetic stripe, the embossed record and the printed card can then be joined together in 1924 to create a finished card.

In an alternative to the embodiment of Figures 18 and 19, which uses a unique identifier and a hash value, respectively, other methods of creating a secure user identifier can be used. For example, it is also possible for user information to be encrypted by the card issuer at the beginning of the process, and decrypted in the card office using a Private / Public key or a Private / Private key encryption technology. This alternative operates similarly to the process described in Figure 19, but with modified security measures; For example, the card office must keep the key.

In another embodiment according to the invention, a secure identifier of the image that is produced based on the instructions of the user, can be embedded in the image itself, or embedded as part of the data file in which the image is saved. For example, a hash key, encrypted identifier, or other secure identifier can be passed through the back end server (such as server 1803 or 1903) in association with the user's image manipulation instructions. At any point in the process of the back end server, such as when the image is produced to be sent to a card office (such as the card office 1905), the image can then be made to have the secure identifier embedded in it. , for example, by embedding a barcode or other machine-readable code, which encodes the secure identifier, placed in the image itself. In this way, the card office 1905 can read the barcode, or other embedded secure identifier, directly from the image itself; and you do not have to acquire any information from the back end server 1903 except the image itself, which includes the barcode. This embodiment has special use in the case where the card production process of the 1905 office involves using an image printer, which is not able to store separately or pass the secure identifier. Thus, using the embedded secure identifier, the image printer can effectively pass the secure identifier as well as the image to the relief stage, simply by passing the printed image itself, which will include the barcode (or other machine-readable identifier embedded ). The embossing stage may then involve reading the barcode (or other machine-readable identifier) of the image, and searching for the associated embossed record for use in the final production of the card. It should be noted that the image printing function of the 1905 office does not have to be performed within a single organization or company; for example, image printing can be carried out, instead, by a company or department separate from the organization that performs embossing, according to an embodiment of the invention. It will be appreciated that several different techniques can be used to embed the secure identifier in the image, such as including the identifier in the image file metadata; including both when the image file is transmitted to the 1905 office or when the image file is used by the back end server or the office.

In another embodiment according to the invention, represented in Figure 20, a modified architecture can be used, in the context of a card issuing kiosk or "instant issuance" system in store. As with the embodiments described above, the front-end software runs in a client-side browser; and the back end software runs on a remote web server. However, unlike the previous embodiments, the card printer is located on the customer's machine (such as a card issuing kiosk). With reference to Figure 20, a user browser housed in a 2002 store kiosk uses the front-end software, provided by a 2001 Internet server, so that the customer can design a personalized card. Then the user's image preference is saved and the image is generated 2003 on the remote web server. The image can then be returned to the 2004 kiosk, and printed on the 2005 client card. The images can be verified on the side of the remote server, to ensure they are suitable for printing, in real time, if necessary. Otherwise, the operation of the system may be similar to the embodiments described above.

In another embodiment according to the invention, depicted in Figure 21, a database can be used to store information between the user's image selections, and the production of rear-end images. In this way, the system can be made more scalable, since you don't have to create the images at the rear end in real time. As with the other embodiments, the user first makes image selections in the front end interface software, and the image manipulations are passed to the rear end server 2101. Then, however, each user manipulation is saved on a base. of data 2102; so that the back end software can take every manipulation, not in real time, and make the 2103 high resolution image.

In another embodiment, the manipulations performed by the user are related to the images maintained locally, for example, on the client's hard disk drive 806. An image file can be loaded into the client's hard disk drive 806 by means from a local input / output medium or through the network.

The browser-based software allows the client to select a local image, for example from hard disk 806, and perform manipulations to be applied to the image in the same manner as described above for remote images. The procedures for defining manipulations and the types of manipulation available are the same as those defined above for remote images. The data defining the or each manipulation applied to the local image is stored in the form of a user manipulation chain 818. Both the user manipulation chain 818 and the image file reside locally, for example on the client's computer, until they are transferred after the user has defined the manipulations, to the image compilation server 808, where the user manipulation chain is interpreted and the user-defined manipulations can be applied to the image. The manipulation chain can be transferred as a single chain or as several parts, likewise each part of the manipulation chain can be transferred with

or without the image file.

In this specification, the term "user-defined image" must be interpreted broadly including any image, images or graphics, which have been selected or from which an element has been defined by a user / cardholder. Such user-defined images can originate for example (i) in the client (perhaps in a collection of personal photos), (ii) with a brand or merchandising company, (iii) on the Internet, (iv) with a card issuer, (v) a card manufacturer, (vi) a card graphics hosting center, (vii) or any other source. The image can be "user defined" because it has been (a) selected, (b) generated, (c) modified or manipulated in some way by the customer, or perhaps (d) a combination of two or more of ( a), (b) or (c).

Although the foregoing describes what is considered to be the best mode and, where appropriate, other ways of carrying out the invention, the invention should not be limited to the specific configurations of apparatus or steps of the method described in this description of the preferred embodiment. . Those skilled in the art will also recognize that the invention has a wide range of applications, and that the embodiments admit a wide range of modifications without departing from the scope of the claims.

Claims (31)

1. A method to produce a transaction card corresponding to an account of a customer and that carries an image defined by said customer, including the method: associate an optically readable identifier with a user-defined image to apply to the transaction card; read said optically readable identifier and reconcile said optically readable identifier with a corresponding identifier (405) associated with customer account information (407, 604) to be applied to the transaction card; where said customer account information (407, 604) is provided by a card issuing authority (401, 603) by a secure link to a card finishing center (403, 606) and where only said customer account information (407, 604) is transferred from said card issuing authority (401, 603) to said card finishing center (403, 606); Y produce a transaction card that carries said user-defined image and said customer account information (407, 604).

2.

 A method according to claim 1, wherein the step of reconciling said optically readable identifier with said corresponding identifier (405) associated with said customer account information (407, 604) includes deriving said corresponding identifier (405) from said account account information. customer (407, 604).

3.

 A method according to any preceding claim, wherein said customer account information (407, 604) and / or said corresponding identifier (405) related thereto are securely received from said card issuing authority (401, 603).

Four.

 A method according to claim 1, 2 or 3, wherein, after the step of reading said optically readable identifier, a version of the optically readable identifier is encoded on a recording medium on the transaction card.

5.

 A method according to claim 4, wherein said coded version of the identifier is read as part of the reconciliation process with said corresponding identifier (405) associated with said customer account information (407, 604).

6.

 A method according to any preceding claim, wherein said customer account information (407, 604) includes a relief record for a financial transaction card.

7.

 A method according to any of claims 4-6, wherein the step of encoding a transaction card with a version of the identifier is carried out at a card manufacturer's site (607).

8.

 A method according to any of claims 4-6, wherein the step of encoding a transaction card with a version of the identifier is carried out at a site of a card finishing center (403, 606) separated from the site of a manufacturer of cards (607).

9.

 A method according to any preceding claim, wherein said corresponding identifier (405) is derived from financial account information.

10.

 A method according to any preceding claim, wherein said corresponding identifier (405) is derived from a relief record.

eleven.

 A method according to any preceding claim, wherein an encryption module (402, 601) at a site controlled by said card issuer generates a secure identifier from account information.

12. A method according to claim 11, wherein said optically readable identifier and said corresponding identifier (405) correspond to or are derived from said secure identifier.

13.

 A method according to any preceding claim, wherein an identifier includes one or more of: a numerical code; an alphanumeric code; a text code; a non-sequential code; a unidirectional code; an encrypted code; a hash code; meta tags; Another suitable identifier.

14.

 A method according to any preceding claim, wherein said optically readable identifier includes one or more of a barcode; a digital signature; text; numbers; alphanumeric code; microdot; micro text; Invisible Ink; digital filigree or other suitable optically readable codes.

fifteen.

 A method according to any preceding claim, wherein said image and said optically readable identifier is stored in a storage center.

16.

 A method according to any preceding claim, wherein cards with optically readable identifiers are transferred from the card manufacturer's control (607) to a card finishing center (403, 606).

17.

 A method according to any preceding claim, wherein one or more of the user-defined image and the optically readable identifier is placed on the front of a card.

18.

 A method according to any preceding claim, wherein one or more of the user-defined image and the optically readable identifier is placed on the back of a card.

19.

 A method according to any preceding claim, wherein the customer has selected said user-defined image.

twenty.

 A method according to claim 19, wherein a customer selects an image from a collection of available images.

twenty-one.

 A method according to any preceding claim, wherein said user-defined image is uploaded by a client via the Internet.

22

 A method according to any preceding claim, wherein said optically readable identifier is placed on said transaction card in a position that is subsequently covered with another element of the card.

2. 3.

 A method according to claim 22, wherein the element is selected from one or more of: a chip; a hologram; or a brand element.

24.

 A method according to any preceding claim, wherein the identifiers for authorized issuance cards are received by a card graphics hosting service of an authorized card issuer such that only user-defined images destined for authorized issuance cards are provided for further processing.

25.

 A method according to any preceding claim, wherein said user-defined image can be manipulated in relation to a template that has one or more non-manipulable card elements.

26.

 A method according to any preceding claim, wherein said optically readable identifier is applied to a portion of a card that is removed to generate a finished card.

27.

 A method according to any preceding claim, wherein an optically readable identifier is applied to a card in more than one format.

28.

 A method according to any preceding claim, wherein said card finishing center (403, 606) makes user-defined images its

ministered from an image storage base to the reconciliation of identifiers.

29.

 A method according to claim 1, wherein said step of producing the transaction card bearing said user-defined image and said customer account information (407, 604) includes producing a sheet of transaction cards, carrying each transaction card a different user-defined image and customer account information.

30

 A method to produce a transaction card that carries account information and a user-defined image, including the method:

receive in a secure link from a card issuing authority (401, 603) a unique identifier derived from customer account information (407, 604); where only said customer account information (407, 604) is transferred from said card issuing authority (401, 603) to a card finishing center (403, 606) on said secure link; embed an optically readable version of said unique identifier in an image defined by said client; read said optically readable identifier and encode a version of the unique identifier in a registration means of said transaction card; receive said account information at a card production center and independently generate a corresponding identifier (405) from it; apply relevant account information and said customer-defined image to a transaction card based on the reconciliation of said corresponding identifier (405) and said coded version of the unique identifier. 31. A method according to any preceding claim, wherein said optically readable identifier is embedded in said user-defined image.