阅读说明：本技术 卡的交易的动态认证方法及系统 (Dynamic authentication method and system for card transaction ) 是由 文卡察沙·穆里达兰 香木哈纳森·西亚加拉贾 于 2018-02-08 设计创作，主要内容包括：公开用于支付卡交易的方法及系统,其中,卡验证值(CVV)或卡验证码(CVC)是作为令牌化地会话的一部分被动态地生成。(methods and systems for payment card transactions are disclosed in which a Card Verification Value (CVV) or Card Verification Code (CVC) is dynamically generated as part of a tokenized session.)

1. A method for processing a payment made via a payment card, comprising the steps of:

Receiving, from a device associated with a requestor, a request for a security code of at least one payment card assigned a unique token and associated with the requestor;

responding to the request for the security code by authenticating the requestor and allowing the requestor to conduct a transaction using the at least one payment card, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor;

After the authentication of the supplicant is successful:

generating a security code for the at least one payment card assigned a unique token;

opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and

Providing the generated security code to the requestor;

Receiving transaction data for a transaction using the at least one payment card, the transaction data including payment card information and a security code of the at least one payment card;

Determining whether the payment card information corresponds to a payment card assigned a unique token; and

If there is a correspondence and if the session of the generated security code is open, authenticating the transaction of the at least one payment card by comparing the received security code of the at least one payment card with the generated security code of the at least one payment card.

2. the method of claim 1, wherein: the method further comprises: assigning a unique token to the at least one payment card when the at least one payment card is issued.

3. The method of claim 1, wherein: the second identifier comprises at least one of a Personal Identification Number (PIN) or a fingerprint.

4. The method of claim 3, wherein: the device comprises a smartphone, a mobile computer, a mobile device, or a device suitable for running a client application.

5. The method of claim 4, wherein: the first identifier is a unique secret identifier associated with a device, wherein a list of trusted multiple devices is associated with each requestor.

6. The method of claim 4, wherein: if a device represented by the first identifier is not currently trusted by the requestor, triggering a process of establishing trust in a new device to treat the new device as a trusted device, the process comprising:

confirming current access to an identification method associated with an owner of the at least one payment card, the confirmation including a telephone number associated with an account of the at least one payment card.

7. The method of claim 1, wherein: the generated security code includes at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

8. The method of claim 1, wherein: the at least one payment card includes a payment card.

9. The method of claim 1, wherein: the at least one payment card includes a plurality of payment cards.

10. The method of claim 1, wherein: if the session is not opened for the generated security code, the transaction will not be verified.

11. The method of claim 1, wherein: the time period of the session includes at least one of: a fixed time or a random time within a certain range, and closing a new session when the session is opened when a new security code is generated for at least one payment card.

12. The method of claim 1, wherein: the payment associated with the payment card includes a payment without a card present.

13. A system for processing a payment made via a payment card, comprising:

A first computer system comprising a processor programmed to:

Receiving, from a device associated with a requestor, a request for a security code of at least one payment card assigned a unique token and associated with the requestor;

Responding to the request for the security code by authenticating the requestor and allowing the requestor to conduct a transaction using the at least one payment card, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor;

After the authentication of the supplicant is successful:

Generating a security code for the at least one payment card assigned a unique token;

Opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and

Providing the generated security code to the requestor;

Receiving, using the at least one payment card, transaction data for a transaction, the transaction data including payment card information and a security code of the at least one payment card, determining whether the payment card information corresponds to a payment card assigned a unique token; and

If there is a correspondence and if the session of the generated security code is open, authenticating the transaction of the at least one payment card by comparing the received security code of the at least one payment card with the generated security code of the at least one payment card.

14. The system of claim 13, wherein: the processor is programmed to determine whether the payment card information corresponds to a payment card assigned a unique token, and is further programmed to query a second computer system whether the payment card information corresponds to a payment card assigned a unique token.

15. The system of claim 14, wherein: the second computer system includes a processor programmed to assign a unique token to the at least one payment card when the at least one payment card is issued.

16. The system of claim 13, wherein: the generated security code includes at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

17. The system of claim 16, wherein: the at least one payment card includes a payment card.

18. The system of claim 16, wherein: the at least one payment card includes a plurality of payment cards.

19. A method for processing a payment made via a payment card, comprising the steps of:

Receiving, from a device associated with a requestor, a request for a security code assigned a unique token and each of one or more payment cards associated with the requestor;

Responding to the request for the security code by authentication of the requestor and allowing the requestor to conduct transactions using the one or more payment cards, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor;

After the authentication of the supplicant is successful:

generating a security code for the one or more payment cards assigned a unique token;

Opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and

Providing the generated security code to the requestor;

receiving, using a payment card of the one or more payment cards, transaction data for a transaction, the transaction data including payment card information and a security code of the payment card of the one or more payment cards, determining whether the payment card information corresponds to a payment card assigned a unique token; and

