WO2006018624A1

WO2006018624A1 - A card customization system

Info

Publication number: WO2006018624A1
Application number: PCT/GB2005/003198
Authority: WO
Inventors: Adam Elgar; Tom Elgar; Nicholas Stammers
Original assignee: Serveside Group Limited
Priority date: 2004-08-17
Filing date: 2005-08-17
Publication date: 2006-02-23

Abstract

The present invention relates to the enabling of a user to make an application for a transaction card to be approved by a card issuer. The user is able to connect to a service. Provider in order to design an image to be displayed on the transaction card, and wherein a unique identifier corresponding to the designed image is generated. Also, an application form having the unique identifier is generated.

Description

A CARD CUSTOMIZATION SYSTEM

Field

The present invention relates to the production of personalized cards and specifically, but not exclusively, for customising the images on a transaction card.

Background

There has been an increasing consumer desire for self- differentiation, particularly for differentiating mass-marketed personal items. This can be clearly seen in the recent popularity of customized mobile phone ring-tones and fascias. Indeed users of a particular mobile phone operator are able to download ringtones and occasional software updates, which might change the appearance of the display on a mobile phone. The internet has thus become a useful tool for users seeking to update their current products.

Typically in the past, financial transaction cards, such as credit cards have remained un-personalised in appearance; perhaps due to anticipated difficulties in allowing a user to personalize the appearance of an item such as a credit card while also maintaining the overall security for the user's private financial information.

Developers of systems capable of applying personalized images to financial transaction cards of users consider it a high priority to provide secure technical means for providing information capable of associating user identities and / or account information with their personalized image. Such secure technical means are regarded as a pre-requisite and allow relevant information to pass from the card personalization service, i.e. the ASP (Application Solution Provider) , directly to the card issuer / production facility within integrated systems thereof (i.e. without compromising sensitive information relating to the user) .

Such integrated systems effect the ability of card issuers to deliver web-based card design software to their clients, because the integration with the Application Solution Provider (Serverside Graphics) is too expensive, resource dependent and time consuming. For example, there are many financial institutions that do not have the size or money to make the purchase of such integrated systems feasible, but who still wish to allow user the capability of customizing their images while allowing the user to make a secure application for a credit card.

An aim of preferred embodiments of the present invention is to alleviate such issues and negate the necessity to set up complex and expensive integrations between the Issuer and the Application Solution Provider (ASP) .

An advantage of doing this is that it will be possible to serve smaller card issuers and thereby broaden the applicability of the product.

Summary

According to one aspect of the present invention there is provided a method of enabling a user to make an application for a transaction card to be approved by a card issuer, the method comprising: connecting the user to a service provider arranged to enable the user to design an image to be displayed on the transaction card; generating a unique identifier corresponding to the designed image; and generating an application form having the unique identifier.

According to another aspect of the present invention there is provided a method of enabling a user to make an application for a transaction card, the method comprising: connecting the user to a service provider capable of providing a service for enabling the user to "design" an image to be displayed on the transaction card; generating a unique identifier in the service provider corresponding to the user image; and generating an application form in the service provider having the unique identifier.

According to another aspect of the present invention there is provided a method of production of a personalized financial transaction card comprising: generating a unique identifier; recording a first version of the unique identifier in an application document, said application document processable by a card issuer to determine whether or not to issue a card to the user; allow the user access to a card personalization process; this process generating an image suitable for application on to a financial card; associating a second version of the unique identifier with this image most commonly through a login process before or after the image design process,- processing the application document to determine a financial transaction card can be issued to the user,- comparing the version of the unique identifier from the application document with the version of the identifier associated with the image to ensure a card is produced with the image and financial information relevant to the user.

According to another aspect of the present invention there is provided a method of production of a personalized financial transaction card comprising: recording a first version of the unique identifier where this identifier is already known to the Issuer (such as Account Number and Sort Code or an Email address) in an application document, said application document processable by a card issuer to determine whether or not to issue a card to the user; allow the user access to a card personalization process,- this process generating an image suitable for application on to a financial card,- associating a second version of the unique identifier with this image most commonly through a login process before or after the image design process; processing the application document to determine a financial transaction card can be issued to the user; comparing the version of the unique identifier from the application document with the version of the identifier associated with the image to ensure a card is produced with the image and financial information relevant to the user.

According to another aspect of the invention there is provided a method of checking the unique identifier for validity using a Check Sum of that data which may be added to the login process on the service providers website,- where this check sum is used to validate the other data entered using a predetermined algorithm known to the issuer and to the service provider.

According to another aspect of the present invention there is provided a method of personalizing a financial transaction card by means of an internet service provider, comprising: causing the service provider to generate a unique identifier; recording a version of the unique identifier on an application document of the sort processed by card issuers to determine whether or not a financial transaction card should be issued to a user; allowing the application document to be processed by a card issuer,- providing the user access to image personalization software capable of producing a personalized image associated with a further version of the unique identifier; sending the image to a card production facility.

