Verification of portable consumer devices. RU patent 2518680.

FIELD: physics, computer engineering.

SUBSTANCE: invention relates to verification of portable consumer devices. A verification token is connected to a computer by a USB connection in order to use networking facilities of the computer. The verification token reads identification information from a user portable consumer device and sends the information to a validation entry over a communication network using the networking facilities of the computer. The validation entity applies one or more validation tests to the information which it receives from the verification token. If a selected number of tests are passed, the validation entity sends a device verification value to the verification token, and optionally to a payment processing network. The verification token may enter the device verification value into a CVV field of a web page appearing on the computer display, or may display the value to the user using the computer display.

EFFECT: safer financial transactions using portable consumer devices (eg credit card).

20 cl, 8 dwg

A cross-reference to related applications

This application is a partial continuation of the earlier application number 12/712,148, entitled "Verification of Portable Consumer Devices", filed on February 24, 2010, the contents of which are fully included by reference in this document. In addition, this application claims the priority of the first application for a U.S. patent number 61/178,636, entitled "Dynamic Data Authentication", filed on may 15, 2009, the content of which is fully included by reference in this document.

THE LEVEL OF TECHNOLOGY

As the methods and devices to participate in financial transactions supplemented, old problems such as fraud and counterfeiting remain.

One of the main sources of Scam that is prevalent in the credit card industry is skimming. Skimming means electronic copying data from the magnetic strip cards, to create a fake card.

Skimming is predominantly a phenomenon affecting static transaction based on the magnetic strips. This is because a magnetic stripe, which is located on the back side of the card transaction and saves a lot of data on three separate tracks, is a passive medium. In other words, the digital contents of the magnetic stripe may be perfectly copied without any of the distinctions between the copy and the original.

One of the main means by which it can be prevented skimming, is a careful tracking user location card transactions. This can give the consumer an opportunity to prevent the holding of the card through improper device. However, as contactless cards are improving, the classical problem of skimming accompanies them when using static data. In fact, in a wireless environment the possibility illegal to copy data from the magnetic strip is more common. In wireless environment to potential skimmer no need to physically have a map, which must be illegally copied or to have access to any physical hardware (for example, POS-terminal, communication lines etc)that are required for skimming in a wired environment. Skimmer without information about the buyer or seller can intercept wireless transaction and copy the data transferred from the card in the POS-terminal.

To resolve the above problem, can be used dCVV, or a dynamic value verification of the card. For example, different systems and methods for formation dCVV are explained in the application at the U.S. patent number 10/642878, titled "Method and System for generating the Dynamic Verification Value", filed on August 18, 2003, and in the application at the U.S. patent number 11/764376, entitled "On-Line Payment Transactions", filed on January 29, 2008. Both of these applications are fully incorporated by reference into this document.

In addition to the formation of dCVV, dCVV may be more effective to prevent fraud, when it is safe accepted by the consumer. Nevertheless, safe intake and use dCVV cannot create undue obstacles for the customer when conducting the transaction. Consumers can use dCVV, or the consumer can spend less transaction, if the inconvenience of reception and use dCVV is too large.

Embodiments of the invention is aimed at solution of the above problems and other problems, individually and collectively.

SUMMARY OF THE INVENTION

Disclosed devices, methods and systems related to verification portable consumer devices.

One approximate variant of the invention is aimed at verification token to get the value of verification devices for portable consumer devices. Sample verification token contains peripheral interface, made to connect to peripheral computer interface, the reader is made to read identifying information from portable consumer devices, computer-readable media, a data processor, electrically connected with peripheral interface token verification, the reader and the computer-readable media, and a code embodied on computer-readable media, which instructs the processor data to perform different actions. In the sample implementation of a verification token contains the code that instructs the data processor to communicate with the computer by means of peripheral interface token verification and gain access to the network means of computer code that instructs the processor data to make the identification information read from the portable consumer devices through the reader, the code that instructs the processor data transfer at least part of acceptable identification information in the object, which can provide value verification device (for example, in an object of verification or gateway), by the network computer, and the code that instructs the processor data to receive, after the transfer of the aforementioned identity information, is verification of the object through the network computer. A verification token can send authentication information to the computer in a number of forms, including: (1) an unmodified form ("open"), (2) an encrypted form, (3) the hashed form (e.g., encrypted), (4) the signed form, (5) or any combination of these forms. These forms can be formed by means of portable consumer devices, token verification, computer, or any combination of the above. In addition, the token verification and the object (for example, an object of verification or gateway) can perform a mutual authentication process before the token verification sends authentication information. When used in the claims, the term "object that can provide value verification device" covers object of verification, gateway, or any combination of the above.

Another approximate variant of the invention is aimed at verification token to get the value of verification devices for portable consumer devices. Sample verification token contains peripheral interface, made to connect to peripheral computer interface, the reader is made to read identifying information from portable consumer devices, computer-readable media, a data processor, electrically connected with peripheral interface token verification, the reader and the computer-readable media, and a code embodied on computer-readable media, which instructs the processor data to perform different actions. In the sample implementation of a verification token contains the code that instructs the data processor to communicate with the computer by means of peripheral interface token verification and to access the network tool of the computer code that instructs the processor data to communicate using the network computer, with the object, which can provide value verification device (for example, with the object of verification or gateway that communicates with the object of verification), the code that instructs the processor data to make the identification information read from portable consumer devices through the reader, the code that instructs the processor data transfer at least part of acceptable identification information in the object (for example, in an object of verification or gateway), by means of the network computer, and the code that instructs the processor data to receive, after the transfer of the aforementioned identity information, is verification of the object through the network computer. A verification token can send authentication information to the computer in the forms specified above.

Another approximate variant of the invention is directed to the method of obtaining the values of verification devices for portable consumer devices. An approximate method contains establishing lines of communication between token verification and computer, and the computer has a network tool; read identifying information from portable consumer devices to the token verification; transfer a matter of identification information from the token verification in a facility that can provide value verification device (for example, in the checked object the reliability and/or gateway)via a network tool of the computer; and after the transfer of identification information reception, in token verification, the values verification of object (for example, from an object of verification and/or gateway) via the network computer. Identification information may be transferred from the token in the computer in a number of forms, including: (1) an unmodified form ("open"), (2) an encrypted form, (3) the hashed form (e.g., encrypted), (4) the signed form, (5) or any combination of these forms. These forms can be formed by means of portable consumer devices, token verification, computer, or any combination of the above. In addition, the method can include instruction for the verification token to authenticate the object of verification and/or gateway, for example, through a process of mutual authentication to pass the authentication information in the object of verification and/or gateway.

Another approximate variant of the invention is directed to the method of obtaining the values of verification devices for portable consumer devices. Approximate the method contains establishing lines of communication between token verification and computer, and the computer has a network tool; establish a communication session between token verification and object, which can provide value verification device (for example, an object of verification and/or gateway), by using the network tools computer; read identifying information from portable consumer devices to the token verification; transfer a matter of identification information from the token verification in the object (for example, in an object of verification and/or gateway), through the session; and after the transfer of identification information reception, in token verification, the values verification of object (for example, from an object of verification and/or gateway) via a communication session. Identification information may be transferred from the token to the computer in any of the above forms. In addition, the method can include instruction for the verification token to authenticate the object of verification and/or gateway, for example, through a process of mutual authentication to pass the authentication information in the object of verification and/or gateway.

Another approximate variant of the invention is directed to the way a token verification. An approximate method contains the connection token verification with a computer by using peripheral interface of the computer, and the computer has a network tool, with a verification token contains peripheral interface, made to connect to peripheral computer interface, the reader is made to read identifying information from portable consumer devices, computer-readable media, and a data processor, and the token is made to to read credentials portable consumer devices using reader and get the value of verification for him from the first object (for example, from an object of verification and/or gateway) using the network computer. The method also provides representation portable consumer devices in the reader token verification, to get the value of verification devices for portable consumer devices, and providing values obtained verification in the second object. The second object can participate in a transaction between itself and the user token verification.

Another approximate variant of the invention is directed on software product that provides values verification. Approximate product contains: code that instructs the processor data to make the query value verification devices for portable consumer devices associated with the user, with the request contains identification information related to portable consumer device; the code that instructs the processor data to apply at least one test validation, referring to accept the request; and the code that instructs the processor data to send, if at least one test validation is passed, the value of verification in a verification token associated with the user, or object that is configured to forward the value of the verification in the token.

Another approximate variant of the invention is directed to the object of verification, which provides values verification token verification. Approximate object of verification contains computer-readable media, a data processor, electrically connected to a computer-readable media, and a code embodied on computer-readable media, which instructs the processor data to perform various stages. Approximate object of verification additionally contains code that instructs the data processor to communicate with the token verification network connection with a computer located between the token verification and communication network, and the token verification is connected to the computer via a peripheral interface computer and configured to access network tool of the computer, and the token verification configured to read portable consumer device on the subject of identification information and instruct sending at least part identification information in encrypted form in the object validation using network tools computer. Approximate object of verification additionally contains code that instructs the processor data to make the encrypted credentials sent through token verification, the code that instructs the processor to decrypt encrypted data identifying information, code that instructs the processor data to apply at least one test validation to decrypted identification information, and code that instructs the processor data transfer if at least one test validation is passed, the value verification token verification. Additional options for implementation may include the transmission of values verification in the payment processing network.

In each of the ways described above, and in each of the ways described below, the connection between the computer and the object of verification may contribute to the gateway, and/or it can be transported through the gateway (for example, a proxy server, the server object, and so on), which is located between the computer and the object of verification. The gateway can act as a mediator between the many tokens of verification and the associated computers with one hand and many objects of verification from the other side. The gateway can take one or more of the initial links from the token verification (through a computer that communicates with the token) and can be determined from the information in one or more of the initial links proper one object of verification to be used to satisfy a request token for values verification. For example, each token verification can be configured to work with portable consumer devices, issued by various issuing banks or other such objects, and one or more objects of verification can be configured to handle requests from portable consumer devices, issued by the relevant issuing banks or other such objects. The gateway can determine the appropriate one of the objects of verification, to use based on the identification of information that a marker reads from portable consumer devices, and sends it to the gateway when the initial connection. In one implementation of the gateway forwards the marker in particular the proper object of verification, and the relationship between token verification and proper object of verification. In other implementations, the connection between the token verification and proper object of verification can be transferred through a gateway (after the gateway initially determines the identity of the proper object of verification on the basis of one or more initial links with the handle). This second implementation may contain relatively easy passage of communication between the bullet and the proper object of verification with minimal processing by the gateway or may contain a virtual representation of the gateway as the proper object of verification token verification. This virtual presentation may contain decoding through the gateway of each message from the token verification, the connection with the proper object of verification, to formulate the answer to a message inside, and encryption and sending the response message in the token verification. The gateway can also implement one or more tests validation on behalf of the proper object of verification, in particular the tests associated with the validation token verification. In this case, the gateway, there is no need to send in a proper object of verification are those that it receives from the token that relate to the tests verifying that handles the gateway. The gateway can be associated or controlled via the network of payment processing.

