AU2011313826B2

AU2011313826B2 - System and method of conducting transactions

Info

Publication number: AU2011313826B2
Application number: AU2011313826A
Authority: AU
Inventors: Ariel Bud
Original assignee: ECRED Pty Ltd
Current assignee: ECRED Pty Ltd
Priority date: 2010-10-08
Filing date: 2011-10-10
Publication date: 2015-10-08
Anticipated expiration: 2031-10-10
Also published as: WO2012045128A1; AU2011313826A1

Abstract

A computer implemented method, system and computer program product for providing an encrypted virtual card image file to a mobile computing device for decryption and display of a virtual card on the mobile computing device, the method including generating, on a computer processor, an encryption key for encrypting a virtual card image file, encrypting, on a computer processor, the virtual card image file using the encryption key, generating, on a computer processor, a URL identification string for at least partly identifying a publicly accessible location where the encrypted virtual card image file is to be stored, storing, on a computer readable medium at the publicly accessible location, the encrypted virtual card image file, receiving a request for the encrypted virtual card image file; and redirecting the request to the publicly accessible location.

Description

WO 20121045128 PCT/AU2011/001299 SYSTEM AND METHOD OF CONDUCTING TRANSACTIONS FIELD OF THE INVENTION This invention described herein relates generally to a method, system 5 and computer program product for sending an image file to a mobile computing device. In particular, the invention is directed to a method, system and computer program for sending a secure image file for display of a virtual card on the mobile computing device, although the scope of the invention is not necessarily limited thereto. 10 BACKGROUND OF THE INVENTION With the increased market penetration of smart phones and other mobile computing devices, an opportunity exists for individuals to carry virtual cards with them on their mobile devices. For companies and individuals to feel confident to use a Virtual Card System (VCS), the level of security 15 associated with these cards must be at least as strong as that available to current card systems. Of course, different card applications require different levels of security. These range from loyalty cards where little protection is required, to primary identification documents such as drivers' licenses or passports where 20 the maximum level of security possible is required. Within these two extremes reside other club membership cards, insurance cards, gift cards, debit and credit cards. SUMMARY OF THE INVENTION The present invention is broadly directed to securely providing a virtual 25 card image file for display on a mobile computing device. The invention provides a system, method and computer program product that securely sends and image file to display a virtual card on a mobile computing device. The virtual card, as displayed on the mobile computing device, may then be used in commerce such as commercial transactions, redemptions or 2 participation in a loyalty program, or for other identification purposes. According to a first aspect, there is provided a computer implemented method for providing an encrypted virtual card image file to a mobile computing device for decryption and display of the virtual card on the mobile 5 computing device, the method including: generating, on a computer processor, an encryption key for encrypting a virtual card image file; encrypting, on a computer processor, the virtual card image file using the encryption key; generating, on a computer processor, a URL identification string for at least partly identifying a publicly accessible location where the 10 encrypted virtual card image file is to be stored; storing, on a computer readable medium at the publicly accessible location, the encrypted virtual card image file; receiving a request for the encrypted virtual card image file; redirecting the request to the publicly accessible location; and deleting the encrypted virtual card image file, from the computer readable medium at the 15 publicly accessible location, after a predetermined time limit. According to an embodiment of the first aspect, the method further includes: generating, on a computer processor, the virtual card image file. Alternatively or additionally, the method includes: receiving, on a computer processor, the virtual card image file. 20 According to an embodiment of the first aspect, the encryption key is generated at least partly from one or more mobile computing device user identifiers. A decryption key, for decrypting the encrypted virtual card image file, is generated at least partly from one or more mobile computing device user identifiers. 25 The mobile computing device user identifiers include at least one of a name, a date of birth, a mobile telephone number, a personal identification number, an e-mail address, a certificate, a public key, a private key, or a user selected password.

2a The one or more mobile computing device user identifiers are entered on the mobile computing device by the user and/or stored on the mobile computing device.

