Integration of Payment Capability into Secure Elements of Computers

CROSS-REFERENCES TO RELATED APPLICATIONS

0001This application is a continuation-in-part of prior application Ser. No. 12/780,657, entitled “Verification of Portable Consumer Devices,” filed May 14, 2010, which is a continuation-in-part of prior application Ser. No. 12/712,148, entitled “Verification of Portable Consumer Devices,” filed Feb. 24, 2010, the contents of which are hereby incorporated in their entirety by reference for all purposes. This application is also a continuation in part of prior application Ser. No. 12/878,947, entitled “Secure Communication of Payment Information to Merchants Using a Verification Token,” filed Sep. 9, 2010, the contents of which are hereby incorporated in their entirety by reference for all purposes. In addition, this application claims priority to U.S. Provisional Patent Application No. 61/449,507, entitled “Integration of Payment Capability into Secure Elements of Computers,” filed Mar. 4, 2011, the contents of which are hereby incorporated in their entirety by reference for all purposes.

BACKGROUND OF THE INVENTION

0002Online purchasing of goods and services has grown dramatically over the last decade. Although such purchases are now conducted with communications between a user's computer and a merchant's website being encrypted, the users' credit card payment information is still susceptible to theft during the online transaction. A common approach used by hackers to steal credit card payment information is to install a malware program on the user's computer without the user's knowledge, where the malware program examines the user's keystrokes and browser content to detect payment information (e.g., credit card number, expiration date, card verification value, etc.). This is the so-called “man-in-the-middle” attack. Once the payment information is detected, the malware program transmits the data to the hacker's remote server, where it can be used or sold to conduct fraudulent transactions.

0003The present invention is directed to ways of evading man-in-the-middle attacks and effecting secure communication of payment information to merchants for purchases made over the Internet.

BRIEF SUMMARY OF THE INVENTION

0004One exemplary embodiment of the invention pertains to methods of installing user-specific payment information in a secure element of a computer, the user-specific payment information having at least an account number (personal account number—PAN), and one or more of the following: a card verification value, an expiration date, and a billing zip code. An exemplary method comprises receiving, at a secure element of a computer, an account number and at least one of an expiration date, a card verification value, or a billing ZIP code of a user-specific payment information; obtaining an identifier for the secure element; sending the received account number, the received at least one of an expiration date, a card verification value, or a billing ZIP code, and the obtained identifier for the secure element to a validation entity; receiving, in response, a pseudo account number from the validation entity, the received pseudo account number being different from the received account number of the user-specific payment information; and storing, in a memory of the secure element, the received pseudo account number. The user-specific payment information is uniquely assigned to a user, and may be the payment information of a user's portable consumer device (e.g., a primary credit card account assigned by a bank), or sub-account linked to the primary account and limited to particular commerce channels and/or particular transactions (such as internet purchases), or a proxy account number linked to the primary credit card account and limited to use with the secure element. Each of the account number of the user-specific payment information and the pseudo account number is recognizable and processable by a card payment processing network that processes credit-card and/or debit-card transactions, such as VisaNet™. The payment processing network is independent of the bank that issued the user-specified payment information, and the merchants involved with the user's transactions. Also, each account number comprises a sequence of at least eleven numeric digits, preferably of at least 13 numeric digits, and typically is a sequence of 15, 16, 17, 18, or 19 numeric digits. The identifier for the secure element may be assigned by the manufacturer of the secure element of the computer and written to a non-volatile memory of the secure element, or may be written to a non-volatile memory of the secure element by a payment application installed in the secure element.

0005Another exemplary embodiment of the invention pertains to methods of using the secure payment information in a secure element of a computer for a user. Such an exemplary method comprises: receiving an indication that the payment application in the secure element is to be activated by the user; sending, from the secure element of the computer, a representation of a pseudo account number stored in a computer readable memory of the secure element to a validation entity; and receiving, in response, dynamic payment information from the validation entity, the received dynamic payment information having an account number that is different from the pseudo account number. The dynamic payment information is recognizable and processable by a card payment processing network that processes credit-card and/or debit-card transactions, such as VisaNet™. The dynamic payment information comprises an account number of at least eleven numeric digits, preferably of at least 13 numeric digits, and typically of 15, 16, 17, 18, or 19 numeric digits.

0006Additional embodiments of the present invention pertain to computer product products that perform the above methods, and secure elements that have computer readable memories that store these computer program products and processors that execute the stored computer program products. For example, one such exemplary embodiment pertains to a computer program product embodied on a tangible non-transitory computer-readable medium. The exemplary product comprises: code that directs a data processor to receive an account number and at least one of an expiration date, a card verification value, or a billing ZIP code of user-specific payment information; code that directs a data processor to obtain an identifier for a secure element; code that directs a data processor to send the received account number, the received at least one of an expiration date, a card verification value, or a billing ZIP code, and the obtained identifier for the secure element to a validation entity; code that directs a data processor to receive, in response, a pseudo account number from the validation entity, the received pseudo account number being different from the account number of the received user-specific payment information; and code that directs a data processor to store, in a memory of the secure element, the received pseudo account number.

0007Another exemplary embodiment of the invention pertains to methods of providing payment information to a secure element that may be stored by the secure element. Such an exemplary method comprises: receiving, at a server, a request from a secure element of a computer to provide a pseudo account number, the request including an identifier of the secure element, and an account number and at least one of an expiration date, a card verification value, or a billing ZIP code of user-specific payment information; applying at least one validation test pertaining to the received request; sending, if the at least one validation test is passed, a pseudo account number to the secure element; and storing the pseudo account number with an indication of at least the received account number.

0008Another exemplary embodiment of the invention pertains to methods of providing dynamic payment information to a secure element that may be used by the secure element to pay for a transaction. Such an exemplary method comprises: receiving, at a server, a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number and an identifier of a secure element; applying at least one validation test pertaining to the received request; and sending, if the at least one validation test is passed, dynamic payment information to the secure element.

0009Additional embodiments of the present invention pertain to computer product products that perform the above methods, and validation entities that have computer readable memories that store these computer program products and processors that execute the stored computer program products. For example, one such exemplary embodiment pertains to a validation entity and comprises: a data processor; a networking facility coupled to the processor; a computer-readable medium coupled to the processor; and a computer program product embodied on the computer-readable medium. An exemplary embodiment of the computer program product comprises: code that directs a data processor to receive a request from a secure element of a computer to provide a pseudo account number, the request including an identifier of the secure element, and an account number and at least one of an expiration date, a card verification value, or a billing ZIP code of user-specific payment information; code that directs a data processor to apply at least one validation test pertaining to the received request; code that directs a data processor to send, if the at least one validation test is passed, a pseudo account number to the secure element; and code that directs a data processor to store the pseudo account number with an indication of at least the received account number. The exemplary computer program product may further comprise: code that directs a data processor to receive a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number and an identifier of a secure element; code that directs the data processor to apply at least one validation test pertaining to the received request; and code that directs a data processor to send, if the at least one validation test is passed, dynamic payment information to the secure element.

0010Further details regarding embodiments of the invention are provided below in the Detailed Description with reference to the Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

0011<figref idref="DRAWINGS">FIG. 1</figref> illustrates exemplary actions pertaining to various methods, secure elements, and validation entities according to the present invention.

0012<figref idref="DRAWINGS">FIG. 2</figref> shows an exemplary implementation of a computer having a secure element according to the present invention.

0013<figref idref="DRAWINGS">FIG. 3</figref> shows an exemplary embodiment of a secure element according to the present invention.