Authenticating the transaction for the payment card of the one or more payment cards by comparing the received security code of the payment card of the one or more payment cards with the generated security code of the payment card of the one or more payment cards if there is a correspondence and if the session of the generated security code is open.

20. The method of claim 19, wherein: the one or more payment cards include all payment cards associated with the requestor.

21. the method of claim 19, wherein: the method further comprises: assigning a unique token to each of the one or more payment cards when each of the one or more payment cards is issued.

22. The method of claim 19, wherein: the second identifier comprises at least one of a Personal Identification Number (PIN) or a fingerprint.

23. the method of claim 19, wherein: the device comprises a smartphone, a mobile computer, a mobile device, or a device suitable for running a client application.

24. The method of claim 23, wherein: the first identifier is a unique secret identifier associated with a device, wherein a list of trusted multiple devices is associated with each requestor.

25. The method of claim 24, wherein: if a device represented by the first identifier is not currently trusted by the requestor, triggering a process of establishing trust in a new device to treat the new device as a trusted device, the process comprising:

Confirming current access to an identification method associated with an owner of the at least one payment card, the confirmation including a telephone number associated with an account of the at least one payment card.

26. The method of claim 19, wherein: the generated security code includes at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

27. The method of claim 19, wherein: the one or more payment cards include a payment card.

28. The method of claim 19, wherein: the one or more payment cards include a plurality of payment cards.

29. The method of claim 19, wherein: if the session is not opened for the generated security code, the transaction will not be verified.

30. The method of claim 19, wherein: the time period of the session includes at least one of: a fixed time or a random time within a certain range, and closing a new session when the session is opened when a new security code is generated for at least one payment card.

31. The method of claim 19, wherein: the payment associated with the payment card includes a payment without a card present.

32. a system for processing a payment made via a payment card, comprising:

A first computer system comprising a processor programmed to:

Receiving, from a device associated with a requestor, a request for a security code assigned a unique token and each of one or more payment cards associated with the requestor;

Responding to the request for the security code by authentication of the requestor and allowing the requestor to conduct transactions using the one or more payment cards, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor;

After the authentication of the supplicant is successful:

Generating a security code for the one or more payment cards assigned a unique token;

Opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and

providing the generated security code to the requestor;

Receiving, using a payment card of the one or more payment cards, transaction data for a transaction, the transaction data including payment card information and a security code of the payment card of the one or more payment cards, determining whether the payment card information corresponds to a payment card assigned a unique token; and

authenticating the transaction for the payment card of the one or more payment cards by comparing the received security code of the payment card of the one or more payment cards with the generated security code of the payment card of the one or more payment cards if there is a correspondence and if the session of the generated security code is open.

33. The system of claim 32, wherein: the processor is programmed to determine whether the payment card information corresponds to a payment card assigned a unique token, and is further programmed to query a second computer system whether the payment card information corresponds to a payment card assigned a unique token.

34. The system of claim 33, wherein: the second computer system includes a processor programmed to assign a unique token to each of the one or more payment cards when each of the one or more payment cards is issued.

35. the system of claim 32, wherein: the generated security code includes at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

36. The system of claim 32, wherein: the one or more payment cards include all payment cards associated with the requestor.

Technical Field

The invention relates to securing card transactions.

background

As shown in fig. 1A (front side 10a) and 2B (back side 10B), on a conventional card such as a credit card 10, CVV (card verification value)/CVC (card verification code) is a three-digit number 15. The CVV/CVC is printed on the back side 10b of the card 10 and is typically used in online transactions. Typically, the card issuance processor will typically have 16 digits imprinted in the card 10, best visible on the front face 10a, based on the Primary Account Number (PAN)14, such as in fig. 1A. The PAN 14 is 5412345678901234 (the first four to six digits are Bank Identification Numbers (BINs), e.g., 5412 for the card 10). The expiration date of the card is typically embossed on the front face 10a of the card 10, e.g., 12-05, representing 12 months of 2005.

traditionally, card transaction verification at the card issuing processor involves a balance (or credit line) check, an expiration check, a match of the CVV with the card number, and any other fraud rules. Card data may be compromised at the user end for a variety of reasons (e.g., via a keyboard logging program or phishing), data leakage or vulnerability to brute force at the issuing bank, acquiring bank, or merchant.

To prevent this harm, card solutions have developed strong authentication/3 d security, often requiring additional steps in approving the card transaction: typically by means of an additional static password known to the user or a dynamic one-time password sent to the registered telephone number. Certain regulatory agencies in a particular country/region typically recommend/authorize the use of enhanced authentication based on transaction type/value thresholds.

to protect card transactions, some cards currently contain a dynamic CVV when no card is present. Using this dynamic CVV, the display of the card back or chip on the back changes the CVV. In some cases, the CVV may be delivered to the user by other methods (e.g., Short Message Service (SMS)) or by a mobile application.