WO 2012/045128 PCT/AU2011/001299 3 According to an embodiment of the first aspect, the method may further include sending, on a computer interface, a user message to notify the user that the encrypted virtual card image file is available. The user message may include at least part of a decryption key for decrypting the 5 encrypted virtual card image file to a virtual card image file. The virtual card may include a card number, a card user ID number, a card user name, a date of issue, an expiry date, a barcode, a virtual hologram, a number of points, a membership level and/or a membership duration. 10 According to an embodiment of the first aspect, the encrypted virtual card image file is deleted from the computer readable medium at the publicly accessible location after a predetermined time limit. Alternatively or additionally, the encrypted virtual card image file is deleted from the computer readable medium at the publicly accessible location after it has 15 been downloaded. According to a second aspect, a system provides an encrypted virtual card image file to a mobile computing device for decryption and display of a virtual card on the mobile computing device, the system including: an agent portal, including a processor and memory, the memory including instruction 20 code operable by the processor to: receive a virtual card image file; generate an encryption key for encrypting the virtual card image file; encrypt the virtual card image file using the encryption key; generate a URL identification string for at least partly identifying a publicly accessible location where the encrypted virtual card image file is to be stored; store, on a computer 25 readable medium at the publicly accessible location the encrypted virtual card image file; receive a request for the encrypted virtual card image file; and redirect the request to the publicly accessible location. According to an embodiment of the second aspect, the system further includes: a card provider server, including a processor and memory, the 30 memory including instruction code operable by the processor to: generate WO 2012/045128 PCT/AU2011/001299 4 the virtual card image file; and transmit the virtual card image file to the agent portal. The card provider server may further include instruction code operable by the processor to: receive a request, from a user, for a card; wherein the virtual card image file is generated based upon the request. 5 According to a third aspect, a computer program is provided, embodied on a computer readable medium, including computer instruction code that, when executed on a data processing apparatus, provides a method according to the first aspect. According to a fourth aspect, a mobile computing device is provided 10 including the computer program according to the third aspect. The mobile computing device may be a smart phone. As used herein, except where the context requires otherwise, the term "comprise" and variations of the term, such as "comprising", "comprises" and "comprised", are not intended to exclude further additives, components, 15 integers or steps. The reference to any prior art in this specification.is not, and should not be taken as, an acknowledgement or any form or suggestion that the prior art forms part of the common general knowledge in Australia. BRIEF DESCRIPTION OF THE DRAWINGS 20 In order that the present invention may be readily understood and put into practical effect, reference will now be made to the accompanying illustration wherein: FIG. I illustrates a system 100 for providing an encrypted virtual card image file to a mobile computing device for decryption and display on a 25 mobile computing device, according to an embodiment of the invention; FIG. 2 illustrates a system 200 for providing an encrypted virtual card image file to a mobile computing device for decryption and display on a mobile computing device, according to a second embodiment of the WO 2012/045128 PCT/AU2011/001299 5 invention; and FIG. 3 illustrates a method for providing an encrypted virtual card image file for decryption and display on a mobile computing device, according to an embodiment of the present invention. 5 DETAILED DESCRIPTION OF EMBODIMENTS The invention of the present application enables the secure provision of a virtual card image file for display on a mobile computing device. The novel and inventive system, method and computer program product of the invention allows display of the virtual card image file on a mobile computing 10 device so that the displayed virtual card may be used in commerce such as commercial transactions, redemptions, or participation in a loyalty program or other form of user identification. The invention is suitable for use on any mobile computing device. The mobile computing device may include a smart phone, a personal digital 15 assistant, a portable computer and/or a portable gaming system. The virtual card image file may be a virtual representation of any conventional card such as, a credit card, a debit card, a health card, a loyalty card, an ID card, a bank card, a payment solutions card, a membership card, a gift card, a trade card or a travel pass. 20 The health card may be operated by a governmental department or by a private provider. The government department may be for the general public or for a specific demographic for which health care is provided such as, war veterans, children, parents, unemployed or low income earners. The health card may be a Medicare care, a Department of Veterans affairs (or similar), 25 or a private health insurance card. The trade card may be a company wide card, such as a card valid for use at any member of a particular franchise or at any store operated by that trader.

