Patent Application
20160148194
This application claims priority to U.S. patent application Ser. No. 13/830,341 filed on Mar. 14, 2013 titled “Dynamically Allocated Security Code System for Smart, Debit and Credit Cards” and is incorporated by reference.
1. Field of the Invention
This invention concerns the field of enhanced security features for smart, debit and credit cards as used in commerce. Specifically, a dynamically allocated security code is generated by the smart, debit or credit card which when analyzed by a payment processor or card issuing network approves or denies specific financial transaction from occurring thus reducing the risk of fraudulent activity with the card.
2. Related Art
Most of online fraud occurs due to thief of a valid debit or credit card Primary Account Number (“PAN”), expiration date and security code that are stolen from the card holder without their knowledge. Typically, this theft of card data is accomplished when a card holder visits a merchant and an unscrupulous merchant employee captures the card data for later resale while returning the actual card to the card holder. With cameras built into most of today's mobile phones, card information can easily be captured when the card holder passes the card to unscrupulous merchant employees. Once stolen, the card data information is often parked for a short period of time (e.g. several months) so that the card holder cannot determine the location where the card information was stolen. After a suitable period of time has elapsed, the data card information and codes can be used for e-commerce transaction and cardholder may never notice the fraudulent purchases unless close examination is made of the bank/credit card statement.
Another way that card data is stolen is from hackers who manage to penetrate the internal firewalls of merchants, thus stealing card data stored by the merchants. In both scenarios, the card holder is typically not aware that their card information was stolen and sold to a third party such as a criminal organization until fraudulent transactions start appearing on the card holder's monthly statements.
One way for banks and credit card processors to combat credit and debit card fraud is to use security codes. These security codes are known by a variety of types of acronyms. Credit cards typically employ a Card Verification Value (“CVV” or “CVV2”), also known as a Card Security Code (“CSC”), Card Verification Data (“CVD”), Card Verification Value Code (“CVVC”), Card Verification Code (“CVC” or “CVC2”), Verification Code (“V-code” or “V code”), Card Code Verification (“CCV”), or Signature Panel Code (“SPC”). These security codes using different terminology help implement enhanced security features for smart, debit and credit card transactions by providing increased protection for merchants against credit card fraud. While American Express places its security code on the front of the card, most smart, debit and credit cards place their security codes on the back of the card forcing thieves to copy this information as well as a further step to discourage and make it slightly more difficult for thieves to capture the smart, debit and credit card information.
The original purpose of implementing three or four digit security codes was to ensure that card holders had the card in hands when making purchases. With the advent of online shopping, an increasing number of merchants started to store the security codes on their servers to speed up the online transaction process as a way to enhance the shopping convenience of the customer. Unfortunately, capturing this information helps thieves when the merchant's card data is hacked by sophisticated hackers and the smart/debit/credit card information along with the stored security codes are stolen removing the necessity for the thief to have the smart, debit or credit card in their physical possession. Thus, the use of security codes as a way to reduce fraudulent transactions is thwarted by the merchants themselves in their attempt to make online purchases easier for the customer.
Additional limitations exist on the use of smart, debit and credit card security codes. The use of these security codes cannot protect against phishing scams where the card holder is tricked into entering the security code along with other card details via a fraudulent website. The growth in phishing is another reason why the use of security codes has reduced their real-world effectiveness as an anti-fraud device. For merchants who do not use security codes, their transactions are typically subjected to higher card processing costs and fraudulent transactions without security codes are more likely to be resolved in favor of the cardholder thus increasing the costs to the merchants.
Some smart, debit and/or credit cards may not have internal batteries and are powered by radio frequency energy (“RF energy”). Such cards operate using RF energy to power the card's internal microprocessor and related transmitter that transfers the card data such as the PAN, expiration date and cardholder's name to a wireless terminal. Certain disreputable people, years ago learned that they could use a portable or stationary wireless terminal and once near an unsuspecting card holder, could use a RF source to energize the smart, debit or credit card and extract the card data to a memory storage device. Later the stolen card data could be uploaded to a fake card or used in online transactions to commit fraudulent purchases.
Therefore, a need exists for smart, debit or credit card to restrict the transfer of sensitive card data when the card holder is not engaged in an authorized transaction. Also, a smart, debt or credit card could add additional functionality and security features by having a dynamically generating card security codes that periodically changes in order to stymie thieves from stealing the card information or rendering stolen data worthless in a short period of time after the theft of the card's security code data. A need also exists for a system a card issuer to support dynamically changing security codes so that financial transactions that take several weeks are not erroneously denied and identified as fraudulent because the card security code has changed during the time delay in processing the financial transaction for the card.
This invention provides an embedded light sensor in the card that controls whether the card can transmit card data when energized by an RF energy source. Certain smart, debit or credit cards energize internal component within the card when entering into certain RF energy fields. The use of a light sensor detects whether a predetermined light level exists. If the predetermined light level is reached, the card's logic assumes that the transaction is authorized and allows for transmission of the card's data to a card reader. If the predetermined light level is not reached, the card's logic assumes that the card is still in a purse or wallet and that the RF energy field is not related to card transactions or the RF energy field belongs to fraudulent parties who seek to capture the card's data in an unauthorized manner.
In a more sophisticated card, the absence of a sufficient amount of light detected by the light sensor may trigger an error message or otherwise provide a visual cue to the card holder indicating a problem with the light source. Upon receiving the error message or cue, the cardholder could input a PIN number into a keypad integrated into the card allowing for the transaction to because authorized and move forward.
Additional sophistication may support the dynamical generation of a security code for the smart, debit and credit cards as an enhanced methodology to thwart fraudulent use of these cards in financial transactions. The card internally may comprise additional components such as a processor connected to a viewable display powered by a battery where the processor is capable of generating security codes on a periodic basis. The card can generate the security code by encrypting certain data is a way that the card issuer as the same security codes so that when the security code is used in a financial transaction, the card issuer can ascertain whether the transaction is valid and authorized or potentially fraudulent.
An alternative embodiment for the dynamic generation of security codes, the card processor may call from a memory storage area on the card a security code from a list of encrypted security codes. The security code is then validated using the same methodology as a security code that was generated by firmware running on the processor.
Dynamically generated security codes typically have a life of a couple of weeks before the security code is changed. To prevent unwanted denials of transactions when the security code is changed, a time period window can be created on the card issuer's network that compares the card security code with the current valid security code stored on the card issuer's server as well as the previous security code in case the transaction was processed over a longer period of time than the life of the dynamically generated security code.
This may be accomplished by creating a mid-point sliding time window whose size is the length of the time allotted for the life of the security code. When the security code arrives at the card issuer's servers, the sliding window is created with the mid-point of the sliding time period window the date of arrival of the card's security code. The sliding time period window may encompass more than one time period representing the life of the card's security code. Therefore, the card issuer's network can analyze all the valid security codes to ascertain whether the correct card security code was assigned at the start of the financial transaction, but was delayed for some reason. This sliding time period window allows for the validation of these slowly processed financial transactions without unduly increasing the risk of fraudulent activity.
Other systems, methods, features, and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.
The components in the figures are not necessarily to scale, emphasis being placed instead upon illustrating the principles of the invention. In the figures, like reference numerals designate corresponding parts throughout the different views.
This invention provides a dynamic allocation of a security code for a smart card, debit card or credit card. In an effort to thwart smart, debit and credit card fraud, this invent provides for the generation of dynamically allocated card security codes calculated by various means. These dynamically allocated security codes may be generated by: (1) a random number that is encoded by encrypting the bank card number, also known as the Primary Account Number (“PAN”), expiration date and service code with encryption keys typically called Card Verification Keys (“CVK”) known only to the card issuing bank or smart card provider; (2) a list of encrypted numbers assigned to a specific card and stored in the card's memory; or (3) periodically wirelessly transmitted from a card issuer's network and stored in a memory area on the card.
In the most simplistic form, a smart, debit or credit card 100 may contain a magnetic stripe 102, a display 104 and a light sensor 106, as well as internal components integrated into a card such as a processor, receiver, transmitter, and antenna (not shown). Some smart, debit and/or credit cards are powered by radio frequency energy (“RF energy”) provided by a card reader (not shown). Such cards operate using RF energy to power the internal card processor and related transmitter that transfers the card data such as the account number, expiration date and PIN security code to the wireless card reader terminal. However, because certain disreputable people, years ago learned that they could use a portable or stationary wireless terminal and once near an unsuspecting card holder, could use a RF source to energize the smart, debit or credit card and extract the card data to a memory storage device. Later the stolen card data could be uploaded to a fake card or used in online transactions to commit fraudulent purchases.
Thus, a light sensor 106 can be used to control whether the smart, debit or credit card transmits the card data once energized by the card reader. If the light sensor 106 senses a predetermined level of illumination, the card will transmit the card data. If the light sensor 106 does not detect the predetermined level of illumination, it is assumed that the card is still in the card holder's wallet or purse and that the RF energy is from a non-authorized source. If the card is used in a low light area such as a restaurant or bar, an integrated button 108 may be pressed during the transaction so that the card data can be transmitted to the card reader.
Other security features on the card may include a signature stripe 110 or a hologram 112. For even more enhanced security features, the card may include the dynamic generation of a security code as a way to overcome the shortcomings of a static, printed security code on the front or back of a smart, debit or credit card 100. The card may dynamically generate a new and different security code periodically and is displayed on the card. On the outside, card 100 looks very similar to today's smart, debit and credit cards in that it has a PAN number, expiration date, name of an individual or company embossed on the front of the card. The card 100 may also have a logo of an issuing bank or organization backing the card.
For a smart, debit or credit card 100 to dynamically generate security codes, the display 104 may be incorporated into the card's structure. For optimum results, this display 104 may be flexible so that it will handle the stresses generated by card use. Typically, the display 104 may show three or four digits, but a card issuer may adopt a larger code display capable of showing more than four digits. A touch sensitive control button 108 may be incorporated into the card 100 so that whenever the touch sensitive control button 108 is selected the security code is shown on the display 104. If the card has an internal battery, use of the touch sensitive control button 108 would preserve battery life as the display could be off until the card holder needs to generate the security code. Also, the card may generate a new security code without any action taken on behalf of the card holder based on the passage of a predetermined amount of time (e.g. a week, two weeks, a month, etc.) set by the card issuer.
The interaction of a fully functional smart, debit, or credit card could support fast transactions such as those at a gas pump or grocery store that employs an RF card reader to speed transactions as well as for use in transactions where the risk of fraud is substantially higher. When the card receives RF energy from an RF card reader, the card could automatically recognize the environment and proceed with a fast transaction. Once again, use of the light sensor 318 could help prevent unauthorized transactions from occurring by restricting the transmission of card data if the light sensor 318 does not detect a predetermined level of illumination. If added security is needed because of the potential for fraud, the RF card reader could ask the card holder to manually input the card holder's zip code of the billing address.
With the added functionality of an internal battery 304, the card 300 would enable the full functionality of the card when in use at a tap and go transaction such as use at a gas pump where speed and smoothness of the transaction is a major selling feature while supporting the dynamic generation of security codes if added security functionality is needed is an online transaction. In such an embodiment, the battery could directly power the both the microprocessor and the light sensor (not shown) or directly power the microprocessor and indirectly power the light sensor as shown in
In non-wireless environments, the use of the touch sensitive control button 310 within the card 300 could indicate that the card holder desires a generation of a new security code. The card 300 would generate a new security code and show the security code in the card's display. The use of such a touch sensitive control button 310 would extend the battery life of the card 300 and would only energize or light up the display 308 specifically when the user seeks to use the card 300. The implementation of a key pad 312 could provide additional security requiring the card holder to insert a PIN on the key pad 312 before the security code is shown on the display 208. An additional security level could be added with the use of a key pad 312 by allowing the secure code algorithm to generate a correct security code when the correct PIN is input on the key pad 312 and the generation of an incorrect security code if an incorrect PIN is input on the key pad 312.
Another security enhancing feature could be the addition of a One Time Password (“OTP”) that would be delivered to the user via a text message sent to the card holder's mobile device for access to online banking. The OTP would not necessarily replace the user's password, but could be required as a third component (login name, password and security code). Since the card only has one display of typically 3 or 4 digits, the OTP could work whenever the user requires an OTP to be generated. When requested, a user would press on the touch sensitive control button 314 of the card 300 and a new OTP would be displayed on the display 308 for a limited time (e.g. 30 seconds or less). Once the OTP code was viewed for the predetermined time period, the security code would replace permanently the OTP on the display 308. Pressing the touch sensitive control button 310 a second time would generate another OTP and so on. Each OTP would be valid for a limited time or based on a counter.
Another embodiment may include the implementation of two distinct functions on the same card (e.g. distinct crypto keys for different functions). In the case of a two feature card such as the implementation of an OTP and a dynamically generated security code, two different crypto algorithms may be implemented or one algorithm for the OTP calculation and a list of security codes for the dynamically generated security code implemented with two separate crypto keys for each function. Therefore, it would be possible for a bank or card issuer to split the security responsibilities between two distinct departments such as online banking and payment processing.
As a way to ensure that a card holder does not mix up the OTP and dynamically generated security code, a solution could be implemented where the OTP utilizes a four digit code and the dynamically generated security code is shown with three digits. Every time a card holder pressed the touch sensitive control button 314, the card holder would see the four digits OTP displayed for predetermined amount of time, e.g. 30 seconds followed by the display the 3 digits dynamically generated security code.
The dynamic generation of security codes may be calculated or called from a list of security codes stored in the memory location 306 on the card 300. An alternative embodiment may allow for the transmission of a unique security code to a card holder's mobile device that is then input into the card via the key pad 312. These solutions present several implementation issues such as (1) how long the security code should be valid; (2) how the card will be authenticated by the card issuer or payment processor with the dynamically generated or recall of the security code from a list of codes stored in the card's memory; and (3) compliance with a variety of card use transaction scenarios such as online, mail order, multi suppliers' orders, fax processed orders, un-synchronized transactions and etc.
Typically, smart cards, debit cards and credit cards are manufactured by one vendor and sent to another vendor for imprinting the PAN number, card holder name and expiration date of the card. The uploading of the security codes maybe be accomplished by the card issuer or the vendor charged with imprinting the PAN number, card holder name and expiration date with a contact or contactless smart card chip or through the use of a built in RF antenna.
Use by the card manufacturer of the RF antenna as a methodology to increase the productivity of the card manufacturer generating the cards for the cardholder as a way to upload the initial storage on the card of the card information such as the PAN number, card holder name, expiration date of the card and in some instances the security code. In addition, the RF antenna embedded in the card may be used to download updated firmware for the internal card processor; to download updated algorithms for calculating the security codes; resynchronize the card with the card issuer's network or download an updated list of security codes sent by the card issuer's network into the memory, not just at the point in time that the card is manufactured or generated for the card holder but at any time including after the card is in the possession of the card holder.
Many card issuer networks are developing standards for the financial industry. EMV stands for the Europay, Master Card and Visa global standard for the interoperation of Integrated Circuit Cards (“IC Cards”) and IC Card point of sale terminals and Automated Teller Machines (“ATMs”) for authenticating smart, debit and credit card transactions. With the adoption of IC Cars in Europe and the planned roll out of IC Cards in the United States and other countries in the coming years, the dynamic generation of security codes may be easily implemented. When the card holder inserts their card into an IC Card point of sale terminal or inserts their IC Card into an ATM, the card with the dynamically generated security code could automatically generate a new security code after the IC Card completes the transaction. Such an implementation could produce a time and event combination where the card dynamically generates a new security code after a predetermined time period has elapsed and where the card dynamically generates a new security code after a specific event occurs such as when the IC Card is inserted into an IC Card point of sale terminal or ATM.
Protecting the security codes inside the card 400 is important for the overall card system security's interface with the transaction processing network as shown in
When a smart, debit or credit card 400 is used with a wireless card reader 402, the wireless card reader acts as a contact-less card reader. In some instances, marketing campaigns proclaim that the card holder taps their card on the card reader. However, what is important is for the card 400 to enter into a close proximity with the card reader 402 such that the RF energy produced by the card reader 402 provides power to the card such that an internal antenna embedded within the card 400 transmits the power to the microprocessor. The microprocessor powers up the RF transmitter which transmits the card's data to the card reader 402.
The RF energy generated by the card reader 402 may also power up an internal light sensor embedded in the card 400 so that when the light sensor detects a predetermined light level the card's microprocessor or RF transmitter is allowed to transmit the card's data to the card reader 402. If the light sensor does not detect any light or the light sensor detects an extremely low amount of light, then the card's microprocessor will determine that the receipt of RF energy was from an unauthorized source and restricts the wireless transmission of card data.
The inclusion of a touch sensitive control button on the card is a way for a card holder to override the blocked transmission of card data if the light sensor does not detect a sufficient amount of light. In such situations such as card use in a dark night club the intended use of the card may be authorized, but the light sensor blocks the wireless transmission of the card data as the card itself decides that the otherwise authorized transaction is an unauthorized transaction. In such scenarios, the card holder could press a touch sensitive control button on the card and the transmission of card data would occur.
The payment processor 404 then compares the card holder's card to a list of banned cards and if a match is not made the payment processor 404 passes the card data to the card networks such as Visa, Master Card, American Express, Discover, Europay Maestro, etc. 406 and 408. This card data is then routed to the appropriate network. For example, Visa cards are routed to the Visa network 406 and the Master Cards care routed to the Master Card network 408. Likewise, American Express cards and Europay cards are routed to their respective networks. These card networks 406 and 408 provide security code authorization, zip code authorization and debit and credit the banks. Please note smaller banks may push zip code authorization to the card networks or even the payment processor 404. These networks 406 and 408 perform the security code authorization points that are capable of authenticating the validity of the security code as well as interface with various banks 410 to ensure the seamless flow of money and goods when card holders seek to complete transactions.
The same system applies to the implementation of dynamically generated security codes. The bank may issue a card to a customer where the bank sends card holder information to a card issuer who generates a working smart, debit or credit card to the bank's customer. The security code information may be based on information supplied by the payment processor 404 or the card issuer. The security code validation data is supplied to the payment processor 404 so that transactions can be verified and authenticated by the payment processor 404 or the card issuer's network 406 and 408.
When the card enters a RF field generated by a card reader 500, the internal card microprocessor is powered up and the internal card light sensor is powered up and activated 502. If the light sensor detects a predetermined light level 504, then the internal card processor recalls from memory the card data and transmits the card data to the card reader 508. In one embodiment, the processor recalls from memory the security code or alternatively generates a new security code that is transmitted to a card reader. Once the card data is received by the card reader 510, the card reader transmits the card data on a network to the payment processor 512. The payment processor then authorizes the transaction with the card issuer by validating the card data and the security code 514.
In this embodiment, if the card is used in low light conditions, the card holder may be attempting to conduct a valid transaction yet when the light sensor fails to detect the predetermined light level the card intentionally withholds the transmission of card data. In this embodiment, when the light sensor fails to detect the predetermined amount of light 604, the card can initiate a visual signal on the card. If the card is in a card holder's wallet or purse, the card's visual signal will not be observed and the card stays in a standby mode thus preventing a potential unauthorized transaction.
However, if the card's light sensor fails to detect an appropriate light level, then the card can display a visual signal such turning on an LED light or a visual code can be shown in the display. Upon receiving the visual cue, the card holder or merchant can engage a manual override 608 comprising of pressing a touch sensitive button or entering a PIN number or code so that the card's internal processor recognizes that an authorized transaction is being attempted. If the card was manually activated 610, the card would enable the transmission of card data to the RF card reader 606. If the card was not manually activated 610, then the card's logic would conclude that the transaction was unauthorized and display an error message or service denied message 612. The amount of light level that is needed to engage the transmission of card data is up to the card manufacturer. Many manufacturers may want to set this predetermined level very low, assuming that if the card is in a wallet or purse there will be virtually no light hitting the light sensor. Yet the card could still function in an area of low light such as at a restaurant or night club.
Another alternative embodiment may be the implementation of an event based solution where a light sensor is employed in the RF powered card and the card is capable of dynamically generating new security codes periodically. This periodic generation of new security codes could be accomplished by algorithms or the new security codes could be pre-loaded on the card at the time of issuance and logic within the card recalls the next security code on a list stored in the card's memory and an internal counter within the card is advanced to the next security code in the list. In such an event based implementation, the new security code may be calculated or recalled from a list stored in memory.
In some circumstances, each time the user seeks to use the card, the card holder will press the touch sensitive control button 310 located on the card. When pressed, the card can dynamically generate a security code. This security code will be valid for a predetermined amount of time, e.g. a couple of days or even several weeks. This would enable the cardholder to use the security code in transactions that may take some time to process such as transactions conducted by mail or fax.
In other circumstances, when the user seeks to use the card, the card holder will press the touch sensitive control button 310 and the card will generate a first security code 402. A built in counter within the card increments will increase the value of the counter by one 404 each time the touch sensitive control button 310 is pressed. When the card holder presses the touch sensitive control button a second time a new security code is generated and displayed on the card. The second security code may be used in the next transaction. The card processor then compares the transmitted security code with the security codes stored in their authorization system. If the security codes match, the transaction is authorized and approved. The card processor's authorization system then increments its counter and waits for the next transaction. If the security codes do not match, the transaction is rejected. In an alternative embodiment, the pressing of the touch sensitive control button 310 will generate the same security code over a predetermined time period, e.g. several days or several weeks.
A problem occurs however when a card holder keeps pressing on the touch sensitive control button or when the card activates by itself based on pressures exerted on a wallet and multiple codes are generated without being submitted as a part of a transaction to the payment processor. Under such conditions, whenever a legitimate transaction is attempted by the card holder a de-synchronization issue will arise between the counter inside the card and the counter located on the backend processing side at the payment processor if there is a one-to-one correlation between the security code generated by the counter in the card and the counter used to pull valid security codes from a list located at the card processor or card issuer.
This issue may be counteracted by allowing the card processor or card insurer to validate any security code that is submitted for that particular card. As an alternative, the card processor or card issuer may create a large window of possibly valid security codes submitted by the card. For example, when a security code is submitted for a valid transaction by a cardholder, the card processor or card issuer may create a window that will validate any of the next 50, 100 or even 200 security code entries on the list of valid security codes associated with that card. Assuming this window is 100 values, if the first security code submitted was valid, and the window was 100 values, if the next security code submitted by the card holder was the 89th entry on the security code list, then the transaction would be authorized by the card processor or card issuer. If the next security code submitted was the 105th entry on the security code list, the transaction would be denied and the cardholder instructed to call into the customer service department so that the security card list could be re-synchronized. If the window selected is too large, the probability that a person engaged in fraud may guess a valid security code may rend the security features meaningless. Also, if a card were to fall into the hands of a child, repeated pressing of the touch sensitive control button could quickly cause the counter to become de-synchronized. In these scenarios, the card holder's frustration is likely to rise and the card issuers cost rise as cards become frequently replaced well before their intended expiration or the card holder has to be resynchronized by the card holder on a frequent basis.
The card processor or card issue's logic in the card authorization network would determine if the security code received from the card matches the security code in the payment processor's or card issuer's authorization system 718. If the security codes match, the transaction is authorized and the system approves the security code 720. If the security code sent by the card was pulled from a stored list of security codes, a counter logic within the card and card processing network would increment by one value 722. If the security codes do not match, the transaction is rejected 724.
A complication that arises in the implementation of a dynamically generated security code is how long the security code should remain valid. If the security code window of validity is limited to several minutes, online and mail order phone transactions have a high probability of success while faxed transactions or transactions accomplished by mail will nearly always fail. Thus, there needs to be a balance between decreasing the potential for fraud activity and optimizing the types of transactions so that the overwhelming majority of card holder transactions are approved. This time window is best optimized for a validity window of one to two weeks. The determination of the optimum time window is typically selected by the card issuer based on their statistical data for card usage and the level of fraud activity.
A time based methodology for the generation of security codes typically requires the card to have an internal clock or wireless access to a time keeping system so that the generation of security codes are synchronized with the card issuer or payment processor. As an alternative, the card could connect to the payment processor or a third party who maintains a clock for synchronization timing solutions. With a sufficiently long period of time window to deal with transactions that require a longer period of time, e.g. faxed or mail transactions, one security code could be used for multiple transactions that may occur during this time period window.
For the time window, a solution is to have a card capable of generating a new security code that is valid during a periodic time window that is sufficiently large enough to overcome delays that may exist in transactions that require more time, e.g. fax and mail transactions. A typical time window could be as short as one week or as long as one month. In other words, a specific security code will be valid for a fixed period of time and the same security code will be displayed on the card. When the time window expires the card will dynamically generate a new code or recall from memory the next security code from a list of security codes stored on the card. As an alternative embodiment for storing a list of security codes on the card, this list may be stored in the cloud on the card issuer's servers or card processor's servers and called by wireless commands automatically sent from the card to these servers without the card holder knowing that these communication messages are being sent and received by the card. However, a major limitation for such a wireless interface with the cloud is for card holders who may be attempting to conduct a transaction in a remote location where wireless connections are not possible thus when it is time for the card holder to conduct a transaction, no current security code is stored on the card.
In
The security code 111 (810) is generated by the card and sent to the payment processor's authorization system 816. In some instances, the authorization system may reside with the card issuer. In either event, the card issuer or payment processor card authorization system 816 compares the card's security code 111 (810) to the security code authorized by the card issuer or payment processor's computer systems 816. If the card's security code 111 (810) corresponding to Period 1 (804) matches the card issuer or payment processor's security authorization system 816 security code 111 (820) for Period 1, then the transaction is authenticated and payment is made. Otherwise, payment authorization is declined.
In order to prevent valid codes from being rejected by the card issuer or the payment processor authorization system 816, when a transaction is attempted by a card holder that is close to or just past the time period window for the security code's validity, the card issuer or payment processor authorization system 816 may consider the security code 111 (810) entered by the card holder was sent during the middle of the sliding time period window 818.
The sliding time period window 818 may allow the authorization of multiple values 111 (820) and 222 (822) allowing for various types of transactions by the card holder ranging from fast e-commerce transaction to transactions taking days or a couple of weeks such as those conducted by mail. For example, if a time period window is considered valid for fifteen (15) days and a security code is submitted on the fourteenth (14th) day, the card issuer or payment processor authorization system 816 may match the submitted security code 111 (810) against a first security code 111 (820) that is seven (7) days old and second security code 222 (822) that is seven (7) days in the future. Therefore, this security code matching methodology allows time period window flexibility for slower transactions such as those attempted by fax or mail without increasing otherwise valid transactions from being declined.
A likely scenario is that the time periods between the dynamic generation of security codes will vary between differing card issuer networks. Also, the sliding time period window will also likely differ between the various card issuer networks.
While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible that are within the scope of this invention.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13830341 | Mar 2013 | US |
| Child | 15004940 | US |