in order to comply with Payment Card Industry (PCI) regulations, merchants, issuers and processors that process cardholder data (card number, CVV, expiry date) must typically comply with a strict set of standards. In many cases, merchants, issuers and processors prefer to avoid the burden of PCI compliance by cooperating with partners that process the original card number and convert it to tokens.

Disclosure of Invention

The present invention allows the card issuer/program manager to greatly increase security and eliminate online fraud while maintaining full PCI compatibility without the burden of card PAN storage. The present invention also protects the card issuer/program manager from CVV damage from any other source-the user, the merchant, and/or the card issuer processor (the card processor associated with the card issuer/program manager). Furthermore, the present invention also ensures that all on-line card transactions using CVV are authenticated by two elements, providing the additional benefit of 3d security verification without the need for an actual extra redirection step.

The present invention is directed to methods and systems for payment card transactions in which a Card Verification Value (CVV) or Card Verification Code (CVC) is dynamically generated as part of a token session.

The present invention is also directed to cards that lack a natural CVV located in themselves, but instead create the CVV, typically dynamically or dynamically by an application. This reduces the risk of online fraud. Therefore, even if the user loses his card, anyone cannot use it online.

Embodiments of the present invention are directed to methods and systems for dynamically presenting a CVV to a user (requestor) (the terms "user" and "requestor" are used interchangeably herein to indicate an entity, and use "user" and/or "requestor," depending on the stage of the in-the-invention process in which the entity participates) in a phone application (app), rather than on a card. The CVV does not exist until the user starts an application (app) on a trusted device (e.g., a smartphone) and is ready for card transactions. In this regard, a session is created for the user, and a CVV is generated for any cards owned by the user, where the cards are identified by their tokens. The CVV is available in the memory of the card issuer/program manager's system and is provided to the user (e.g., trusted device) through a secure session in an application program (app). This temporary CVV has a short lifetime and is only valid during the session. The method is compliant with the Payment Card Industry (PCI) because the authorization system (i.e., card issuer/program manager) does not have a card PAN, and the PAN is converted to a card token by another system (e.g., a third party processor). The card issuer/program manager is the authorization system and authorizes the transaction based on the card token and the dynamic CVV.

Embodiments of the present invention relate to a method for processing payments made through a payment card (e.g., a debit card, credit card, or other transaction card). The method comprises the following steps: receiving, from a device associated with a requestor (also referred to as a user), a request for a security code of at least one payment card assigned a unique token and associated with the requestor; responding to the request for the security code by authenticating the requestor and allowing the requestor to conduct a transaction using the at least one payment card, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor; after the authentication of the supplicant is successful: 1) generating a security code for the at least one payment card assigned a unique token; 2) opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and 3) providing the generated security code to the requestor; receiving transaction data for a transaction using the at least one payment card, the transaction data including payment card information and a security code of the at least one payment card; if there is a correspondence (e.g., a match) and if the session of the generated security code is open, authenticating the transaction of the at least one payment card by comparing the received security code of the at least one payment card with the generated security code of the at least one payment card.

Optionally, a unique token is assigned to the at least one payment card when the at least one payment card is issued.

Optionally, the second identifier comprises at least one of a Personal Identification Number (PIN) or a fingerprint.

Optionally, the device comprises a smartphone, a mobile computer, a mobile device, or a device adapted to run a client application.

Optionally, the method is such that the first identifier is a unique secret identifier associated with a device, wherein a list of trusted multiple devices is associated with each requestor.

Optionally, the method is such that if a device represented by the first identifier is not currently trusted by the requester, a procedure of establishing trust in a new device to treat the new device as a trusted device is triggered, the procedure comprising: confirming current access to an identification method associated with an owner of the at least one payment card, the confirmation including a telephone number associated with an account of the at least one payment card.

Optionally, the method causes the generated security code to include at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

Optionally, the method is such that the at least one payment card comprises a payment card.

Optionally, the method is such that the at least one payment card comprises a plurality of payment cards.

optionally, the method is such that the transaction is not verified if the session is not opened for the generated security code.

Optionally, the method is such that the time period of the session comprises at least one of: a fixed time or a random time within a certain range, and closing a new session when the session is opened when a new security code is generated for at least one payment card.

optionally, the method is such that the payment associated with the payment card comprises a payment without a card present.

Embodiments of the present invention are directed to a system for processing payments made by payment cards. The system comprises: a first computer system comprising a processor programmed to: receiving, from a device associated with a requestor, a request for a security code of at least one payment card assigned a unique token and associated with the requestor; responding to the request for the security code by authenticating the requestor and allowing the requestor to conduct a transaction using the at least one payment card, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor; after the authentication of the supplicant is successful: generating a security code for the at least one payment card assigned a unique token; opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and providing the generated security code to the requestor; receiving, using the at least one payment card, transaction data for a transaction, the transaction data including payment card information and a security code of the at least one payment card, determining whether the payment card information corresponds to a payment card assigned a unique token; and if there is a correspondence, and if the session of the generated security code is open, authenticating the transaction of the at least one payment card by comparing the received security code of the at least one payment card with the generated security code of the at least one payment card.