0014<figref idref="DRAWINGS">FIG. 4</figref> shows an exemplary embodiment of a validation entity according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION

0015The present invention is directed to ways of effecting secure communication of payment information to merchants for purchases made over the Internet. Exemplary embodiments of the present invention involve the incorporation of payment information (e.g., credit card or debit card payment information) into secure elements of specially designed computers, and the use of the incorporated payment information to purchase a product or service from a merchant by way of the merchant's website with a highly improved degree of security. The secure element of the computer is described below in greater detail. As a brief summary, the secure element provides a hardware-level interface with the user which cannot be controlled or accessed by the operating system running on the computer, and is thus immune from being hacked by computer viruses that may be inadvertently installed on the user's computer. The secure element can be accessed by the user by hitting a particular key or sequence of keys on the computer or the computer's keyboard, or by the user clicking a button provided on a browser toolbar provided by a special browser plug-in. When activated, the secure element can access the user interface of the computer (e.g., screen, keyboard, and mouse), and can prevent keyboard keystrokes, mouse clicks, mouse movements, and screen cursor position information from being sent to the operating system that is running on the computer. The secure element can also access the networking facility of the user's computer, either directly or indirectly through the operating system, to securely communicate with a validation server. The validation server assists the user in conveying payment information to a merchant website for a purchase transaction. This server may be provided by an issuing bank or a payment processing network, such as VisaNet™. The secure element may comprise its own data processor and memory, and may further have switching circuitry that selectively connects and disconnects the screen, keyboard, and mouse from the I/O controller of the computer. A payment application is installed on the secure element and executed by the processor of the secure element. The payment application handles the processing of payment information and communicates with the user and the validation entity.

0016<figref idref="DRAWINGS">FIG. 1</figref> illustrates exemplary actions A<b>1</b>-A<b>27</b> that may be used to implement payment interactions between a user <b>1</b>, a merchant website <b>20</b>, a computer <b>10</b> that is used by user <b>1</b> to make a purchase from website <b>20</b>, and a validation entity <b>80</b>. In action A<b>1</b>, user <b>1</b> activates the secure element of computer <b>10</b> by pressing a special key on the browser window (which may be set up in a tool bar provided by a browser plug-in), or by pressing a special key or a combination of regular keys on the computer's keyboard. (The use of a special key can be advantageous for laptop, PDA, and smart phone implementations.) In response, in action A<b>2</b>, the secure element disconnects the computer's user interface from the operating system running on the computer, and presents a dialog box on the computer screen that asks the user to enter a password. The password may be entered by using the computer's keyboard, or by the user clicking an image of a keyboard or a 0-9 numerical keypad displayed on the computer screen by the secure element. In action A<b>3</b>, user <b>1</b> enters the password, which allows full access to the secure element. In the full access state, user <b>1</b> can have access to the aforementioned payment application that has been previously installed in the memory of the secure element. The payment application may automatically start upon receipt of a correct password, or the secure element can present a secure “desktop” screen to the user, with this secure screen having an icon that user <b>1</b> can click on to start the payment application. The secure “desktop” screen may be smaller than the regular desktop screen, and may be laid over a portion of the regular desktop so that the user can still see portions of the regular desktop. Upon activation, the payment application may present its own sequence of dialog boxes, just like a regular application running from the regular desktop. The payment application enables user <b>1</b> to register an instance (e.g., datum) of user-specific payment information, such as credit card or debit card information, with the payment application and validation entity <b>80</b> for use with future transactions with merchant websites, such as merchant website <b>20</b>. In action A<b>4</b>, user <b>1</b> instructs the payment application to register an instance of user-specific payment information. In action A<b>4</b>, user <b>1</b> provides the following fields of the instance of user-specific payment information: the PAN (personal account number), the name of the card holder, card expiration date (if applicable), card verification value (CW, if applicable), and card holder billing address and/or billing zip code. The user-specific payment information is uniquely assigned to user <b>1</b>, and may be the payment information of a portable consumer device <b>5</b> of the user (e.g., a primary credit card account assigned by a bank), or sub-account linked to the primary account and limited to particular commerce channels and/or particular transactions (such as internet purchases), or a proxy account number linked to the primary credit card account and limited to use with secure elements. In action A<b>5</b>, the payment application encrypts the payment information provided by user <b>1</b>, accesses the computer's networking facility to contact validation entity <b>80</b>, and securely communicates the payment information to entity <b>80</b> along with an identifier that uniquely identifies the secure element. The identifier for the secure element may be assigned by the manufacturer of the secure element of the computer and written to a non-volatile memory of the secure element, or may be written to a non-volatile memory of the secure element by the payment application. The unique identifier for the secure element is different from every serial number that the computer manufacturer has encoded into the CPU, memory, and firmware of computer <b>10</b>, and preferably cannot be derived therefrom by using a single mathematical operation. As such, the identifier for the secure element is not accessible to the operating system.

0017Entity <b>80</b> validates the received instance of user-specific payment information in action A<b>6</b>, and sends back a pseudo account number (pseudo-PAN) to the payment application running on the secure element in action A<b>7</b>. The pseudo account number (pseudo-PAN) is different from the real account number (PAN) provided to it by user <b>1</b>, and preferably cannot be derived from it by using a single mathematical operation. In addition, the pseudo-PAN preferably has the form of a PAN that can be processed by payment processing network (such as network <b>70</b> described below), being a string (sequence) of at least 11 numeric digits, preferably of at least 13 numeric digits, and typically being a sequence of 15, 16, 17, 18, or 19 numeric digits, but preferably not more than 20 digits. As part of action A<b>6</b>, entity <b>80</b> creates a computer record that stores and associates the following items: the user-specific payment information provided by user <b>1</b>, the pseudo account number (pseudo-PAN), and the unique identifier of the secure element. In action A<b>8</b>, the payment application provides user <b>1</b> with an indication that the payment information has been registered, and provides an icon or other representation that the user may click on or select at a later date to send the payment information to a merchant website <b>20</b>. This icon or representation may comprise the name of the bank that issued the user-specific payment information plus the last 3 to 5 digits of the real PAN of the user-specific payment information. Also, the payment application may provide an input dialog box that allows user <b>1</b> to create a name for the registered payment information. In action A<b>9</b>, user <b>1</b> clicks on an icon or representation in the payment application to close it, and further clicks on another icon or representation to exit the secure element, the action of which restores the operating system's access to the computer's user interface. To protect the security of the user's real payment information, such as from a reverse engineering of secure element <b>40</b>, the payment application running on the secure element does not permanently store the PAN, CW, and expiration date of the user-specific payment information that was provided to it by the user. Instead, the payment application can relay this information to the validation server <b>80</b> without any local storage of the information.