According to another aspect of the present invention there is provided an internet service enabling a user to design an image for a transaction card, the service provider comprising: a design application capable of enabling the user to design the image for display on the transaction card; and generation apparatus capable of generating a unique identifier corresponding to the designed image and of generating an application form having the unique identifier.

-A- According to another aspect of the present invention there is provided method for manufacturing a card bearing an image designed by a user, the method comprising: generating a unique identifier to be associated with the image; and generating an application form for the card, which is capable of associating the unique identifier with a record of the user.

List of Drawings

Reference will now be made by way of example to the accompanying drawings, Embodiments of the present invention will now be described in relation to the accompanying drawings,

Figure 1 shows a context for which a preferred embodiment of the present invention is implemented;

Figure 2 shows a screen of website software with a standard library of images;

Figure 3 shows a login screen allowing users to login to the website;

Figure 4 shows the capability to browse a user's own computer for images; Figure 5 shows a new library including both the user's images and a set of stock images;

Figure 6 shows selecting a thumbnail image and manipulating the enlarged loaded image;

Figure 7 shows the addition of frames for the image; Figure 8 shows the ability to return to a previous screen where the image and the frame can be seen;

Figure 9 shows the final version of the credit card as customized by the user;

Figure 10 shows an alternative embodiment where a UID is generated by the card issuer;

Figure 11 shows the preferred embodiment where a UID is generated by the ASP;

Figure 12 shows a web-based embodiment; Figure 13 shows a branch-based embodiment; Figure 14 shows an embodiment where the application form is supplied by the card issuer through the ASP to the user;

Figure 15 shows an embodiment where the card issuer forwards a list of UID' s previously generated to the ASP. Figure 16 shows a flow diagram of various modules for implementing a web-based embodiment; and

Figure 17 shows a flow diagram of various modules for implementing a branch-based embodiment.

Description

Figure 1 shows a simple example of an embodiment of the invention which can be carried out across the internet represented by the cloud 2. The internet or World Wide Web is incredibly powerful in being able to connect and disseminate data to may different computers that are linked throughout the world. A plurality of users 4 are shown which have the capability of connecting to the internet; for example using a computer, modem and the relevant software.

The users are able to access the websites of a plurality of card issuers 6, for example financial institutions or banks. The concept of online banking has already become widespread, where access to a user's private account details can be accessed by an approved login process.

An Application Service Provider (also "Service Provider") ASP 8 is also shown, which for example, may be a website server owned and operated by a third party which is capable of providing specific services to the users 4 and/or card issuers 6. According to one embodiment of the present invention, the ASP 8 provides a design application 10 which allows a user to customize and/or design the images on a transaction card, for example a credit card. In a preferred embodiment, the design application 10 is for example a computer program run on a dedicated server which allows the design and editing functionality required by the user to customize an image for a credit card. It should be appreciated that the design application can be located either within the ASP itself or accessed from a remote location (i.e. a remote server or website) .

Several screen-shots revealing how such a credit card design website might operate in a series of steps as shown in Figures 2 to 9. Figure 2 shows a first screen with a standard library of images assigned to the particular card issuer that is using the credit card design website, on the left of the screen. Figure 3 shows a screen allowing users to log in so that a username and password (and/or other information such as account number and sort code or email address or a coded unique identifier - UID) can be used to identify the user and the card they design. In Figure 4, the upload allows the user to browse his or her own computer for images to upload. Figure 5 shows a screen with a new library including both the user's images and a set of stock images. In the screen of Figure 6, by clicking on the thumbnail image on the left hand side, the bigger but still web-optimized image is loaded. At this point it can be scaled, flipped, rotated, or undergo other manipulations; and the card details can be viewed or hidden. In the screen of Figure I₁ frames can then be added. These are for example Flash (.swf) files that allow transparencies. Again they can be flipped, scaled, rotated, or undergo other manipulations; and the card details can be hidden. In the screen of Figure 8, by clicking a button or on the Step 1 tab, the user can return to a previous screen. At this point the image is shown as "live" but the frame can be seen as well. The screen of Figure 9 shows the final version of the personalized credit card before it is sent off to the back end software to be manufactured. In certain systems such as that disclosed in PCT/GB2004/000626, a unique identifier (UID) is issued by a card issuer and used by the to ensure each card produced bears the image and personal information of the relevant user. The UID is retained by the card issuer and associates or links a user to his/her personal account details.

This technique a number of problems. First, the cost of integrating the systems to pass over the UID in real time with the user and, the system changes required to enable the storage of the UID, has substantial cost. Second, the user must return to the card issuers website to get a new UID if the initial one is lost (by a network failure or session timeout for example) . Third, there is very often not a shared database between the website and the mainframe / embossing elements of the Issuers IT systems.