WO 2012/045128 PCT/AU2011/001299 6 Herein the terms "virtual card image file" and "virtual card" may be used interchangeably. It is understood that the virtual card image file is read, accessed or otherwise loaded by a mobile computing device to display the virtual card which is a display, on a screen comprised on the mobile 5 computing device, corresponding to a card. When displayed, the virtual card may comprise one or more of a card number, or card user ID number, a card user name, a date of issue, an expiry date or one or more other identifiers. The one or more other identifiers may include a barcode and/or a virtual hologram or indeed any other 10 information such as a number of points, a membership level or "member since" type information. This document describes the features and advantages of the present invention. A discussion of the advantages of a Virtual Card System (VCS) for a number of different embodiments of the invention is presented, followed by 15 the security provisions of the invention. Additionally, a discussion of how current Physical Card Systems (PCS) address these security requirements is provided before a discussion of how the present invention addresses these security requirements for a VCS. Also provided is a discussion of some security risks that are unique to a VCS and a detailed workflow for a VCS at 20 a number of security levels indicating which card types would most likely require which security level. The technical details for the implementation of the VCS are also provided. Of significant advantage, the present invention is able to offer equal or better security to the protocols in place for current physical or conventional 25 cards. These security protocols are outlined below. Current physical or conventional card security protocols require the card to be delivered to the appropriate person (or other legal entity) - as specified by the cardholder upon registration. Three levels of security are possible with the delivery of the card. 30 Firstly, the physical card is to be delivered by mail to the address WO 2012/045128 PCT/AU2011/001299 7 specified by the cardholder at the time of registration or subsequently. No identification is required to collect the card. Secondly, the physical card is delivered by registered mail to the address specified by the cardholder at the time of registration or 5 subsequently. A signature is required for the cardholder to receive the card from the delivery agent such as a postal company. Thirdly, the cardholder is required to collect the card from the card provider. The cardholder can be identified using existing identification such as a driver's license, a passport, a bank statement or the like. 10 An additional level of security is often added by banks. Where high security is required, the cardholder must call the bank, identify themselves over the phone to confirm receipt of the card and the card provider then activates the card. These levels of security also ensure that the current physical or 15 conventional card is not delivered to the wrong entity or intercepted and used by a malicious cardholder. The physical or conventional card is not able to be copied to or shared with (either intentionally or unintentionally) any other device. While there is no specific barrier to preventing people from sharing most current physical or 20 conventional cards they receive, notable exceptions include ID cards with photographs on them. Of course sharing a payment card and using a payment card are different concepts. To use a payment card, a cardholder must verify their intention to use the card either with a secret PIN or via a signature registered with the bank. 25 Current physical or conventional cards are not able to be tampered with once delivered to the cardholder. There are two possible types of cards with respect to the cardholder: cards that a cardholder may be prepared to share such as ID cards or membership cards (where the issuing card provider would not want the card WO 2012/045128 PCT/AU2011/001299 8 shared); and cards that the intended cardholder would not want to share such as credit or debit cards. Where a legitimate cardholder might want to share a card which is not 5 in the interest of the issuing card provider (for example a gym membership card) traditional cards have photographs of the legitimate cardholder either on the card itself or in the system linked to the issued card. Where a legitimate cardholder would not want to share a card (for example a credit card), the card transaction is protected by a PIN or signature verification 10 step. It is possible to deactivate current physical or conventional cards if they are lost or stolen. The card provider is able to register a deactivation in their database such that if the card is presented it is not considered valid. It is also possible to securely re-issue current physical or conventional 15 cards if the original card is lost or stolen. The cardholder and card provider follow the same procedure as for the original issue of the card. Current physical or conventional cards must be able to be destroyed when expired or when the cardholder no longer wishes to use the card. The cardholder or the card provider physically destroys the card, typically by 20 destroying the card and disposing of it securely. The present invention may operate under high level security requirements. The present invention delivers a level of security at least as high as that offered by current conventional or physical card systems. In an embodiment of the present invention, the image file is delivered to the 25 appropriate mobile computing device (as specified by the cardholder upon registration) and the image file is not delivered to the wrong person or mobile computing device. Also, the image file is not able to be intercepted and used by a malicious party and the image file is not able to be shared with or copied to (either intentionally or unintentionally) any other device. Additionally, the WO 2012/045128 PCT/AU2011/001299 9 image file is not able to be tampered with once on the legitimate mobile computing device and the image file is able to be deactivated if the mobile computing device is lost or stolen. Further, the image file is able to be securely reissued if the original image file is lost or stolen and the image file 5 is able to be destroyed when expired or when the cardholder no longer wishes to use the card. FIG. I illustrates a system 100 for providing an encrypted virtual card image file to a mobile computing device for decryption and display on a mobile computing device, according to an embodiment of the invention. 10 The system 100 includes a card provider server 102, for generating a virtual card image file. The card provider server 102 may receive a request for a new card from a mobile computing device 104, or may generate the virtual card image file automatically or based upon other input. The system 100 includes an agent portal 106 for encrypting the virtual 15 card image file. The agent portal receives the virtual card image file from the card provider server 102, possibly in combination with user or device information. The agent portal 106 generates an encryption key for encrypting the virtual card image file. The virtual card image file is then encrypted using the 20 encryption key. The agent portal 106 additionally generates a Uniform Resource Locator (URL) component for the encrypted virtual card image file. The location of the encrypted virtual card image file is at least partly identified by the URL component. 25 The system 100 includes a virtual card server 108, in communication with a virtual card database 110, for storage of the encrypted virtual card image file at the URL. The components of the system 100 may be in operative WO 2012/045128 PCT/AU2011/001299 10 communication through a communications network. The communications network may be any suitable network including the Internet. In one embodiment of system 100, a user 104 requests a virtual card image file from the card provider server 102. The virtual card image file is 5 then generated. In an alternative embodiment of system 100, the card provider server 102 may create the virtual card image file automatically, or based upon other input. The request may include information of the user including one or more 10 mobile computing device user identifiers. The mobile computing device user identifiers include at least one of a name, a date of birth, a mobile telephone number, a personal identification number, an e-mail address, a certificate, a public key/private key pair, and a user selected password. The virtual card image file is then transmitted from the card provider 15 server 102 to the agent portal 106 for encryption. The virtual card image file may be transmitted together with the further information of the user, and or information from the user obtained through other means. The agent portal 106 generates an encryption key, which is used to encrypt the virtual card image file. The encryption key may be generated 20 from the one or more mobile computing device user identifiers, for example. In this way the virtual card image file is encrypted so that only the requesting user can decrypt and open it. The encryption key may be part of a public/private key pair, a shared secret, or any other suitable encryption key. 25 The agent portal 106 additionally generates a Uniform Resource Locator (URL) component for the encrypted virtual card image file. The URL component is used to generate, at least partly, the location of the encrypted virtual card image file when it is stored on the virtual card server 108.

WO 2012/045128 PCT/AU2011/001299 11 The encrypted virtual card image file is then transmitted, together with the URL component, to the card provider server 102. Once the card provider server 102 has received the encrypted virtual card image file from the agent portal 106, the card provider-stores and makes the encrypted virtual card 5 image file available from the virtual card server 108 and the virtual card database. The URL of the encrypted virtual card image file is at least partly defined by the URL component. The card provider server 102 may inform the agent portal 106 of the URL of the encrypted file. Alternatively, the agent portal may be able to 10 generate the URL from the URL component, possibly in combination with other information. The card provider server 102 sends a message to the mobile computing device that the encrypted virtual card image file is available. The message may be an SMS or email sent to or receivable on mobile computing 15 device 104, or a response to the request for a virtual card image file, if present. The message may include a decryption key for decrypting or partially decrypting the encrypted virtual card image fiie. The decryption key may be a personal identification number (PIN). Alternatively, the mobile computing 20 device 106 may generate the decryption key from the mobile computing device user identifiers, either stored on the device 106 or input by the user. The mobile computing device 104 then requests the agent portal 106 for the virtual card image file. The agent portal 106 then redirects the request to the virtual card server 108 and virtual card database 110 through 25 the URL that was generated from the URL component above. The encrypted virtual card image file is then downloaded to mobile computing device 104. A user is then able to decrypt the encrypted virtual card image file using the decryption key which may, for example, be generated based upon one or more of the mobile computing device user 30 identifiers such as a personal identification number or public key.