Optionally, the system is such that the processor is programmed to determine whether the payment card information corresponds to a payment card assigned a unique token, and is further programmed to query a second computer system whether the payment card information corresponds to a payment card assigned a unique token.

Optionally, the system is such that the second computer system comprises a processor programmed to assign a unique token to the at least one payment card when the at least one payment card is issued.

optionally, the system is such that the generated security code comprises at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

Optionally, the system is such that the at least one payment card comprises a payment card.

Optionally, the system is such that the at least one payment card comprises a plurality of payment cards.

Embodiments of the present invention are directed to a method for processing payments made through a payment card. The method comprises the following steps: receiving, from a device associated with a requestor, a request for a security code assigned a unique token and each of one or more payment cards associated with the requestor; responding to the request for the security code by authentication of the requestor and allowing the requestor to conduct transactions using the one or more payment cards, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor; after the authentication of the supplicant is successful: generating a security code for the one or more payment cards assigned a unique token; opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and providing the generated security code to the requestor; receiving, using a payment card of the one or more payment cards, transaction data for a transaction, the transaction data including payment card information and a security code of the payment card of the one or more payment cards, determining whether the payment card information corresponds to a payment card assigned a unique token; and if there is a correspondence, and if the session of the generated security code is open, authenticating the transaction of the payment card of the one or more payment cards by comparing the received security code of the payment card of the one or more payment cards with the generated security code of the payment card of the one or more payment cards.

Optionally, the method causes the one or more payment cards to include all payment cards associated with the requestor.

optionally, the method is such that the method further comprises: assigning a unique token to each of the one or more payment cards when each of the one or more payment cards is issued.

optionally, the method is such that the second identifier comprises at least one of a Personal Identification Number (PIN) or a fingerprint.

Optionally, the method is such that the device comprises a smartphone, a mobile computer, a mobile device, or a device adapted to run a client application.

Optionally, the method is such that the first identifier is a unique secret identifier associated with a device, wherein a list of trusted multiple devices is associated with each requestor.

Optionally, the method is such that if a device represented by the first identifier is not currently trusted by the requester, a procedure of establishing trust in a new device to treat the new device as a trusted device is triggered, the procedure comprising: confirming current access to an identification method associated with an owner of the at least one payment card, the confirmation including a telephone number associated with an account of the at least one payment card.

Optionally, the method causes the generated security code to include at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

Optionally, the method is such that the one or more payment cards comprise a payment card.

Optionally, the method is such that the one or more payment cards include multiple payment cards.

Optionally, the method is such that the transaction is not verified if the session is not opened for the generated security code.

Optionally, the method is such that the time period of the session comprises at least one of: a fixed time or a random time within a certain range, and closing a new session when the session is opened when a new security code is generated for at least one payment card.

Optionally, the method is such that the payment associated with the payment card comprises a payment without a card present.

Embodiments of the present invention are directed to a system for processing payments made via payment cards. The system comprises: a first computer system comprising a processor programmed to: receiving, from a device associated with a requestor, a request for a security code assigned a unique token and each of one or more payment cards associated with the requestor; responding to the request for the security code by authentication of the requestor and allowing the requestor to conduct transactions using the one or more payment cards, the authentication of the requestor including: receiving a first identifier for the apparatus; and receiving a second identifier associated with the requestor; after the authentication of the supplicant is successful: generating a security code for the one or more payment cards assigned a unique token; opening a session for the generated security code, the session being continuously open for a period of time during which the generated security code is valid; and providing the generated security code to the requestor; receiving, using a payment card of the one or more payment cards, transaction data for a transaction, the transaction data including payment card information and a security code of the payment card of the one or more payment cards, determining whether the payment card information corresponds to a payment card assigned a unique token; and if there is a correspondence, and if the session of the generated security code is open, authenticating the transaction of the payment card of the one or more payment cards by comparing the received security code of the payment card of the one or more payment cards with the generated security code of the payment card of the one or more payment cards.

Optionally, the system is such that the processor is programmed to determine whether the payment card information corresponds to a payment card assigned a unique token, and is further programmed to query a second computer system whether the payment card information corresponds to a payment card assigned a unique token.

Optionally, the system is such that the second computer system comprises a processor programmed to assign a unique token to each of the one or more payment cards when each of the one or more payment cards is issued.

Optionally, the system is such that the generated security code comprises at least one of a Card Verification Value (CVV) or a Card Verification Code (CVC).

Optionally, the system causes the one or more payment cards to include all payment cards associated with the requestor.

The terms used herein are used consistently and interchangeably. The terms, including variations thereof, are as follows.

"computer" includes machines, computers and computing or computer systems (e.g., physically separate locations or devices), servers, computers and computerized devices (also referred to as "devices"), including "trusted devices", processors, processing systems, computer cores (e.g., shared devices), and similar systems, workstations, modules, and combinations of the foregoing. The aforementioned "computers" may be of various types, such as personal computers (e.g., laptop computers, desktop computers, tablet computers) or any type of computer device, including devices that can be easily transported from one location to another (e.g., smart phones, Personal Digital Assistants (PDAs), mobile phones, or cellular phones).