In a preferred embodiment according to this invention the UID for the images that are produced by the design software 10 are created by the ASP 8. This avoids the costly implementation costs. This UID is used to associate a user (or user account information) with their personalized and/or customized image. It is a feature of preferred embodiments that the ASP design software 10 generates and issues a UID associating each image to the relevant user, and sends this UID in one form or another to the relevant user. From this point forward the design/image is always associated with the user by this identifier. In another embodiment, the UID could be assigned to the user later in the "web experience" if their information was held as a Session Variable before this point but this would not substantially change the process.

It should be noted that the UID can be expressed in many different ways. For example, the UID may be numerical, alpha¬ numeric or coded in some other machine-readable form, for example a barcode. Irrespective of where it is generated, a UID may be embedded in an application form for a transaction card or a similar document. Such an application form may be provided by the card issuer and/or the ASP, as will be explained below. Alternatively, or in addition, the UID may be embedded within the image itself, and the image applied to the application document, wherein decode circuitry is able to recover the UID from the image. The association of the UID with the application form ensures that, after the form has been completed and returned for processing by the card issuer, the cards generated for the user in question bears the relevant personal account information and that users personalized image. In fact, the association with the application form enables the card manufacturing process to source individual personalized images prepared by users (usually in groups of images) for application to cards which will also bear the relevant individual account information.

Indeed, PCT/GB04/003537 from which the present application claims priority, describes a system where a credit card embossed with the image (s) designed by a user, and having a UID embedded therein, can be read without explicit indication of the user. Thus there is still security in that a card issuer may entrust the card-making facilities to a trusted card manufacturer by providing them with the relevant decode circuitry (and/or including the relevant decode algorithms) to be able to recover the UID from the image to be printed on each card. Figure 10 shows an example of this.

Figure 10 shows an embodiment where the UID is generated by the card issuer, as opposed to preferred embodiments of the invention where the UID as generated by the ASP, but it is still useful in illustrating aspects of the present invention. Specifically, the card issuer might have in-house card manufacturing facilities or instead make use of a remote trusted card manufacturer 11 (further shown in Figure 1) .

Figure 10 shows such a system, including a card manufacturer having facilities 311 and 313, a card issuer 301 and an ASP 303. It should be appreciated that the facilities 311 and 313 may be owned and operated by the same or different parties either on site or in remote locations. Moreover, many of the features shown in Figure 10 as being associated with the card manufacturer might be associated with one of the other institutions. For example, the read/write module 318 is an example of decode circuitry which is able to read the OID (Optical Identifier) , recover the UID embedded in the image, and/or write the recovered UID into the cards magnetic strip, thereby making the UID of each card magnetically readable by a card finishing machine 319.

In figure 10 a card issuer 301 passes a UID 302, for each cardholder who will be personalizing their card's appearance, to a card graphics hosting facility 303.

The card graphics hosting facility 303 associates 306 each cardholder's digital identifier with the cardholder's completed card design digital image, and stores them in a card graphics warehouse module 308 which may be a near-line image storage facility. In one embodiment, the card graphics hosting facility 303 associates 306 the UID with its corresponding image by converting the digital identifier into an optical format, using, for example, a barcode, text, microdot, microtext, invisible ink, or other technique; and embedding the optical-format identifier (OID) as part of the digital image to be applied to the card; for example by printing the OID into the image itself. The OID may also be printed in two or more different optical formats, or multiple times in the same format, so that it can be read in the event of a mis-scan. The card graphics warehouse 308 passes the digital images with embedded OID' s 312 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 facility, designed to optimize images for the associated printer. Because the UID's have been embedded optically in the digital images, only the images 312 need to be passed to the card manufacturer 313, without a need for the UID's to be transmitted separately. The digital image with embedded optical OID 315 can then be passed to a digital printer 316, which simply prints all of the cards whose images are passed to it by the print server 314. The digital printer 316 may be a machine that is Pantone-compliant and prints at over 800 dpi; that can lay down logos, brand marks, OID's, and card designs in a single process, both rapidly and economically.

Next, the printed card 317 with embedded OID in its printed image is passed to a read/write module 318, which reads the OID of each card and encodes it into the card's magnetic stripe, thereby making the UID of each card magnetically readable by a card finishing machine 319. The cards with magnetic UID's 320 are shipped through the conventional channels from the card manufacturer 313 to the card finishing facility 311. A card finishing machine 319 (such as a Datacard 9000 or other machine) , can then read each card' s magnetic UID and use it to associate the correct image-printed card with the associated cardholder's financial information, as provided over link 310. A finished card 321 can then be produced, which has a user's financial information as well as a personalized appearance.

There are a number of advantages to the embodiment of Figure 10. First, because the UID' s are optically embedded in the digital images 312, there is no need to send the UID's separately to the card manufacturer 313. This means that only one file type (the digital image file type) needs to be passed to the card manufacturer 313, in one direction; thus, the dedicated line for transmitting data 312 can be easily locked down in a firewall. In addition, the process of Figure 10 makes it easier for a card issuer 301 to request that a card be re-issued; the card issuer 301 simply sends the UID of the card to be re-issued in the same list 307 of digital identifiers that is sent 309 to the card finishing facility 311.