WO 2012/045128 PCT/AU2011/001299 12 FIG. 2 illustrates a system 200 for providing an encrypted virtual card image file to a mobile computing device for decryption and display on a mobile computing device, according to a second embodiment of the invention. 5 The system 200 includes an agent portal 206, fbr generating and encrypting a virtual card image file. The agent portal 206 may receive a request for a new card from a mobile computing device 204, or may generate the virtual card image file automatically or based upon other input. A request for a new card may include user information as described above in the 10 context of FIG. 1. The agent portal 206 generates an encryption key for encrypting the virtual card image file, similar to that described above in the context of FIG. 1. The virtual card image file is then encrypted using the encryption key. The agent portal 206 additionally generates a Uniform Resource 15 Locator (URL) component for the encrypted virtual card image file, the location of the encrypted virtual card image file at least in part identified by the URL component, which is used to generate a URL. The system 200 includes a virtual card server 208, in communication with a virtual card database 210, for storage of the encrypted virtual card 20 image file at the URL, similar to the virtual card server 108 and virtual card database 110 of FIG. 1. The components of the system 200 may be in operative communication through a communications network. The communications network may be any suitable network including the Internet. 25 In one embodiment of the system 200, a user 204 requests a virtual card image file from the agent portal 206. The virtual card image file is then generated. In an alternative embodiment of system 200, the agent portal 206 may create the virtual card image file automatically, or based upon other input.

WO 2012/045128 PCT/AU2011/001299 13 The request may include information of the user including one or more mobile computing device user identifiers as described above in the context of FIG. 1. The agent portal 206 generates an encryption key, which is used to 5 encrypt the virtual card image file. The encryption key may be generated from the one or more mobile computing device user identifiers, for example. In this way the virtual card image file is encrypted so that only the requesting user can decrypt and open it. The agent portal 206 additionally generates a Uniform Resource 10 Locator (URL) component for the encrypted virtual card image file. The URL component is used to generate, at least partly, a URL of the encrypted virtual card image file when it is stored on the virtual card server 208. The encrypted virtual card image file is then transmitted, together with the URL component, to the virtual card server for storage. The agent portal 15 206 may directly control the virtual card server and/or virtual card database 210 such that the encrypted virtual card image file is made available at the URL. Alternatively, the agent portal 206 may send a request to the virtual card server 208 which performs the storage. The agent portal sends a message to the mobile computing device 20 that the encrypted virtual card image file is available. The message may be an SMS or email sent to or receivable on mobile computing device 104, or a response to the request for a virtual card image file, if present. The message may include a decryption key for decrypting or partially decrypting the encrypted virtual card image file. The decryption key may be a 25 personal identification number (PIN). Alternatively, the Mobile computing device 106 may generate the decryption key from the mobile computing device user identifiers, either stored on the phone or input by the user. The mobile computing device 204 then requests the virtual card image file from the agent portal 206. The agent portal 206 then redirects the WO 2012/045128 PCT/AU2011/001299 14 request to the virtual card server 208 and virtual card database 210 through the URL that was generated from the URL component above. The encrypted virtual card image file is then downloaded to mobile computing device 104. A user is then able to decrypt the encrypted virtual 5 card image file using the decryption key which may, for example, be generated based upon one or more of the mobile computing device user identifiers such as a personal identification number or public key as discussed above in the context of FIG. 1. FIG. 3 illustrates a method for providing an encrypted virtual card 10 image file for decryption and display on a mobile computing device, according to an embodiment of the present invention. At step 302, a virtual card image file is generated, on a computer processor. In an alternative embodiment, the virtual card image file is received, on a computer interface. 15 At step 304, an encryption key for encrypting the virtual card image file is generated, on a computer processor. The encryption key may, but need not be, generated based upon mobile computing device user identifiers as described above in the context of FIGs 1 and 2. At step 306, the virtual card image file is encrypted using the 20 encryption key. At step 308, a URL identification string, for at least partly identifying a publicly accessible location where the encrypted virtual card image file is to be stored, is generated. At step 310, the encrypted virtual card image file is stored, on a 25 computer readable medium and at the publicly accessible location. At step 312, a request is received for the encrypted virtual card image file. At step 314, the request is redirected to the publicly accessible WO 2012/045128 PCT/AU2011/001299 15 location. The method may also include sending a user message to notify the user that the encrypted virtual card image file is available. The invention further provides a computer program product embodied 5 on a computer readable medium including software code adapted, when executed on a data processing apparatus, to provide the method of FIG. 3. Of significant advantage to users who carry a mobile computing device with them, the invention provides a mobile computing device comprising the computer program product of the invention. 10 The mobile computing device may be a smart phone. As is apparent from the above description, the secure image file to mobile computing device of the invention deals with the security points above as described below. The image file may be delivered to the appropriate mobile computing 15 device - as specified by the cardholder upon registration for the card with the card provider. Although the image file of the encrypted card can potentially be downloaded by anyone with access to the public internet, the card cannot be decrypted without the decryption key. The decryption key may be combined 20 with a Security Code sent to the cardholder at the mobile computing device specified at the time of registration with the card provider. The information may be entered into a virtual wallet also stored on the mobile computing device. In this manner the present invention is more secure than standard 25 mail and of similar security to registered mail. To be equivalent to the cardholder collecting the card, the cardholder would have to identify themselves personally to the card provider before receiving the security code in person to be entered into the Application to decrypt the card.