Another approximate variant of the invention is directed to ways of providing value verification. An approximate method comprises: reception, on the server, the query values verification devices for portable consumer devices associated with the user, with the request contains identification information related to portable consumer devices; the use of at least one test of verification belonging to accept the request; and the submission if at least one test validation passed, values verification devices in a verification token associated with the user, or object that is configured to forward the value of the verification in the token.

Another approximate variant of the invention is aimed at validation path portable consumer devices, presented in a verification token. An approximate method contains a relationship with a verification token over a network connection with a computer located between the token verification and communication network, and the token verification is connected to the computer via a peripheral computer interface and configured to access network tool of the computer. A verification token configured to read portable consumer device on the subject of identification information and send authentication information to the object of verification using the network computer. A verification token is also configured to send sequence number and a message that is encrypted with the encryption key, the object of verification, and the ordinal number and the encryption key is uniquely assigned to a verification token. The method also provides reception of a sequence number, encrypted messages and identifying information from the token verification and application of one or more tests validation to the ordinal number and the encrypted message. The method also provides a transfer, if the number of one or more tests validation completed, the values of verification in the token. Additional options for implementation may include the transmission of values verification in the payment processing network.

Another approximate variant of the invention is directed to the method that contains the reading of identification information from portable consumer devices to the token verification, temporarily connected to a computer via peripheral interface; communication between token verification and computer, and the computer has a network tool; and the establishment of a connection between token verification and object of verification using the network computer. A verification token can be connected with a removable computer. The relationship between token verification and object of verification may contain a session.

It should be reiterated that the connection between the computer and the object validation in each of the above embodiment can be transported through the server that is located between the computer and the object of verification, as described above.

More detailed information concerning the embodiments of the invention, provided below is a detailed description with reference to the drawings.

Brief description of drawings

Fig. 1 illustrates some indicative options for carrying out the invention.

Fig. 2 illustrates the approximate variant of the method, which can be used by token verification.

Fig. 3 illustrates the approximate variant of the method that can be used by the user token verification.

Fig. 4 illustrates the approximate variant of the method, which can be used by means of an object of verification.

Fig. 5 illustrates a sample implementation of a computer-readable storage device that can be used by token verification.

Fig. 6 illustrates the token verification and computer using the USB connectors peripheral interfaces.

Fig. 7 illustrates the approximate identification information that can go through a verification token and used by means of an object of verification.

Fig. 8 illustrates additional indicative options for carrying out the invention.

DETAILED DESCRIPTION

Options for implementation disclosed in this document, refer to verification portable consumer devices. Portable consumer device is a device that stores the authentication information relating to the account, saved by the user, with another object, which typically is an object that stores, extend or credits the items that has a cost to the user (for example, cash, credits, debts and so on). Portable consumer devices cover a credit card, payment cards, debit cards, Bank cards, prepaid cards, access cards, cards, blanks and other maps that identify the expense of saved by the user to another object. Card permit in passive forms (for example, cards with magnetic stripe)and active forms (for example, cards with IC chip smart card), and additionally covers a portable electronic device which, in whole or in part, to act as such cards. Such portable electronic devices can include memory cards, markers accounts, key rings, labels, cell phones (including phone number in the near zone), the unit rings (for example, offered on the market Speedpass based on Exxon-Mobil Corp.), personal digital devices, other mobile electronic devices, transponders, media such as a smart card and the device search call.

Identification information saved through (for example, embodied in) consumer portable devices, contains at least, account number and preferably at least one of the following: digital fingerprint, magnetic strip portable consumer devices or variable element of data that varies every time portable consumer device is read on the subject of identification information, as illustrated in Fig. 7. Magnetic stripe transfers, at least, the account number of the device. Account number identifies the account of the customer at least one net payment processing and may contain primary account number (PAN); it also can contain alphanumeric characters. Digital fingerprint of the magnetic strip is the distribution of magnetic particles that form a magnetic strip, and is formed by a specialized card reader, which discretional distribution of magnetic particles when the card is carried out through the reader. Variable element data typically contains numeric characters and can contain alphanumeric characters. The value of the variable element of data vary in a way that is known for portable consumer devices, and for authorization object, and the second of them may be the issuing Bank or the payment processing network. Variable data element covers a dynamic value CVV ("dCVV") and value verification card CVC3 formed by means of smart cards (contact and contactless forms), as well as the cryptogram, formed by many smart cards (for example, the cryptogram 17). The value of a data item can pre-stored on computer-readable media devices and on computer-readable media authorization object or can be formed through each device and the object as needed (for example, "to form on the fly") with the use of the algorithm confidential, known for the device and the object, or by a well-known algorithm that uses confidential or sensitive information. Variable data element may contain or may be accompanied by a counter value that indicates the number of times the portable consumer device produces variable data element; the value of the counter can help authorization object to retrieve the variable item from a computer-readable media object or formation of the variable item from the algorithm. However, the counter is not mandatory, and the authorization object may display a number of times when the device produces variable element data, from prehistory of authorization requests made to the device, or can be used an algorithm that does not require the counter.

Identification information can optionally contain the name of the account holder (for example, user), the date of expiration of the card validity, service codes and discretionary data. As an example, identifying information may include traditional "payment information"stored on the magnetic stripe track traditional credit card (for example, track 1, track 2 and/or track 3).

Identity portable consumer devices is read by the reader, who is an electrical component that can read identifying information from portable consumer devices and provide identification information in the other electrical components. The reader may contain one or more of the following: the magnetic stripe reader (which may include a scheme of sampling prints), contact reader and contactless card reader, and the second one is known as RFID reader (RFID is an abbreviation for radio frequency identification). Reader for reading fingerprints magnetic strips can include module security, which contains a proprietary algorithm, which creates a fingerprint of the discretized data footprint and encrypts digital fingerprint using single words using the encryption key. Readers are mostly in locations sales outlets sellers.

The typical flow of credit card transactions using portable consumer devices in the location of the store is described next. Portable consumer device, the user is granted to the user by or on behalf of the issuing Bank. The issuing Bank extends a loan to a user represents a user in credit card transactions and pay vendors for purchases made by the user. The user represents your portable device consumer to the seller in the location of the store to pay for the item or service. The seller uses the reader to read portable consumer device user, and sends the authentication information read from the device, together with the information of the seller and the transaction amount in the acquiring Bank. The seller can also read portable consumer device on the subject of the printed values of verification of the card (for example, CVV, printed on the back of many credit cards) and can send it forth as part of the information the transaction is sent to the acquiring Bank. The acquiring Bank represents and warrants to seller in credit card transactions. The issuing Bank sends the transaction information in the payment processing network, for example, VisaNet™, for authorization. The payment processing network, in General, covers a set of one or more server computers, sub-systems, networks and data processing operations, used to support and deliver one or more of the following: authorization services, file services, exceptions and services clearing and settlement. Network processing payments cover banking network processing, network processing credit card payments, etc. Estimated payment processing network may include VisaNet™. Example network processing payments have the ability to handle one or more of the following: credit card transactions, transactions on debit card and other types of commercial transactions. The payment processing network may use any appropriate wired or wireless network, including the Internet, to communicate with banks acquiring and issuing banks.

Prior to the transaction, credit card payment processing network establishes a Protocol with each issuing Bank on how Bank transactions must be authorized. In some cases, for example when the transaction amount is below the threshold, a payment processing network authorizes the transaction based on the information it has about the user's account, without recourse to the issuing Bank and accepts responsibility, if the transaction turns out to be fraudulent. In other cases, for example, when the amount of transactions above the threshold, a payment processing network should send the information of the transaction in the issuing Bank for verification and authorization. As part of the authorization process the payment network or the issuing Bank can verify the fingerprint or varying the item data provided by portable consumer devices. The fingerprint is stored in the Issuer and may be provided in a secure network processing payments through issuing Bank for storage and later use. An algorithm for the formation of varying data item is stored in the Issuer and may be provided in a secure network payment processing for storage and later use. As part of the authorization process the payment network or the issuing Bank can verify the printed value of verification of the card (for example, CVV), which remains in the Issuer and can securely be provided by the issuing Bank in the payment processing network for storage and later use. The degree to which the payment processing network is involved in the verification of consumer handheld devices and authorization transactions, typically configured according to the wishes of the issuing Bank. As the transaction is authorized, the payment processing network sends indicator authorization in the acquiring Bank, which forwards the indicator authorization to the seller. To reduce fraud, sellers are not allowed to store digital prints variable data item and printed values verification card (CVV) for more than 24 hours.

Fig. 1 illustrates some indicative options for carrying out the invention in the context of online purchasing. Provides a General brief description of embodiments and components, shown on the drawing, and then provides a more detailed description of the components. The drawing shows the icons for user 1, portable consumer devices 5 user, device communications 7 user (for example, cellular phone), computer 10 user, the web site 20 of the seller and of the first network of 31 communication, which allows the user's computer and the web site of the seller to communicate with each other. The first network 31 communication may include the Internet, the network connection (for example, a wireless network, mobile phone network, telephone network, cable network or any combination of the above), wide area network (WAN), local area network (LAN), own a router or gateway, connected to one of the above networks, or any combination of the above. Also in Fig. 1 shows the acquiring Bank 50 for the seller, the issuing Bank 60 for portable consumer devices 5, a network of 70 payment processing, and a second network of 32 communications, which provides the capability of a network of 70 payment processing to communicate with each of the banks of 50 and 60. The second network 32 communications may include the Internet (and, therefore, may overlap, and share funds with the first network 31 communication) or may contain one or more private networks, or a combination of one or more private networks to the Internet. A private network can contain a communications network, wide area network (WAN), local area network (LAN) or any combination of the above. In some cases, the first and the second network 31 and 32 of communication can be identical (for example, a network with the use of the Internet as a backbone network). The communication network, in General, maintains a network of one or more lines and two or more nodes that pass messages from one part of the network to another part. Each node contains one or more elements of electrical equipment, and each line can contain one or more of the following: a fibre optical communication lines, radio links, cables. Features discussed so far, for the most part are traditional, arranged in the traditional way.

Fig. 1 illustrates the token 40 verification according to one variant of the invention, and the object 80 validation according to other variant of the invention. These components and the interactions between them and between other components, is shown in Fig. 1, are new and are not part of the prior art. Marker 40 verification has the reader 44 to read portable consumer device 5, and peripheral interface 46, is made to connect to peripheral interface 16 computer 10. Reader 46 may contain one or more of the following: a reader of magnetic stripes (which may include a scheme of sampling prints and security plug-ins), contact reader and contactless card reader, and the second one is known as RFID reader. Marker 40 verification configured to communicate with the object 80 validation by the network tools on 14 computer 10. After the user 1 fill a shopping cart on your web site 20 of the seller, the user can load the page of payment the seller to provide information about the payment of the user and to make a purchase. Here the user 1 can represent your portable device consumer 5 in the device 44 card reader token 40 verification to provide identification information of the device (an example of which is illustrated in Fig. 7). Marker 40 verification reads identifying information from portable consumer devices 5 user and sends at least part identification information in a secure manner (for example, in an encrypted form) in object 80 validation to request the value of verification devices for portable consumer devices 5. For clarity and without loss of generality we can mention such a value verification provided through the object 80 validation as is "dCVV2"in order to distinguish it from dynamic values "CVC3" or "dCVV", formed by means of smart cards, which are described above, and from the fields CVV, located on the payment page of the seller. Object 80 validation applies one or more tests validation to the marker 40 verification and/or identification information, to obtain a certain level of confidence about what portable consumer unit 5 is actually presented in the token 40 verification, to request a value dCVV2. When one or more tests validation passed and preferably no failed tests, the object 80 validation sends the value dCVV2 in token 40 verification.

