Patent Application
20190005498
Presently, when a purchase is made by a consumer, it is common for the retailer to retain a copy of the account number for later returns, customer rewards, etc. However, a data breach of the retailer's computer can result in the stored account numbers being obtained and then exploited for unauthorized purposes.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate various embodiments and, together with the Description of Embodiments, serve to explain principles discussed below. The drawings referred to in this brief description should not be understood as being drawn to scale unless specifically noted.
Reference will now be made in detail to embodiments of the subject matter, examples of which are illustrated in the accompanying drawings. While the subject matter discussed herein will be described in conjunction with various embodiments, it will be understood that they are not intended to limit the subject matter to these embodiments. On the contrary, the presented embodiments are intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the various embodiments as defined by the appended claims. Furthermore, in the Description of Embodiments, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present subject matter. However, embodiments may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the described embodiments.
Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present Description of Embodiments, discussions utilizing terms such as “selecting”, “outputting”, “inputting”, “providing”, “receiving”, “utilizing”, “obtaining”, “updating”, “accessing”, “changing”, “correlating”, “prescreening”, “developing”, “presenting” or the like, often refer to the actions and processes of an electronic computing device/system, such as a desktop computer, notebook computer, tablet, mobile phone, and electronic personal display, among others. The electronic computing device/system manipulates and transforms data represented as physical (electronic) quantities within the circuits, electronic registers, memories, logic, and/or components and the like of the electronic computing device/system into other data similarly represented as physical quantities within the electronic computing device/system or other electronic computing devices/systems.
A system and method of protecting a consumer's private label card number at a retailer database is discussed herein. In general, when a credit purchase is processed the retailer will contact the private label credit account company or its agent (hereinafter private label credit account provider) for authorization to accept the purchase. In one embodiment, the private label credit account provider will generate an authorization token which is similar to a bank identification number (BIN), issuer identification number (T N), or the like, but will not include the private label credit account number.
In so doing, the private label credit account number will be protected from theft or loss at the retail database. In other words, a data breach (or hack) of the merchant environment will not result in the actual credit account information being stolen.
A brand specific credit account refers to a credit account that is available for use only at locations related to the brand. E.g., Tim's store has a brand specific credit account that allows Celeste, a Tim's store customer, to purchase with credit at Tim's store using Tim's brand specific credit account. However, Celeste cannot use the Tim's brand specific credit account to make purchases at her local gas station. A brand specific credit account may also be referred to as a private label card, e.g., a card that can be used for purchases only at the store on the label.
A co-branded card refers to a card that has a store on the label as well as an underlying credit card network with an accompanying logo (e.g., Visa™, Mastercard™, etc.). As such, a co-branded card may be used for purchases at the store on the label as well as at other stores that accept that credit card network's credit cards.
Importantly, the embodiments of the present invention, as will be described below, provide an approach for private label card number protection in the retail environment which differs significantly from the conventional processes. In conventional approaches, when a purchase is authorized the account number is stored at the retail database. Here, the present embodiments, as will be described and explained below in detail, provide a previously unknown procedure to identify the transaction throughout the purchase life cycle, e.g., from authorization, through settlement all the way to billing using a token. Moreover, the present embodiments allow the private label credit account provider and/or retailer to maintain a running tally of purchase information for a specific credit account by linking the tokens to the credit account at the credit provider database. Thus, embodiments of the present invention provide an approach for tracking authorized purchases and customer earned rewards and offers which extends well beyond what was previously done by hand.
As will be described in detail, the various embodiments of the present invention do not merely implement conventional monitoring of processes on a computer. Instead, the various embodiments of the present invention, in part, provide a previously unknown procedure to protect the credit account number throughout the purchase life cycle, e.g., from authorization, and purchase all the way to returns, refunds, warranties, and rewards earnings. Moreover, the present embodiments provide real-time security for the private label credit account provider and/or retailer in the case of a retailer data breach. Hence, embodiments of the present invention provide a novel process for tracking authorized purchases which is necessarily rooted in computer technology to overcome a problem specifically arising in the realm of retailer data breach.
Moreover, the embodiments do not recite a mathematical algorithm; nor do they recite a fundamental economic or longstanding commercial practice. Instead, they address a business challenge of accurately and timely authorizing purchases for the private label credit account provider and retailer while maintaining credit account number security and ensuring customer loyalty, rewards and purchases are linked and trackable. Thus, the embodiments do not merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet. Instead, the embodiments are necessarily rooted in retail technology in order to overcome a problem specifically arising in the realm of a data breach (or hack) of the merchant environment.
Referring now to
In one embodiment, private label credit account number 105 is provided to the retail computing system 110 by a customer in a retail environment planning on making a purchase with a credit account. For example, private label credit account number 105 may be provided by a customer at the time of purchase. In general, private label credit account number 105 is provided via a card swipe, a mobile device payment method at a point of sale (POS), via e-commerce (such as an Internet purchase, etc.), and the like. In general, a mobile device refers to a user's personal device, such as but not limited to a mobile phone, smart jewelry, cell phone, tablet, notebook, or other electronic device with wired or wireless internet connectivity capable of performing one or more steps in a mobile payment process. In general, the mobile device will perform the mobile purchasing process or will have an application operating thereon that will perform the mobile purchasing process.
In one embodiment, retail computing system 110 includes a retail sales device such as a cash register at the POS, an employee held tablet, or the like with wired or wireless internet connectivity. Retail computing system 110 also includes a retailer database 118 which is used to store customer purchase information, rewards information, and the like.
In one embodiment, retail computing system 110 will provide identifying aspects 119 about the purchase to private label credit account provider 130. The identifying aspects 119 will include, but is not limited to, a request for authorization and the private label credit account number 105.
In one embodiment, identifying aspects 119 will also include details about the goods purchased. For example, in one embodiment, identifying aspects 119 will include information about the purchase such as, type of payment (e.g., mobile), client identifier (e.g., mobile device identifier, account number, SSN, or the like), Store identifier (e.g., Store #, register #, clerk name/number, etc.), purchase amount, description of the goods purchased (e.g., manufacturer, make, model, color, size, etc.) and other aspects. In general, the different identifying aspects that are provided may be pre-set, retailer configurable, private label account provider configurable, or a combination thereof.
Retail computing system 110 will communicate with private label credit account provider 130 via dedicated communication connection 121 between retail computing system 110 and private label credit account provider 130. In one embodiment, dedicated communication connection 121 is a closed loop connection. In one embodiment, dedicated communication connection 121 is the communication connection used for all communication between retail computing system 110 and private label credit account provider 130.
Private label credit account provider 130 is the agent of the private credit account being used and provides authorization for payment to retail computing system 110 before the purchase can be completed at retail computing system 110.
In one embodiment, private label credit account provider 130 will receive the purchase request including identifying aspects 119 at request receiver 132. Request receiver 132 will pass the request to token generator 135 which will generate authorization token 133.
In one embodiment, token generator 135 includes token rules engine 136. Although token rules engine 136 is shown as distinct from token generator 135, it should be appreciated that the token rules engine 136 may be a part of token generator 135. For example, token rules engine 136 may be a remote system or database that is accessed by token generator 135 similar to that of account database 138.
Token generator 135 will include, in one embodiment, a token scope. The token scope allows for limiting the use of the authorization token. For example, the authorization token with a broad scope would be available for use on any number of channels, devices and the like. In contrast, a limited scope would restrict the token usage to specific channels, devices or the like. In general, channels refer to web, mobile, etc.; and devices refers to phones, computers, watches, smart jewelry, etc. Allowing different limitations to be integrated as part of the token scope, will further limit the use of the authorization token to help prevent fraud. For example, if a token has a scope that limits it use to a mobile channel and a smart watch device the token would be narrow in scope.
Token rules engine 136 is used to ensure that the scope of the token being generated matches the scope defined by the authorization request. For example, if the authorization request is for a token with a narrow scope that authorizes a mobile purchase over near field communication (NFC), then the token scope of the authorization token 133 should identify mobile device and NFC when it is checked by token rules engine 136. In one embodiment, if the scope does not match, the request will be declined. Similarly, if the authorization request is for a token with a broad scope, the token rules engine 136 will check the generated authorization token 133 to ensure that the scope is not unduly narrowed. In yet another embodiment, if the authorization request is for a token with a broad scope, the token rules engine 136 will check the generated authorization token 133 to ensure that the scope is not unduly broad. For example, the token rules engine 136 may have a number of different rules provided for fraud prevention that are applied even to authorization tokens that are broad based on the authorization request. In one embodiment, the rules used by token rules engine 136 can be different per client, per customer, per purchase amount, and the like.
In addition, token generator 135 will link authorization token 133 with the private label credit account associated with private label credit account number 105 at the account database 138. Moreover, any number of authorization tokens 133 may be linked with a single private label credit account on the database 138.
Because the authorization token(s) 133 are linked with the underlying private label credit account, the private label credit account provider 130 will be able to tally a plurality of metrics for every authorization token 133 linked with the private label credit account and utilize the tally to calculate different metrics. For example, the metrics may include, rewards information for the private label credit account, customer loyalty, spending trends, offers, incentives, coupons, and the like. By maintaining the tallies for the different authorization token(s) 133 associated with the underlying private label credit account, the private label credit account provider 130 can ensure that the customer receives all earned rewards, benefits, etc.
Token generator 135 will provide authorization token 133 to authorization token provider 137 which will transmit authorization token 133 to retail computing system 110 via dedicated communication connection 121.
For example, during a transaction, the customer provides the private label account number to the retailer, the transaction is transmitted directly to the private label credit account provider (e.g., Alliance Data) over the dedicated connection. When the private label credit account provider approves the sale, instead of returning the account number and the approval code to the retailer, an authorization token is provided instead. The token resembles the credit card structure so that it is usable, but does not include the credit account number. The retailer will then stores the authorization token 133 in their system, in place of the credit account number, for purposes of returns, loyalty rewards, etc.
Thus, the authorization token 133 is provided by private label credit account provider 130 at the time of the sale and replaces private label credit account number 105 when the purchase information is stored at retailer database 118. Moreover, authorization token 133 seamlessly replaces private label credit account number 105 without need to modify or upgrade retail computing system 110.
In one embodiment, in addition to being a replacement for the private label credit account number 105 to be stored at retail database 118, authorization token 133 will include some or all of the information about the purchase such as, a client identifier (e.g., mobile device identifier, account number, SSN, or the like), a store identifier (e.g., Store #, register #, clerk name/number, etc.), a purchase amount, a description of the goods purchased (e.g., manufacturer, make, model, color, size, etc.) and other aspects. In general, the different identifying aspects 119 may be preset, user configurable or a combination thereof. An example of the authorization token 133 is described in more detail in the discussion of
With reference now to
A physical in-store interaction at the POS can include actions such as, a physical card swipe, a physical card chip read, a scan of a display screen of a customer's mobile device, a wireless transmission of the private label credit account number from the customer's mobile device (e.g., Bluetooth transmission, near field communication (NFC), etc.), a bar code displayed on the mobile device, a UPC displayed on the mobile device, a screen shot, or the like, that can be presented by the application on the purchaser's mobile device to the retail computing system 110, visually, electronically, communicatively, or the like.
An account lookup interaction allows a customer to use the private label credit account to make a purchase when the customer is not physically able to provide the private label credit account number to the retail computing system. For example, the customer may have forgotten their credit card, mobile device for mobile payment, etc. The retailer is able to look up the customer by a customer identifier (e.g., name, address, DL number, etc.) and then allow the customer to provide some type of authorization to the private label account. For example, the customer is able to provide a log-in and password to sign in at the POS, the customer can provide a driver's license or license number that would match the number on the account, etc. Once the customer is verified, the customer is able to use the private label credit account to make a purchase at the POS.
An account acquisition interaction refers to the scenario such as when a customer applies for a credit card at the store, e.g., completes an application at the POS, when the customer is approved they can perform a purchase on that day. When this type of purchase is made, the account provider returns the authorization token 133 to the retailer, the authorization token 133 including an identifier that it was a token from an account acquisition interaction.
Referring now to 220 of
With reference now to 230 of
With reference now to 240 of
Thus, the technology allows the credit account number to be replaced with the authorization token 133, at the retailer, without a need for modifying or upgrading the POS retail computing system 110, a retailer database, a retailer system, or the like. In other words, the entire purchase process remains the same for retail computing system 110 and for customer except that the authorization token 133 replaces the private label credit account number at the retailer database.
Referring now to
In
For example, in one embodiment grouping 310 is the authorization to perform a credit account transaction. In one embodiment, grouping 310 may indicate date and time or other functional aspects. In one embodiment, grouping 315 includes information about the store identifier (e.g., Store #, register #, clerk name/number, etc.). Grouping 320 includes information about the purchase amount, coupons used, discounts received, offers utilized, description of the goods purchased (e.g., manufacturer, make, model, color, size, etc.) and other aspects.
Grouping 325 includes information about the purchase such as, a physical in-store interaction at a point of sale (POS), an e-commerce interaction, an account lookup interaction, an account acquisition interaction, and the like.
By including the transaction type as a portion of the authorization token 133 a level of security is established. For example, if there is a data breach at the retailer and a number of authorization tokens 133 are stolen, the transaction type portion of the authorization token 133 will deter fraudulent future use of the authorization token 133.
As such, if a token number is presented in an area that it was not initially mapped to, the authorization rules will recognize the token number as invalid and the transaction will be declined. For example, a customer makes a physical instore purchase (e.g., swipes a card), the authorization token 133 that is provided by the account provider will include information to indicate that the authorization token 133 is related to an instore purchase (and not an e-commerce, account look-up, or acquisition purchase).
So, if the retailer database is hacked and the (card swipe) authorization token 133 is stolen, when an attempt is made to use the authorization token 133 in a different manner, (e.g., an e-commerce, account look-up, or acquisition purchase), the credit provider would decline the use as fraudulent as the authorization token 133 was related to a physical swipe purchase.
In another example, if someone hacks a database and obtains the cache of authorization token 133 numbers from the retailer database, and the hacker attempts to make a counterfeit plastic card using the authorization token 133 number, the account provider will know that the authorization token 133 should not be part of mag stripe data on a physical piece of plastic. As such, the account provider will decline the fraudulent purchase because, the actual card would have the account number not the authorization token 133 number.
Similarly, if authorization token 133 is trying to be fraudulently used in the same channel, e.g., an authorization token 133 generated from an e-commerce transaction being used on a fraudulent second e-commerce purchase, the consumer would, in one embodiment, have to provide log-in credentials for authentication since it is not the actual account number, but instead the authorization token 133 that is attempting to be used for the purchase.
Thus, the technology allows a private label credit account to provide more payment security, and consumer confidence (that their account information is being protected), e.g., by replacing the card numbers with tokens that are relevant to each different transaction type, use case, and management life-cycle events.
Although one example of the groupings is discussed herein, it should be appreciated that different identifying aspects may be preset, user configurable, or a combination thereof. Moreover, the size of the groupings for authorization token 133 may be configured differently based on the amount of data needed for a given grouping.
Thus, in one embodiment, when the private label credit account provider 130 provides the authorization token 133 that authorizes the purchase at the retail computing system 110, the authorization token 133 will be stored at the retailer instead of the private label credit account number. Additionally, the retailer will link, at a database of the retail computing system, any details of the purchase, such as the goods purchased, with the stored authorization token 133. In so doing, the retail computing system will be able to utilize the authorization token 133 to perform a customer return, refund, or the like.
In one embodiment, the credit account provider links the authorization token 133 with the private label credit account on a credit account provider database 138. Moreover, any number of authorization tokens 133 may be linked with a single private label credit account on the database 138. Since the authorization token(s) 133 are linked with the underlying private label credit account, the private label credit account provider 130 will be able to tally a plurality of metrics for every authorization token linked with the private label credit account and utilize the tally to calculate different metrics. For example, the metrics may include, rewards information for the private label credit account, customer loyalty, spending trends, offers, incentives, coupons, and the like. By maintaining the tallies for the different authorization token(s) 133 associated with the underlying private label credit account, the private label credit account provider 130 can ensure that the customer receives all earned rewards, benefits, etc.
Moreover, the authorization token will be able to be used by the credit account provider to identify the transaction throughout the purchase life cycle, e.g., from authorization, through settlement all the way to billing.
In one embodiment, in addition to linking the authorization token(s) 133 to the private label credit account, in the field of lifecycle management another account can be linked to the prior account and any authorization tokens associated therewith. For example, if a customer needs a replacement card, the replacement card account number can be mapped to the old account number. Thus, the customer's previously earned rewards, and the like will be linked to the new account without requiring significant data transfer, database duplication, and the like.
With reference now to
Computer system 400 of
System 400 also includes computer usable non-volatile memory 410, e.g., read only memory (ROM), coupled to bus 404 for storing static information and instructions for processors 406A, 406B, and 406C. Also present in system 400 is a data storage unit 412 (e.g., a magnetic disk drive, optical disk drive, solid state drive (SSD), and the like) coupled to bus 404 for storing information and instructions. Computer system 400 also includes an optional alpha-numeric input device 414 including alphanumeric and function keys coupled to bus 404 for communicating information and command selections to processor 406A or processors 406A, 406B, and 406C. Computer system 400 also includes an optional cursor control device 416 coupled to bus 404 for communicating user input information and command selections to processor 406A or processors 406A, 406B, and 406C. Optional cursor control device may be a touch sensor, gesture recognition device, and the like. Computer system 400 of the present embodiment also includes an optional display device 418 coupled to bus 404 for displaying information.
Referring still to
Computer system 400 also includes an I/O device 420 for coupling system 400 with external entities. For example, in one embodiment, I/O device 420 is a modem for enabling wired or wireless communications between system 400 and an external network such as, but not limited to, the Internet or intranet. A more detailed discussion of the present technology is found below.
Referring still to
System 400 also includes one or more signal generating and receiving device(s) 430 coupled with bus 404 for enabling system 400 to interface with other electronic devices and computer systems. Signal generating and receiving device(s) 430 of the present embodiment may include wired serial adaptors, modems, and network adaptors, wireless modems, and wireless network adaptors, and other such communication technology. The signal generating and receiving device(s) 430 may work in conjunction with one or more communication interface(s) 432 for coupling information to and/or from system 400. Communication interface 432 may include a serial port, parallel port, Universal Serial Bus (USB), Ethernet port, Bluetooth, thunderbolt, near field communications port, WiFi, Cellular modem, or other input/output interface. Communication interface 432 may physically, electrically, optically, or wirelessly (e.g., via radio frequency) couple system 400 with another device, such as a mobile telephone, radio, or computer system.
The computing system 400 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present technology. Neither should the computing environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computing system 400.
The present technology may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer-storage media including memory-storage devices.
The foregoing Description of Embodiments is not intended to be exhaustive or to limit the embodiments to the precise form described. Instead, example embodiments in this Description of Embodiments have been presented in order to enable persons of skill in the art to make and use embodiments of the described subject matter. Moreover, various embodiments have been described in various combinations. However, any two or more embodiments may be combined. Although some embodiments have been described in a language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed by way of illustration and as example forms of implementing the claims and their equivalents.
This application claims priority to and benefit of co-pending U.S. Provisional Patent Application No. 62/526,936 Filed on Jun. 29, 2017, entitled “PRIVATE LABEL ACCOUNT NUMBER PROTECTION” by Arthur Roca, and assigned to the assignee of the present application, the disclosure of which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62526936 | Jun 2017 | US |