WO 2012/045128 PCT/AU2011/001299 16 The image file is not delivered to the wrong person or device. If the encrypted image ends up in the wrong hands, it is not be able to be decrypted within a reasonable amount of time without the key. State of the art strong encryption algorithms such as AES or 3DES together with a key 5 strengthening algorithm such as PKDF2 provide appropriate protection for this purpose. According to certain embodiments, the encrypted card image file may only be available for download for a short period following a notification, for example SMS or email, that it is ready. Another notification with another 10 download period can be sent at a later time. Once the encrypted card image has been downloaded from the card provider, the card provider may remove the encrypted image file from its server. To enforce the highest level of security, the card provider may require the cardholder to register the virtual card in order to use it. This could include 15 an activation step, wherein the cardholder reads a code from the virtual card to the card provider once it has been decrypted and displayed on their device. The card is not able to be intercepted and used by a malicious cardholder. According to certain embodiments, the card is only available on 20 the public internet for a short time, a malicious intercept would have to happen within that time frame. Further, according to certain embodiments, the attacker would need to find the URL Hash string in order to download the encrypted card image; and subsequently break the strong encryption to decrypt the image. 25 As a further security measure following a malicious downloaded, the image file could be removed from the internet and any subsequent download attempts could be recorded. Thus it would not be available to the intended user who could alert the card provider. The virtual card could then be deactivated and reissued. 30 The image file is not able to be shared (copied) either intentionally or WO 2012/045128 PCT/AU2011/001299 17 un-intentionally with any other device. According to certain embodiments, the image file for the virtual card is stored as an encrypted image and can only be decrypted on the device with the phone number for which it was intended. For high security applications, the user phone number could be 5 verified by sending an SMS with a secure key to enable a high security level. The application would only install high security level cards after it had received the correct SMS key. The decryption key may involve the cardholder's name, date of birth, 10 phone number and/or the transmitted security number which may all be stored within the application, but encrypted separately. Thus if the encrypted card image file was copied to another device, it would not be able to be decrypted without the entire application and data being transferred as well. According to certain embodiments, both devices would also have to have the 15 same phone number rendering them useless as mobile telephony devices. The virtual card file may be displayed with a real time clock ticking over it so that a simple screenshot of the image would not be a substitute for the actual card. For virtual card transactions requiring the highest security such as 20 credit card payments, a PIN or signature may further be required to verify the transaction. We note that credit card transactions are currently taken over the phone and internet without presentation of PIN or signature. The same level of security may be available with a virtual card image file in terms of verification of delivery of goods or services at the merchant's risk. 25 The virtual card image file is not able to be tampered with once on the mobile computing device. Certainly, an ID card should not be able to have a photograph replaced or an ID number changed in the encrypted card image. As the virtual card image file is encrypted, this would require a significant level of sophistication and intention to achieve this.