If portable consumer device 5 user forms the cryptogram (for example, the cryptogram 17), the device 44 card reader provides the device 5 user "sham" transaction information, which is known as token 40 and object 80 validation. Fictitious transaction information may include static transaction amount and static name of the seller, depending on the type of the cryptogram, which should be formed. Fictitious transaction information may be different for each token 40. Unit 5 user uses the information in the transaction in order to form the cryptogram. The user's device typically has a counter that is often called a counter transaction applications (ATC), which is included in the calculation of cryptograms and which increases with each transaction. Counter reduces the probability of guessing a fraud values of the cryptogram. In some cases the device 5 user may also require a PIN code to activate the calculation of the cryptogram. For this marker 40 can display a pop-up window on the computer 10 user that requests a PIN code user and marker 40 can provide the PIN-code in the device 5 user with the request of the cryptogram.

The value dCVV2 provided through the object 80 validation, contains a variable element data (e.g., multi-digit number) and is used by the user to complete the purchase transaction. Marker 40 verification can display the value dCVV2 the user, so the user can enter the value dCVV2 in the field CVV the payment page of the web site of the seller, or the token 40 verification can enter a value dCVV2 directly in the field CCV page of payment the seller. After the value of dCVV2 entered in the CVV, the user can complete the purchase. This form of value dCVV2 gives him the opportunity to work in existing systems and flows of payment processing. Web site 20 of the seller then uses the value dCVV2 for CVV in its request for authorization to purchase. The authorization request is sent to the acquiring Bank 50, which then forwards it to the network 70 payment processing for authorization. Through a separate channel object 80 validation can send the value dCVV2 in a network of 70 payment processing and/or the issuing Bank 60, together with information of the account (for example, an account number), so that a request to authorize the seller may be processed. This serves to notify a network of 70 payment processing and/or the issuing Bank 60 that is dCVV2 for portable consumer devices 5 requested and provided to the seller, and expect the seller must provide the value dCVV2 in the authorization for the account.

A network of 70 payment processing can compare the incoming authorization requests from sellers (for example, sent by means of acquiring banks) with the information it receives from the object 80 validity checks (for example, through consideration of account numbers), and can be mapped (for example, to correlate) incoming authorization requests with information on validation sent via the object 80 validation. If a match is found, the network of 70 payment processing has a high degree of assurance that consumer portable device 5 is at 1 when is the purchase transaction. This provides a greater degree of assurance in comparison with confidence to the values CCV, printed on the back of credit cards. A network of 70 payment processing and issuing Bank 60 can then take other actions that they perform, to authorize the transaction, for example, check whether or not the seller 20 good reputation, and checking account limit user 1 to ensure that there are sufficient funds to cover the amount of purchases by the transaction. In this case, the network 70 payment processing is no need to check the authenticity of a digital fingerprint and/or variable data item portable consumer devices 5, if this action is performed through the object 80 validation. (Network of 70 payment processing can, however, perform these steps validation for transactions at the point of sale the seller.)

As more functionality, which is useful when multiple devices 5 allocated under one account number (for example, some cards under one PAN for a family), identifiable information that token 40 collects and provides to the object 80 validation, may include only one device ID with the account number. This device identifier uniquely identifies one of the devices to be allocated to the account number. Object 80 initialization can continue to use the device ID to get different values dCVV2 for various devices allocated to the account number. As additional functionality object 80 validation can send a token 40 information, shipping address and/or information clearing address of the user who previously associated with the device, and the token 40 can fill it in the corresponding field on the payment page of the seller.

Options for implementation and components shown in Fig. 1, is now described in detail. Computer 10 user can contain a desktop computer, a laptop, or any portable electronic device that has a network tool and peripheral interface for communication with one or more peripheral devices. The computer has 10 one or more CPUs 11, material of computer-readable media 12, connected to the processor(s) 11, which maintains a set of instructions (software)that instruct the processor(s) 11, and which stores data that is used by a processor(s), 11, and user interface 13, connected to the processor(s) 11. The network tool 14 and peripheral interface 16 above also connected to the processor(s) 11, and network tool 14 also connected with the first network 31 communication. The user interface 13 contains one or more units of output (for example, displays, screens) and one or more input devices (e.g. keyboard, mouse, trackball, etc.) for reception by 1 user information from the computer 10 and providing input 10. Computer-readable media, 12 may contain a combination of semiconductor memory devices and non-volatile storage devices, for example one or more disk drives and/or non-volatile memory. Computer-readable media 12 stores the operating system for your computer 10, which provides the ability to run processes and applications through the processor(s) 11. The operating system provides services to these processes and applications, and enables these processes and applications to access user interface components 13, parts of the computer-readable media 12, network tool 14, peripheral interface 16 and other components of the computer 10. The operating system can be complex and full-featured, for example, on the desktop, or simplified, for example on cell phones, PDA and many other types of portable electronic devices.

The network tool 14 computer 10 may contain the software and hardware that provide capability to process running on the computer 10, to communicate with the network connection, for example network 31, send and receive messages, data, etc. in one or more objects, connected with a network connection. Hardware tools 14 may include specialized hardware that is separate from the processor(s), 11, or sharing of CPU(s) 11, or a combination of the above. Software tools 14 may contain firmware, software stored on computer-readable media, 12 or other computer-readable media, part of the operating system or a combination of any of the previous items. The network tool 14 preferably is nonexcludable resource, providing access to a communication network through other processes and applications running through a computer 10. Peripheral computer interface 16 10 contains a wired or wireless connection that allows a peripheral device (separate from the computer 10) to communicate with the computer. Traditional wired connections include connectors universal serial bus (USB) ("USB ports"), serial ports, parallel ports, and PCMCIA ports. Traditional wireless connections include infrared (IR) base station and base station Bluetooth™that plugs into a computer 10 or which are connected with peripheral computer interface 10.

In addition to the reader 44 and peripheral interface 46 (described above), marker 40 verification additionally contains the processor 41, material of computer-readable media 42 coupled to the processor 41, store the data and codes that instruct the processor 41, 43 module security, coupled with the processor 41 and performed to securely save one or more encryption keys to encrypt and decrypt data for the token 40, reader 44 connected to the processor 41 and executed to read portable consumer devices 5, and peripheral interface 46 connected to the processor 41 and executed to communicate with the computer by 10 peripheral interface 16. Processor 41 may contain a traditional microprocessor and computer-readable media 42 may contain a combination of semiconductor memory devices and non-volatile storage devices, for example non-volatile memory. Fig. 5 illustrates a sample implementation of computer-readable media, 42, which involves storing multiple data elements (described in more detail below), codes processor that instruct the processor 41, and the mass memory CPU CPU 41 can use when performing their tasks. Again referring to Fig. 1, module 43 security may contain scheme encryption and decryption (which may include one or more processors), and can contain one or more encryption keys stored in protected storage. Module 43 security may also include protection scheme based firewall, which protects the token 40 verification against attacks from hackers conducted through peripheral interface 16. Reader 44 may contain a traditional reader, as described above. Peripheral interface 46 may contain a wired or a wireless connection is made to communicate with peripheral interface 16 computer 10. As noted above, traditional wired connections include connectors universal serial bus ("USB"), serial ports, parallel ports, and PCMCIA ports. Traditional wireless connections may include infrared remote stations and remote stations Bluetooth™. When using traditional wired connection to peripheral interface 46 token 40 verification can be connected with a removable computer 10 in peripheral interface 16, for example in the USB-port. Fig. 6 illustrates a sample token 40-1 verification USB port (connector type) as part of its peripheral interface 46-1. Also illustrated in Fig. 6 computer 10, his peripheral interface 16-1 with a USB port (socket type), in which the USB connector 46-1 is inserted, user interface 13 of the computer (for example, screen and keyboard), portable consumer device 5 user (RFID card), the user 1 and representation of the value dCVV2 in the user interface 13. Marker 40 additionally may include visual display, for example light-emitting diode (LED)that illuminates when it is ready to read the device 5 user, and additionally may include audible indicator, for example piezoelectric buzzer that beeps when the token 40 completes the reading device 5 user. Visual and audible indicators can work through a scheme reader 44. In other implementations, one or more of these indicators can operate through a processor 41 through the commands of input-output. Although Fig. 6 illustrates the token as something like a USB flash device, the token can take other forms. For example, it may be part of a hardware or other module installed in the computer, consumer device, or another device.

Again referring to Fig. 1, the second token code 40 verification instructs the processor 41 data to make the identification information read from the portable consumer devices 5 through reader 44. The second code can include code that instructs the processor 41 data to adopt a uniform resource identifier (URID) object 80 validation read from portable consumer devices 5 through reader 44. The second code can contain statements that instruct the processor 41 to contact with a reader 44 with periodic intervals through the command I / o to determine what is or not a reader of any data to the processor, and read the data when the data are listed as present. The second code can also instruct the processor 41 to contact with a reader 44 through the command I / o to clear the data once the processor 41 reads them, or reader 44 can be configured to clear the data once it detects that the processor 41 reads them, or after a period of time exceeding periodic interval contact used by the processor 41. In other implementation reader 44 can be configured to generate an interrupt signal to the CPU 41 when data is present, and the second code can include statements that instruct the processor 41 to respond to the interrupt signal by reading data from the reader 44 and treatment interruption. The second code can additionally include, as an option, statements that instruct the processor 41 to form the signal I / o, which instructs the above sound indicator to beep in response to the receive data through the processor 41 of the reader 44. The above instructions may include traditional instructions I / o, which instructed the relationship with the reader 44 and indicators. Various portable consumer devices 5 can save and provide different URID in different objects 80 validation. A uniform resource identifier (URID) may include the uniform resource locator (URL)the address of the Internet Protocol (IP address), or any other type of identifier that can identify an object in a communication network. If portable consumer device 5 does not provide URID in the object 80 verification token 40 verification can save URID in the object 80 validation by default. In some configurations, some markers 40 verification can be Mnogomernye with relevant banks and to work only for portable consumer devices that are Mnogomernye with identical to the issuing banks, and each issuing Bank may have its own object 80 verification own URID. In this configuration, these handles 40 verification can save URID in their respective mnogomernyh the 80 objects of verification. Instead of or in addition to this configuration, some markers 40 verification can be associated with the corresponding networks 70 payment processing, and each of the network can have its own object 80 validation. In this configuration, data markers 40 verification can save URID in their respective associated 80 objects of verification. Accordingly, the second token code 40 verification can be optionally configured to instruct the processor 41 data be used only URID default, saved by token 40 or use URID by default, if the consumer portable device 5 does not provide a marker 40 URID in the object 80. As another different implementation of the marker 40 verification may include code that instructs the processor 41 to select one of a number of URID stored in the token 40, on the basis of non Bank provided in identity information or embedded in the account number. Above additional guidance and codes can be implemented using traditional statements of I / o statements memory access and logical and control CPU instructions. One or more URID for objects of verification can be stored on computer-readable storage device, 42, as illustrated in the example shown in Fig. 5.