Figure 11 shows a basic diagram of a preferred embodiment of the present invention. One of the differences over the embodiment of Figure 10, is that in the preferred embodiment, the UID is generated in the ASP and not by the card issuer. Figure 10 has been simplified in several respects but Figure 10 remains useful in describing the functionality that can still be used in the preferred embodiments.

Specifically, the functionality of the card graphics hosting facility 303 of Figure 10 is similar to the ASP 8 of the preferred embodiment shown in Figure 11 in that both allows a user to customize the design or images of a credit card over the internet.

However, whereas Figure 10 shows different functionality representing the card manufacturer 313 and the card finishing facility 311, such card processing functionality is not shown in Figure 11. Indeed it may be assumed that such processing functionality is performed by the card issuer 6 themselves. It should be appreciated that an alternative embodiments, such processing functionality can be assigned to third parties, which are trusted yet distinct from the card issuer.

Such simplifications make it useful in emphasizing that in the preferred embodiment of Figure 11, the UID is generated within the ASP and provided back to the user along line 102 after the design has been established via line 100. The UID is preferably provided as part of or embedded in a document provided to the user along line 102. Typically, the document is an application form for a personal transaction card, such as a financial transaction card or a loyalty card, or the like.

Specifically, Figure 11 shows a user 4 which is able to communicate separately with an ASP 8 and a card issuer 6. The user 4 is able to visit the website of the ASP 6 and customize the image (s) of a credit card online. In creating/modifying an image, a UID is automatically generated by the ASP and is associated with that image. A document is then created which includes the generated UID and is sent back to the user.

This document may be in paper or electronic form. The document can for example be an application form for a new credit card with a particular bank.

Figure 12 shows a web-based embodiment where the credit card application form is in an electronic form and can be received, completed and sent by the user 4 to the card issuer in electronic form.

Figure 13 shows a branch-based embodiment where the credit card application form is in a paper form. In this embodiment, this application form has a "bangtail" component which can be detached as will be explained in more detail below. The generated application form can be provided by a bank for collection by a user and completion or alternatively, the generated application form can be sent directly to the user who can submit the completed application form to the bank.

In another embodiment, the application form can be transferred to a processor or production center of a card issuer. For example, the card issuer will receive the application form and process it within its systems, using the embedded UID to match the user's financial account information with the relevant personalized/customized image. A database or table can exist within the card issuer system which contains cross-reference information relating each UID with the user's corresponding private account.

Preferably the embedded UID is machine read as part of a card production process and a computer performs the matching to produce a card with a given user's personalized / customized image and relevant account details. However, the UID may also be embedded as an OID, in which case the production centre

(processor) of a card issue will need to have a read/write device of a similar nature to the one shown in Figure 10 for recovering the UID from the read OID.