WO 2012/045128 PCT/AU2011/001299 18 The steps required may include: retrieve the encrypted image from the application data storage (not that difficult), decrypt the image (difficult), modify the image as required by the attacker (not difficult), encrypt the image so that it can be decrypted by the application (difficult) and reinsert the new 5 encrypted image into the Application data store (medium difficulty). Importantly, we note that this attack is of a similar level of sophistication, complexity and intention as forging a physical card. That is the present invention provides security at least equivalent to current physical or conventional cards. 10 The virtual card image file is able to be deactivated if lost or stolen. This may be dealt with by the card provider in exactly the same manner as when a physical card is lost or stolen. The virtual card image file is able to be securely reissued if the original card is lost or stolen. This may follow the same protocol as the original issue. 15 The virtual card image file must be able to be destroyed when expired or when the cardholder no longer wishes to use the card. The cardholder may optionally delete an image file from the application. This would permanently delete the image file and the decryption key. It would also clear the memory in which the card was stored on the device. 20 The present invention also solves the unique security risks associated with image files. An attacker could forge the entire mobile device. application and then put a forged virtual card within that application. This is not dissimilar from an attacker forging a physical card and presenting that instead and requires a similar level of sophistication and intention of attack. This could 25 potentially be hardened by giving the verifier access to viewing the same card temporarily on their computer screen. Official cards could not be identical to attacked cards unless the attacker managed to steal and decrypt a legitimate cardholder's encrypted card image and associated files. The virtual card image file may have an expiry beyond which, the WO 2012/045128 PCT/AU2011/001299 19 decryption will no longer work. Security Level Requirements: There may be different levels of security requirements for different types of card delivery. Each level is described herein with examples and the 5 process for each security level is described below. The Security Level would be chosen by the card provider according to the risks associated with the virtual card image file to be delivered. This would be a procedural decision for all delivery of this type of image file. The following description could assist a card provider with this decision. 10 Level I Security Protocol: Where there is no risk of financial loss and little other risk to the card provider or the cardholder, to simplify the virtual card image file transfer transaction, the card provider could choose the Level 1 Security Protocol for card delivery. 15 At this level, there is no encryption of the image file prior to delivery. This makes it reasonably easy to copy the card or share it with someone else. Similarly, a malicious attacker could potentially use the card if they were to download it. At this level of security, there is also no need to use SSL delivery of 20 the card. Similarly at this level of security, there is no need to identify the cardholder on registration. Examples of Level 1Security Card Delivery include: Loyalty Programs; Trade Cards; and Other advertising Programs. The repercussions of malicious use of these cards involve no financial loss for either the cardholder or the card provider. In fact a card provider 25 might even be quite happy for individuals to share their loyalty cards with others. Level 2 Security Protocol: WO 2012/045128 PCT/AU2011/001299 20 Where -there is risk of financial loss to the cardholder or the card provider, a card provider could choose the Level 2 Security Protocol for virtual card image file delivery. At this level, the virtual card image file is encrypted. The download 5 may be protected by encryption such as, SSL, and the card provider may require identification of the proposed cardholder before issuing the virtual card image file. Virtual Cards at this level need to be guaranteed that they cannot be copied, shared or maliciously interfered with. 10 Examples of Level 2 Security Card Delivery include: Membership Cards; Bank / Payment Cards; Gift Cards; Travel Passes; and Medicare / Health Care I DVA Cards. The repercussions of malicious use of each of these cards could potentially be minor financial loss to either the cardholder or the card 15 provider. We note that any financial transactions made using these cards are separately protected - either by PIN or signature at the point of transaction. As for current internet or telephone credit card transactions, the cardholder may be protected by Merchant Delivery Guarantees. Level 3 Security Protocol: 20 The highest level of security is reserved for Primary Documents where there is the possibility of identity fraud (or even theft) if these virtual cards are not sufficiently protected. This security level includes all of the protection given by Security Level 2. In addition, the cardholder needs to be physically identified from Primary Identification Documents or the equivalent as part of 25 the request for a virtual card image file. The cardholder would also need to physically identify in order to install the virtual card image file on the specified mobile computing device. Examples of Level 3 Security Card Delivery include: a drivers licence; WO 2012/045128 PCT/AU2011/001299 21 and any other form of Primary Identification. The repercussions of malicious use of any of these cards could be very serious, including, but not limited to identity theft and false identification. Basic Process: 5 This section details the basic workflow for each of the Security Level Protocols described above. Level 1 Security Process: A Cardholder may request a virtual card image file, either online or via traditional methods. At Security Level 1, minimal identification is required. 10 The cardholders name, mobile phone number, or email address, may be collected by the card provider at this point. The card provider may process and generate the virtual card image file as would be required with conventional or physical cards although there may be no need to create or post a physical card. 15 The card provider may format a string uniquely hashed, with for example a one way hash, from the cardholder's name and/or mobile phone number or e-mail address which may also comprise a URL Identification String. The card provider may place the virtual card image file on its website 20 with an address corresponding to the URL Identification String. The card provider may send a text message or email message to the cardholder to indicate that there is a new virtual card image file ready to download. The image file may be downloaded into an Application stored on the mobile computing device. The application may be a virtual wallet. 25 The cardholder may open the mobile computing device application and request any card updates or this may be performed automatically.

WO 2012/045128 PCT/AU2011/001299 22 The application, may create the URL identification string as the card provider did and download the virtual card image file from the card provider website. The card provider may remove the image file from the website either 5 once it has been downloaded or after a short amount of time. The short amount of time may be 24, 48 or 72 hours - or any other amount of time. The Application may store the virtual card image file on the mobile computing device. When the cardholder wishes to use the virtual card image file, the 10 Application may display it on the mobile computing device. The Level 2 Security Process: A Cardholder may request a card, either online or via traditional methods which may require identification. The cardholder's name, date of birth, mobile phone number and email 15 address may be collected by the card provider at this point. The card provider may process and generate the card as would be currently required. The card provider may encrypt the virtual card image file Using a key. The key may be based on the cardholder's mobile phone number, their name 20 and/or date of birth/e-mail. The card provider may format a string uniquely hashed, for example with a one way hash, from the cardholders name and/or mobile phone number which may also comprise a URL Identification String. Importantly this algorithm must not be trivial to replicate which reduces 25 the chance of malicious downloads of the encrypted virtual card image file. The card provider may place the encrypted image of the virtual card on a secure web page (secured with for example SSL) on its website with an WO 2012/045128 PCT/AU2011/001299 23 address corresponding to the URL Identification String. The card provider may send a text or email message to the cardholder to indicate the virtual card image file availability. This text or email message may include a security code that is 5 required to install the new card on their mobile computing device or into an Application thereon. The cardholder may open the mobile computing device Application and request any card updates or this may be performed automatically. The Application may create the URL Identification String as the card 10 provider did, or request the URL Identification String from the card provider or its agent, and may download the encrypted virtual card image file from the card provider website. The card provider may remove the encrypted image from the website either once it has been downloaded or after a short amount of time. The 15 short amount of time may be 24, 48 or 72 hours or any other time period. The Application may store the encrypted image on the mobile device and prompt the cardholder for the security code previously. sent to the cardholder. When the cardholder wishes to use the virtual card image file, the 20 Application decrypts the encrypted image and displays it on the mobile device. The virtual card image file may be verified at the point of -presentation if required. Level 3 Security Process: 25 A cardholder or potential cardholder may. request a virtual card. Traditional methods would be required at this security level, for example the card provider may verify the Cardholder's identity through physical WO 2012/045128 PCT/AU2011/001299 24 identification possibly including, but not limited to signature verification, biometric verification, sighting of a certain number of points of identification,, or requiring verified copies of primary identification documents such as a birth certificate or passport. 5 The cardholder's name, date of birth, mobile phone number and email address may be collected by the card provider at this point. The card provider processes and generates the card as would be currently required. The card provider may encrypt the virtual card image file using a key 10 based on the cardholder's mobile phone number, their name and/or date of birth, email or other information. The card provider may format a string uniquely hashed, with for example with a one way hash, from the cardholder's name and mobile phone number which may also comprise a the URL Identification String. 15 Importantly this algorithm must not be trivial to replicate which reduces the chance of malicious downloads of the encrypted virtual card image file. The card provider may place the encrypted image of the Virtual Card on a secure web page, for example secured with SSL, on its website with an address corresponding to the URL Identification String. 20 The card provider may optionally send a user name and password via separate communication method - email or phone contact to further secure the download path of the encrypted virtual card image file. The card provider may send a text or email message to the cardholder to indicate the Virtual Card's availability. 25 This text or email message may include a security code that is required to install the new virtual card image file into the cardholder's mobile computing device or an application thereon.