an "application" includes executable software by which certain functions may be implemented, and optionally any Graphical User Interface (GUI).

A "client" is an application program that runs on a computer, workstation, or the like, and relies on a server to perform certain operations or functions.

Unless defined otherwise herein, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present invention, exemplary methods and/or materials are described below. In case of conflict, the present specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not necessarily limiting.

Drawings

Some embodiments of the invention are described herein, by way of example only, with reference to the accompanying drawings. With specific reference to the drawings, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the embodiments of the present invention. In this regard, it will be apparent to those skilled in the art from this description, taken in conjunction with the accompanying drawings, how embodiments of the present invention may be practiced.

attention is now directed to the drawings, wherein like reference numerals or characters designate corresponding or identical elements. In the drawings:

fig. 1A and 1B are schematic views of a conventional card, such as a credit or debit card.

Fig. 2A is an exemplary schematic diagram of a system in which embodiments of the disclosed subject matter are implemented.

Fig. 2B-1 and 2B-2 are schematic diagrams of a card according to an embodiment of the invention as shown in fig. 2A being used.

Fig. 3A to 3D are flowcharts of a process according to an embodiment of the present invention.

Detailed Description

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not necessarily limited in its application to the details of construction and to the arrangements of the components and/or methods set forth in the following description and/or illustrated in the drawings. The invention is capable of other embodiments or of being practiced or carried out in various ways.

as will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, aspects of the present invention may take the form of a computer program product embodied on one or more non-transitory computer-readable (storage) media having computer-readable program code embodied thereon.

Throughout this text, numerous text and graphical references are made to trademarks and domain names. These trademarks and domain names are the property of their respective owners and are referenced herein for illustrative purposes only.

The present invention relates to a method and system for payment card transactions in which a Card Verification Value (CVV) or Card Verification Code (CVC) (the terms "CVV" and "CVC" are used interchangeably herein) is dynamically generated and valid for a short period of time. For example, a short-term session is created using multi-factor authentication that controls the validity of the CVV/CVC associated with a card token, verified using a unique token instead of the card number, and is open for a predetermined period of time and thus valid for the session.

The present invention is directed to methods and systems for card transactions in which no card is required to perform a transaction, such as a payment (payment), also referred to as a "card not present" transaction or payment. The disclosed method and system provide a dynamic CVV as a security code. Embodiments of the present invention provide all the benefits of enhanced authentication/3D security based on two factors, in that neither party, including the issuer, can access the card and CVV at any time.

Thus, when there is an active session for a user (requestor) (the terms "user" and "requestor" are used interchangeably herein), the disclosed methods and systems use the "user" and/or "requestor" to dynamically generate a CVV and verify a transaction to indicate an entity, depending on the stage of the process of the present invention in which the entity is involved. Having the card identified by its token will generate a dynamic CVV that can be used to verify the card's token. This allows CVV verification to be performed on the card without any party in the transaction processing chain (the user, or even the verification issuer) and only the user has all the details necessary to complete the transaction. These details include, for example, the card PAN, CVV, and card expiration date. Furthermore, the CVV is not only dynamic, but also linked to the login session, which makes the CVV non-existent when there is no session, thus eliminating brute force attacks.

As such, a user's base session can only be created based on two-factor authentication using an identity-enabled user: using the PIN (which they know) and the trusted device (which they own), the device is authenticated by additionally verifying the user's identity during the first session with the new untrusted device, in which trust is established for the user. Other verifications may be performed, such as: the current access to the primary phone number linked to the user is verified by sending the user a one-time password. Successful authentication results in linking the device to the user's trusted device, which is identified by a persistent device identifier that may be difficult to forge the hardware attributes of the device, or the server generates a unique fingerprint that is difficult to guess, which will be provided to the device upon authentication. Suitable trusted devices include smart phones or mobile computers, mobile devices, and other devices suitable for running client applications.

The present invention provides a method and system for generating a CVV, i.e., a security code, wherein the generated CVV is linked to a session and a card token. The CVV does not exist when the user is not logged into the session, and the card token or token is linked to the CVV when the user is logged into the session. The CVV is not directly linked to the card number or PAN.

the method and system of the invention require: 1) the user (e.g., indicated by their phone number). Must log on to the session to generate the CVV; 2) the system is logged in based on the trusted device (phone) and a secret PIN or other personal identity, e.g. a touch Identification (ID), e.g. a fingerprint known/owned by the user.

For example, if an imposter attempts to generate a CVV for a user, the imposter needs to be able to obtain the user's trusted phone (or know the unique secret device identifier that the server assigns to the user's trusted phone to emulate the user's phone) and then log in using the user's identifier (phone number) and the user's PIN. In addition, an impostor needs to access the user's SIM card and PIN to log on as on a new handset. Thus, the CVV is bound to a login, which is bound to a trusted device.