The process may begin with a user arriving at a branded URL (such as http://issuer.asp.com) . This URL will allow the ASP to select the correct branding for the look and feel of the site and for the financial card templates that the user will see. Thus a number of card issuer websites for a number of distinct card issuers can be hosted using a single web interface. By assigning specified default criteria to the URL forwarding process or by other parameter setting means the webserver is able to differentiate between the different card issuers and thereby assign their various branding, template and application form elements. In this way, the ASP is able to provide an interface capable of supporting a plurality of card design websites corresponding to a variety of different card issuers. Thus the user is able to select which URL to access (i.e. website hosted by the ASP corresponding to a particular card issuer) .

The application form will be selected from a number of such forms based on the URL (or other identifier) that the user enters through. Thus a number of application forms for a number of card issuers can be hosted using a single web interface. Alternatively, the ASP may have a single URL which the user is able to log onto and from those login details, the ASP is able to redirect the user to the corresponding application form (or URL bearing that application form) which is associated with the relevant card issuer. In both cases, the application forms are hosted by the ASP on behalf of the card issuer, but are separated from the card issuer and/or the website of the card issuer.

The user is now able to design their card using the online card design software and utilizing a number of tools such as image galleries, a variety of different card templates (different fixed elements to the card) , and a variety of different frames or different designer types. Designer types may include the ability to move, size, rotate and flip images and /or logos and /or they may allow the addition of text on to the card for example as shown by the screenshots of Figures 2 to 9 described above. Various other functions associated with the ASP are for example shown in relation to steps 2a and 2b in the embodiments of Figure 14 and Figure 15 respectively, which will be discussed in more detail later.

After the issuer has finished their design, the next step in the process is to output a UID from the ASP, which is associated with a particular user, which is in turn associated with the image that has just been designed by that user. A data table is held in a location accessible to the ASP (i.e. either within or remote from the ASP) so as to associate the user with their image by way of the UID.

The next step in the process is that the ASP is able to generate the relevant application form with the UID embedded into it, which can then be presented to the user 4. This application form might be sent and presented electronically to the user as an MS Word document or an Adobe Acrobat (PDF) document for example. The user is able to compete the form electronically and submit it to the relevant card issuer 6 electronically, for example using the web-based form shown in Figure 12. In the embodiment of Figure 12, the application form comprises a UID which in this case is simply a humanly-readable alpha-numeric sequence 120. The application form can also comprise for example an attached picture of the design 122 of the credit card created by the user. Thus, the application form may or may not include a copy of the image that has been generated. The image may be included as a marketing tool. The user is also able to complete the form by filling in his personal details 124.

It should be appreciated that in another embodiment, for security reasons, the personal details 124 might be left off the form (in which case the ASP would need to contact the card issuer separately to provide the generated UID associated with each user's design) . In this way, the card issuer is then able to match up the received UID with the relevant user's account details.

In different embodiments, the UID may be embedded as either text, barcode, machine-readable or humanly-readable form.

Alternatively, the user can print-out paper copies of the application form, which was received in electronic form. The user 4 then completes the form and can then either post it or take it to the relevant card issuer (or bank branch) directly. Thus, the user at this stage may print the application form and complete it.

In another embodiment, the form may be provided to the user as a hard copy. Thus, the ASP 8 can send the application form to the user, to an email address, to a card issuer branch, or to some other remote location for completion at a later date. For example, the form can be emailed from the ASP to a branch of a card issue who can then print-it off in hard copy and wait for the relevant user to come into the branch requesting the application form or it can be sent to the user in the post.

Thus, the user is able to fill in the application form and either send the application form into a form processing centre of the card issuer by post (or another suitable transmission means) or physically to go to an card issuer's branch themselves. The transfer of the application form from the user 4 to the card issuer 6 may in some embodiments be completely electronic and/or automated.

In one embodiment the system may incorporate a technology, for example one developed by Adobe systems that allows the user to enter details in an electronic environment (on PDF software for example) and for a barcode to be generated within the same document that reflects the information input. Thus when the information is input and printed (including the UID) the application details and UID can be scanned using a barcode reader by the card issuer 6 to obtain all of the information in the form - thus avoiding the cost and errors associated with data re-entry.

In another embodiment of the invention, the user 4 is forwarded after the design process, to the card issuer's website (with the associated UID also being passed) and wherein the user is subsequently able to fill in a form either online or offline.'

However, this embodiment is more costly as there is at least some integration cost for the card issuer 6 and the ASP 8. This allows for a similar process as that if the form is hosted by the ASP. However, the advantage of this embodiment is that it allows the card issuer 6 to integrate the card design process with their standard on-line card application or card management system.

In a preferred embodiment of this method the user would be transferred to the card issuers website by means of a hyperlink, for example in HTML (Hyper Text Markup Language) , with the UID stored in the URL. To avoid security breaches this URL would be encrypted by means of a digital signature which may include a timestamp.

Figure 14 shows such an embodiment where the application form is supplied 142 by the card issuer 6 through the ASP to the user 4. The UID is either embedded in the application form or passed along with it, for example with the UID stored in the URL.

At step S4, the user fills in the application form and then may return it to the card issuer 6 electronically, or can print off the application form in hard copy and return it by post or directly depositing it at the relevant branch of the card issuer 6. By allowing the user to print-off the application and deliver it offline, it is possible to overcome the aforementioned disadvantages associated with a fully integrated system, while still retaining security in having an embedded UID in the application form.

At step S5, the card issuer 6 processes the application form in its standard manner but additionally sends the UID with the embossing records to the processor 140 at step S6. This UID may be included in the embossing record or sent as a cross-reference table or the like.

Once the processor 140 receives the embossing record at step S7, it can request the image from the ASP 8 at step S8. This process could be done in advance of receiving the embossing record but would be less efficient as many images would remain unused. The image and the embossing record, which both contains forms of the UID, can then be associated and printed using standard industry printing and embossing systems such as those provided by Datacard and explained in relation to the Figure 10 embodiment. A further embodiment is for the ASP to email the user at the step S3 of image checking to see if the card designed by the user is rejected. This will allow the user to re-enter the site (using the original UID or a new one) to redesign the card.

If however the image has been rejected at the step S3 of image checking then the ASP will respond with a code to show why the image has been rejected and the user may be sent a standard card design by the Processor 140.

Another embodiment of the invention is shown in Figure 15 wherein the card issuer 6 may forward a list, or database, of UID' s previously generated by the card issuer to the ASP. The card issuer would hold this list in reference to the users financial account details. The ASP would hold only the list of UID's. In this embodiment the ASP would request that the user log in to the website as shown by step T4 using the UID, or information that will identify the UID, and thereby associate the user with a UID. The user would again be asked to design the card and then, at step T5, offered an application form to print out or forward as with the Figure 14 embodiment. The difference being that in the embodiment of Figure 15, the UID, once returned to the card issuer, could then be associated with existing account details. In this way the invention could be used to accommodate pre- existing accounts.

In a further embodiment the UID used in for example the branch example might be or be derived from the Account Number and Sort Code or an email address or other personal information that is already known to the issuer. In order to avoid the danger that a third party may enter another customers information it should be possible to use a shared security key that will for example run a hash on the information that will be given to the user in branch

(thereby ensuring that the information is secure) which the user can take away with them before logging in to the service providers site. This will ensure that: 1. the information is secure (it has been obtained from a bank representative); 2. that the issuer need not retain any new information as it is already- known to them (and may even be present in the embossing record) so few IT changes are required; 3. the information that is entered in to the website can be checked against the hash data to ensure that it is valid.

A further aspect of the invention is that, in order to avoid the mis-input of the UID' s by staff associated with the card issuer, in the preferred embodiment there would be a "self-verifying" element in the UID. In essence this will mean that the UID has an inherent checking capability that will check the integrity of the rest of the UID. For example, the check might be that the final digit of the UID is equal to the final digit of the sum of the rest of the UID. Thus, 1292 could be a UID where 2 is the carried over check on the rest of the ID (1+2+9 = 1 [2] ) . There are a number of well known algorithms to achieve this type of check process.

In a further embodiment the UID' s (or range of UID' s) are pre- generated by either the ASP or the card issuer and supplied to the other party. The card issuer will use these UID's to generate a set of paper-based application forms. These forms will be distributed through traditional paper-based means such as through the bank branch or other marketing processes. The forms will have two sections as shown in Figure 13 before. In the first section 136 there will be a normal application form with the UID embedded 134 - either as: a printed number (as shown in Figure 13), a barcode, or other machine-readable form (for example a digital or binary sequence) . The second section 130 will be a rip-off strip (a "bang-tail") that the user can take-off the main application form. The bang-tail 130 contains the UID of the main application form and, according to certain embodiments, also contains the website address of the ASP 8. At the point of application for the card, the user fills out section 136 and typically will leave it with the card issuer, for example with a clerk or agent in the branch, but retains bang- tail section 130. With section 130 the user is able to access the ASP website and use the UID printed on the bang-tail to log-in to ensure that the number on the application form and the image created can later be married up. The log-in process can occur before or after the card has been designed. By using different URL's and UID' s it is possible for the ASP to determine which card templates and branding information - such as stock images - should be shown to a particular user.

In an further embodiment the card issuer may generate the UID's and need not supply them to the ASP in which case a self- verifying UID would be a sensible option to select to ensure that the UID is valid.

In a further embodiment the card issuer generates UIDs, or requests UID's from the ASP, on an ad-hoc basis whenever an additional application form is requested.

Figure 16 provides a flow diagram showing examples of various modules that are able to implement the web-based embodiments associated with Figure 12.

Specifically, the card issuer 6 is shown to have the following modules: a card issuer website 160, a web-based campaign 161, a direct mail campaign 162, an application form delivery module 167, an application form processing module 168 and an image checking module 169. The processor functionality 140 is shown to comprise: a card bureau 170, a print module 171, and a card sending module 172. The ASP 8 is shown to comprise: a marketing page 163, an image design interface 164, a terms and conditions unit 165, and an application form module 166. Figure 16 shows that the website module 160 of the card issuer 6, which for example provides information on the various products provided by the card issuer, is interconnected to a web-based campaign module 161 and a direct mail campaign module 162. Both modules being associated with marketing such products to users, but wherein module 161 does so by using the web or email, whereas module 162 does so by using the standard postal service.

The ASP 8 is shown to step through a sequence of the modules 163, 164m 165 and 166. And each connection between the sequences provided over an SSL (Secure Socket Layer) in a preferred embodiment, which allows secure access to validated users. So initially, a user is able to access a marketing page provided by the ASP which can provide a cover page and a layout of the various service offered by the ASP. The user is then able to select the desired service, or for example, the relevant image design interface 164 which could for example provide the design software but presented with the specific branding or themes associated with the relevant card issuer (or bank) selected by the user. A terms and conditions module 165 is then able to set out the terms for using the ASP website and/or parameters associated with the card (i.e. requested credit limit) . Such terms and conditions can be enclosed in the application form which is generated by the application form module 166.

The application form module 166 also generates a UID and this is embedded in the generated application form along with a copy of the image (s) designed by the user for the card. The application form then being sent to the card issuer 6- shown as route A in Figure 16.

For route A, the application form is sent from the ASP 8 to module 167 of the card issuer 6, which indicates that the application can for example be sent: electronically (for example, over the web) , hand-delivered directly by walking into the branch or by normal post. The application form is then processed using the module 168 which might for example have a read/write device that is capable of retrieving the UID in the application form, particularly if embedded as an 0IR in the image itself. Module 168 sends the embossed records and recovered UID to the processor 140, specifically the card bureau module 170.

In route B, the image is sent from the ASP 6 to an image checking unit 169 (described earlier) which checks whether the image designed by the user for the card is suitable. If not, the user is able to re-enter the site using the existing UID associated with the image, or alternatively a new one required to redesign the card. The image checking unit is able to communicate with the card bureau module 170 of processor 140 using SSL and can request from the bureau module 170 if the designed image is supportable by the functionality of the processor 140 (for example, has the appropriate printing apparatus for printing the user's desired image) . If it is supportable, the image is sent to the card bureau module 170, whereas if it is not, a standard default image is sent to the card bureau module 170.

After receiving the design at the card bureau module it is sent to the print module 171 having the appropriate printing apparatus for printing and embossing the designed image (s) onto the card.

The card sending module 172 represents that the finished physical card is then sent to the user 4.

Figure 17 provides a flow diagram showing examples of various modules that are able to implement the branch-based embodiments associated with Figure 13.

Some of the modules are the same as referred to in Figure 16 and as such the same reference numerals are used. Figure 17 differs in that the user enters the branch which already contains an application form having an embedded UID shown by the modules 180 and 182 respectively.

In use, the completed application form - 182 - is processed by processing module 168, which for example might contain read/circuitry able to recover the embedded UID. The image corresponding with the UID can then be generated by the user - using the same UID as the service providers website 164 - to log in to the service provider 190. To do this the user tears off the bang-tail section 130 of the application form as shown in Figure 13 and is able to then separately access the ASP 8 in order to generate the relevant design to be used on the card. For example, the bang-tail section provides a certain URL "www.internationalbanking.com/photocard" which will take the user to the relevant login page or server hosting the design software for the relevant bank. The login process being indicated by the login module 190 may for example involve typing in the UID which is also printed on the bang-tail module. The user can than create the required image which is then checked by the image checking unit 169 to see if it is supported. If yes, the image is sent to the card bureau 170 of the processor 140, but if not, a standard image which is supported is sent to the card bureau 170.

The embossed record which might include client information, the image and the UID are then sent from the module 160 to the card bureau module 170 of the processor module 140.

Thereafter, the card is printed and sent to the user as explained in Figure 16.

There are a plurality of advantages that flow from embodiments of the present invention: 1) The embedding of a UID with in an application form that corresponds to the image that the user has designed, which allows for the advantage that the UID is passed in a non-technical manner from the service provider to the Issuer and therefore requires no technical integration of the two systems

2) The embedding of a version of the image within the application form has the advantage that the user is more likely to fill in the form as the form has personal resonance.