0018At a later time, user <b>1</b> shops at merchant website <b>20</b>, finds one or more products or services to purchase, and navigates to the website's checkout page to pay for the transaction. These actions are indicated at A<b>10</b> in the figure. At the checkout page, user <b>1</b> activates the secure element in action A<b>11</b> by pressing a special key on the browser (which may be set up in a tool bar provided by a browser plug-in), or by pressing a special key or a combination regular keys on the computer's keyboard, as indicated above. At action A<b>12</b>, the secure element displays the secure screen and asks for the user's password, as described above. In action A<b>13</b>, user <b>1</b> enters the password, which allows full access to the secure element when correctly entered. Upon confirmation of the correct password, the secure element takes action A<b>14</b> to automatically start the payment application or to present the secure desktop screen to enable user <b>1</b> to start the payment application. Once started, if the user has previous registered a number of instances of user-specific payment information (e.g., a number of portable consumer devices) with the payment application, the payment application may present a dialog box to user <b>1</b> with icons/representations of each of them to enable the user to select one of them (e.g., one of the portable consumer devices, or cards) to use for payment. If only one instance of user-specific payment information has been registered, the payment application may present a dialog box to confirm use of the instance (and to allow another instance or portable consumer device to be registered and used if desired), or the payment application may be configured to proceed to use the sole registered instance (e.g., portable consumer device) without confirmation from the user. These interactions are indicated at A<b>15</b> in the figure. Once the payment application has selected a portable consumer device to use for payment, the payment application generates a cryptogram based on the pseudo-PAN and other info, and sends the cryptogram to validation entity <b>80</b> through a networking facility of the user's computer <b>10</b>, as denoted by action A<b>16</b> in the figure. The cryptogram sent in action A<b>16</b> can also have the previously-described identifier that uniquely identifies the secure element. This identifier can be used by entity <b>80</b> to ensure that it is communicating with a trusted entity. As a further security feature, one of actions A<b>11</b>-A<b>14</b> can include obtaining a unique identifier for merchant <b>20</b>, and action <b>16</b> can include the merchant identifier in the cryptogram, or transmit it along with the cryptogram. Entity <b>80</b> may then use the merchant identifier to either directly communicate payment information to the merchant, or to instruct the payment processing network (described below) to only process the transaction with the merchant indicated by the identifier. The merchant identifier may be obtained from the active web browser, either as the URL of the merchant checkout page or a data field in the contents of the checkout page, and may be displayed to the user within the secure environment of the secure element to confirm the identity of the merchant.

0019Validation entity <b>80</b> determines if the cryptogram is valid, as denoted by action A<b>17</b>, and if valid, it generates return payment information and associates the return information to the user's account. The validation process includes accessing the previously stored record for the user's user-specific payment information (e.g., the user's portable consumer device) based on the value of the received pseudo-PAN, and may include comparing the received identifier of the secure element with identifier of the secure element that was previously stored in the accessed record. The validation process may also include checking a database of fraudulent activity related to the pseudo-PAN and the corresponding real account number of the user, and/or the identity of the secure element. The return payment information may comprise a dynamic PAN number (dPAN) plus a dynamic card verification value (dCW2), or the real PAN number plus a dCW2 value, or a dPAN or real PAN plus a dynamic expiration date, with an optional dCW2 value. The dynamic PAN is different from the pseudo-PAN and the corresponding real PAN of the user's user-specific payment information (e.g., the payment information for portable consumer device <b>5</b>). The dPAN, dCW2, and dynamic expiration date are referred to as being “dynamic” since their values vary with time. Each may have the same value over a designated period of time, or each may change with each request made to validation entity <b>80</b>. The return payment information may be referred to as a dynamic payment information because at least one of its data fields has a value that varies with time. The use of the dynamic dPAN is currently preferred over the use of the real PAN. In action A<b>18</b>, validation entity <b>80</b> sends the return (dynamic) payment information to the payment application running on the secure element of computer <b>10</b>. Action A<b>18</b> may also include sending shipping information. Previous action A<b>17</b> preferably includes storing the return payment information in entity <b>80</b> with an indication of the user's user-specific payment information (e.g., the real account information), and optionally with an indication of the merchant identifier. This will facilitate the processing of the transaction through the card payment system, as described below in greater detail.

0020At this point, payment for the transaction with merchant <b>20</b> may be completed in several different ways. As a first way, the payment application may cause the returned dynamic payment information to be displayed in a window of the browser or another type of window of the operating system, so that the user can copy the dynamic payment information into the merchant's checkout page, either by hand or by cut-and-paste tools of the operating system. To do this, the payment application may pass the dynamic payment information to a companion application running under the computer's operating system, and the companion application may display the dynamic payment information to the user. As a second way, the payment application can pass the dynamic payment information to a companion application running under the operating system, and the companion application can locate the merchant's checkout page on computer <b>10</b> and insert (form fill) the dynamic payment information into the fields of the checkout page. In either case, user <b>1</b> can exit from the secure element interface and return to the interface provided by the operating system and then submit the checkout page with the filled-in payment information to merchant <b>20</b> for processing. This action is denoted by action A<b>19</b> in the figure. Merchant website <b>20</b> may then sends the received dynamic payment information to acquiring bank <b>50</b> to process the transaction. As a third way, validation entity <b>80</b> may send the dynamic payment information directly to merchant website <b>20</b>, as shown by action A<b>18</b>-A in the figure, along with information about user <b>1</b> and/or the user's browser session with the merchant that may have been previously collected in one or more of actions A<b>11</b>-A<b>14</b> and sent to entity <b>80</b> in action A<b>16</b>. Merchant website <b>20</b> can use this additional information to correlate the received dynamic payment information to the user's browser session, and can resend the checkout page to computer <b>10</b> with an indication that the PAN, CVV, and expiration date data have been received (such as showing asterisks in these fields). As another approach, entity <b>80</b> can provide merchant <b>80</b> with the user's name and a portion of the user's real PAN, and merchant <b>80</b> can determine if the user has previously set up an account with the merchant (the user would have provided the portion of the real PAN when the account was set up, and merchant <b>20</b> would have stored the portion). If so, and if user <b>1</b> had logged into her account prior to navigating to the checkout page, then merchant <b>20</b> can easily identify the user's purchasing session from all of the active purchasing sessions, and can correlate the payment information from entity <b>80</b> to the correct purchase session and correct checkout page.

0021Once merchant <b>20</b> receives the dynamic payment information, the purchase transaction may be completed through the conventional credit card/debit card processing channels. In action A<b>20</b>, merchant <b>20</b> sends the transaction information, including the dynamic payment information for the user, to its acquiring bank <b>50</b>, the acquiring bank <b>50</b> records the information (for later settlement purposes), and forwards the transaction information in action A<b>21</b> to a payment processing network <b>70</b>, which may be VisaNet™ as one example. If payment processing network <b>70</b> recognizes the PAN provided in the transaction information as a dynamic PAN, it may contact validation entity <b>80</b> in action A<b>22</b> to ask for the real payment information. Validation entity <b>80</b> can check the dynamic PAN received from network <b>70</b> against its records, and provide network <b>70</b> with the corresponding real payment information in action A<b>23</b>. As another approach, validation entity <b>80</b> may forward the user's dynamic payment information along with the user's real payment information when the dynamic payment information is generated in action A<b>17</b>, thereby enabling actions A<b>22</b> and A<b>23</b> to be omitted. Network <b>70</b> may then check each transaction it receives against the information sets that it has received from entity <b>80</b> to find a match of the sets of dynamic payment information, and to substitute real payment information for the received dynamic payment information if a match is found. Network <b>70</b> and entity <b>80</b> may be owned and operated by the same service provider, and each may have their messages funneled through (e.g., passed through) a gateway server. Each of the authorization code and the decline code has a different format from that of the each of the above-described PANs. An authorization/decline code is less than 13 characters in length, and is typically 5 to 9 characters in length, and may include alpha characters and well as numeric digits.

0022Once payment processing network <b>70</b> has the real payment information, it can contact the issuing bank <b>60</b> for user <b>1</b> to seek approval for the transaction, as shown by action A<b>24</b> in the figure. In some cases, issuing bank <b>60</b> may have previously given network <b>70</b> a set of criteria that network <b>70</b> can use to approve transactions on its own without seeking approval from the issuing bank for each transaction. If so, network <b>70</b> can approve or disapprove the transaction on its own using the pre-supplied criteria as part of action A<b>24</b>. In action A<b>25</b>, payment network <b>70</b> sends, along with an indication of the transaction, an authorization code to acquiring bank <b>60</b> if the transaction is approved or a declined code if the transaction is not approved. In action A<b>26</b>, acquiring bank <b>50</b> finds the record for the transaction based on the indication of the transaction sent by network <b>70</b>, stores the authorization code or declined code in the found record, and forwards the received code to merchant <b>20</b>, along with an indication of the transaction. Upon receiving the authorization or declined code, the merchant website <b>20</b> can send an indication to user <b>1</b> in action A<b>27</b> as to whether the transaction was approved or declined.

0023Computer <b>10</b> and merchant website <b>20</b> may communicate with one another over a public communication network, which may include the Internet. Also, computer <b>10</b> and validation entity <b>80</b> may communicate with one another over a public communications network, which may include the Internet. Entities <b>20</b>, <b>50</b>, <b>60</b>, <b>70</b>, and <b>80</b> may communicate with one another over a combination of one or more public and private communications networks, which may include the Internet. Virtual private networks may be established between these components, particularly over the segments that are public networks. Each of the above possible combinations of communication networks is generally denoted herein and in the figures by reference number <b>31</b>.

0024An advantage of using dynamic payment information is that the real payment information (e.g., the above-mentioned user-specific payment information) is not compromised if a hacker is able to receive and decrypt the request message for dynamic payment information sent from secure element <b>40</b> to validation entity <b>80</b>. This allows user <b>1</b> to continue to use her user-specific payment information (e.g., portable consumer device <b>5</b>) in other commerce channels, such as in-store purchases, even if the hacker tries to use the dynamic payment information in a transaction. Enhanced protection is provided by using a dPAN instead of the real PAN in the dynamic payment information. Using the pseudo-PAN in the request messages to obtain dynamic payment information also has the above advantages of protecting the real PAN. As an additional advantage of using the pseudo-PAN, payment processing network <b>70</b> can be configured to send an alert message to validation entity <b>80</b> whenever a transaction is attempted to be processed through network <b>70</b> with the pseudo-PAN, and entity <b>80</b> can flag the user's account for potential fraud, and the operator of entity <b>80</b> can send the user an updated payment application program to install on secure element <b>40</b>, with the updated payment application program having new encryption keys, and optionally a new unique identifier for secure element <b>40</b>. In this manner, with the pseudo-PAN having the form of a PAN that can be processed by payment processing network <b>70</b>, the pseudo-PAN further provides the advantage of detecting the hacking of communication messages between secure element <b>40</b> and validation entity <b>80</b>. To further aid in this detection, secure element <b>40</b> may include a fake expiration date and fake CW value along with the pseudo-PAN in the request messages that it sends to entity <b>80</b>. As indicated above, the account number of the user-specific payment information, and pseudo-PAN, and the dynamic PAN are each recognizable and processable by a card payment processing network <b>70</b> that processes credit-card and/or debit-card transactions, such as VisaNet™. (The payment processing network <b>70</b> is independent of the bank that issued the user-specified payment information, and the merchants involved with the user's transactions.) Also, each of the above account numbers (PAN) comprises a sequence of at least eleven numeric digits, preferably of 13 digits, and typically is a sequence of 15, 16, 17, 18, or 19 digits. These features of the account numbers enable the above requests to establish and receive a pseudo-PAN, to receive a dynamic PAN, and to use a dynamic PAN to all be processed through existing and legacy card payment networks without the need for significant changes the existing payment processing networks.