Referring to fig. 2A, an exemplary operating environment is shown including a network 50, a Home Server (HS)200 also linked to the network 50, the Home Server (HS)200 also referred to as a home server. The home server 200, alone or in combination with other computers, also defines a system including servers, components and applications, such as client applications, associated with the home server 200, as described below. The home server 200 and its system belong to or are associated with, for example, a card issuer/program manager that manages cards used for financial transactions, such as credit cards, debit cards, and other types of payment cards (collectively "cards"). The home server 200 comprises components forming a system (or part of a system) for issuing tokens corresponding to cards, issuing CVVs (security codes) and controlling the time of a session in which the CVVs are valid, linking the tokens to the CVVs and token matching, e.g. as mask data, to cards, databases and other storage media (for storing CVVs, tokens, card numbers) already issued by the issuer/program manager, and a processor for controlling the same. The home server 200 and system perform additional functions as described in detail below.

the network 50 is, for example, a communication network such as a Local Area Network (LAN) or a Wide Area Network (WAN), including a public network such as the internet. The network 50 may be a single network, a combination of networks and/or a plurality of networks, and may include (in addition to the communication networks described above, such as the internet), for example, a cellular network. As used herein, "link" includes a direct or indirect wired or wireless link and places computers, including servers, components, etc., in electronic and/or data communication with each other.

Other servers linked to the network 50 include, for example, an application server 202, a card issuer/processor server 206, a card provider server 208, a server representing a merchant 210, and a server 210 of a merchant acquirer 212. A merchant acquirer for processing a merchant's card transaction. A user (requester) 240 is linked to the network 50 through his cellular phone tower 244 through his trusted device, such as a smartphone 242. The user 240 also holds the card 20 of the present invention, an exemplary card operation of which is described in detail in 3A-3D below.

The application server 202 stores and makes accessible a plurality of devices, computers, etc. via the network 50, for example by downloading an Application (APP)203 of the present invention. When the Application (APP)203 is installed and running on a trusted device, such as the smartphone 242 of the user 240, it is mapped to the home server 200. The following is an operational discussion of an application 203 installed on a device such as a smartphone 242.

A server 206 (e.g., global processing server fzlc (gps) of debye academy) belonging to or associated with the card issuer processor is the entity that the issuer/manager processes the card transactions. The server 206 is linked to the network 50. The server 206 performs operations for receiving and processing various card data including CVVs and PANs, as well as other data, creating and augmenting tokens, and performs other operations as described in detail below. The server 206 also includes databases and other storage media, such as for cards and their PANs.

the server 208 belongs to or is associated with the card provider. An example of a card provider is the server 208, e.g. for a card provider associated with a BIN (bank identification number), e.g. associated with a BIN.

the server 210 represents a merchant's server, such as (Argos ltd, kaiens, milton, uk, www.argos.co.uk). The server 212 is the server of the merchant acquirer and processes card payment transactions for the merchant. The server 212 is, for example, a merchant acquirer WorldPay (payment processing service www.worldpay.com).

the user 240 has his trusted device 242, i.e. his smartphone and card 20. The card is shown in FIGS. 2B-1 and 2B-2. On the back side 22b there is no conventional CVV number, except for the PAN (including BIN) and the expiration date on the front side 20a of the card 20. Instead, the CVV is replaced by the word "APP" 25, or alternatively, the CVV is not present on the card 20. The card 20 is, for example, a payment card, and may be a credit or debit card.

reference will now be made to fig. 3A-3D, collectively referred to as fig. 3. A flowchart detailing a computer-implemented process according to an embodiment of the disclosed subject matter is shown. Reference is also made to the elements shown in fig. 2B-1 and 2B-2. The processes and sub-processes of fig. 3 are computerized processes performed by the system. The foregoing processes and sub-processes are, for example, performed automatically and in real time. However, these processes may be performed manually or may be used in conjunction with automated processes.

referring to fig. 3A-3D, and in the description of these figures below, the various participants associated with the transaction are indicated based on the server of fig. 2A and/or the server associated with the particular entity being represented. For example, the entity card issuer/program manager represented as and/or associated with the home server 200 is indicated as card issuer/program manager 200. Similarly, the physical card issuer processor represented by and/or associated with the server 206 is represented as a card issuer processor 206. The physical card provider represented by and/or associated with the server 208 is represented as a card provider 208. The physical merchant represented by and/or associated with server 210 is represented as merchant 210, and the physical merchant acquirer represented by and/or associated with server 212 is represented as merchant acquirer 212.

In fig. 3, the process described in detail before its start block 302, for example, by downloading an application 203 from an application server 202 over the network 50 and installing it on his trusted device, i.e. smartphone 242, by the user 240.