3) The generating of the UID to be assigned to the users image has the advantage that the Issuer and the Card Designer need not be technically linked.

4) The assignation of branding elements and application forms to a variety of different URL or website access points, which has the advantage that multiple issuers can be maintained on a simple site by only changing simple branding elements.

5) The hosting of a plurality of application forms associated with corresponding card issuer's on a website has the advantage that a single design interface can be used to apply to a plurality of card issuers.

6) The branch-based embodiment which makes use of a tear-off strip with a UID associated with the original application form to enable personalization to occur after the application and from a different geographic location if preferred. For example, one can take the bang-tail to an internet cafe to personalise the image. This means that the acquisition (of new card holder) benefits of personalization of financial cards is not missed on in-branch statements of interest in the cards. The user is signed up for the product first - and then given access to the site. 7) The embodiment wherein there is a URL link after the card design process which redirects the user back to the card issuer's

(or partner) website and passes the UID associated with the image, which has the advantage of allowing the partial integration of the design process into the standard online application processes of the bank.

8) By using previously known information to identify the user in the Branch based scenario the Issuer may be able to avoid any substantial changes to their present IT system as they will not need to i . integrate with the service provider or ii. Make changes to saving new information in their mainframes or iii. (Potentially even not) make changes to their embossing records.

Claims