If the token 40 wants to use Internet Explorer module for network services, it can optionally contain calls API functions in the operating system of the computer to initiate the browser instance and to grant him access to the instance of the browser. In some implementations, for example, when the object 40 verification saves URID object 80 validation, third code can instruct the processor 41 data to communicate with the object 80 validation long before the user 1 represents consumer portable device 5 for reader 44, and before the processor 41 reads the data from the reader 44. Marker 40 verification and object 80 validation can save the session as long as the device 5 does not seem to the reader 44, and between the times when the device is 5 rendered for the reader 44, through the exchange from time to time messages "confirmation health". For example, the token 40 verification may occasionally, periodicheski or arbitrarily send the object 80 verification message, confirming its presence in a session, and the object 80 validation can send the response message, confirming its presence in the session.

Third, the code can be executed in response to the receive data through the processor 41 of the reader 44 or can be made to receive data from the reader 44. In the second case, the third code may include, as an option, statements that instruct the processor 41 to send the command I / o reader 44 to activate it possible to read after the processor 41 establishes communication with the object 80 validation.

Fourth token code 40 verification instructs the processor 41 data transfer at least part identification information in the object 80 validation by the network tools on 14 computer 10, with the identifying information is transmitted in an encrypted form. When an SSL session is established, the fourth code can instruct the processor 41 data to pass authentication information to the module network services computer using the appropriate function calls in the API module for network services, and identifying information may be transferred in the SSL session, and transmitted and received data are encrypted using a session key. For an additional level of security code fourth optionally may contain code that instructs the processor 41 encrypt authentication information through the use of the module 43 security using encryption key stored in the token 40, prior to its submission to the network tool 14. These instructions may include traditional instructions I / o, which instructed communication with the module 43 security to pass authentication information to the module 43 and take back the encrypted information. The encryption key can be stored on computer-readable media in module 42 or 43 security.

Fifth token code 40 verification instructs the processor 41 data to receive, after the transfer of the aforementioned identity information, value verification device (for example, the value dCVV2) from the object 80 validation by the network tools on 14 computer 10. This code can contain calls to functions in the module API network services computer to retrieve the data sent by the object 80 in the session. The value dCVV2 can be encrypted via an 80 validity checks when the fifth token code verification optionally instruct the processor 41 data to decrypt the encrypted value, for example, through the use of the module 43 security (via a call instruction I / o module 43). Fifth, the code can include code that instructs the processor 41 data to display the received value dCVV2 user 1, for example, through the user interface 13 computer 10 or miniature LCD screen, etc. that is integrated with a marker 40 verification. In the first case, this code can contain calls to the API functions in a graphical user interface to the operating system of your computer 10 to expand the display unit in the user interface 13, to display the value of dCVV2 in alphanumeric and/or graphical form. In the second case, this code can contain instructions I / o on a tiny LCD screen, etc. In a different implementation of the marker 40 verification can insert accept the value dCVV2 in the field CVV page purchases of the seller. In this case, the fifth additional code can include code that instructs the processor 41 data to find a browser session on the computer that has the form field values for verification, and to fill in a field value verification taken from an object of verification. It can include function calls in the API of the web browser to look on an active web page or all open web pages input field labeled CVV, and enter the value dCVV2 in the field CVV.