At the start block 302, upon issuance by the card issuer processor 206, tokens (also referred to as unique tokens, since each token is unique to a single issued card) are created and assigned to the card issuer/program manager 200. The process passes to block 304, where the card issuer/program manager 200 receives the following from a user 240 (also referred to as a requestor) (e.g., a trusted device associated with the requestor): 1) PIN (personal identification); 2) a login request, and 3) a CVV request from a device 242 (e.g., a trusted device) of the requestor 240.

The process flows to block 306 where if the user (requestor) 240 is attempting to log in from the trusted device 242 (based on the unique secret device identifier) and using the user/requestor identifier (e.g., PIN or otherwise) in block 306. A personal identification or other identifier, such as a touch ID (e.g., a fingerprint), that is known/available only to the user. For example, the trusted device 242 is from a list of trusted devices associated with each requestor. If the login is accepted, the requestor (user) and trusted device are validated (via the card issuer/program manager 200) and the requestor (user) is logged in. This is the identification of two factors, e.g. the trusted device is identified by a unique secret device identifier (first factor) and the supplicant (user) is identified by a username/supplicant identifier (e.g. PIN), second factor.

Likewise, if the first of the two factor identifier identifications of a trusted device represents that the requestor (user) is not currently a device of the trusted device (e.g., from a list of trusted devices associated with the requestor), a process of establishing trust in the new device to present the new device as a trusted device may be triggered. The process includes, for example, confirming current access to an identification method associated with an owner of a payment card, including a phone number associated with an account of the payment card.

for example, the user (requestor) 240 attempts to log in from the device 242 using their phone number (e.g., "+ 447624222721" and its PIN "3234"). A unique secret device identifier (e.g., a long string value "asddad 13145536363636363663" uniquely identifying the device 242) is automatically submitted to the card issuer/program manager 200 with the login request. The card issuer/program manager 200 checks whether "addr 131455363636363663" matches the user's currently valid trusted device identifier as represented by the telephone number "+ 447624222721". If the PIN is valid but the device 242 (represented by the unique secret device identifier "asddad 131455363636363663") is not trusted, a one-time password is sent, for example, by short message service, for example, by the card issuer/program manager 200, (SMS) to the telephone number +447624222721 of the user (requester) 240. Providing a one-time password results in the current device 242 (identified by the secret identifier "asddad 131455363636363663") being the trusted device for the user 240. If the device is a trusted device and the PIN is valid, the login is successful and a session is generated.

in the event that the user (requestor) login is verified and approved (authenticated), a user login session (for the authenticated user/requestor) is established (e.g., opened), which is in an open state for a period of time and effectively set up by the card issuer/program manager 200. The CVV is generated (e.g., as a security code) for any card owned by the user (including all cards owned by the user/requester) and for the duration of the session, identified by a linked or assigned token (unique token). The opening of the session and the generation of the security code are performed simultaneously in time and may be performed in any order or simultaneously. The session may be, for example, a fixed time, a random time within a time range. Furthermore, when a new session is opened (e.g. by a new login name), the session is closed, generating a new security code (CVV/CVC) for the same card (e.g. payment card).

The process proceeds to block 308 where a user selection of a card is provided from the card issuer/program manager 200 to the user in block 308 and received, for example, by the card issuer/program manager 200. In block 310, the generated CVV (as a security code) is transmitted to the user device 242 (e.g., from the server 200 to the client (device) 242) for each selected card(s). The user/requester's cards (including all of the user/requester's cards) and the masked card number (e.g., 5434-xxxx-xxxx-9456) and the card's expiration date.

At block 312, the user 240 purchases the card 20 from the item 210, such as the merchant 210, via the device 242. The purchase includes the user 240 sending to the transaction data, and the merchant 210 receiving the transaction data, which includes at least: card PAN, 2) CVV and 3) card expiration date. Proceeding to block 314, the merchant 210 sends transaction data to the merchant acquirer 212, where the transaction data includes, for example, the card PAN, 2) CVV and 3) the card expiration date, for example, a WorldPay secure payment processing program (WorldPay Group PLC, www.worldpay.com, London, UK) may process the card transaction for ARGOS with it.

The process proceeds to block 316 where merchant acquirer 212 analyzes the BIN (bank identification number) of the card PAN and identifies the card provider at block 316. Merchant acquirer 212 sends transaction data (e.g., card PAN, CVV, and card expiration date) to card vendor server 208 associated with the BIN, i.e., the process proceeds to block 318, where card provider 208 identifies the card BIN and sends the transaction data, e.g., card PAN, CVV, and card expiration date, to issuer processor 206 at block 318.

At block 320, the issuer processor 206 receives the card PAN, CVV, and card expiration date and checks the card PAN against its active card set (e.g., stored in a database or other storage medium including cloud storage). If the card PAN exists in the active card set, the issuance processor 208: 1) obtain a token representing the card, and 2) send the token and CVV to an authentication system, e.g., card issuer/program manager 200.

The process flows to block 322 where the card issuer/program manager 200 receives the token and CVV from the issuer processor 206.