0025Having this provided a description of overall systems and methods, descriptions of the specific components is now provided. The user's computer <b>10</b> may comprise a desktop computer, a laptop computer, a smart phone, or any portable electronic device that has a networking facility. Referring to <figref idref="DRAWINGS">FIG. 2</figref>, an exemplary implementation of computer <b>10</b> has one or more processors <b>11</b>, a tangible non-transitory computer-readable medium <b>12</b> coupled to processor(s) <b>11</b> that stores instruction codes (software) that direct processor(s) <b>11</b> and that stores data used by processor(s) <b>11</b>, an I/O controller <b>15</b> that interfaces processor(s) <b>11</b> to a user interface <b>13</b>, and a networking facility <b>14</b>. User interface <b>13</b> comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.) for user <b>1</b> to receive information from computer <b>10</b> and to provide input to computer <b>10</b>. Networking facility <b>14</b> may comprise software and hardware that enable a process running on computer <b>10</b> to communicate with a communications network so as to send and receive messages, data, and the like to one or more entities coupled to the communications network. The above components are found in conventional computers. As an unconventional feature, the exemplary implementation of computer <b>10</b> shown in <figref idref="DRAWINGS">FIG. 2</figref> further comprises a secure element <b>40</b> of the type described above with reference to <figref idref="DRAWINGS">FIG. 1</figref>. Secure element <b>40</b> has its own processor and memory, as described below, or multiplexes the use of processor(s) <b>11</b> and computer-readable medium <b>12</b> in a secure manner that prevents the operating system from controlling it or accessing its memory. The above-described payment application is loaded into the memory of secure element <b>40</b>, and executed by the processor of element <b>40</b>. The data flowing between I/O controller <b>15</b> and user interface <b>13</b> goes through secure element <b>40</b> so that secure element <b>40</b> can provide visual information to the user via the computer's screen, and can receive user inputs from user interface <b>13</b> and prevent the inputs from being received by I/O controller <b>15</b> when secure element <b>40</b> is actively interfacing with the user. Secure element <b>40</b> can be integrally assembled with processor(s) <b>11</b> of computer <b>10</b>, such as on the same semiconductor die or in the same semiconductor package, so that the processor <b>11</b> has to be damaged or destroyed in order to obtain the data and encryption keys stored in secure element <b>40</b>.

0026Computer-readable medium <b>12</b> of computer <b>10</b> may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory. Computer-readable medium <b>12</b> stores an operating system for computer <b>10</b>, which enables processes and applications to be run by processor(s) <b>11</b>. The operating system provides services to these processes and applications, and enables these processes and applications to access components of user interface <b>13</b>, portions of computer-readable medium <b>12</b>, networking facility <b>14</b>, peripheral interface <b>16</b>, and other components of computer <b>10</b>. The operating system may be complex and full featured, such as found on desk-top computers, or simplified, such as found on cell phones, PDAs, and many other types of portable electronic devices.

0027The companion application for element <b>40</b>'s payment application is loaded onto computer-readable medium <b>12</b>, and is executed by processor(s) <b>11</b>. Access to a small portion of computer-readable medium <b>12</b> may be shared with the processor of secure element <b>40</b>. The payment application running on secure element <b>40</b> and the companion application running on processor(s) <b>11</b> can communicate with one another using the shared portion of medium <b>12</b>. For example, each application may be assigned a “mail box” section and a “flag” section in the shared portion, with both sections being readable and writable by each application. When the payment application wants to send data and instructions to the companion application, it can write the instructions and/or data into the mailbox section for the companion application, and then write a data word to the “flag” section for the companion application that indicates that the mailbox has just been written to. The companion application can periodically check its flag section for such a data word, and when found, it can read its mail box, then erase the contents of its mail box section and reset its flag section to zero. The data word written to the flag section may be a non-zero integer value that indicates the number of words (or bytes) written to the mail box section. Before writing to the mailbox section of the companion application, the payment application can periodically read the flag section of the companion application, and can write the instructions and/or date when the flag section has a zero word value. In a similar manner, when the companion application wants to send data and instructions to the payment application, it can write the instructions and/or data into the mailbox section for the payment application, and then write a data word to the “flag” section for the payment application that indicates that the mailbox has just been written to. The payment application can periodically check its flag section for such a data word, and when found, it can read its mail box, then erase the contents of its mail box section and reset its flag section to zero. As above, the data word written to the flag section may be a non-zero integer value that indicates the number of words (or bytes) written to the mail box section. Before writing to the mailbox section of the payment application, the companion application can periodically read the flag section of the payment application, and can write the instructions and/or data when the flag section has a zero word value. The companion application may be downloaded and installed by the user before starting the set up process outlined in <figref idref="DRAWINGS">FIG. 1</figref> (e.g., before action A<b>1</b>). The companion application may be configured by the operating system registry to run as a low-CPU level background process each time the computer is booted up.