WO 2012/045128 PCT/AU2011/001299 25 Alternatively, the card provider may require the Cardholder to attend the card provider premises in person to be identified and then given the security code required to decrypt the virtual card image file. The cardholder may open the mobile device Application and request 5 any card updates or this may be done automatically. The Application may create the URL Identification String as the card provider did, or request the URL Identification String from the card provider or its agent and download the encrypted virtual card image file from the (e.g. SSL protected) card provider website. 10 The card provider may remove the encrypted image from the website either once it has been downloaded or after a short amount of time. The short amount of time may be 24, 48 or 72 hours or any other time period. The Application may store the encrypted image on the mobile device and may prompt the cardholder for the security code previously sent to the 15 cardholder. The Cardholder may telephone the card provider, or may visit in person to be physically identified, and confirm that the virtual card image file has been successfully installed into the Cardholder's mobile computing device or Application. 20 The card provider may activate the virtual card image file and may allow the Cardholder to transact with that Virtual Card. When the cardholder wishes to use the virtual card, the mobile computing device or Application decrypts the encrypted image and displays it on the mobile computing device. 25 The Virtual Card may generally be verified at the point of presentation. The One Way Hash and URL Identification String may be a MD5 or SHA or SHA256 or any other one way strong encryption algorithm.

WO 2012/045128 PCT/AU2011/001299 26 The Encryption Algorithm may be AES or any other strong encryption algorithm. The Key Strengthening Algorithm may be PBKDF2 or any other that uses some or part of the user identification data, special other data, some 5 cryptographic salt and the number of iterations to strengthen the key. The number of iterations could be the Security Code sent from the card provider. The following non-limiting examples illustrate the invention. These examples should not be construed as limiting. The examples are included for 10 the purposes of illustration only. The discussion below in the Examples will be understood to represent an exemplification of the invention. Examples The card provider is the company who creates the virtual card and wants to send it to the mobile computing device. The user is the holder of the 15 mobile computing device. The agent portal provides a link between the mobile computing device and the provider. METHOD: One example of the method of the invention is: 1. Image file is requested either by card provider or user. 20 2. Image file is created by the card provider and sent to the portal. 3. Portal generates encryption keys and URL path. 4. Image file is encrypted by the portal in such a way that only the requesting user can open it. 5. Encrypted image file is returned to the card provider. 25 6. Card provider stores encrypted packaged image file in a publicly accessible location.