Proceeding to block 324, the first of a series of checks (e.g., comparisons) is now performed by the card issuer/program manager 200. Here, it is determined whether a user (requestor) associated with the token is logged into the open session. If there is no open session ("no" at block 324), the process proceeds to block 330 where the transaction is not verified and not approved at block 330. From block 330, the process proceeds to block 332, where the information is sent to the merchant 210 rejecting the transaction, and the process ends at block 338.

If yes at block 324, the process passes to block 326 where a determination is made at block 326 as to whether the CVV provided (received) matches (is generated) the CVV of the token (i.e., the token/unique token assigned to the card/payment card), the session currently being in the active state. If no at block 326, the process passes to block 330, then to blocks 332 and 338, as described above. If yes at block 326, the process passes to block 328 and an additional check is made at block 328.

Additional checks of block 328 include, for example, one or more of balance availability, card limit checks, fraud rules, and the like. However, these additional checks are optional, such that block 328 need not be part of the process. If no other checks are passed, the process moves to block 330 and then to blocks 332 and 338, as described above. If all additional checks pass, the process passes to block 334 where the transaction is validated and approved.

From block 334, the process moves to block 336, where information for the accepted transaction is sent to the merchant 210 that completed the transaction in block 336. The process moves to block 338 where it ends.

The processes of blocks 324, 326 and 328 are shown in an exemplary order only. The processes of these blocks may be performed in any order, as these processes are performed, for example, concurrently in time, and may be performed concurrently.

Also, if block 328 is not performed, as is optional, if yes at block 326 (block 324 if the order of blocks 324 and 326 is reversed), the process will move to block 334 where the transaction is validated and approved (and then blocks 336 and 338 are reached as described above).

Implementation of the method and/or system of embodiments of the present invention may include performing or completing selected tasks manually, automatically, or a combination thereof. Furthermore, according to actual instrumentation and equipment of embodiments of the method and/or system of the present invention, several selected tasks could be implemented by hardware, software, firmware or a combination thereof using an operating system.

For example, hardware for performing selected tasks according to embodiments of the invention could be implemented as a chip or a circuit. As software, selected tasks according to embodiments of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In an exemplary embodiment of the invention, one or more tasks according to exemplary embodiments of the methods and/or systems described herein are performed by a data processor, such as a computing platform for executing a plurality of instructions. Optionally, the data processor comprises volatile memory and/or non-volatile memory for storing instructions and/or data, e.g. a non-volatile storage medium, such as a magnetic hard disk and/or removable medium and/or data, for storing instructions and/or data. Optionally, a network connection is also provided. A display and/or user input device, such as a keyboard or mouse, is also optionally provided.

For example, any combination of one or more non-transitory computer-readable (storage) media may be utilized in accordance with the above-listed embodiments of the present invention. The non-transitory computer-readable (storage) medium may be a computer-readable signal medium or a computer-readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any other suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

As will be understood from the reference paragraphs provided above and with reference to the accompanying drawings, various embodiments of computer-implemented methods are provided herein, some of which may be performed by various embodiments of the apparatus and systems described herein, and some of which may be performed. According to instructions stored in a non-transitory computer readable storage medium as described herein. Furthermore, it will be apparent to those skilled in the art that some embodiments of the computer-implemented methods provided herein may be performed by other devices or systems and according to instructions stored in computer-readable storage media different from those described herein. Reference is made to the embodiments described herein. Any reference to systems and computer-readable storage media for the following computer-implemented methods is provided for illustrative purposes and is not intended to limit any such systems and any such non-transitory computer-readable storage media in terms of: the above-described embodiments of a computer-implemented method. Likewise, any reference to the following computer-implemented methods with respect to systems and computer-readable storage media is provided for illustrative purposes and is not intended to limit any such computer-implemented methods disclosed herein.

The flowcharts and blocks in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The description of various embodiments of the present invention has been presented for purposes of illustration but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles of the embodiments, the practical application or technical improvements to the technology found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments should not be considered essential features of those embodiments unless the embodiment is inoperable without those elements.

The above-described processes including portions thereof may be performed by software, hardware, and combinations thereof. These processes, and portions thereof, may be performed by computers, computer-type devices, workstations, processors, microprocessors, other electronic search tools and memory, and other non-transitory storage type devices associated therewith. The apparatus and portions thereof may also be embodied in a programmable non-transitory storage medium such as a Compact Disc (CD) or other magnetic disk, including magnetic, optical, etc., readable by a machine or the like, or other computer usable storage medium including magnetic, optical, or semiconductor storage, or other source of electronic signals.

The processes (methods) and systems herein, including components thereof, have been described with exemplary reference to specific hardware and software. The processes (methods) have been described as exemplary, such that one of ordinary skill in the art may omit and/or alter certain steps and their order to reduce these embodiments to practice without undue experimentation. The processes (methods) and systems have been described in a manner sufficient to enable those of ordinary skill in the art to readily adapt other hardware and software that may be required to reduce any embodiment without undue experimentation and implementation using routine techniques.