CLAIMS :

1. A method of producing a personalized transaction card of the type approved for issue by a card issuer, the method comprising: connecting the user to a service provider arranged to enable the user to personalize an image to be displayed on the transaction card; generating a unique identifier corresponding to the personalized image; and generating an application form for processing by a card issuer and comprising the unique identifier.

2. The method according to claim 1, wherein the unique identifier is generated by the service provider.

3. A method according to claim 2, wherein the application form comprising the unique identifier is supplied to the user by the service provider.

4. The method of claim 1, wherein the application form comprising the unique identifier is supplied to the user by a card issuer or agent thereof, other than the service provider.

5. The method of claim 4, wherein the application form is supplied by the card issuer and further comprises a tear-off section which includes the unique identifier, or personal information from which the UID can be derived, and access data relating to the web site of the service provider, and wherein the user is able to detach the tear-off section and use the tear-off section to provide logon information at the web site of the service provider.

6. The method of any preceding claim, wherein the personalized image comprises one or more selected from: an image prepared by the user, an image edited by the user, an image selected by the user, a plurality of images, one or more of the aforementioned together with text.

7. The method of any preceding claim, wherein the unique identifier is in a humanly-readable form.

8. The method of any of claims 1 to 7, wherein the unique identifier is in a machine-readable form.