0028<figref idref="DRAWINGS">FIG. 3</figref> shows an exemplary embodiment of secure element <b>40</b>. The exemplary embodiment comprises a processor <b>41</b>, a tangible non-transitory computer-readable medium <b>42</b> coupled to processor <b>41</b> that stores instruction codes that direct processor <b>41</b> and that stores data used by processor(s) <b>41</b>, an I/O controller <b>45</b> that interfaces processor <b>41</b> to computer-readable medium <b>12</b> and user interface <b>13</b> of computer <b>10</b>, and a networking facility <b>14</b>, and a multiplexer unit <b>46</b> that selectively connects user interface <b>13</b> to I/O controller <b>45</b> of secure element <b>40</b> when secure element <b>40</b> is interfacing with user <b>1</b>, and that selectively connects user interface <b>13</b> to I/O controller <b>15</b> of computer <b>10</b> when secure element <b>40</b> is not interfacing with user <b>1</b>. The payment application is stored in medium <b>42</b>, and it comprises codes that direct processor <b>41</b> to perform the above-described tasks. The payment application also has encryption keys stored in medium <b>42</b> that it uses to encrypt communications to validation entity <b>80</b>, and to decrypt communications from validation entity <b>80</b>. These keys and the encrypting of the messages enable the secure element to keep the payment information secure from malware that may be running on the operating system of computer <b>10</b>. The payment application can be loaded into memory <b>42</b> at the factory by the computer manufacturer, and it can also be loaded into memory <b>42</b> in the field by the user. For the latter case, the payment application, including user specific encryption keys, may be securely provided to the user on a CD-ROM or memory card, and user interface <b>13</b> can have a ROM drive or USB port that can allow the program to be securely transferred to memory <b>42</b> when secure element <b>40</b> is activated by the user. For this, and to provide a basic graphical user interface (GUI) to the user, a rudimentary operating system may be loaded onto memory <b>42</b> at the factory by the computer manufacturer, with the operating system being run by processor <b>41</b>. The rudimentary operating system can be configured to provide a loading facility to load applications from secured devices of user interface <b>13</b> into memory <b>42</b>.

0029The companion application is stored on the computer's medium <b>12</b> and comprises code that directs the computer's processor(s) <b>11</b> to establish and handle communications with validation entity <b>80</b> using networking facilities <b>14</b> of computer <b>10</b> and the shared portion of computer-readable medium <b>12</b>. The companion application may also comprise code that directs the computer's processor(s) <b>11</b> to obtain the merchant identifier from the web browser running on the operating system, and to provide the merchant identifier to the secure element through the shared portion of medium <b>12</b>. The companion application may also comprise code that directs the computer's processor(s) <b>11</b> to receive display dynamic payment information from secure element <b>40</b> through the shared memory, and to display it to the user, or to form fill the dynamic information into the checkout page of the merchant, as displayed by the user's browser. The companion application may also comprise code that directs the computer's processor(s) <b>11</b> to detect a specific keyboard sequence or combination of keys of the keyboard, and to send a message to secure element <b>40</b> to start its interface with the user and to decouple user interface <b>13</b> from the operating system. In view of this description, one of ordinary skill in the computer software art can readily create a set of instructions to implement the companion program without undue experimentation.

0030With regard to computer <b>10</b>, networking facility <b>14</b> of computer <b>10</b> may comprise software and hardware that enable a process running on computer <b>10</b> to communicate with a communications network, such as network <b>31</b>, to send and receive messages, data, and the like to one or more entities coupled to the communications network. The hardware of facility <b>14</b> may comprise dedicated hardware separate from processor(s) <b>11</b>, or the shared use of processor(s) <b>11</b>, or a combination thereof. The software of facility <b>14</b> may comprise firmware, software stored in computer-readable medium <b>12</b> or another computer-readable medium, portions of the operating system, or a combination of any of the preceding items. Networking facility <b>14</b> is preferably a non-exclusive resource, allowing access to the communications network by other processes and applications being run by computer <b>10</b>.

0031The operating system of computer <b>10</b> comprises one or more software modules and application programs, generically called “network services modules” herein, that can access networking facility <b>14</b> and set up communications sessions to entities on communications network <b>31</b>. Such network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, the OS Services Layer and the Base Services Layer of the Symbian operating system, Internet browsers, and the like. Each of these network services modules is non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and provides an application programming interface (API) to a collection of functions that a processor can access using respective function calls. With these API facilities, a collection of function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network <b>31</b> coupled to networking facility <b>14</b>, and to exchange messages and data with the entity. The companion application can have such a collection of function calls to the API of a network services module of computer <b>10</b>, including one or more function calls that provide the universal resource identifier (URID) for validation entity <b>80</b> (as passed to the companion application by the payment application) and an instruction to establish a session with the validation entity. The session may be a secure socket layer (or secure transport layer) session (e.g., SSL session, STL session) with mutual authentication. As part of establishing the session in some implementations, the companion application may include directing data processor <b>41</b> to provide, or to cause to be provided, a network address for the computer's network services module to validation entity <b>80</b>. The network address may be static or dynamic, the latter of which may be obtained through API function calls to the computer's network services module. The network address may an IP address.

0032If the companion application wishes to use an Internet browser for a network services module, it may further comprise API function calls to the computer's operating system to initiate an instance of the browser and provide it with access to the browser instance. In some implementations, such as when the payment application in secure element <b>40</b> stores the URID of validation entity <b>80</b>, the companion application may direct the data processor <b>41</b> to establish communications with validation entity <b>80</b> well before user <b>1</b> invokes secure element <b>40</b> to request it to pay for a transaction. The companion application and validation entity <b>80</b> may keep the communications session active until the user makes such a request, and between requests, by intermittently exchanging “heartbeat” messages. For example, the companion application may periodically, aperiodically, or randomly send messages to validation entity <b>80</b> confirming its presence in the session, and validation entity <b>80</b> may send a reply message confirming its presence in the session.

0033Referring back to <figref idref="DRAWINGS">FIG. 3</figref>, secure element <b>40</b> comprises various codes embodied on computer-readable medium <b>42</b> that direct data processor <b>41</b> to perform respective actions. A first code directs data processor <b>41</b> to communicate with computer <b>10</b> by way of the companion application so as to gain access networking facility <b>14</b> of computer <b>10</b>. The first code may comprise code that directs data processor <b>41</b> to send and receive instruction and data by way of the above-described mailbox and flag section of the shared portion of medium <b>12</b>, and may include instructions the direct processor <b>41</b> to carry out the above-described actions of the exchange protocol. The companion application may comprises a collection of instructions that enables the element's data processor <b>41</b> to make function calls to various application program interfaces (API's) of the computer's operating system, such as those related to networking and accessing networking facility <b>14</b>. In this manner, the element's data processor <b>41</b> can sent function calls intended for computer <b>10</b> to the companion application, and the companion application can submit the function calls to the operating system of computer <b>10</b> on behalf of the processor <b>41</b>, and can receive the results of the function calls and forward them to processor <b>41</b>.