WO 2012/045128 PCT/AU2011/001299 27 7. The provider informs the agent portal that the new encrypted image file is available for the user and details the user and location. 7a. Card provider optionally, depending on security level, sends SMS to User including PIN for unlocking the encrypted image file. 5 8. The mobile computing device checks the agent portal for any new image file. 9. Image request is redirected to the correct URL. 10. Encrypted image file may be saved to the mobile computing device for later viewing. 10 11. Encrypted image file is decrypted. 12. Image file is displayed on the mobile computing device. IMAGE FILE REQUEST INITIATED BY A USER: If the user requests that the image file be created, for example a loyalty card, the provider collects sufficient information about the user to 15 encrypt and transmit the card appropriately. This includes, but would not be limited to: Name; Date of Birth; Mobile Phone Number; email address. IMAGE FILE REQUEST INITIATED BY A PROVIDER: If a provider requires an image file to be created, for example a voucher or special offer, for an existing customer, the provider needs to have 20 previously collected sufficient information about the user to encrypt and transmit the image file appropriately. This includes but, but would not be limited to: Name; Date of Birth; Mobile Phone Number; email address. IMAGE IS CREATED BY PROVIDER: Once the, provider has the necessary information, for example 25 obtained from the image file requests described above, the provider creates the image file to be transmitted as a standard digital image. This image might WO 2012/045128 PCT/AU2011/001299 28 include some or all of the information collected in the image file request, as well as provider information specific to the user such as a card number, expiry date or other required information. PORTAL GENERATES ENCRYPTION KEYS AND URL PATH: 5 A private shared key is generated by the portal in order to encrypt the image. This key is created using information shared between the user and the provider in the image file request process and strengthened using standard key strengthening algorithms such as PBKDF2. IMAGE FILE SERVER ENCRYPTS AND PACKAGES IMAGE FILE AND 10 RELATED DATA The generated image file is then encrypted using this key. Any other information required for the use of the virtual card is also encrypted and stored together. ENCRYPTED IMAGE FILE IS RETURNED TO THE CARD PROVIDER: 15 This encrypted packaged image file is then returned to the card provider to be served to the mobile computing device. CARD PROVIDER STORES ENCRYPTED PACKAGED IMAGE FILE IN A PUBLICLY ACCESSIBLE LOCATION: The card provider stores the packaged file in an area available for 20 download by the mobile computing device. This would typically be on the internet somewhere, but in rare circumstances could be on a private network that was only accessible when the mobile computing device is directly connected to a particular network. THE PROVIDER INFORMS THE AGENT PORTAL THAT THE NEW 25 ENCRYPTED IMAGE'FILE IS AVAILABLE FOR THE USER AND DETAILS THE USER AND LOCATION: The provider informs the portal where the packaged image file has WO 2012/045128 PCT/AU2011/001299 29 been stored so that the mobile computing device can be redirected to this image file when required. This information is stored in a lookup table of some description on the portal. CARD PROVIDER OPTIONALLY (DEPENDING ON SECURITY LEVEL) 5 SENDS SMS TO USER INCLUDING PIN FOR UNLOCKING THE ENCRYPTED IMAGE FILE: For high security applications, the card provider can send an SMS to the mobile computing device to ensure that only the legitimate holder of the mobile computing device is able to decrypt the message. The PIN contained 10 in the SMS needs to be generated by the portal and is part of the information required to generate the key to decrypt the message. For example, this could be the number of iterations to run the key strengthening algorithm for. THE MOBILE COMPUTING DEVICE CHECKS THE AGENT PORTAL FOR ANY NEW IMAGE FILE: 15 The mobile computing device periodically checks for any new cards and informs the user if there are images available. The user may then initiate a download to request the new encrypted card image file. IMAGE REQUEST IS REDIRECTED TO THE CORRECT URL The portal redirects the request to the correct URL for the requested 20 image file. ENCRYPTED IMAGE FILE MAY BE SAVED TO THE MOBILE COMPUTING DEVICE FOR LATER VIEWING The encrypted image file is then saved to the mobile computing device. It is saved in an encrypted form and only decrypted when being 25 displayed. ENCRYPTED IMAGE FILE IS DECRYPTED The encrypted image file is decrypted for display using the shared key WO 2012/045128 PCT/AU2011/001299 30 created from the user id data, the salt data and the number of iterations. IMAGE IS DISPLAYED ON THE MOBILE COMPUTING DEVICE. When requested, the image file is displayed on the mobile computing device. 5 The present claimed invention has many advantages including: cost; environment; distribution efficiency; reissue simplicity; security advantages; and micro payments. Throughout the specification the aim has been to describe the preferred embodiments of the invention without limiting the invention to any 10 one embodiment or specific collection of features. It will therefore be appreciated by those of skill in the art that, in light of the instant disclosure, various modifications and changes can be made in the particular embodiments exemplified without departing from the scope of the present invention. 15

Claims

1. A computer implemented method for providing an encrypted virtual card image file to a mobile computing device for decryption and display of a 5 virtual card on the mobile computing device, the method including: generating, on a computer processor, an encryption key for encrypting a virtual card image file; encrypting, on a computer processor, the virtual card image file using the encryption key; 10 generating, on a computer processor, a URL identification string for at least partly identifying a publicly accessible location where the encrypted virtual card image file is to be stored; storing, on a computer readable medium at the publicly accessible location, the encrypted virtual card image file; 15 receiving a request for the encrypted virtual card image file; redirecting the request to the publicly accessible location; and deleting the encrypted virtual card image file, from the computer readable medium at the publicly accessible location, after a predetermined time limit. 20

2. A method according to claim 1, further including: generating, on a computer processor, the virtual card image file.

3. A method according to either claim 1 or claim 2, further including: 25 receiving, on a computer processor, the virtual card image file.

4. A method according to any one of claims 1 to 3, wherein the encryption key is generated at least partly from one or more mobile computing device user identifiers. 30

5. A method according to any one of claims 1 to 4, wherein a decryption key, for decrypting the encrypted virtual card image file, is 32 generated at least partly from one or more mobile computing device user identifiers.

6. A method according to either claim 4 or claim 5, wherein the mobile 5 computing device user identifiers include at least one of a name, a date of birth, a mobile telephone number, a personal identification number, an e-mail address, a certificate, a public key, a private key, and a user selected password. 10

7. A method according to any one of claims 4 to 6 wherein at least one of the one or more mobile computing device user identifiers is entered on the mobile computing device by the user.

8. A method according to any one of claims 4 to 7, wherein at least one 15 of the one or more mobile computing device user identifiers is stored on the mobile computing device, or entered by the mobile computing device holder each time it is required.

9. A method according to any one of claims 1 to 8, further including: 20 sending, on a computer interface, a user message to notify the user that the encrypted virtual card image file is available.

10. A method according to claim 9, wherein the user message includes at least part of a decryption key for decrypting the encrypted virtual card image 25 file to a virtual card image file.

11. A method according to any one of claims 1 to 10, wherein the virtual card includes at least one of a card number, a card user ID number, a card user name, a date of issue, an expiry date, a barcode, a virtual hologram, a 30 number of points, a membership level and a membership duration. 33

12. A method according to any one of claims 1 to 11, further including: deleting the encrypted virtual card image file, from the computer readable medium at the publicly accessible location, after redirecting the request to the publicly accessible location. 5

13. A method according to any one of claims 1 to 12, further including: displaying the card image file with a temporally varying image.

14. A method according to claim 13, wherein the temporally varying image 10 is a real time clock image.