9. The method of any preceding claim, wherein the application form further comprises the personalized image.

10. The method of claim 9, wherein the unique identifier is embedded in the personalized image as an optically readable identifier.

11. The method of claim 10, wherein the card issuer is capable of receiving and decoding the optically readable identifier so as to recover the unique identifier

12. The method of any preceding claim wherein the application form is in a paper form.

13. The method of any of claims 1 to 11 wherein the application form is in an electronic form.

14. The method of any preceding claim, wherein the user is connected to the service provider over an internet connection.

15. The method of any preceding claim, wherein the service provider is a separate entity from the card issuer and provides a plurality of interfaces corresponding to different branding templates, each branding template being associated a different card issuer.

16. The method according to claim 1, wherein the unique identifier is generated in the service provider and wherein after personalizing the image, the user is able to be automatically redirected to the card issuer via the service provider for completing the application form online.

17. The method of any preceding claim, further comprising the card issuer: receiving the completed application form,- and either checking in a database whether the received unique identifier corresponds to a customer account for the user; or processing the application form; producing the transaction card with the personalized image applied to it and sending the transaction card to the user.

18. A method of enabling a user to make an application for a transaction card, the method comprising: connecting the user to a service provider capable of providing a service for enabling the user to determine a personalized an image to be displayed on the transaction card; generating a unique identifier in the service provider corresponding to the user image; and generating an application form in the service provider comprising the unique identifier.

19. The method according to claim 18, wherein the user receives and complete the application form separately from the card issuer and submit the completed application form to the card issuer.

20. A method of production of a personalized financial transaction card comprising: generating a unique identifier; recording a first version of the unique identifier in an application document, said application document processable by a card issuer to determine whether or not to issue a card to the user; associating a second version of the unique identifier with an image desired by the user to personalize the financial transaction card; processing the application document to determine a financial transaction card can be issued to the user; matching the version of the unique identifier from the application document with the version of the identifier associated with the image; and producing a financial transaction card bearing the personalized image and financial information relevant to the user.

21. A method of producing a personalized financial transaction card by means of an internet service provider, comprising: generating a unique identifier; recording a version of the unique identifier on an application document of the sort processed by card issuers to determine whether or not a financial transaction card should be issued to a user,- allowing the application document to be processed by a card issuer; providing the user access to image personalization software capable of producing a personalized image associated with a version of the unique identifier from the application document; and sending the image to a card production facility.

22. A method as in claim 21, wherein software of the internet service provider generates a financial a transaction card application document for completion by users, the application document comprising said version of the unique identifier.

23. A method as in claim 22, wherein the software of the internet service provider comprises a selection of financial transaction card application documents, each relating to a different card issuer, from which the user may select.

24. A method as in claims 22 or 23, wherein a version of the unique identifier is recorded on the or each financial transaction card application form selected by the user.

25. A method according to any preceding claim, wherein the unique identifier comprises or is derived from personal information relating to the user.

26. A method according to any preceding claim, wherein the unique identifier comprises or is derived from one or more selected from: account number; sort code; postal address; and email address.

27. A method according to any preceding claim, wherein the unique identifier comprises or is derived from information held by the card issuer before the transaction card is applied for.

28. A method according to claim 25, wherein the unique identifier is generated by the card issuer and the service provider verifies the unique identifier by re-determining it from the personal information used by the issuer to generate it.

29. A method according to any preceding claim, wherein the unique identifier is applied to the transaction card application form after the image is designed.

30. A method according to any preceding claim, wherein the unique identifier is applied to the transaction card application form before the image is designed.

31. A computer program of facilitating a method according to any preceding method claim.

32. A computer program according to claim 31, recorded on a carrier.

33. An internet service provider site enabling a user to design an image for a transaction card, the service provider comprising: a design application capable of enabling the user to design the image for display on the transaction card; and generation apparatus capable of generating a unique identifier corresponding to the designed image and of generating an application form comprising the unique identifier.

34. The service provider of claim 33 comprises a computer arranged to execute a computer program in response to instructions received from the user for designing the image.

35. A method for manufacturing a card bearing an image designed by a user, the method comprising: generating a unique identifier to be associated with the image; and generating an application form for the card, which is capable of associating the unique identifier with a record of the user.

36. The method of claim 35, wherein the step of generating a unique identifier is performed before the image is designed.

37. The method of claim 35, wherein a step of applying for a card is performed before the image is designed.

38. The method of claim 35, wherein the unique identifier is generated in a service provider in response to a request from the user which has logged onto the service provider, wherein the generated unique identifier will be associated with the image to be designed at a later time.

39. The method of claim 35, wherein the step of generating a unique identifier is done after the image is designed.

40. The method of claim 35, wherein the step of generating an application form capable of associating the unique identifier with a record of the user is performed after the image is designed.

41. The method of claim 35, wherein a step of applying for a card is performed after the image is designed.