0034Another code of the payment application on secure element <b>40</b> directs data processor <b>41</b> to establish communications with validation entity <b>80</b> using networking facility <b>14</b> of computer <b>10</b>. This can be done by providing a URL of entity <b>80</b> to the companion application and directing the companion application to establish the communications with entity <b>80</b>.

0035Other codes of the payment application direct data processor to establish a first secure interface with user <b>1</b> to receive the information described above pertaining to the user's portable consumer device <b>5</b>, to encrypt this information and an identifier of the secure element with an encryption key stored in medium <b>42</b>, to provide this encrypted information to the companion application with an instruction that it is to send it to validation entity <b>80</b> (so as to obtain a pseudo-PAN), to receive back an encrypted message from entity <b>80</b> by way of the companion application, to decrypt the encrypted message and extract the pseudo-PAN, and to store the pseudo-PAN. These codes may comprises: code that directs data processor <b>41</b> to receive a real account number and at least one of an expiration date, a card verification value, or a billing ZIP code of user-specific payment information; code that directs data processor <b>41</b> to obtain an identifier for secure element <b>40</b>; code that directs data processor <b>41</b> to send the received real account number, the received at least one of an expiration date, a card verification value, or a billing ZIP code, and the obtained identifier for the secure element to validation entity <b>80</b>; code that directs data processor <b>41</b> to receive, in response, a pseudo account number from the validation entity <b>80</b>, the received pseudo account number being different from the real account number of the user-specific payment information; and code that directs data processor <b>41</b> to store, in memory <b>42</b> of the secure element, the received pseudo account number. The payment application may be stored in a non-volatile section of memory <b>42</b>, and may contain the unique identifier for secure element <b>40</b>. This allows the value of the identifier to be updated with a reloading of the payment application, such as when fraudulent activity is detected by entity <b>80</b>. As another approach, the unique identifier for secure element <b>40</b> may be stored by the manufacturer of element <b>40</b> in non-volatile part of memory <b>42</b> that is separate from the location where the payment application is stored. As another approach, the identifier may be a combination of a number stored with the payment application and a number stored by the manufacturer in a part of memory <b>42</b> that is separate from the payment application.

0036Additional codes of the payment application direct data processor to establish a second secure interface with user <b>1</b> at a later date to receive a request to obtain dynamic payment information, which may include receiving a selection of an pseudo-PAN account from the user, to encrypt this pseudo-PAN and an identifier of the secure element with an encryption key stored in medium <b>42</b>, to provide this encrypted information to the companion application with an instruction that it is to send it to validation entity <b>80</b> (so as to obtain the dynamic payment information), to receive back an encrypted message from entity <b>80</b> by way of the companion application, to decrypt the encrypted message and extract the dynamic payment information. These codes may also include instructions that direct data processor <b>41</b> to send a message to the companion application with an instruction to find and provide it with the merchant identifier associated with the active merchant checkout page, encrypting the merchant identifier, and sending the encrypted merchant identifier to entity <b>80</b> with the other data in the request. Additional instructions may direct data processor <b>41</b> to display the decrypted dynamic payment information to the user, or to send the decrypted dynamic payment information to the companion application with an instruction that the companion application display the dynamic payment information in a window, or to direct the companion application to fill the dynamic payment information into the merchant checkout page. These codes collectively comprise at least: code that directs data processor <b>41</b> to send, from the secure element of a computer, a representation of the pseudo account number to a validation entity; and code that directs data processor <b>41</b> to receive, in response, dynamic payment information from the validation entity, the received dynamic payment information having an account number that is different from the pseudo account number.

0037In establishing the above secure interfaces with the user, data processor <b>41</b> can send and instruction to multiplexer unit <b>46</b>, by way of I/O controller <b>45</b>, to prevent inputs from user interface <b>13</b> from reaching the I/O controller <b>15</b> of computer <b>10</b>.

0038The above codes, instructions, and actions of the payment application and the companion application can be readily implemented with conventional I/O instructions, database function calls, network function calls, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, these codes, instructions, and actions may be implemented by one of ordinary skill in the art without undue experimentation. Data processor <b>41</b> may be implemented with one CPU or multiple CPUs.

0039Having described various embodiments and implementations of secure element <b>40</b>, various embodiments and implementations of validation entity <b>80</b> are now described with reference to <figref idref="DRAWINGS">FIG. 4</figref>. Validation entity <b>80</b> comprises a system having one or more servers coupled to a communications network <b>31</b> that can receive a request from a secure element <b>40</b> to process, and to provide the appropriate data depending upon the request, as described above. One of the servers of entity <b>80</b> is shown in <figref idref="DRAWINGS">FIG. 4</figref>; the server comprises one or more processors <b>81</b> electrically coupled to each of a tangible computer-readable medium <b>82</b>, a user interface <b>83</b>, one or more databases <b>86</b>, and a networking facility <b>84</b>, the latter of which is coupled to one or more communications networks <b>31</b> so that it can communicate to computer <b>10</b>, merchant <b>20</b>, payment processing network <b>70</b>, and banks <b>50</b> and <b>60</b>. User interface <b>83</b> comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator of entity <b>80</b> to receive information from the server and to provide input to the server. Computer-readable medium <b>82</b> may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory. Data processor <b>81</b> may be implemented with one CPU or multiple CPUs.

0040Computer-readable medium <b>82</b> stores an operating system for the server, which enables processes and applications to be run by processor(s) <b>81</b>, and enables codes for directing the operation of processor(s) <b>81</b> to be run. The operating system provides services to these processes and applications, and enables these processes and applications to access components of user interface <b>83</b>, portions of computer-readable medium <b>82</b>, networking facility <b>84</b>, and other components of entity <b>80</b>. The operating system may be full featured. Specifically, the operating system provides one or more I/O communications modules that enable processor(s) <b>81</b> to communicate with user interface <b>83</b> and databases <b>86</b>. Each I/O communications module has an application programming interface (API) with a collection of functions that a processor <b>81</b> can call in order to access the components. The operating system of entity <b>80</b> also comprises one or more network services modules that can access networking facility <b>84</b> and set up communications sessions to entities on the communications networks <b>31</b>. Such network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, and the OS Services Layer and the Base Services Layer of the Symbian operating system, and the like. Each of these network services modules can be non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and each provides an application programming interface (API), which has a collection of functions that a processor <b>81</b> can call in order to manage communications with another entity. With these API facilities, a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled to networking facility <b>84</b>, and to exchange messages and data with the entity. The above operating system, modules, and APIs all include instructions that direct the operation of processor(s) <b>81</b>.

0041One or more databases <b>86</b> may be configured as database servers, which processor(s) <b>81</b> can access via networking facility <b>84</b> over a private communications network <b>87</b>, which is illustrated by the dashed line in <figref idref="DRAWINGS">FIG. 4</figref>. Validation entity <b>80</b> conventionally has a clock <b>88</b> for tracking time and dates for various applications. Clock <b>88</b> may be a simple counter of seconds, or fractions thereof, that can be read by processor <b>81</b> by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read by processor <b>81</b> through the execution of one or more I/O operations.