In some implementations field CVV on the seller's page can be configured as a hidden field that is invisible to the user. This can be done to reduce the complexity for the user's transaction and reduce the probability of failure of the transaction due to user confusion, technical difficulties or explicit needs too large volume of information. In this case, and as an option the fifth code may contain statements that instruct the processor 41 data to find a browser session on the computer that has a hidden field values for verification of the device (for example, the page of payment the seller), and to fill in a field value verification taken from an object of verification. In this case there is no need to present the value of verification in a visual form to the user. Hidden field, in many languages, web programming, can easily be specified via the ID tag or variable browser, which is known as seller, and the token 40. If the processor 41 unable to find a hidden field, the fifth additional code may instruct the processor 41 to present to accept the value verification to the user. These instructions can include function calls in the API of the web browser to look on an active web page or all open web pages in a hidden field of the hidden field (marked by ID or name of a variable, type a value dCVV2 in a hidden field, and the instructions of input-output on the LCD screen or in the computer 10 to visually present value dCVV2, if hidden field can not be found, or function calls in the API of Internet Explorer to visually present value dCVV2 temporary browser window, if hidden field cannot to be found.

In some configurations, the object 80 validation can provide dynamic account number (often called "dPAN" in the art) together with the value dCVV2. For these configurations, the fifth code can be supplemented to take dPAN together with the value dCVV2 and display the value dPAN user 1 or fill in a value in the account page purchases of the seller and include instructions, similar to those described above for handling values dCVV2. In particular, the fifth additional code can include code that instructs the processor 41 data to display the received value dPAN user 1, for example, through the user interface 13 computer 10 or miniature LCD screen, etc. that is integrated with a marker 40 verification. In the first case, this code can contain calls to the API functions in a graphical user interface to the operating system of your computer 10 to reveal an indicator glass in the user interface 13, to display the value of dPAN in alphanumeric and/or graphical form. In the second case, this code can contain instructions I / o on a tiny LCD screen, etc. In a different implementation of the marker 40 verification can insert accept the value dPAN in the field account page purchases of the seller. In this case, the fifth additional code can include code that instructs the processor 41 data to find a browser session on the computer that has the form fields for the account number and value verification device (for example, fields CVV), and fill in the account field value dPAN and the value field verification value dCVV2 taken from an object of verification. It can include function calls in the API of the web browser to look on an active web page or all open web pages of the input field labeled "account" (or "credit card number") and CVV, and enter the value dPAN in the "account number" and the value dCVV2 in the field CVV.

The use of function calls in a variety of application programming interfaces (APIs), your computer operating system 10, its modules support, tools and applications is known in engineering software, and specialists in the art must be able to draw up instructions and calls API functions to implement the above codes and objectives with regard to this disclosure without undue experimentation.

Fig. 2 illustrates a sample implementation of 140 way that can be used by token 40 verification. An approximate method 140 contains many stages 141-145. Stage 141 contains establishing lines of communication between token verification and computer, and the computer has a network tool, as described above. Stage 142 contains establish a communication session between token verification and object of verification using network tools computer and module network services for him. Stage 143 contains the reading of identification information from portable consumer devices 5 in the token verification using the reader, for example reader 44. In some implementations stage 143 may be preceded by one or both stages 141 and 142. Stage contains 144 transfer a matter of identification information from the token verification in object validation through the session, with the identifying information is passed to the object of verification in encrypted form. Stage 144 may contain direction of the communication session to encrypt authentication information, and/or encryption identity information using encryption key stored in the token. The algorithm is based with triple DES encryption can be used for both encryption. Stage contains 145, after the transfer of identification information, reception, in token verification, the values verification of the object of verification by means of a communication session. Stage 145 also may include a reception dPAN and/or address information, as described above.

Fig. 3 illustrates a sample implementation 150 way for the user to use the token 40 verification etc. Approximate method 150 contains many stages 151-153. Stage 151 contains the connection token verification, for example token 40 with your computer, for example a computer 10, using peripheral computer interface. Stage 152 contains a representation of portable consumer devices 5 for reader token verification, to get the value of verification device to device. If the device has 5 magnetic strip, stage 152 may include conducting magnetic stripe reader through magnetic strips token verification. If the device 5 contains the wireless interface, stage 152 may contain warning device 5 next to the reader token verification. Stage 153 contains providing values obtained verification in the object involved in a transaction between a user and object. Stage 153 may contain input verification on the web page of the object or value transfer via telephone to a representative of the object.

Alternatively, the token 40 verification can send from time to time, one or more fragments unique to machine information computer 10 in the object 80 validation that can compare this information with the database of information of computers associated with a known Scam. This unique machine information may include the sequence number of processors, disk drives and operating systems computer 10. Marker 40 verification can contain code that instructs the processor 41 data to obtain one or more fragments unique to machine information from your computer 10 and send machine-specific information in the object 80 validation. This code can include function calls in the API of the operating system of the computer to receive data calls functions in the module API network services computer to send information to the object 80 validation.

As another option, marker 40 verification can be configured to prompt the user 1 to enter a password to activate one or more functionality token 40. The password can be saved on computer-readable media, located in the module 43 security, or on computer-readable media, 42 (see Fig. 5 for a sample implementation of the latter). The password can be provided to the user on 1 sheet of paper by the vendor or seller token 40. Marker 40 can be sent to a user 1 through the mail, by or on behalf of the issuing Bank or may be acquired by user 1 in the store. Marker 40 can be configured to require that the password was entered each time a user wants to submit a consumer portable device 5, and/or each time the token 40 connects to the computer 10. For this marker 40 verification can optionally contain code that incarnate on computer-readable media, 42, which instructs the processor 41 data to prompt the user to enter a password on the computer keyboard 10, to read the password entered by the user, and compare the entered password with the saved password, incarnate on computer-readable media. This code can contain calls to the API functions in a graphical user interface to the operating system of your computer 10 to reveal an indicator glass in the user interface 13 to request and receive a password from the user 1, instructions I / o, instruction memory access and logical and control statements CPU. Marker 40 verification can optionally contain one or more of the following:

(1) code, embodied in a computer-readable media, 42, which instructs the processor 41 data to initiate and/or to allow the above connection with computer 10 in response to match the entered password with saved password;

(2) the code is embodied in a computer-readable media, 42, which instructs the processor 41 data to initiate and/or to give the opportunity to the above communication with the object 80 verification in response to match the entered password with saved password;

(3) the code is embodied in a computer-readable media, 42, which instructs the processor 41 data to enable the reader 44 and/or accept credentials from the reader 44 in response to match the entered password with saved password; and

(4) code embodied on computer-readable media, 42, which instructs the processor 41 data to initiate and/or to allow the above transmission identification information in the object 80 verification in response to match the entered password with the saved password.

These codes can be implemented using the instructions I / o, instructions memory access and logical and control CPU instructions. They, individually or in combination, to prevent transmission of identification information in the object 80 when the password entered is not identical to the saved password, and thereby contain the code, embodied in a computer-readable media, which instructs the processor data to do this. The specialists in the art must be able to draw up instructions and calls API functions to implement the above codes with this disclosure without undue experimentation. As an additional security token 40 validation can optionally contain code that incarnate on computer-readable media, 42, which instructs the processor 41 data to set the user name for the marker by presenting the user with 1 dialog box to accept the entry that indicates the user name, and by storing user name on computer-readable media 42 (an example is shown in Fig. 5). The above code to handle advanced password can be supplemented to include the username prompt for the token and comparing accept the user name with the saved user name for a match, and the inclusion of the match as the conditions that must be satisfied in each of the four above codes that initiate or give the opportunity to perform various stages. These codes can be implemented using the instructions I / o, instructions memory access and logical and control CPU instructions.

Additional implementations, as additional protection, marker 40 validation can optionally contain code that incarnate on computer-readable media, 42, which instructs the processor 41 data set one or more addresses of delivery and/or settlement of addresses in the token, the token 40 can be used to fill in the form for filling the location of the page of the seller. Each delivery address and/or billing address can be associated with portable consumer devices. The code can instruct the processor 41 to represent a sequence of dialog boxes to the user through the user interface of your computer 13 to accept information, address and account number (or the last four digits of portable consumer devices 5, which should be associated with the address information, and save the addresses on computer-readable media, for example the media 42 (as illustrated through the example shown in Fig. 5). Marker 40 optionally may contain code that incarnate on computer-readable media, 42, which instructs the processor 41 data access address information in response to the request object 80 validation (information addresses can be selected from many saved addresses, on the basis of the account number sent in the request), and fill in the address data in the proper location of the page of payment the seller, for example, when the value dCVV2 be taken back from the object 80 validation. The code can be configured to instruct the processor 41 to fill out the address information only when the location for information on the payment page of the seller are empty, and when the object 80 validation does not provide information address as described above. Code to fill can be optionally configured to instruct the processor 41 data to use the information on delivery and/or account information saved on portable consumer device 5, when the information on delivery and/or account information is stored in the token 40 for the account number of the device 5, and additionally, if location for information delivery on the payment page of the seller are empty, and the object 80 validation does not provide information address as described above. Code to fill can include code that instructs the processor 41 data to find a browser session on the computer that has the form fields for address information and/or values verification, and fill in the address fields selected by the address information. It can include function calls in the API of the web browser to look on an active web page or all open web pages input field labeled name, address, city, postcode, country, and CVV, and enter the data item is selected address information in the appropriate fields. The above codes can be implemented through calls API functions, instructions I / o, instructions memory access and logical and control CPU instructions.

In each of the ways described in this document relating to the marker 40 verification of the above codes token 40 and identification information read from the device 5 through a token-40 can be saved independently of a computer 10 and can be protected from programs (including spyware, and other malicious software)that run on the computer 10. In such implementations identification information is translated in a protected form (for example, encrypted, hashed, signed, or a combination of the above) by token 40 verification before information is available in the computer 10. Accordingly, information security is not dependent on computer security 10. Symmetric or asymmetric keys can be used for encryption and signing. The keys for the token 40 verification can be unique relative to other markers of verification (i.e. the keys for the token can be unique to this marker). The keys for the marker and, in particular, symmetric keys can be based on a uniquely assigned a sequence number for verification token that can communicate with the object 80 validation when the initial connection. As a token verification, and the object of verification can be shared secret on how to retrieve the key from the serial number of a token, for example, through processing and/or replace the selected digit serial number. A certain number of keys can be retrieved from a unique sequence number using the appropriate shared secrets. Thus, the message of challenge and response, used in the mutual authentication between a verification token and an object of verification, can be signed using the appropriate keys, extracted from the sequence number token verification.

After describing the various options for the implementation and realization of the marker 40 verification of different options for implementation and realization of the object of verification now describe. Object 80 validation contains a system with one or more servers connected to the communications network, which can accept a request from the token 40 verification to handle (for example, to check the validity of the identification information that marker reads from portable consumer devices 5, and provide value verification (dCVV2) in the marker and a network of 70 payment processing, if the identifying information passes one or more test validation. One of the servers object 80 shown in Fig. 1; the server contains one or more processors 81, electrically connected with each of the material of computer-readable media, 82, user interface, 83, one or more databases 86 data and network tools 84, the latter of which is connected with the first and second networks 31 and 32 of communication. The user interface 83 contains one or more units of output (for example, displays, screens) and one or more input devices (e.g. keyboard, mouse, trackball, and so on), which provide an opportunity to the administrator of the object 80 to receive information from the server and to provide input to the server. Computer-readable media 82 may contain a combination of semiconductor memory devices and non-volatile storage devices, for example one or more disk drives and/or non-volatile memory.

One or more databases 86 data can be configured as servers of databases to which the processor(s) 81 can access through the network tool 84 private network 87 communication, which is illustrated by the dashed line in Fig. 1. Object 80 validation traditionally has 88 watch for time tracking and dates for different applications. Watch 88 can be a simple counter seconds or their shares, which can be read by the processor 81 through the operations of input-output, or may contain more complex layout of the hardware or firmware, which can provide different components of the current date and time (year, month, day, hour, minute and second) in different registers, which can be read by the processor 81 by performing one or more disk I / o.

Object 80 validation may process identification data that is transmitted from many different markers 40 verification (for example, millions of markers), and can handle any number of transfers through specific marker 40. Object 80 validation applies one or more tests validation to the marker 40 verification and/or identification information, to obtain a certain level of confidence about what portable consumer unit 5 is actually presented in the token 40 verification, to request a value dCVV2. When one or more tests validation passed and preferably when none of the tests fails, the object 80 validation sends the value dCVV2 in token 40 verification and not necessarily in a network of 70 payment processing together with the account number found in your identity. For these tasks the object 80 validation can contain code, embodied in a computer-readable media, 82, which instructs the processor 81 data to communicate with your computer 10 and marker 40 verification using network tools 84 network 31 communication. This code may include instructions that establish a session with a computer 10, which includes the option of setting up an SSL session with mutual authentication and encryption based on the DES algorithm with triple encryption, and instructions for sending and receiving messages in the token 40 verification through the session. Object 80 validation can optionally contain code that incarnate on computer-readable media, 82, which instructs the processor 81 data to make the encrypted identification information sent via the token 40 verification, and code that instructs the processor 81 data to decrypt the encrypted credentials. Identification information can be encrypted by the session key of the SSL session or through the encryption key stored in the token 40 verification and known for object 80 validation, or may be encrypted twice by both keys. The second key can uniquely be assigned to handle. Object 80 validation can optionally contain code that incarnate on computer-readable media, 82, which instructs the processor 81 data to apply one or more tests checking the validity, as described above, and send the value dCVV2 in token 40 and is not necessary to send the value dCVV2 and account number in the network of 70 payment processing if the number of tests validation passed. Processor 81 data can access databases 86 data when one or more test validation. Tests validation and codes for them are described in more detail below. These codes and the codes below for an object 80 validation can be implemented in any number of programming languages. In addition, experts in the art should be easy for you to issue regulations to implement these codes with this disclosure without undue experimentation.

As described above, the first test validation, which can use the object 80 validation refers to verify that the token 40 verification is genuine. For this marker 40 verification can send your order number in the object 80 verification, along with the test message is encrypted with the encryption key, and a test message and the encryption key (or the corresponding decryption key) is known as a token 40 and object 80 (but not to the public), and advanced encryption key is assigned a unique ordinal position of the marker. Object 80 validation can access the database of serial numbers of markers and relevant uniquely assigned encryption keys (or the corresponding decryption keys) at one of the bases 86 data and may determine that sends or not the marker 40 verification of the correct test message to the sequence number that provides a handle. Test message can be fixed or variable; in the second case it can be formed on the basis of information known as a token 40 and object 80. Test message can be encrypted and decrypted by the algorithm with triple DES encryption, which can be implemented by a certain number of known sets of computer instructions using one of the symmetric encryption key. Test message can be encrypted through the first set key asymmetric encryption keys in the token 40 verification and decrypted by the second key (the decryption key) set asymmetric encryption keys in the object 80 validation, which can be implemented by a certain number of known sets of computer instructions. To validate the encrypted test messages sent via the token 40, object 80 can decrypt the test message using a key that he has, and can compare the decrypted test message with a set of valid messages on the subject of the match. Object 80 can also check the credibility of test messages encrypted reverse way through encryption set of valid messages and compare the encrypted test messages sent through a token-40, with acceptable set of encrypted messages. If you send a test message is correct, the first test of verification can be considered as passed, otherwise, the first test verification is considered failed.

As the second test validation object 80 validation can have the database in the database 86 data, which tracks the index number of a verification token that is used in a fraud (for example, suspicious markers), and the object 80 validation can check the serial number of the marker 40 verification with this database. If you check this database indicates that the token 40 verification was not involved in fraudulent activity or not a suspect in other respects, the second test validation can be considered passed. To help track fraudulent activity back in the token verification, the object 80 validation can send sequence number token 40 together with the value dCVV2 and account number, which it sends to the network 70 payment processing. If the network is 70 subsequently learns that the transaction is processed with the account number provided by the token 40, is fraudulent, it could send a message with this goal in object 80 validation, and the object 80 can then enter the ordinal number of the marker in the database markers used in a fraud. To implement the second test is to verify the authenticity of the object 80 validation can contain code, embodied in a computer-readable media, 82, which instructs the processor 81 data to receive the message from the token 40 verification through the network tool 84, which has a sequence number of a token code that instructs the processor 81 data to compare the received sequence number with the serial numbers stored in the database of databases 86 data, which maintains a sequence number suspicious markers used in a fraudulent transaction to determine that passed the second test validation (fraudulent activity is absent) or failed (fraudulent activity). This code can additionally include statements that instruct the processor 81 to obtain the source IP address of the message from the token 40 and compare the source IP address and serial number of the marker 40 C IP addresses and serial numbers in the 86 data of failed verification of reliability on the subject of the match. If a match is found, the second test validation can be considered as failed. Checking serial numbers of cookies and IP addresses thereby prevents attacks replay through the Scam. The above codes can be implemented using traditional statements of I / o calls API functions in the database, instructions, memory access, logical CPU instructions and control CPU instructions. With this in mind, disclosure, codes can be implemented by experts in the field of technology without undue experimentation.

By carrying out one or more of the above three tests validation object 80 validation can get some degree of confidence that the identification information sent via the token 40 is true, and may, in some implementations, to provide value dCCV2 in token of 40 and a network of 70 payment processing. In this case the marker 40 verification is not necessary to send a fingerprint or a variable element data portable consumer devices 5 in the identification of information and there is no need to get this item from the device 5.

To increase the reliability, the object 80 validation can perform fourth test validation, which compares digital fingerprint, adopted in identity information, if available, with the saved copy of a trusted digital fingerprint that the object has 80 number of the account specified by the identities. If the fingerprints match the extent feasible (for example, the degree of similarity or correlation of these two above prints the selected level of similarity), the object 80 validation can be considered the fourth test validation passed. The degree of similarity between the two prints can be estimated by applying the correlation functions for the two prints. Such correlation functions is known in the field of technology. Before taking identifying information for portable consumer devices 5 from the token, the issuing Bank for the device can provide in the object 80 validation reliable digital magnetic imprint of the device that the object 80 can be saved in one of the bases 86 data. When the object 80 validation accepts credentials from the token 40 verification for a specific portable consumer devices 5, it provides access to databases 86 data to write a trusted digital fingerprint and compares the received fingerprint with reliable digital thumbprint to assess the degree of similarity and to determine that passed the fourth test validity checks (for example, the degree of similarity between the two above prints the selected level) or failed (for example, the degree of similarity between the two prints below the selected level). To implement the fourth test to verify the authenticity of the object 80 validation can contain code, embodied in a computer-readable media, 82, which instructs the processor 81 data get stored reliable digital fingerprint for the account of one of the bases 86 data and the code that instructs the processor 81 data to compare the received digital fingerprint and saved reliable digital fingerprint for similarity to determine what passed on the test (sufficient similarity) or fail (lack of similarity). The second code can contain code that instructs the processor 81 data to generate a value that represents the similarity between the two prints, by applying one or more of correlation functions for prints and compare the value with the selected level. Such correlation functions, also known as probabilistic models are known in the field of technology of credit cards. The above codes can be implemented using traditional statements of I / o calls API functions in the database, instructions, memory access, arithmetic CPU instructions, logical CPU instructions and control CPU instructions. With this in mind disclosure codes can be implemented by experts in the field of technology without undue experimentation.

In order to increase confidence in comparison with the level of reliability offered by the first three tests validation described above, the object 80 validation can perform the fifth test validation, which compares a variable element data (e.g., CVC3, dCVV, the cryptogram), adopted as part identification information, if available, with a set of one or more acceptable values for the variable element of data that the object 80 verification is for the account number provided in as part of the identities. If the values match, the object 80 validation can be considered the fifth test validation passed. There are a number of ways in which variable data element can be configured to change in time. As some examples, the variable data element can be configured to change its value, depending on each use of portable consumer devices 5, and 5 device can provide a counter value in the data element or with the item data. Object 80 of verification or the payment processing network can use a counter to determine what value of variable data element must have for this counter. This determination can be made on the basis of the algorithm, which is a function of the value of counter (and/or other possible variables), or lookup tables, records of which are correlated with the value of counter (table can cyclically repeated). The algorithm can contain one or more of the random number generators, each of which assumes an initial "seed" value whose value can be selected to adjust the algorithm to specific portable consumer device 5. The value of the lookup table can be based on the output of the algorithm. Variable data element can also be based on time, date, or other information, known as token 40 verification, and for object 80, which may use or not to use the value of the counter. Additional ways of formation of the values of variable data element are explained in the application at the U.S. patent number 10/642878, titled "Method and System for generating the Dynamic Verification Value", filed on August 18, 2003, and in the application at the U.S. patent number 11/764376, entitled "On-Line Payment Transactions", filed on January 29, 2008. Both of these applications are fully incorporated by reference into this document. In some implementations, there may be slight differences in the initial information the device 5 and object 80 is used when forming their corresponding values of a data item, for example differences in their hours, and the object 80 can generate a set of acceptable values for a data item on the basis of possible small differences in initial information and can compare the value of a data item taken from the unit 5, with each member of the set, to determine that there is or is not a coincidence.

Before taking identifying information for portable consumer devices 5 from the token issuing Bank for the device can provide in the object 80 validation table search algorithm (including any seed values) or other data elements that uses a device to form a variable element data device (such as CVC3, dCVV or the cryptogram), which is the object 80 can be saved in one of their bases 86 data. When the object 80 validation accepts credentials from the token 40 verification for a specific portable consumer devices 5, it makes the access to the record table search algorithm or other data items for a specific device 5 to determine its value or set of values for a variable data element and compares accept the value for the variable element data (e.g., CVC3, dCVV or cryptogram) with a value or a set of acceptable values for a variable element data to determine that passed the fifth test validity checks (for example, a match the values found) or completed fail (for example, a match is not found). To implement the fifth test to verify the authenticity of the object 80 validation can contain code, embodied in a computer-readable media, 82, which instructs the processor 81 data to access one or more elements of the stored data is used to obtain a variable element data for the account of one of the bases 86 data, code that instructs the processor 81 data to obtain one or more acceptable values for variable data element of one or more elements of the stored data, and code that instructs the processor 81 data to compare accept a variable element data and one or more acceptable values for matches to determine that passed the fifth test (match) or fail (match is not found). Code that instructs the processor 81 data to obtain one or more acceptable values can be based on the method lookup tables described above, or any of the methods based on the algorithm described above. Codes may include statements that instruct the processor 81 data to determine that contains or not accept a variable element data the cryptogram, and if so, receive a fictitious transaction information from the database 86 data based on the sequence number of the marker. Depending on the implementation to process cryptograms code additionally may include statements that instruct the processor 81 data to determine the identity of the issuing Bank and obtain ATC-value for the device 5 of the Bank and to form one or more acceptable values of the cryptogram using fictitious information transaction, ATC-values and other inputs used in the algorithm. In addition, the code can additionally include statements that instruct the processor 81 data to send information and accounts of fictitious transaction information identified in the issuing Bank with the request of one or more acceptable values of the cryptogram. In addition, instead of instructing processor 81 to receive one or more acceptable values of the cryptogram and compare the cryptogram, adopted from the token 40, with acceptable values of the cryptogram, the code may include statements that instruct the processor 81 data to get a fictitious transaction information, as described above, to identify the issuing Bank, as described above, to send information invoices, fictitious transaction information and the cryptogram, adopted from the token 40, identified in the Bank with a request that the Bank sent the indicator back regarding whether or not the cryptogram reliable, and pass or failed to complete fifth test, verification on the basis of the indicator that is sent back by the issuing Bank. The above codes can be implemented using traditional statements of I / o calls API functions in the database, instructions, memory access, arithmetic CPU instructions, logical CPU instructions and control CPU instructions. With this in mind disclosure codes can be implemented by experts in the field of technology without undue experimentation.

Object 80 validation can be configured to perform one or more of the above tests, verification, and can be configured to send the value dCCV2 in token verification, and a network of 70 payment processing if one or more of the tests pass. Object 80 validation can contain code, embodied in a computer-readable media, 82, which instructs the processor 81 data to perform the selected or more tests, verification and tracking results-pass/failure and code that instructs the processor 81 data to generate and send the value dCVV2 if the number of the tests passed. Because the value dCVV2 is sent as seller (relayed via the token 40 verification)and a network of 70 payment processing (which can forward it to the Bank-emitter), object 80 validation can use any method to generate value dCCV2, and it is not necessary to use the method used by portable consumer devices 5 to form a variable element data (e.g., CVC3 or dCVV). Object 80 validation can generate values dCVV2 using a random number generator or a lookup table, or serial counter (for example, if the distribution of values of this counter for different accounts). The process of formation dCVV2 can run on a transaction basis (fully dynamically) or for a group of transactions (semi), the latter is designed for a specific device 5 or device group 5. If two or more devices 5 are appointed with the General account number, identification information, sent via the token 40, may contain the device ID and account number, and the object 80 validation can use the device ID to distinguish between devices and generate different values dCVV2 for devices that have a common account number. Object 80 validation can use a particular value dCVV2 for a particular device 5 for a selected period of time (for example, three days) and then choose a different value dCVV2 for a particular device selected for the next period of time, etc. in Addition, the object 80 validation can take values dCVV2 to use during the selected time periods, from the issuing Bank device 5 before the selected time periods and save them for later use, as defined by hours of object 80. This allows the object 80 validation to omit the step of sending values dCVV2 in a network of 70 payment processing. The value of the verification provided by object 80 validation, can have a format identical to CVC3 and dynamic CVV ("dCVV")displayed via existing credit card on the basis of smart cards (for example, the line of 3 or 4 numbers). As another approach, object 80 validation can send a message to the Bank-emitter 60 to portable consumer device 5 requested value to provide value to dCVV2; this request may include account number, and any device ID. The above codes and stages can be implemented using traditional instructions I / o, instructions, memory access, arithmetic CPU instructions, logical CPU instructions and control CPU instructions. With this in mind disclosure codes can be implemented by experts in the field of technology without undue experimentation.

As described above, the object 80 validation can send a token 40 information, shipping address and/or information clearing user address that was previously associated with the device 5. The Association can be stored in the 86 data object 80 of verification or credit card Issuer 60 for device 5. Object 80 validation can optionally contain code that instructs the processor 81 data to get the address information for the account of the customer, specified by the account number in the incoming identity information, or database 86 data, either from the Bank-Issuer 60 and send the address information in the token 40 together with the value of verification, if the number of tests validation completed, as described above. The above codes and stages can be implemented using traditional statements of I / o function calls databases, call network functions, instructions, memory access, arithmetic CPU instructions, logical CPU instructions and control CPU instructions. With this in mind, disclosure, codes can be implemented by experts in the field of technology without undue experimentation.

Object 80 verification can optionally contain code that instructs the processor 81 send a text warning in a personal communication device 7 user 1 or send a warning mail to the electronic mail address of the user 1, one or more of the following events occurs: (1) when the token 40 verification initiates communication with the object 80, (2) when the token 40 verification reads portable consumer device 5 user 1, (3) when the object 80 verification accepts credentials from the portable consumer devices 5 or token 40 verification associated with the user 1, (4) when the object 80 verification checks the validity of the mentioned identification information, (5) when the object 80 verification sends the value dCVV2 in token 40 verification, and (6) when the object 80 verification rejects the request values dCVV2. Alerts are sent via an 80 may include information related to the events that trigger alert, for example, part of the corresponding account number. Text alerts can be sent from a network tools 84 on the server 35 relay SMS, which is connected with one of the networks 31 and 32 of the communication, together with a phone number or network address of the device connection 7 user. The relay server SMS has an interface with one or more mobile networks and can relay a text message to a phone number or network address provided by the processor 81. Object 80 validation can contain a relay server. Alerts by e-mail can be sent directly to the e-mail address of the user from the network tools 84. For this network tool 84 may contain traditional mail user agent, which is known in the field of technology.

Object 80 validation may include the web site, available for user 1, which enables the user: (1) to create a password-protected administrative expense associated with a serial number of the token, and the second of them may be available on a piece of paper, originally sent marker; (2) to associate the email address that should be used for one or more of the above warnings; (3) to associate the number of a mobile phone and/or URID (for example, the network address) communication devices 5 user that should be used for one or more of the above warnings; and (4) select one or more of the above emergencies. The web site also can enable the user to provide and to associate the account numbers for one or more devices 5 user with a password-protected account and can additionally provide you with the opportunity to associate e-mail and mobile phones to alert a specific device 5 according to their account numbers. The web site can also provide an opportunity for the user to associate the address of delivery and/or billing address with one or more particular account numbers of devices that object 80 validation can provide a marker 40 for each request dCCV2 made for such specified account number of the device. This Association may include the option that the user can choose for the account of the device, which instructs the object 80 to receive information address of the issuing Bank 60 for the account of the device. The web site can also provide an opportunity for the user to associate the address of delivery and/or billing address with the token that the object 80 validation can provide a marker 40 for each request dCCV2, with the address of delivery and/or billing address associated with the account number of the devices in dCVV2 request.

One of the bases 86 data may be appointed to store the above password-protected user accounts. When the object 80 validation takes a request to check the validity of the token 40 verification code in the object 80 may instruct the processor 81 to query this database 86 data, to find the password-protected user account (for example, to identify a user from the sequence number of the token and/or account number sent in identifiable information), to determine what warnings in the form of text messages and email the message should be formed to explore, on the basis of the parameters stored in a password-protected account to identify the mobile phone number or the uniform resource identifier (for example, the network address) personal communication device on which you want to send messages, and/or to identify the email address to which you can send messages, and send certain messages to the identified destination. One or more warnings, specific dCVV2-request, can be combined in a single text message or email message to the user. Object 80 may also have code that instructs the processor 81 data to determine from the record of the account, whether or not any of the information delivery address or information clearing address to go with the message run dCVV2 by finding settings that the user may have been granted to the account number of the device that you specify in the message dCVV2 request, and send the address information in the token 40 according to the detected settings. The above codes and stages can be implemented using codes the HTML codes XML pages and the like (for example, web pages), the traditional statements of I / o instructions, memory access, call API functions databases, arithmetic CPU instructions, logical CPU instructions and control CPU instructions. With this in mind disclosure codes can be implemented by experts in the field of technology without undue experimentation.

If the object 80 validation sends dPAN in token verification, it can send an alert email and/or text alert the user that provides the user with a transaction number that is associated with dPAN. Number of a transaction may provide an opportunity is easier for the user to return the goods purchased in the transaction. The transaction number is different from the dPAN and account number, but enables tracking transactions with dPAN, in the opposite direction to the seller and the issuing Bank. For this object 80 can contain code that instructs the processor 81 data to access administrative account based on the account number, derived from identification of data, received from the token 40 to get the mobile phone number or the uniform resource identifier (for example, the network address) personal communication devices to associate with the account number, or email address associated with the account number, and which should go a transaction number. Object 80 optionally may contain code that instructs the processor 81 data to send the number of transactions with dPAN, date, time and value dCVV2 to receive a phone number or the uniform resource identifier personal communication devices or received e-mail address. The code also instructs the processor 81 data to send this information in a network of 70 payment processing and/or the issuing Bank 60, together with the account number in order correlation. The code can also instruct the processor 81 data to send the number of transactions in the token 40, and the token 40 might have code that instructs its processor 41 to enter this information in a visible or hidden field of the page of payment the seller. Token code 40 for this can be implemented in a way similar to the code to input values dCVV2. The above codes and stages can be implemented using function calls databases, traditional instructions I / o, instructions, memory access, call API functions databases, arithmetic CPU instructions, logical CPU instructions and control CPU instructions. With this in mind disclosure codes can be implemented by experts in the field of technology without undue experimentation.

Embodiments of the invention is not limited authentication systems, with the participation of the transaction. A similar approach can be used for other authentication systems. For example, options for implementation can be used to authenticate the user using the online banking application. The card holder can enter your user ID in the web site of banking services. The card holder can then submit your portable device consumer in the token verification. The web site of banking services can validate the user ID and user token data through communication with the object of verification.

Embodiments of the invention is not limited to the above variants of implementation. For example, although separate functional blocks shown on the Issuer, the system of payment processing and acquirer, some objects perform all these functions and can be included in the embodiments of the invention.

In each of the ways described in this document, the connection between the computer 10 and object 80 validation can help gateway, and/or it can be transported through the gateway (for example, proxy server, the server object, and so on), which is located between the computer 10 and object 80 validation. This gateway is shown in 90 Fig. 8. Gateway 90 can act as an intermediary between multiple markers 40-A, 40-B,..., verification and their associated computers 10-A, 10-B,..., on the one hand, and of 80-A, 80-B,..., validation, on the other hand. Markers, 40-A, 40-B,..., can be made identical to the token 40 shown in Fig. 1, and can interact with the appropriate computers 10-A, 10B,..., corresponding user 1-A, 1-B,..., and relevant portable consumer devices 5-A and 5-B,...,. Computers, 10-A, 10B,..., may be identical to a computer 10, shown in Fig. 1, and can connect to the first network 31 connection, as described above. The first network 31 connection, the second network 32 communications, web sites 20 of the seller, acquiring banks 50, banks 60 and a network of 70 payment processing are connected to each other, as described above. The first and the second network 31, 32 communications are also connected to many objects 80-A, 80 B, 80 C,..., validation, each of which can be made identical to the object 80 validation, shown in Fig. 1.

In the following explanation of the options for implementing and implementations shown in Fig. 8, number link without suffix-A, -B or-C, in General, means each equipped with a suffix of elements (for example, an 80 means each of the 80-A, 80 B, 80 C).

Gateway 90 may take one or more primary links of one of these markers, 40-A, 40-B,..., verification (through one of the computers 10-A, 10B,...that communicates with a token), and can be determined from the information in the initial communicating one of many objects 80-A, 80 B, 80 C,..., validation, to be used to satisfy a request to the marker on the subject of value dCVV2. For example, each token 40-A, 40-B,..., verification can be configured to work with portable consumer devices 5, released through many different banks-issuers of 60 or other such objects, and one or more objects 80 validation can be configured to handle requests from portable consumer devices 5, issued by the corresponding banks-issuers of 60 or other such objects. Gateway 90 can determine the appropriate one of the objects of 80-A, 80 B, 80 C,..., verification on the basis of the identification of the information that the marker reads from portable consumer devices, and sends it to the gateway when the initial connection. For example, part of the account number in identity information may contain a unique identifier assigned to the Bank 60, which produces portable consumer devices 5, which read identifying information.

In one implementation, once the gateway 90 determines the proper object of verification to query token, the gateway can direct a token to implement the additional connection with certain proper object of verification, or may send a specific object of verification, to communicate with the token to implement the additional link. In a different implementation of all communication between the token verification and certain proper object of verification can be carried through the gateway 90 (after the gateway initially determines the identity of the proper object of verification on the basis of one or more initial links with the handle). This second implementation may contain relatively easy passage of communication between the bullet and the proper object of verification with minimal processing by the gateway 90 or may contain a virtual representation of the gateway as the proper object of verification token verification. This virtual presentation may contain decryption by the gateway 90 each message from the token verification, liaison with the proper object of verification, to formulate the answer to a message inside, and encrypting and sending the response message in the token verification. In each of these implementations in other implementations, the gateway 90 can also implement one or more tests validation on behalf of the proper object of verification, in particular the tests associated with the validation token verification. In this case, the gateway is not necessary to send in particular the proper object of verification are those that it receives from the token, which refers to the tests verifying that handles the gateway. Gateway 90 may be associated or controlled through a network of 70 payment processing or owner. It is possible to consider that, in each of these implementations, the gateway 90 acts as an object that can provide value verification (value dCVV2) in token 40, as in the case when the object 80 validation can provide value verification token 40, when the object 80 direct contact token 40.

Referring to Fig. 8, gateway 90 contains a system with one or more servers, grid-connected networks that can accept a request from the token 40 verification to process as described above. One of the servers gateway 90 shown in Fig. 8; the server contains one or more processors 91, electrically connected with each of the material of computer-readable media, 92, user interface, 93, one or more databases 96 data and network tools 94, the latter of which is connected with the first and second networks 31 and 32 of communication. The user interface 93 contains one or more units of output (for example, displays, screens) and one or more input devices (e.g. keyboard, mouse, trackball, and so on), which provide the possibility for the admin gateway 90 to receive information from the server and to provide input to the server. Computer-readable media 92 may contain a combination of semiconductor memory devices and non-volatile storage devices, for example one or more disk drives and/or non-volatile memory.

Gateway 90 can contain code, embodied in a computer-readable media, 92, which instructs the processor 91 data to communicate with your computer 10 and the associated token 40 verification using network tools 94 network 31 communication. This code may include instructions that establish a session with a computer 10, which includes the option of setting up an SSL session with mutual authentication and encryption based on the DES algorithm with triple encryption, and instructions for sending and receiving messages in the token 40 verification through the session. Gateway 90 optionally may contain code that incarnate on computer-readable media, 92, which instructs the processor 91 data to make the encrypted identification information sent via the token 40 verification, and code that instructs the processor 91 data to decrypt the encrypted credentials. Identification information can be encrypted by the session key of the SSL session or through the encryption key stored in the token 40 verification and known for gateway 90, or may be encrypted twice by both keys. The second key can uniquely assigned to marker, as described above. Gateway 90 optionally may contain code that incarnate on computer-readable media, 92, which instructs the processor 91 data to determine from the accepted identity and/or identity token (such as a sequence number marker), proper one of the objects of 80-A, 80 B, 80 C,..., validation, which should be used for further processing of the request from the token 40 verification. For this processor 91 data can access one of the bases 96 data for a list of correlation, which connects identification information (or part thereof) with 80 objects of verification, and/or for a list of correlation, which connects the IDs token 80 objects of verification, and can then compare the information downloaded from the token 40, with a list(kami) correlation to determine the appropriate one from the 80 objects of verification. Gateway 90 optionally may contain code that incarnate on computer-readable media, 92, which instructs the processor 91 data to apply one or more tests checking the validity, as described above, and to continue processing the request from the token 40 if the number of tests validation passed. Various ways to continue processing are described below in different possible implementations gateway 90. The above codes for gateway 90 and codes for gateway 90, described below, can be implemented in any number of programming languages. In addition, experts in the art should be easy for you to issue regulations to implement these codes with this disclosure without undue experimentation.

In one implementation gateway 90 optionally may contain code that incarnate on computer-readable media, 92, which instructs the processor 91 data to send the connection to the token 40 (through associate computer 10), indicating to the marker to make contact with a certain proper object 80 validation, to get the value dCVV2. This connection can include URID appropriate for a particular object of verification. Marker 40 can then communicate with a specific proper object 80 as described above, and changes to the object 80 is not required. In this implementation gateway 90 code optionally instruct the processor 91 data to send a link to a specific proper object 80 verification, which reports to the object relative to the request from the token 40 (together with the indicator relative to the identification of information sent by a token 40), and tells the object that the token 40 should contact with him on the subject of value dCVV2 for identifying information (sent to the gateway by 90 token 40). This connection through the gateway 90 may act as an additional security measures, which guarantees for the proper object 80 verification that the subsequent contract by means of a token-40 is legal.

In other implementation gateway 90 optionally may contain code that incarnate on computer-readable media, 92, which instructs the processor 91 data to send a link to a specific proper object 80 validation with the indicator relative to the identification of data, received from the token 40 verification and request that object of verification formed the value dCVV2 for identity information and sent the value dCVV2 in token 40 verification (by the associated computer 10). This connection can include URID token 40 verification. Object codes 80 validation described above, can be supplemented to instruct the processor 81 object can accept the above link from the gateway 90 and initiate communication with the requesting token 40. Object codes 80 verification not required to instruct the processor 81 object can accept authentication information from the requesting token (as it may be provided in the object through a gateway 90); however, as an additional security measures, requesting the token 40 can provide identification information in the object 80, and the object can include code to accept credentials from the token. In this implementation gateway 90 code for gateway 90 optionally instruct the processor 91 data to send the connection to the token 40 verification (through associate computer 10), indicating to the token that a proper object 80 verification shall liaise with it to potentially send the value dCVV2.

In another different implementation gateway 90 gateway can optionally contain code that incarnate on computer-readable media, 92, which instructs the processor 91 data: (1) to send an initial communication from the requesting token 40 and/or indicator relative to the identity sent by the requesting token 40, in particular the proper object 80 validation, to get the value dCVV2; (2) to take back the value dCVV2 of proper object 80 validation; and (3) send the value dCVV2 in token 40 verification. This implementation gateway 90 provides the opportunity to object 80 validation to omit the code for linking to a computer 10 used by requesting the token 40 verification (this task can be handled by the gateway 90). The codes object 80, above which direct communication with the token 40, can be modified to direct connectivity to gateway 90 instead. This implementation gateway 90 provides the ability grouping requests from many markers 40 for more efficient processing by means of an object 80. In addition, as the gateway 90 virtual presents itself in the token 40 verification as an object of verification, gateway 90 can act as an Internet firewall to protect the interest of the 80-A, 80-B,..., validation from malicious Internet attacks.

In another different implementation gateway 90 handles the initial connection with the token 40 to determine the appropriate object 80 validation, and then passes the service communication channel particular object 80 verification to complete the request token. All communication between the requesting token 40 and specific object 80 can be transferred through the gateway 90. If the gateway 90 previously installed an SSL session with the requesting token 40, gateway 90 can send the session key(s) and protocols in specific object 80, so that the object can take control of the session (for example, to take over control of the communication is encrypted with the session token keys and protocols). For this implementation, the gateway 90 optionally may contain code that incarnate on computer-readable media, 92, which instructs that the processor 91 data (1) sent a link in a certain proper object 80 verification, indicating that he should handle additional connection with requesting marker (routed through the gateway 90) and, optionally, information session (which may include keys and SSL-session), (2) send an additional link that gateway 90 receives from the requesting token 40, in a certain object 80, and (3) send the link that gateway 90 receives from a particular object 80, in requesting the token 40. To do this, the gateway 90 can maintain a table in a storage device or one of its bases 96 data, which tracks the channels that are currently being transferred through the gateway 90, with each record in the table has the identity of the requesting token, a specific object of verification and information session. To perform the above-mentioned second stage, the code can instruct the processor 91 to access the table of the channel, to find a certain object 80 for requesting the token 40, and then to share packets communication from the requesting token object that is in the table. Gateway 90 can encapsulate these packets due to preserve their header information, and may include an indicator as to the identity of the requesting token 40 in favour of a particular object 80. To simplify the above third stage, a certain object 80 validation can send your packages due to the requesting token 40 in the gateway 90 in encapsulated form, optional, along with the ID that identifies the requesting a marker in the capsule. The gateway then 90 can include code that instructs the processor 91 data to retrieve from the encapsulated packet, the token ID, and the package should go to the requesting token 40. If the extracted package already has the destination address for a computer 10, United with the requesting token 40, there is no need to encapsulated package included the identity of the requesting marker. If the extracted package does not include the destination address, the code gateway 90 may instruct the processor 91 data to determine the destination address from the extracted token ID and the above table information channel and paste a specific destination address in the extracted package before it is sent to a computer 10. This step can provide an additional level of security. In addition, as the gateway 90 virtual presents itself in the token 40 verification as an object of verification, gateway 90 can act as an Internet firewall to protect the interest of the 80-A, 80-B,..., validation from malicious Internet attacks.

It should be understood that various embodiments of the present invention, as described above, can be implemented in the form of logic using computer software modular and integrated way. Based on the disclosure and ideas provided in this document, experts in the art should know and take into account other way and/or ways to implement embodiments of the present invention using hardware and combinations of hardware and software.

Any of the software components or features described in this application can be implemented as a software code that must be executed by the processor, using any appropriate machine language, such as, for example, C, C++, C#, Java, C++, or Perl, using, for example, traditional and object-oriented technologies. The code can be saved as a sequence of instructions or commands on computer-readable media, such as random access memory (RAM), permanent memory (ROM), magnetic media, such as hard drive or floppy drive, or optical media, such as CD-ROM. Any such computer-readable media can constantly be accommodated within a single computing device or may be present or to be inside various computing devices in the system or network.

The description above is illustrative and is not restrictive. Many varieties of the invention and its variants implementation should become obvious to specialists in a given field of technology after reading this disclosure. Therefore, the volume of the invention must be defined with reference to the above description, but should instead be defined with reference to the attached claims together with its full volume or equivalents.

One or more characteristics of any option exercise can be combined with one or more attributes of any other option exercise without derogating from the scope of the invention.

Singular means "one or more", if other is not mentioned explicitly.

All patents, patent applications, publications and descriptions mentioned above, are fully incorporated herein by reference. None of them is not recognized as prior art.

1. A verification token that gets the value verification for transactions conducted using portable consumer device, with a verification token contains: - peripheral interface, made to connect to peripheral computer interface; - the reader is made to read identifying information from portable consumer devices; - computer-readable media; - a data processor, electrically connected with peripheral interface token verification, the reader and the computer-readable media; code embodied on computer-readable media, which instructs the processor data to make the identification information read from portable consumer devices by means of the reader, for the mentioned transactions, and identification information includes your account number and the first value verification provided portable consumer device; code embodied on computer-readable media, which instructs the processor data to communicate with the computer by means of peripheral interface token verification and to access the network agent computer code, embodied in a computer-readable media, which instructs the processor data set, with using network tools of computer, connection to the object, which can provide the second value verification; code embodied on computer-readable media, which instructs the processor data to send, at least, account number and the first value verification of the received identification information in the network through the means of a computer; and code embodied on computer-readable media, which instructs the processor data to receive, after the transfer of the aforementioned identity, the second value verification for the said transactions of the object referred to by the network computer, and the second value verification devices configured to enter in the value field verification of the card on the web page of the seller.

2. Token verification of claim 1, wherein peripheral interface token verification contains connector universal serial bus.

3. Token verification of claim 1, wherein the identifying information is encrypted, and the first value verification varies each time portable consumer device is read on the subject of identification information.

4. Token verification of claim 1, wherein the code that instructs the data processor to communicate with the computer that contains the code that instructs the processor data to send to the device driver in the computer, and the instructions to install the device driver in the operating system of the computer, the device driver allows the computer to recognize the token verification and to make a connection with a token verification; - where the code that instructs the processor data to access the network tool is a computer, contains a call to the functions in the module network services computer operating system; and where the code that instructs the data processor to communicate with the said object using the network facilities of the computer that contains one or more function calls in the application programming interface module network services computer, and one or more function calls provide a uniform resource identifier of the mentioned object and instruction to establish a session with the mentioned object, with a uniform resource identifier stored on computer-readable media, or read from portable consumer devices.

5. Token verification of claim 1, further contains a sequence number and an encryption key, and the token verification transmits a sequence number and a message that is encrypted with the encryption key, in the mentioned object, and the ordinal number and the encryption key is uniquely assigned to a verification token.

6. Token verification of claim 1, further comprising: - code embodied on computer-readable media, which instructs the processor data to find the web browser on the computer that has the form field values for verification of the device, and enter the value verification, taken from the mentioned object, in the form field.

7. Token verification of claim 1, further comprising: - code embodied on computer-readable media, which instructs the processor data to display the value of verification, taken from the mentioned object, the user of the computer display.

8. Token verification of claim 1, wherein the code that instructs the processor data to take the value of the verification of the mentioned object, further instructs the processor data to take dynamic account number of the mentioned object.

9. Token verification of claim 8, further comprising: - code embodied on computer-readable media, which instructs the processor data to find the web browser on the computer that has the first field of the form for the account number and the second form field values for verification, and fill out the first field dynamic account number and the second field - value verification taken from the mentioned object.

10. Token verification of claim 8, further comprising: - code embodied on computer-readable media, which instructs the processor to display dynamic data account number and value verification, taken from the mentioned object, the user on each display device of the computer.

11. Token verification of claim 1, further comprising: - code embodied on computer-readable media, which instructs the processor data to prompt the user to enter a password on the computer keyboard, read the password entered by the user, and compare the entered password with the saved password, incarnate on computer-readable media; and code embodied on computer-readable media, which instructs the processor data to prevent, at least, read or send identifying information, when read password is not identical to the saved password.

12. The way to get the value of verification for transactions conducted using portable consumer devices containing phases in which: - establish a communications link between the token verification and computer, and the computer contains a network tool; - installing, using networking computer communication session between token verification and object, which can provide value verification; - read identifying information from portable consumer devices to the token verification for the said transaction, and a few identification information includes your account number and the first value verification; - transmit a matter of identifying information from the token verification referred to in the object through the session, and a matter of identifying information is passed in the mentioned object in encrypted form; and - after sending a matter of identifying information, take, in the token verification, the second value verification for the said transactions of the object referred to by means of a communication session, and the second value verification devices configured to enter in the value field verification of the card on the web page of the seller.

14. The method indicated in paragraph 12, optionally containing phases in which: - prompt user to enter a password in the computer; - read the password entered by the user; - compare the entered password with the password stored in the token verification; and - prevent, at least, read or send identifying information, when read password is not identical to the saved password.

15. The method indicated in paragraph 12, additionally contains the stage at which: - transfer from the token verification in the mentioned object via a communication session sequence number that is saved in the token verification, and the message is encrypted with the encryption key stored in the token verification, and the ordinal number and the encryption key is uniquely assigned to a verification token.

16. The method indicated in paragraph 12, additionally contains at least one of the stages in which: - display the value verification, taken from the mentioned object, the user on the display of a computer; and - find a web browser on the computer that has the form field values for verification of the device, and enter the value verification, taken from the mentioned object, in the form field.

17. The method indicated in paragraph 12, optionally containing a phase in which, after the transfer of identification information: - accept, in the token verification, dynamic account number of the mentioned object by means of a communication session.

18. The method according to 17, optionally containing phases in which: - find a web browser on the computer that has the first field of the form for the account number and the second form field values for verification; and - fill the first field dynamic account number, and the second field - value verification taken from the mentioned object.

19. The way of conducting the transaction, containing phases in which: - connect the token verification with a computer by using peripheral interface of the computer, and the computer contains a network tool, with a verification token contains: peripheral interfaces to connect to peripheral computer interface, the reader is made to read identifying information from portable consumer devices, computer-readable media, and processor data; the verification token configured to read identifiable information, which includes room account and the first value verification portable consumer devices, using reader and get the second value verification for him from the first object using network tools of computer; - represent portable consumer device for reader token verification to provide token with the account number and the first value verification for the said transaction and get the second value verification devices for portable consumer devices, and the second value verification device configured with input possibility in the value field verification of the card on the web page of the seller; and - provide obtained the second value verification in the second object as part of the conduct of the mentioned transaction.

20. The method of claim 19, additionally contains the stage at which: - are password token verification.