0042Validation entity <b>80</b> can process requests transmitted from a plurality of different secure elements <b>40</b> (e.g., millions of elements), and can process any number of transmissions by a particular element <b>40</b>. As described above, there are two basic types of requests: (1) a request to obtain a pseudo-PAN for a real account (e.g., account of portable consumer device <b>5</b>), and (2) a request to obtain dynamic payment information (e.g., a d-PAN) corresponding to a pseudo-PAN. The former may be referred to as a pseudo-PAN request, and the latter may be referred to as a dynamic-information request. Validation entity <b>80</b> applies one or more validation tests to secure element <b>40</b> and/or the information in its requests to obtain a level of confidence that the requests are legitimate. When the one or more validation tests are passed, and preferably when none of the tests are failed, validation entity <b>80</b> sends the requested data to secure element <b>40</b>, and optionally to payment processing network <b>70</b> along with the real account number (e.g., real PAN) associated with the request. For these tasks, validation entity <b>80</b> may comprise code embodied on computer-readable medium <b>82</b> that directs data processor <b>81</b> to communicate with computer <b>10</b> and secure element <b>40</b> using networking facility <b>84</b> over communications network <b>31</b>. This code may include instructions that establish a communications session with computer <b>10</b>, including the option of establishing an SSL/STL session with mutual authentication and encryption based on a triple DES algorithm, and instructions for sending and receiving messages to secure element <b>40</b> through the communications session. Validation entity <b>80</b> may further comprise code embodied on computer-readable medium <b>82</b> that directs data processor <b>81</b> to receive encrypted requests sent by secure element <b>40</b>, and code that directs data processor <b>81</b> to decrypt the encrypted information in the requests. This information may be encrypted by a session key of an SSL/STL session or by an encryption key stored in secure element <b>40</b> and known to validation entity <b>80</b>, or may be doubly encrypted by both keys. The latter key may be uniquely assigned to the secure element. Validation entity <b>80</b> may further comprise code embodied on computer-readable medium <b>82</b> that directs data processor <b>81</b> to apply one or more validation tests as described below, and to send the requested data to secure element <b>40</b>, and optionally to payment processing network <b>70</b>, if a selected number of validation tests are passed. Data processor <b>81</b> may access databases <b>86</b> in performing the one or more validation tests. The validation tests and codes therefor are described below in greater detail. The above codes and codes described below for validation entity <b>80</b> may be implemented in any number of programming languages. They can be implemented with conventional I/O instructions, database function calls, network function calls, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. Furthermore, one of ordinary skill in the art will be readily able to construct instructions to implement these codes in view of this disclosure without undue experimentation.

0043A first validation test that validation entity <b>80</b> may apply pertains to verifying that secure element <b>40</b> is authentic. Validation entity <b>80</b> may maintain a first database <b>86</b> of valid identifiers of the secure elements, and this database may also include indications of whether a valid identifier has been associated with fraudulent activity. The first validation test may comprise determined whether the received identifier of secure element <b>40</b> is in the first database <b>86</b> of valid identifiers. If it is, the first validation test is passed; if not, it is failed. If the first validation test is failed, validation entity <b>80</b> may record the identifier of the failed secure element <b>40</b> and the source IP address from which the failed secure element <b>40</b> made the request in a third database <b>86</b> described below. A second validation test that validation entity <b>80</b> may apply pertains to verifying that secure element <b>40</b> has not been involved in fraudulent transactions. For this, validation entity <b>80</b> may also have a second database <b>86</b> that tracks the identifiers of secure elements <b>40</b> that have been used in fraudulent activities, and may check the identifier of secure element <b>40</b> against this database. If the identifier in the request is found in the second database, the second validation test is deemed to have failed. The second validation test may further comprise checking the element's identifier and/or the IP address from which an incoming request was originated (the source IP address of the message) against the previously-described third database <b>86</b> that stores element identifiers and IP addresses associated with requests that have failed the first validation test. If an element identifier or IP address is found in this database, the second validation test is deemed to have been failed. Checking the element identifiers and/or the IP addresses in this way prevents replay attacks by fraudsters. It may be appreciated that the second and third databases <b>86</b> into a single database generically termed as a database of identifiers of suspicious secure elements. If the first and second validation tests are passed, validation entity <b>80</b> may send the pseudo account number or dynamic payment information, depending upon the type of received request, to secure element <b>40</b>, or may apply the additional validation tests described below before sending the information.

0044When validation entity <b>80</b> receives a pseudo-PAN request from secure element <b>40</b> for a pseudo-PAN, the request will have the real account number (e.g., real PAN) of the portable consumer device <b>5</b>, and additional information, which is at least one of an expiration date, a card verification value, or a billing ZIP code associated with device <b>5</b>. As a third validation test, in addition to conducting the above first and second validation tests, entity <b>80</b> may access its database <b>86</b> of user account information or contact the bank that issued the user-specific payment information (e.g., device <b>5</b>), thereby obtaining the information record for the real PAN provided in the pseudo-PAN request, and can compare the additional information provided in the pseudo-PAN request (e.g., expiration date, card verification value, and/or a billing ZIP code) against the values in the obtained information record. If the additional information in the pseudo-PAN request does not fully match the information in the obtained information record, the third validation test can be deemed to have been failed, and the pseudo-PAN request is rejected. If the additional information fully matches the information in the obtained information record, third validation is passed, and validation entity <b>80</b> may proceed to provide secure element <b>40</b> with a pseudo-PAN corresponding to the real PAN, and may create a record in a fourth database <b>86</b> that associates the issued pseudo-PAN with the user account of device <b>5</b> (e.g., with the real PAN of the user-specific payment information), and with the received identifier for secure element <b>40</b>. As an option, validation entity may conduct a fourth validation test after the third test before providing the pseudo-PAN to secure element <b>40</b>. In this test, the issuing bank and/or payment network <b>70</b> and/or validation entity <b>80</b> may limit the number of computers with secure elements <b>40</b> that user <b>1</b> can use with a particular instance of user-specific payment information (e.g., that user <b>1</b> can use with a particular portable consumer device <b>5</b>). As the forth validation test, entity may access a fifth database <b>86</b> to determine if a limit on the number of secure elements <b>40</b> has been placed on the received instance of user-specific payment information (e.g, device <b>5</b>). if so, entity <b>80</b> can access the aforementioned fourth database <b>86</b> to see how many secure elements have already been associated with the received instance of user-specific payment information (e.g., with the real PAN for device <b>5</b>). If the limit has not yet been reached, entity <b>80</b> proceeds with providing the pseudo-PAN to secure element <b>40</b> and updating the fourth database <b>86</b> to include the new pseudo-PAN and the identifier of the secure element <b>40</b> to which the pseudo-PAN has been provided. Entity <b>80</b> also updates the fourth database <b>86</b> to increment the number of secure elements associated with device <b>5</b>. It may be appreciated that the fourth and fifth databases <b>86</b> may be combined together into a single database.

0045When validation entity <b>80</b> receives a dynamic-information request from secure element <b>40</b> for dynamic payment information, the request will have pseudo-PAN and the identifier of secure element <b>40</b> that made the request. As a fifth validation test, in addition to conducting the above first and second validation tests, entity <b>80</b> may access its fourth database <b>86</b> to obtain the record for the received pseudo-PAN, obtain the identifiers for all of the secure elements that have been previously associated with the received pseudo-PAN (as associated by the processing of the above pseudo-PAN requests), and to compare the identifier for secure element <b>40</b> received in the dynamic-information request against the identifier(s) in the accessed record for a match of identifiers. If no match is found, the fifth validation test is deemed to have failed, and validation entity <b>80</b> can record the received identifier for element <b>40</b> in the above-mentioned second database <b>86</b> of secure elements associated with fraudulent transactions. If a match is found, validation entity <b>80</b> can send the dynamic payment information (e.g., d-PAN, dCW2, and dynamic expiration date) to secure element <b>40</b>, can record the contents of the issued dynamic payment information and the indication of the corresponding customer account for device <b>5</b> (e.g., with the real PAN of the user-specific payment information), in a sixth database <b>86</b>, and can optionally send the dynamic payment information and the real payment information (i.e., the user-specific payment information) to payment processing network <b>70</b> with an indication that the dynamic data will be used soon in a transaction to be processed by network <b>70</b>.

0046As described above, validation entity <b>80</b> may send to secure element <b>40</b> the user's shipping address information and/or billing address information that has been previously associated to user <b>1</b>. The association may be stored in a database <b>86</b> of validation entity <b>80</b> or at the issuing bank <b>60</b> for the user's portable consumer device <b>5</b>. Validation entity <b>80</b> may further comprise code that directs data processor <b>81</b> to obtain address information for the consumer account indicated by the pseudo account number in the received request, either from a database <b>86</b> or from an issuing bank <b>60</b>, and to send the address information to element <b>40</b> along with the dynamic payment information when the selected number of validation tests have been passed, as described above. The above codes and actions can be implemented with conventional I/O instructions, database function calls, network function calls, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.

0047As indicated above, validation entity <b>80</b> may be configured to send a dynamic account number (dPAN) to secure element <b>40</b> and the payment processing network <b>70</b> along with a dCW2 value and/or a dynamic expiration date. Validation entity <b>80</b> may contact the issuing bank <b>60</b> for device <b>5</b> to obtain the dPAN, or may read it from a list of dPANs previously sent to entity <b>80</b> by bank <b>60</b> or created by entity <b>80</b> or network <b>70</b>, or may generate it from an algorithm previously provided to entity <b>80</b> by bank <b>60</b>. Validation entity <b>80</b> may comprise code embodied on computer-readable medium <b>82</b> that directs data processor <b>81</b> to execute these actions, as desired by the issuing bank. When payment processing network <b>70</b> received the dCCV2 value, dPAN value, and the account number for device <b>5</b>, it may forward all three datum to the issuing bank <b>60</b> so that the issuing bank can correlate the dPAN to the account number of device <b>5</b>.

0048To perform the above actions and tasks, validation entity <b>80</b> may comprises a computer program product installed on its computer-readable memory <b>82</b>. The computer program product may comprise: code that directs data processor <b>81</b> to receive a request from a secure element <b>40</b> of a computer to provide a pseudo account number, the request including an identifier of the secure element, and a real account number (PAN) and at least one of an expiration date, a card verification value, or a billing ZIP code of an instance of user-specific payment information; code that directs data processor <b>81</b> to apply at least one validation test pertaining to the received request; code that directs data processor <b>81</b> to send, if the at least one validation test is passed, a pseudo account number to the secure element; and code that directs data processor <b>81</b> to store the pseudo account number with an indication of at least the received real account number in one of its databases <b>86</b>. The program may further comprise: code that directs data processor <b>81</b> to receive a request from a secure element <b>40</b> of a computer to provide dynamic payment information, the request including a pseudo account number and an identifier of the secure element; code that directs data processor <b>81</b> to apply at least one validation test pertaining to the received request; and code that directs data processor <b>81</b> to send, if the at least one validation test is passed, dynamic payment information to the secure element. The computer program product may further comprise code that directs data processor <b>81</b> to receive a request from a payment processing network <b>70</b> to provide real payment information corresponding to an instance of dynamic payment information; and code that directs data processor <b>81</b> to provide the requested real payment information to the payment processing network <b>70</b>.

0049The further embodiments of the computer program product may be adapted to convey the payment information directly to the merchant, and to a payment processing network. For example, a further computer program product may comprise: code that directs data processor <b>81</b> to receive a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number, an identifier of the secure element, and an identifier of a merchant; code that directs data processor <b>81</b> to apply at least one validation test pertaining to the received request; and code that directs data processor <b>81</b> to send, if the at least one validation test is passed, dynamic payment information to a merchant indicated by the received merchant identifier. In another embodiment, such a computer program produce may comprise: code that directs data processor <b>81</b> to receive a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number, an identifier of the secure element, and an identifier of a merchant; code that directs data processor <b>81</b> to apply at least one validation test pertaining to the received request; code that directs data processor <b>81</b> to send, if the at least one validation test is passed, dynamic payment information to secure element <b>40</b>; and code that directs data processor <b>81</b> to send, if the at least one validation test is passed, the dynamic payment information and an indication of the identity of the merchant to a payment processing network <b>70</b>.

0050The above described validation tests can be implemented by the following instructions of the computer program product. The first validation test can be implemented by instructions that direct data processor <b>81</b> to compare the receive identifier of the secure element <b>40</b> against a database of valid identifiers to find a match, the first validation test being passed if a match is found, otherwise failed. The second validation test can be implemented by instructions that direct data processor <b>81</b> to compare the receive identifier of the secure element against a database of identifiers of secure elements involved in prior fraudulent activity, the second validation test being failed if a match is found, otherwise passed. The instructions for the second validation test may also include instructions that direct data processor <b>81</b> to compare the IP address of the request sent by the secure element <b>40</b> against a database of IP addresses that have been associated with fraudulent activity, the second validation test being failed if a match in this database is found. The third validation test may be implemented by first instructions that direct data processor <b>81</b> to obtain the real payment information for the received account number of the user-specific payment information (e.g., portable consumer device <b>5</b>) from a database or the bank that issued the user-specific payment information (e.g., device <b>5</b>); and second instructions that direct data processor <b>81</b> to compare the received at least one of an expiration date, a card verification value, or a billing ZIP code to the real payment information for the received account number for a match, the third validation test being passed if a match is found, otherwise failed.

0051The fourth validation test can be implemented by first instructions that direct data processor <b>81</b> to access a database to determine the limit on the number of secure elements has been placed on the received real account number; second instructions that direct data processor <b>81</b> to access a database to determine the current number secure elements have already been associated to the received real account number; and third instructions that direct the data processor to compare the current number to the limit to determine if an additional association of a secure element would exceed the limit. If the limit would be exceeded, the fourth validation test is failed, otherwise it is passed. If a real account number is not eligible to be used with secure elements (e.g., the portable consumer device <b>5</b> is not enrolled in the program), then the limit for the account number may be set to zero, or the limit may be taken as zero if the account number is not in the database.

0052The fifth validation test can be implemented by first instructions that direct data processor <b>81</b> to access a database to obtain the record for the received pseudo account number; second instructions that direct data processor <b>81</b> to obtain from the record the identifiers for all of the secure elements <b>40</b> that have been previously associated with the received pseudo account number; and third instructions direct the data processor <b>81</b> to compare the identifier for the secure element received in the request against each identifier in the accessed record for a match. If a match is found, the fifth validation test is passed, otherwise it is failed.

0053Validation entity <b>80</b> may further comprise code that directs data processor <b>81</b> to receive a message from a payment processing network <b>70</b> that a transaction using a pseudo-PAN has been attempted, and code that directs data processor <b>81</b> to send an alert notification to the user to which the pseudo-PAN has been assigned, or the issuing bank of the user-specific payment information to which the pseudo-PAN has been assigned. The alert notification can indication that user's payment application should be replaced so as to provide new encryption keys, and optionally a new identifier for the secure element.

0054The above codes of the various embodiments of computer program products can be implemented with conventional I/O instructions, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.

0055It should be understood that various embodiments of the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.

0056Any of the software components or functions described in this patent application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, C, C++, C#, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

0057The above description is illustrative and is not restrictive. Many variations of the invention and embodiments thereof will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

0058One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

0059A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.

0060All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.