US20170076281A1 - Devices, systems, and methods for tokenizing sensitive information - Google Patents
Devices, systems, and methods for tokenizing sensitive information Download PDFInfo
- Publication number
- US20170076281A1 US20170076281A1 US15/362,188 US201615362188A US2017076281A1 US 20170076281 A1 US20170076281 A1 US 20170076281A1 US 201615362188 A US201615362188 A US 201615362188A US 2017076281 A1 US2017076281 A1 US 2017076281A1
- Authority
- US
- United States
- Prior art keywords
- token
- sensitive information
- credit card
- tap device
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2149—Restricted operating environment
Definitions
- the present invention relates generally to the tokenization of sensitive information, and more particularly, but not by way of limitation, to devices, systems and methods for tokenizing sensitive information.
- Exemplary embodiments may include methods for tokenizing sensitive data by: (a) receiving sensitive information via an input device, the input device being communicatively coupled to a transaction terminal; (b) tokenizing the sensitive information at the input device to generate a token; and (c) associating the token and the sensitive information together in a storage medium associated with the input device.
- Additional exemplary embodiments may include methods for tokenizing sensitive data that include: (a) receiving a token from a tap device disposed between a sensitive information source and a transaction terminal, the token including sensitive information that has been tokenized by the tap device, the tap device being operatively connected to the sensitive information source; and (b) associating the token and the sensitive information together in a storage medium associated with the tap device.
- systems for tokenizing sensitive information may include: (a) a tap device configured to be disposed between a sensitive information source and a transaction terminal, the tap device including a tokenization module configured to receive sensitive information from the sensitive information source and generate a token from the sensitive information source; and (b) a provider system communicatively coupled to the tap device that receives the sensitive information and the token from the tap device and associates the sensitive information and the token together in a storage medium.
- the present technology may be directed to tap devices for tokenizing sensitive information.
- the tap devices may include (a) a communications module that receives sensitive information from a credit card reader; (b) a tokenizing module that tokenizes sensitive information received from the credit card reader to produce a token; and (c) wherein the tap device is configured to reside inline between the credit card reader and a point of sale terminal, at a retail location.
- FIG. 1 illustrates an exemplary system for practicing aspects of the present technology.
- FIG. 2 illustrates a schematic diagram of a tokenizing application.
- FIG. 3 illustrates an additional exemplary system for practicing aspects of the present technology.
- FIG. 4A illustrates a flow chart of an exemplary method of facilitating financial transactions utilizing tokens created from credit card data.
- FIG. 4B illustrates a flow chart of an exemplary method of processing credit card transactions utilizing tokens created from credit card data.
- FIG. 4C illustrates a flow chart of another exemplary method of processing credit transactions utilizing tokens created from credit card data.
- FIG. 5 is a block diagram of an exemplary computing system that may be utilized to practice aspects of the present disclosure.
- PCI payment card industry
- PCI governing bodies require that entities must enact systems or processes that protect credit card data from intentional and/or unintentional exposure to third parties.
- these commonly utilized systems and processes may require expensive hardware and software solutions, along with complex privacy policies that are difficult to understand and properly enforce.
- Many entities find it difficult to comply with the PCI requirements and seek ways to reduce both the risk and cost associated with meeting their PCI requirements, namely PCI data security standards.
- PCI data security standards require that entities eliminate any stored credit card data not required by the entity after any payment transaction. As such, the more an entity may reduce the places where credit card data is stored or otherwise retained, the more the entity may reduce the scope of their PCI compliance requirements.
- Tokenization is a technology wherein an electronic token is used to replace a credit card number (or other credit card data) in an electronic transaction.
- the electronic token is a set of reference characters designed to prevent the theft of the credit card number during electronic transmission and or storage of the credit card data.
- a token may include a 16 digit, randomly generated character set resembling a credit card number.
- the token may include a 15 digit character sets to accommodate various card brand characteristics.
- One of ordinary skill in the art will appreciate that many other types and sizes of tokens created from credit card data may likewise be utilized in accordance with the present disclosure.
- tokenization procedures may produce tokens from credit card data that include only residual characters or numbers from the original primary account number, also known as a “PAN.”
- PAN may include the last four digits of a credit card, which may become the last four digits of the electronic token.
- tokenization complies with all PCI requirements, obligations, and standards. Tokenization may allow the entity to utilize unique tokens associated with individual or repeated credit card transactions. Therefore, the entity may completely eliminate the need to store credit card data in their environment (e.g., within a point of sale terminal, a database, or a web server).
- tokens may also be used to store other customer information including banking account information, driver license numbers, social security card information, and image documents, among other sensitive information or combinations thereof.
- Tokenization systems may include input or tap devices that reside inline with credit card readers and point of sale terminals to intercept sensitive credit card data before the credit card data enters the point of sale terminal.
- Entities that utilize tap devices inline with point of sale “POS” systems may not require hardware or software upgrades to their POS systems.
- the POS terminal(s) of the entity are not considered to be “in scope” relative to PCI requirements. Ensuring that an entity's POS terminals are not “in scope” may significantly reduce or substantially eliminate risk and assessment costs associated with achieving and maintaining PCI compliance.
- a reduction of operating costs associated with eliminating or substantially reducing the PCI compliance of an entity may also be seen in other internal company systems such as firewall and router configurations, software, detection systems, other point of sale system equipment, along with any other systems that an entity may utilize to process credit card data.
- PCI approved scanning vendor also known as “ASV”
- ASV PCI approved scanning vendor
- While not all entities may eliminate all PCI compliance issues, even entities that are still subject to a measure of PCI compliance requirements may benefit from an expedited compliance engagement, yielding a reduced cost and risk to their environment.
- FIG. 1 illustrates an exemplary system 100 for practicing aspects of the present technology.
- the system 100 includes a sensitive information source, hereinafter “card reader 105 ,” a tap device 110 , a POS terminal 115 , a provider system 120 , a retail system 125 , and a credit card authority 130 (also known as a “transaction processor”).
- the system 100 may be arranged such that the card reader 105 , tap device 110 , and POS terminal 115 reside at a first location such as a retail establishment or mobile point of sale system.
- the provider system 120 may reside at a second location that is remote from the first location.
- the retail system 125 and the credit card authority 130 may reside at third and fourth locations, respectively.
- tap device 110 and the provider system 120 may be operated by the same entity, or may be operated by separate entities.
- the tap device 110 and the provider system 120 may be communicatively coupled to one another via a first network 135 .
- the tap device 110 and provider system 120 may communicate with one another over the first network 135 may utilize any of a number of end-to-end security protocols.
- the provider system 120 may communicatively couple to the credit card authority 130 to facilitate the authorization of credit card transactions via a second network 140 .
- the second network 140 has been shown as a dotted line.
- the second network 140 may be configured to utilize any one of a number of end-to-end security protocols.
- the POS terminal 115 and retail system 125 may not receive credit card data, they may communicatively couple to one another via a third network 145 that may include a public or private communications network. It will be understood that because the POS terminal 115 and retail system 125 do not receive credit card data, they are considered to be “outside” of the scope of PCI requirements.
- credit card data may be provided to the card reader 105 by a consumer.
- the credit card data may be passed to the tap device 110 .
- the tap device 110 generates a token from the credit card data and transmits the token along with the credit card data to the provider system 120 . Additionally, the tap device 110 may provide the token to the POS terminal 115 .
- the credit card data and token are associated with one another in a database of the provider system 120 .
- the POS terminal 115 may provide the token to the retail system 125 along with transaction information (e.g., transaction amount, SKU, etc.) that corresponds to the instant transaction.
- the retail system 125 may provide the token, along with the transaction information to the provider system 120 .
- the communicative coupling of the retail system 125 and the provider system 120 is shown as dotted line 175 .
- provider system 120 may provide the credit card data and the transaction data to the credit card authority 130 .
- the credit card authority 130 provides payment verification or authorization to the retail system 125 .
- the credit card authority 130 may also provide the token back to the retail system 125 for verification purposes. It will be understood that the terms “payment verification” may correspond to the phrase “transaction authorization information.”
- the retail system 125 may then provide the POS terminal 115 with the payment verification that enables the retail establishment to complete the transaction.
- the POS terminal 115 may provide the token to the provider system 120 along with transaction information (e.g., transaction amount, SKU, etc.) that corresponds to the instant transaction.
- the provider system 120 may provide the token, along with the transaction information to the credit card authority 130 .
- the credit card authority 130 Once the credit card authority 130 has authorized the transaction, the credit card authority 130 provides payment verification or authorization to the provider system 120 .
- the provider system 120 may then send the POS terminal 115 the payment verification or authorization information.
- the terms “payment verification” may correspond to the phrase “transaction authorization information.”
- the system 100 may include a middleware device 180 disposed between the retail system 125 and the credit card authority 130 .
- the retail system 125 may receive a token and transaction information from the POS terminal 115 .
- the provider system 120 may receive a token from the retail system 125 and the provider system may pass the credit card data associated with the token back to the retail system 125 or potentially the middleware device 180 .
- the middleware device 180 may facilitate credit card transactions between the credit card authority 130 and the retail system 125 , exchanging data such as credit card data, transaction data, and payment authorization therebetween.
- the card reader 105 , tap device 110 , provider system 120 , and credit card authority 130 are all subject to PCI compliance requirements.
- the POS terminal 115 and retail system 125 are entirely outside the scope of PCI compliance requirements, thus minimizing and/or substantially eliminating the PCI requirements of the retail establishment.
- the card reader 105 may include any one of a number of different devices that are configured to receive credit card data from an individual.
- the card reader 105 may be configured to facilitate “card present” and/or “card not present” transactions.
- Card present transactions may occur when the consumer has their credit card physically present and available to the retailer, and where the consumer and the retailer are both together in the same physical location.
- Card not present transactions may occur when the consumer and the retailer are not together in the same location, such as the retail location. Card not present transactions frequently occur over the telephone or across the Internet.
- an individual may swipe their credit card through a slot associated with the card reader 105 .
- the slot typically includes one or more reading members that are configured to read credit card data stored in the magnetic stripe of a credit card.
- the magnetic stripe of the credit card stores pertinent credit card data such as track one, track two, and track three information.
- Track one (International Air Transport Association, “IATA”) data may include data such as proprietary credit card authority data (e.g., card issuer data) along with discretionary data such as expiration date, service code, name, and so forth.
- Track two (American Bankers Association “ABA”) data may include additional information compared to track one data. Additionally, track two data is stored in a different format from track one data.
- Track three data may include additional types of data such as demographic data related to height, age, eye color, and so forth.
- card reader 105 may include any number of devices or components for gathering credit card data from a credit card.
- some credit cards store credit card data via smart card or radio frequency identification “RFID” technology that provide credit card data to an RFID credit card reader when the credit card is brought into close proximity with an RFID card reader.
- RFID radio frequency identification
- the systems and methods provided herein may be configured to utilize Europay, MasterCard, and Visa standardized data, also referred to as “EMV” data.
- the card reader 105 may include devices that are configured to facilitate “card not present” transactions where customers or retail employees may enter the credit card data of the customer via a keypad or keyboard. It is noteworthy that there are inherent security risks with regard to facilitating card not present transactions. As such, to reduce these risks, retailers and transaction processors that allow “card not present” transactions may require additional security data such as a card security code such as CVV, CVVC, CSC, or other types of credit card security data that would be known to one of ordinary skill in the art with the present disclosure before them.
- a card security code such as CVV, CVVC, CSC, or other types of credit card security data that would be known to one of ordinary skill in the art with the present disclosure before them.
- the reading member obtains the credit card data stored on the magnetic stripe of the credit card and translates that credit card data into a data format that is utilizable by the POS terminal 115 .
- the tap device 110 may include a housing 150 adapted to at least partially house a communications device (also known as a “communications module”) 155 , memory 160 , and a processor 165 .
- Tap device 110 may also include one or more of the components of computing system 500 as will be described in greater detail infra, with reference to FIG. 5 .
- the communications device 155 may be configured to facilitate communication of data between the card reader 105 and the tap device 110 , namely the processor 165 of the card reader 105 .
- the communications device 155 may include a transceiver, a transmitter, a network adapter, and so forth.
- the card reader 105 and the tap device 110 may be linked together via a universal serial bus “USB” cable extending between the card reader 105 and the tap device 110 . Therefore, the tap device 110 may include a USB adapter that receives an end of the USB cable. While the tap device 110 has been disclosed as utilizing a USB cable, one of ordinary skill in the art with the present disclosure before them will appreciate that many other types of connecting cables or linkages such as a serial cable, a firewire cable, and so forth, may likewise be utilized in accordance with the present technology.
- the processor 165 is configured to execute instructions that are stored in memory 160 to tokenize credit card data received from the card reader 105 . Once the credit card data has been tokenized, the communications device 155 provides the credit card data and the token to the database of the provider system 120 . It will be understood that rather than communicating the credit card data and the token to the database of the provider system 120 , the credit card data and the token may be stored locally on the tap device 110 in a local memory store (not shown).
- FIG. 2 illustrates a block diagram of a tokenization application 200 that resides within the memory 160 of the tap device 110 and that may be executed by the processor 165 .
- the tokenization application 200 may include a communications module 205 , an analysis module 210 , and a token generator 215 .
- tokenization application 200 may include additional modules, engines, or components, and still fall within the scope of the present technology.
- module may also refer to any of an application-specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
- ASIC application-specific integrated circuit
- processor shared, dedicated, or group
- combinational logic circuit and/or other suitable components that provide the described functionality.
- the communications module 205 may include USB host frame work, TCP/IP stack, and serial communication routines that facilitate all of the communications of the tap device 110 .
- the communications module 205 may receive credit card data from the card reader 105 and provide tokens to the provider system 120 and the POS terminal 115 .
- the analysis module 210 may receive credit card data from the communications module 205 and evaluate the credit card data to determine the PAN, card verification value “CVV,” or “CVV2,” card security code “CSC,” card verification value code “CVVC,” and any other associated information included in the data provided by the card reader 105 .
- the token generator 215 may apply one or more tokenization schemas to the credit card data to create a token.
- the tokenization schema may operate to create a token of any size and/or composition.
- the token may include a plurality of numbers that include a portion of the PAN, or may include any permutation of numbers, letters, symbols, and so forth.
- the token that is generated by the token generator 215 may have no mathematical or algorithmic relationship to the original credit card data. As such, the original credit card data may not be recreated from the token, even when the tokenization schema is known.
- the token may be at least partially relatable to the original credit card data.
- the tokenization application 200 may include an indexing module 220 that is configured to associate tokens with the credit card data from which the token was created. Associating the token and credit card data together allow for further transaction processing. It will be understood that in some exemplary embodiments, the indexing module 220 may be associated with the provider system 120 , such as when the provider system 120 is utilized to store tokens and associated credit card data.
- Allowing the tap device 110 to store tokens and credit card data locally may reduce system latency. Additionally, storing tokens and credit card data on the tap device 110 removes the additional step of transmitting data across the first network 135 , thus increasing the security of the system 100 .
- the tap device 110 may communicate bidirectionally with the credit card authority 130 .
- the token and credit card data are to be stored remotely in the database of the provider system 120 , the token and credit card data are provided to the provider system 120 by the communications module 205 of the tokenization application 200 . Tokens may also be provided to the POS terminal 115 via the communications module 205 .
- the tap device 110 may include an additional locking module 225 that functions to render the tap device 110 inoperable upon the occurrence of a security breach.
- the provider system 120 may monitor the operation of the tap device 110 to determine if a security breach of the tap device 110 has occurred. For example, the provider system 120 may determine unauthorized attempts to access to the tap device 110 , or credit card data stored thereon.
- the provider system 120 may communicate a locking signal to the locking module 225 .
- the locking module 225 may erase or rewrite at least a portion of the data storage of the tap device 110 . Additionally, the locking module 225 may cause any other damaging effect that renders the tap device inoperable and the data of the tap device 110 unrecoverable and/or unusable.
- the locking module 225 may also be configured to determine if the tap device 110 has been unexpectedly disconnected from the card reader 105 or the POS terminal 115 . Upon determining the occurrence of such an event, the locking module 225 may render the tap device 110 inoperable or unusable.
- FIG. 3 illustrates an additional exemplary embodiment of a system 300 for tokenizing sensitive information.
- the system 300 generally includes all of the components of system 100 (see FIG. 1 ) with the exception that the card reader 305 includes an integrated tokenization device 310 .
- the combination of the card reader 305 and the integrated tokenization device 310 may be generally referred to as an “input device.”
- the card reader 305 may include a tokenization application (not shown) that functions similarly to the tokenization application 200 of FIG. 2 , described in greater detail supra. Therefore, the tokenization of credit card data may occur within the card reader 305 , itself.
- FIG. 4A illustrates a flow chart of an exemplary method 400 for facilitating financial transactions utilizing tokens created from credit card data.
- the method 400 may include the step 405 of creating a transaction data set at a POS terminal.
- the transaction data set may include information corresponding to a desired product and/or service and a payment amount that corresponds to the desired product and/or service.
- the method 400 includes the step 410 of receiving credit card data at the card reader. Step 410 may include swiping or entering credit card information at the card reader.
- the tap device receives the credit card data from the card reader and generates a token from the credit card data utilizing a tokenization schema.
- the method includes the step 420 of providing the credit card data and the token to a provider system.
- the credit card data and the token may be indexed and stored together in the database of the provider system.
- the method 400 may also include step 430 of determining how the transaction should be processed.
- step 430 may include determining if the credit card transaction should be processed via the retail system in step 435 ( FIG. 4B ) or the provider system in step 455 ( FIG. 4C ). It will be understood that the way in which the system 100 processes credit card transactions may be established in advance by the administrators of the retail system 125 and/or the provider system 120 .
- FIG. 4B illustrates a flow chart of an exemplary method 435 for processing credit card transactions utilizing a token and associated credit card data.
- the method may include the step 440 of the provider system receiving a token from the retail system (see 215 of FIG. 2 ).
- the POS terminal provides the token and transaction information (e.g., transaction amount, SKU, etc.) to the retail system.
- the provider system then provides the transaction data and the credit card data to the credit card authority in step 445 .
- the method may include the step 450 of the provider system providing the token to the credit card authority for verification purposes.
- the credit card authority may alternatively receive the token and transaction information from a POS terminal or a retail system. Again, though not germane to the method, once the credit card authority has authorized the transaction, the credit card authority may pass the transaction authorization back to the retail system.
- FIG. 4C illustrates a flow chart of an alternative exemplary method 455 for processing credit card transactions utilizing a token and associated credit card data.
- the method may include the step 460 of the provider system receiving a token from the retail system along with transaction information (e.g., transaction amount, SKU, etc.).
- transaction information e.g., transaction amount, SKU, etc.
- the provider system then facilitates the transaction with the credit card authority by providing the credit card authority with the credit card data and the transaction information.
- Step 470 includes the provider system receiving transaction authorization from the credit card authority.
- the method may include the provider system providing the transaction authorization back to the POS terminal in step 475 .
- method 455 contemplates the provider system executing the above-described steps, it will be understood that the tap device, or card reader/tap device may execute one or more of the above-described steps in place of the provider system, for example, when the tap device stores the token and the credit card data locally.
- provider system may pass the token and the credit card data back to the credit card authority, allowing for the retail system and the credit card authority to communicate directly with one another to finalize a transaction.
- FIG. 5 illustrates an exemplary computing system 500 that may be used to implement an embodiment of the present technology.
- the computing system 500 of FIG. 5 includes one or more processors 510 and memory 520 .
- Main a memory store 520 stores, in part, instructions and data for execution by processor 510 .
- Main a memory store 520 can store the executable code when the system 500 is in operation.
- the system 500 of FIG. 5 may further include a mass storage device 530 , portable storage medium drive(s) 540 , output devices 550 , user input devices 560 , a graphics display 540 , and other peripheral devices 580 .
- FIG. 5 The components shown in FIG. 5 are depicted as being connected via a single bus 590 .
- the components may be connected through one or more data transport means.
- Processor 510 and main a memory store 520 may be connected via a local microprocessor bus, and the mass storage device 530 , peripheral device(s) 580 , portable storage device 540 , and display system 570 may be connected via one or more input/output (I/O) buses.
- I/O input/output
- Mass storage device 530 which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 510 .
- Mass storage device 530 can store the system software for implementing embodiments of the present technology for purposes of loading that software into main a memory store 520 .
- Portable storage device 540 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, compact disk or digital video disc, to input and output data and code to and from the computing system 500 of FIG. 5 .
- the system software for implementing embodiments of the present technology may be stored on such a portable medium and input to the computing system 500 via the portable storage device 540 .
- Input devices 560 provide a portion of a user interface.
- Input devices 560 may include an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys.
- the system 500 as shown in FIG. 5 includes output devices 550 . Suitable output devices include speakers, printers, network interfaces, and monitors.
- Display system 570 may include a liquid crystal display (LCD) or other suitable display device.
- Display system 570 receives textual and graphical information, and processes the information for output to the display device.
- LCD liquid crystal display
- Peripherals 580 may include any type of computer support device to add additional functionality to the computing system.
- Peripheral device(s) 580 may include a modem or a router.
- the components contained in the computing system 500 of FIG. 5 are those typically found in computing systems that may be suitable for use with embodiments of the present technology and are intended to represent a broad category of such computer components that are well known in the art.
- the computing system 500 of FIG. 5 can be a personal computer, hand held computing system, telephone, mobile computing system, workstation, server, minicomputer, mainframe computer, or any other computing system.
- the computer can also include different bus configurations, networked platforms, multi-processor platforms, etc.
- Various operating systems can be used including UNIX, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems.
- Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium).
- the instructions may be retrieved and executed by the processor.
- Some examples of storage media are memory devices, tapes, disks, and the like.
- the instructions are operational when executed by the processor to direct the processor to operate in accord with the technology. Those skilled in the art are familiar with instructions, processor(s), and storage media.
- Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk.
- Volatile media include dynamic memory, such as system RAM.
- Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one embodiment of a bus.
- Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications.
- RF radio frequency
- IR infrared
- Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASHEPROM, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.
- a bus carries the data to system RAM, from which a CPU retrieves and executes the instructions.
- the instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
Abstract
Description
- This non-provisional patent application is a continuation of U.S. application Ser. No. 13/085,843, filed on Apr. 13, 2011 entitled “DEVICES, SYSTEMS, AND METHODS FOR TOKENIZING SENSITIVE INFORMATION”, which claims the benefit and priority of U.S. Provisional Application Ser. No. 61/282,899, filed on Apr. 19, 2010, entitled “Data Security—Credit Card Extraction to Support Tokenization and E2E Process”—all of which are hereby incorporated by reference herein in its entirety including all references and appendices cited therein.
- The present invention relates generally to the tokenization of sensitive information, and more particularly, but not by way of limitation, to devices, systems and methods for tokenizing sensitive information.
- Provided herein are exemplary devices, systems and methods for tokenizing sensitive information. Exemplary embodiments may include methods for tokenizing sensitive data by: (a) receiving sensitive information via an input device, the input device being communicatively coupled to a transaction terminal; (b) tokenizing the sensitive information at the input device to generate a token; and (c) associating the token and the sensitive information together in a storage medium associated with the input device.
- Additional exemplary embodiments may include methods for tokenizing sensitive data that include: (a) receiving a token from a tap device disposed between a sensitive information source and a transaction terminal, the token including sensitive information that has been tokenized by the tap device, the tap device being operatively connected to the sensitive information source; and (b) associating the token and the sensitive information together in a storage medium associated with the tap device.
- In other exemplary embodiments, systems for tokenizing sensitive information that may include: (a) a tap device configured to be disposed between a sensitive information source and a transaction terminal, the tap device including a tokenization module configured to receive sensitive information from the sensitive information source and generate a token from the sensitive information source; and (b) a provider system communicatively coupled to the tap device that receives the sensitive information and the token from the tap device and associates the sensitive information and the token together in a storage medium.
- According to some embodiments, the present technology may be directed to tap devices for tokenizing sensitive information. The tap devices may include (a) a communications module that receives sensitive information from a credit card reader; (b) a tokenizing module that tokenizes sensitive information received from the credit card reader to produce a token; and (c) wherein the tap device is configured to reside inline between the credit card reader and a point of sale terminal, at a retail location.
- Certain embodiments of the present invention are illustrated by the accompanying figures. It will be understood that the figures are not necessarily to scale and that details (e.g., dimensions) not necessary for an understanding of the invention or that render other details difficult to perceive may be omitted. It will be understood that the invention is not necessarily limited to the particular embodiments illustrated herein.
-
FIG. 1 illustrates an exemplary system for practicing aspects of the present technology. -
FIG. 2 illustrates a schematic diagram of a tokenizing application. -
FIG. 3 illustrates an additional exemplary system for practicing aspects of the present technology. -
FIG. 4A illustrates a flow chart of an exemplary method of facilitating financial transactions utilizing tokens created from credit card data. -
FIG. 4B illustrates a flow chart of an exemplary method of processing credit card transactions utilizing tokens created from credit card data. -
FIG. 4C illustrates a flow chart of another exemplary method of processing credit transactions utilizing tokens created from credit card data. -
FIG. 5 is a block diagram of an exemplary computing system that may be utilized to practice aspects of the present disclosure. - While this invention is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail several specific embodiments with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the invention to the embodiments illustrated.
- It will be understood that like or analogous elements and/or components, referred to herein, may be identified throughout the drawings with like reference characters.
- Broadly speaking, devices, systems, and methods for tokenizing sensitive information are provided herein. While one of ordinary skill in the art will appreciate that the present technology may be applied to a wide variety of systems that receive, process, and store sensitive information, for the purposes of brevity, the following discussions will include a detailed description of the utilization of the present technology in the context of financial transactions.
- The payment card industry, hereinafter “PCI,” has established a set of compliance requirements that impose mandates on all entities that store, process, and/or transmit credit card data.
- It will be understood that entities that receive or process credit card data must store cardholder data from each transaction for some period of time. Systems employed by entities for storing and/or transmitting credit card data may be susceptible to a wide variety of security breaches. For example, common security breaches may include credit card fraud, hacking, and numerous other security threats. Additionally, traditional methods for data protection, such as encryption, are often unsuitable to protect such highly sensitive information.
- In response to these threats, PCI governing bodies require that entities must enact systems or processes that protect credit card data from intentional and/or unintentional exposure to third parties. Unfortunately, these commonly utilized systems and processes may require expensive hardware and software solutions, along with complex privacy policies that are difficult to understand and properly enforce. Many entities find it difficult to comply with the PCI requirements and seek ways to reduce both the risk and cost associated with meeting their PCI requirements, namely PCI data security standards.
- To be sure, PCI data security standards require that entities eliminate any stored credit card data not required by the entity after any payment transaction. As such, the more an entity may reduce the places where credit card data is stored or otherwise retained, the more the entity may reduce the scope of their PCI compliance requirements.
- To ensure that entities are compliant with PCI standards, entities must complete PCI compliance assessments and conduct additional ancillary tests, all of which impose significant financial obligations. Additionally, entities often spend significant time ensuring compliance with their annual PCI assessments. This problem is exacerbated when an organization maintains hundreds if not thousands of retail locations and performs thousands of transactions weekly.
- The only way to ensure that entities are insulated or substantially relieved of their PCI requirements is to ensure that the credit card data utilized (e.g., stored, processed, transmitted) by these entities is minimized as much as practicably possible. By limiting PCI obligations, an entity may save tremendous amounts of time and money, and reduce risk in their environment.
- One method for reducing stolen credit card information is in the use of tokenization. Tokenization is a technology wherein an electronic token is used to replace a credit card number (or other credit card data) in an electronic transaction.
- The electronic token is a set of reference characters designed to prevent the theft of the credit card number during electronic transmission and or storage of the credit card data.
- When properly utilized by an entity, tokenization may significantly reduce the scope and requirements of PCI compliance without costly changes to the systems of the entity. In some embodiments, a token may include a 16 digit, randomly generated character set resembling a credit card number. In other embodiments, the token may include a 15 digit character sets to accommodate various card brand characteristics. One of ordinary skill in the art will appreciate that many other types and sizes of tokens created from credit card data may likewise be utilized in accordance with the present disclosure.
- According to some embodiments, tokenization procedures may produce tokens from credit card data that include only residual characters or numbers from the original primary account number, also known as a “PAN.” The PAN may include the last four digits of a credit card, which may become the last four digits of the electronic token.
- For credit card processing, tokenization complies with all PCI requirements, obligations, and standards. Tokenization may allow the entity to utilize unique tokens associated with individual or repeated credit card transactions. Therefore, the entity may completely eliminate the need to store credit card data in their environment (e.g., within a point of sale terminal, a database, or a web server).
- While the above described use of tokens have contemplated their use in credit card transactions, tokens may also be used to store other customer information including banking account information, driver license numbers, social security card information, and image documents, among other sensitive information or combinations thereof.
- The devices, systems, and methods described herein may be configured to tokenize sensitive information to reduce PCI obligations of entities that utilize the same. Tokenization systems provided herein may include input or tap devices that reside inline with credit card readers and point of sale terminals to intercept sensitive credit card data before the credit card data enters the point of sale terminal.
- Entities that utilize tap devices inline with point of sale “POS” systems may not require hardware or software upgrades to their POS systems. As such, the POS terminal(s) of the entity are not considered to be “in scope” relative to PCI requirements. Ensuring that an entity's POS terminals are not “in scope” may significantly reduce or substantially eliminate risk and assessment costs associated with achieving and maintaining PCI compliance.
- A reduction of operating costs associated with eliminating or substantially reducing the PCI compliance of an entity may also be seen in other internal company systems such as firewall and router configurations, software, detection systems, other point of sale system equipment, along with any other systems that an entity may utilize to process credit card data.
- Additionally, entities may no longer require PCI approved scanning vendor, also known as “ASV,” services or penetration testing, thus reducing or eliminating additional costs associated with the same.
- While not all entities may eliminate all PCI compliance issues, even entities that are still subject to a measure of PCI compliance requirements may benefit from an expedited compliance engagement, yielding a reduced cost and risk to their environment.
- Turning to the present technology in greater detail,
FIG. 1 illustrates anexemplary system 100 for practicing aspects of the present technology. Generally speaking, thesystem 100 includes a sensitive information source, hereinafter “card reader 105,” atap device 110, aPOS terminal 115, aprovider system 120, aretail system 125, and a credit card authority 130 (also known as a “transaction processor”). - The
system 100 may be arranged such that thecard reader 105,tap device 110, andPOS terminal 115 reside at a first location such as a retail establishment or mobile point of sale system. Theprovider system 120 may reside at a second location that is remote from the first location. Additionally, theretail system 125 and thecredit card authority 130 may reside at third and fourth locations, respectively. - It will be understood that the
tap device 110 and theprovider system 120 may be operated by the same entity, or may be operated by separate entities. - The
tap device 110 and theprovider system 120 may be communicatively coupled to one another via afirst network 135. For security purposes, thetap device 110 andprovider system 120 may communicate with one another over thefirst network 135 may utilize any of a number of end-to-end security protocols. Additionally, theprovider system 120 may communicatively couple to thecredit card authority 130 to facilitate the authorization of credit card transactions via asecond network 140. Because thesystem 100 may utilize alternative device configurations to facilitate the authorization of credit card transactions, thesecond network 140 has been shown as a dotted line. Similarly to thefirst network 135, thesecond network 140 may be configured to utilize any one of a number of end-to-end security protocols. - Because the
POS terminal 115 andretail system 125 may not receive credit card data, they may communicatively couple to one another via athird network 145 that may include a public or private communications network. It will be understood that because thePOS terminal 115 andretail system 125 do not receive credit card data, they are considered to be “outside” of the scope of PCI requirements. - During the course of a retail transaction, credit card data may be provided to the
card reader 105 by a consumer. The credit card data may be passed to thetap device 110. Thetap device 110 generates a token from the credit card data and transmits the token along with the credit card data to theprovider system 120. Additionally, thetap device 110 may provide the token to thePOS terminal 115. The credit card data and token are associated with one another in a database of theprovider system 120. - Exemplary Transaction Processing Utilizing a Token and Credit Card Data
- In some embodiments, to complete a transaction, the
POS terminal 115 may provide the token to theretail system 125 along with transaction information (e.g., transaction amount, SKU, etc.) that corresponds to the instant transaction. Theretail system 125 may provide the token, along with the transaction information to theprovider system 120. The communicative coupling of theretail system 125 and theprovider system 120 is shown as dottedline 175. - To finalize the transaction,
provider system 120 may provide the credit card data and the transaction data to thecredit card authority 130. Once thecredit card authority 130 has authorized the transaction, thecredit card authority 130 provides payment verification or authorization to theretail system 125. Thecredit card authority 130 may also provide the token back to theretail system 125 for verification purposes. It will be understood that the terms “payment verification” may correspond to the phrase “transaction authorization information.” - The
retail system 125 may then provide thePOS terminal 115 with the payment verification that enables the retail establishment to complete the transaction. - Additional Exemplary Transaction Processing Utilizing a Token and Credit Card Data
- In alternative embodiments, to complete a transaction, the
POS terminal 115 may provide the token to theprovider system 120 along with transaction information (e.g., transaction amount, SKU, etc.) that corresponds to the instant transaction. Theprovider system 120 may provide the token, along with the transaction information to thecredit card authority 130. - Once the
credit card authority 130 has authorized the transaction, thecredit card authority 130 provides payment verification or authorization to theprovider system 120. Theprovider system 120 may then send thePOS terminal 115 the payment verification or authorization information. The terms “payment verification” may correspond to the phrase “transaction authorization information.” - Additional Exemplary Transaction Processing Utilizing a Token and Credit Card Data
- In yet another exemplary embodiment, the
system 100 may include amiddleware device 180 disposed between theretail system 125 and thecredit card authority 130. In this embodiment, theretail system 125 may receive a token and transaction information from thePOS terminal 115. Theprovider system 120 may receive a token from theretail system 125 and the provider system may pass the credit card data associated with the token back to theretail system 125 or potentially themiddleware device 180. In some applications, themiddleware device 180 may facilitate credit card transactions between thecredit card authority 130 and theretail system 125, exchanging data such as credit card data, transaction data, and payment authorization therebetween. - To be sure, the
card reader 105,tap device 110,provider system 120, andcredit card authority 130 are all subject to PCI compliance requirements. In contrast, thePOS terminal 115 andretail system 125 are entirely outside the scope of PCI compliance requirements, thus minimizing and/or substantially eliminating the PCI requirements of the retail establishment. - Turning now to the components of the
system 100, thecard reader 105 may include any one of a number of different devices that are configured to receive credit card data from an individual. Thecard reader 105 may be configured to facilitate “card present” and/or “card not present” transactions. Card present transactions may occur when the consumer has their credit card physically present and available to the retailer, and where the consumer and the retailer are both together in the same physical location. Card not present transactions may occur when the consumer and the retailer are not together in the same location, such as the retail location. Card not present transactions frequently occur over the telephone or across the Internet. - With regard to card present transactions, an individual may swipe their credit card through a slot associated with the
card reader 105. The slot typically includes one or more reading members that are configured to read credit card data stored in the magnetic stripe of a credit card. The magnetic stripe of the credit card stores pertinent credit card data such as track one, track two, and track three information. Track one (International Air Transport Association, “IATA”) data may include data such as proprietary credit card authority data (e.g., card issuer data) along with discretionary data such as expiration date, service code, name, and so forth. Track two (American Bankers Association “ABA”) data may include additional information compared to track one data. Additionally, track two data is stored in a different format from track one data. Track three data may include additional types of data such as demographic data related to height, age, eye color, and so forth. - One of ordinary skill in the art will appreciate that
card reader 105 may include any number of devices or components for gathering credit card data from a credit card. For example, some credit cards store credit card data via smart card or radio frequency identification “RFID” technology that provide credit card data to an RFID credit card reader when the credit card is brought into close proximity with an RFID card reader. In some applications, the systems and methods provided herein may be configured to utilize Europay, MasterCard, and Visa standardized data, also referred to as “EMV” data. - The
card reader 105 may include devices that are configured to facilitate “card not present” transactions where customers or retail employees may enter the credit card data of the customer via a keypad or keyboard. It is noteworthy that there are inherent security risks with regard to facilitating card not present transactions. As such, to reduce these risks, retailers and transaction processors that allow “card not present” transactions may require additional security data such as a card security code such as CVV, CVVC, CSC, or other types of credit card security data that would be known to one of ordinary skill in the art with the present disclosure before them. - Once swiped through the slot of the
card reader 105, the reading member obtains the credit card data stored on the magnetic stripe of the credit card and translates that credit card data into a data format that is utilizable by thePOS terminal 115. - Instead of providing credit card data to the
POS terminal 115, the credit card data is provided to thetap device 110. According to some embodiments, thetap device 110 may include a housing 150 adapted to at least partially house a communications device (also known as a “communications module”) 155,memory 160, and aprocessor 165.Tap device 110 may also include one or more of the components ofcomputing system 500 as will be described in greater detail infra, with reference toFIG. 5 . - The
communications device 155 may be configured to facilitate communication of data between thecard reader 105 and thetap device 110, namely theprocessor 165 of thecard reader 105. In some embodiments, thecommunications device 155 may include a transceiver, a transmitter, a network adapter, and so forth. - It will be understood that in some embodiments, the
card reader 105 and thetap device 110 may be linked together via a universal serial bus “USB” cable extending between thecard reader 105 and thetap device 110. Therefore, thetap device 110 may include a USB adapter that receives an end of the USB cable. While thetap device 110 has been disclosed as utilizing a USB cable, one of ordinary skill in the art with the present disclosure before them will appreciate that many other types of connecting cables or linkages such as a serial cable, a firewire cable, and so forth, may likewise be utilized in accordance with the present technology. - According to additional embodiments, the
processor 165 is configured to execute instructions that are stored inmemory 160 to tokenize credit card data received from thecard reader 105. Once the credit card data has been tokenized, thecommunications device 155 provides the credit card data and the token to the database of theprovider system 120. It will be understood that rather than communicating the credit card data and the token to the database of theprovider system 120, the credit card data and the token may be stored locally on thetap device 110 in a local memory store (not shown). -
FIG. 2 illustrates a block diagram of atokenization application 200 that resides within thememory 160 of thetap device 110 and that may be executed by theprocessor 165. Thetokenization application 200 may include acommunications module 205, ananalysis module 210, and atoken generator 215. - It is noteworthy that the
tokenization application 200 may include additional modules, engines, or components, and still fall within the scope of the present technology. As used herein, the term “module” may also refer to any of an application-specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. - In some embodiments, the
communications module 205 may include USB host frame work, TCP/IP stack, and serial communication routines that facilitate all of the communications of thetap device 110. Generally speaking, thecommunications module 205 may receive credit card data from thecard reader 105 and provide tokens to theprovider system 120 and thePOS terminal 115. - The
analysis module 210 may receive credit card data from thecommunications module 205 and evaluate the credit card data to determine the PAN, card verification value “CVV,” or “CVV2,” card security code “CSC,” card verification value code “CVVC,” and any other associated information included in the data provided by thecard reader 105. - Based upon the determined credit card data, the
token generator 215 may apply one or more tokenization schemas to the credit card data to create a token. It will be understood that the tokenization schema may operate to create a token of any size and/or composition. For example, the token may include a plurality of numbers that include a portion of the PAN, or may include any permutation of numbers, letters, symbols, and so forth. It is noteworthy to mention that the token that is generated by thetoken generator 215 may have no mathematical or algorithmic relationship to the original credit card data. As such, the original credit card data may not be recreated from the token, even when the tokenization schema is known. In some applications, the token may be at least partially relatable to the original credit card data. - If the
tap device 110 stores the token and the credit card data, thetokenization application 200 may include anindexing module 220 that is configured to associate tokens with the credit card data from which the token was created. Associating the token and credit card data together allow for further transaction processing. It will be understood that in some exemplary embodiments, theindexing module 220 may be associated with theprovider system 120, such as when theprovider system 120 is utilized to store tokens and associated credit card data. - Allowing the
tap device 110 to store tokens and credit card data locally may reduce system latency. Additionally, storing tokens and credit card data on thetap device 110 removes the additional step of transmitting data across thefirst network 135, thus increasing the security of thesystem 100. In such embodiments, thetap device 110 may communicate bidirectionally with thecredit card authority 130. - If the token and credit card data are to be stored remotely in the database of the
provider system 120, the token and credit card data are provided to theprovider system 120 by thecommunications module 205 of thetokenization application 200. Tokens may also be provided to thePOS terminal 115 via thecommunications module 205. - According to some embodiments, the
tap device 110 may include anadditional locking module 225 that functions to render thetap device 110 inoperable upon the occurrence of a security breach. In some embodiments, theprovider system 120 may monitor the operation of thetap device 110 to determine if a security breach of thetap device 110 has occurred. For example, theprovider system 120 may determine unauthorized attempts to access to thetap device 110, or credit card data stored thereon. - Upon determining a security breach, the
provider system 120 may communicate a locking signal to thelocking module 225. Upon receiving the locking signal, thelocking module 225 may erase or rewrite at least a portion of the data storage of thetap device 110. Additionally, thelocking module 225 may cause any other damaging effect that renders the tap device inoperable and the data of thetap device 110 unrecoverable and/or unusable. - The
locking module 225 may also be configured to determine if thetap device 110 has been unexpectedly disconnected from thecard reader 105 or thePOS terminal 115. Upon determining the occurrence of such an event, thelocking module 225 may render thetap device 110 inoperable or unusable. -
FIG. 3 illustrates an additional exemplary embodiment of asystem 300 for tokenizing sensitive information. Thesystem 300 generally includes all of the components of system 100 (seeFIG. 1 ) with the exception that thecard reader 305 includes anintegrated tokenization device 310. The combination of thecard reader 305 and theintegrated tokenization device 310 may be generally referred to as an “input device.” For example, thecard reader 305 may include a tokenization application (not shown) that functions similarly to thetokenization application 200 ofFIG. 2 , described in greater detail supra. Therefore, the tokenization of credit card data may occur within thecard reader 305, itself. -
FIG. 4A illustrates a flow chart of anexemplary method 400 for facilitating financial transactions utilizing tokens created from credit card data. Themethod 400 may include thestep 405 of creating a transaction data set at a POS terminal. The transaction data set may include information corresponding to a desired product and/or service and a payment amount that corresponds to the desired product and/or service. In response to generating a transaction data set, themethod 400 includes thestep 410 of receiving credit card data at the card reader. Step 410 may include swiping or entering credit card information at the card reader. - In
step 415, the tap device receives the credit card data from the card reader and generates a token from the credit card data utilizing a tokenization schema. Next, the method includes thestep 420 of providing the credit card data and the token to a provider system. The credit card data and the token may be indexed and stored together in the database of the provider system. Themethod 400 may also includestep 430 of determining how the transaction should be processed. For example, step 430 may include determining if the credit card transaction should be processed via the retail system in step 435 (FIG. 4B ) or the provider system in step 455 (FIG. 4C ). It will be understood that the way in which thesystem 100 processes credit card transactions may be established in advance by the administrators of theretail system 125 and/or theprovider system 120. -
FIG. 4B illustrates a flow chart of anexemplary method 435 for processing credit card transactions utilizing a token and associated credit card data. The method may include thestep 440 of the provider system receiving a token from the retail system (see 215 ofFIG. 2 ). To be sure, the POS terminal provides the token and transaction information (e.g., transaction amount, SKU, etc.) to the retail system. The provider system then provides the transaction data and the credit card data to the credit card authority instep 445. - Next, the method may include the
step 450 of the provider system providing the token to the credit card authority for verification purposes. Although not germane to the method, it is noteworthy that the credit card authority may alternatively receive the token and transaction information from a POS terminal or a retail system. Again, though not germane to the method, once the credit card authority has authorized the transaction, the credit card authority may pass the transaction authorization back to the retail system. -
FIG. 4C illustrates a flow chart of an alternativeexemplary method 455 for processing credit card transactions utilizing a token and associated credit card data. The method may include thestep 460 of the provider system receiving a token from the retail system along with transaction information (e.g., transaction amount, SKU, etc.). Next, instep 465, the provider system then facilitates the transaction with the credit card authority by providing the credit card authority with the credit card data and the transaction information. - Step 470 includes the provider system receiving transaction authorization from the credit card authority. Lastly, the method may include the provider system providing the transaction authorization back to the POS terminal in
step 475. Whilemethod 455 contemplates the provider system executing the above-described steps, it will be understood that the tap device, or card reader/tap device may execute one or more of the above-described steps in place of the provider system, for example, when the tap device stores the token and the credit card data locally. - Additionally, the provider system may pass the token and the credit card data back to the credit card authority, allowing for the retail system and the credit card authority to communicate directly with one another to finalize a transaction.
-
FIG. 5 illustrates anexemplary computing system 500 that may be used to implement an embodiment of the present technology. Thecomputing system 500 ofFIG. 5 includes one ormore processors 510 andmemory 520. Main amemory store 520 stores, in part, instructions and data for execution byprocessor 510. Main amemory store 520 can store the executable code when thesystem 500 is in operation. Thesystem 500 ofFIG. 5 may further include amass storage device 530, portable storage medium drive(s) 540,output devices 550,user input devices 560, agraphics display 540, and otherperipheral devices 580. - The components shown in
FIG. 5 are depicted as being connected via asingle bus 590. The components may be connected through one or more data transport means.Processor 510 and main amemory store 520 may be connected via a local microprocessor bus, and themass storage device 530, peripheral device(s) 580,portable storage device 540, anddisplay system 570 may be connected via one or more input/output (I/O) buses. -
Mass storage device 530, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use byprocessor unit 510.Mass storage device 530 can store the system software for implementing embodiments of the present technology for purposes of loading that software into main amemory store 520. -
Portable storage device 540 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, compact disk or digital video disc, to input and output data and code to and from thecomputing system 500 ofFIG. 5 . The system software for implementing embodiments of the present technology may be stored on such a portable medium and input to thecomputing system 500 via theportable storage device 540. -
Input devices 560 provide a portion of a user interface.Input devices 560 may include an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. Additionally, thesystem 500 as shown inFIG. 5 includesoutput devices 550. Suitable output devices include speakers, printers, network interfaces, and monitors. -
Display system 570 may include a liquid crystal display (LCD) or other suitable display device.Display system 570 receives textual and graphical information, and processes the information for output to the display device. -
Peripherals 580 may include any type of computer support device to add additional functionality to the computing system. Peripheral device(s) 580 may include a modem or a router. - The components contained in the
computing system 500 ofFIG. 5 are those typically found in computing systems that may be suitable for use with embodiments of the present technology and are intended to represent a broad category of such computer components that are well known in the art. Thus, thecomputing system 500 ofFIG. 5 can be a personal computer, hand held computing system, telephone, mobile computing system, workstation, server, minicomputer, mainframe computer, or any other computing system. The computer can also include different bus configurations, networked platforms, multi-processor platforms, etc. Various operating systems can be used including UNIX, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems. - Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium). The instructions may be retrieved and executed by the processor. Some examples of storage media are memory devices, tapes, disks, and the like. The instructions are operational when executed by the processor to direct the processor to operate in accord with the technology. Those skilled in the art are familiar with instructions, processor(s), and storage media.
- It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one embodiment of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASHEPROM, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.
- Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
- The above description is illustrative and not restrictive. Many variations of the technology will become apparent to those of skill in the art upon review of this disclosure. The scope of the technology should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.
Claims (17)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/362,188 US20170076281A1 (en) | 2010-04-19 | 2016-11-28 | Devices, systems, and methods for tokenizing sensitive information |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US28289910P | 2010-04-19 | 2010-04-19 | |
US13/085,843 US9558494B2 (en) | 2010-04-19 | 2011-04-13 | Devices, systems, and methods for tokenizing sensitive information |
US15/362,188 US20170076281A1 (en) | 2010-04-19 | 2016-11-28 | Devices, systems, and methods for tokenizing sensitive information |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/085,843 Continuation US9558494B2 (en) | 2010-04-19 | 2011-04-13 | Devices, systems, and methods for tokenizing sensitive information |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170076281A1 true US20170076281A1 (en) | 2017-03-16 |
Family
ID=44788953
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/085,843 Active 2032-08-26 US9558494B2 (en) | 2010-04-19 | 2011-04-13 | Devices, systems, and methods for tokenizing sensitive information |
US15/362,188 Abandoned US20170076281A1 (en) | 2010-04-19 | 2016-11-28 | Devices, systems, and methods for tokenizing sensitive information |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/085,843 Active 2032-08-26 US9558494B2 (en) | 2010-04-19 | 2011-04-13 | Devices, systems, and methods for tokenizing sensitive information |
Country Status (2)
Country | Link |
---|---|
US (2) | US9558494B2 (en) |
WO (1) | WO2011133494A2 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022093851A1 (en) * | 2020-10-29 | 2022-05-05 | Pacific Investment Management Company LLC | Surrogate data generation of private data |
US11429749B2 (en) | 2020-07-22 | 2022-08-30 | Mastercard International Incorporated | Systems and methods for tokenization of personally identifiable information (PII) and personal health information (PHI) |
US11615206B2 (en) | 2020-07-22 | 2023-03-28 | Mastercard International Incorporated | Systems and methods for tokenization of personally identifiable information (PII) |
US11803846B2 (en) | 2010-08-12 | 2023-10-31 | Visa International Service Association | Securing external systems with account token substitution |
US20230401181A1 (en) * | 2022-06-10 | 2023-12-14 | Capital One Services, Llc | Data Management Ecosystem for Databases |
Families Citing this family (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8447669B2 (en) | 2008-08-26 | 2013-05-21 | Visa U.S.A. Inc. | System and method for implementing financial assistance programs |
US20120124496A1 (en) | 2010-10-20 | 2012-05-17 | Mark Rose | Geographic volume analytics apparatuses, methods and systems |
WO2012106655A2 (en) | 2011-02-05 | 2012-08-09 | Visa International Service Association | Merchant-consumer bridging platform apparatuses, methods and systems |
US9953334B2 (en) | 2011-02-10 | 2018-04-24 | Visa International Service Association | Electronic coupon issuance and redemption apparatuses, methods and systems |
CN103765453B (en) | 2011-02-16 | 2018-08-14 | 维萨国际服务协会 | Snap mobile payment device, method and system |
US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
BR112013021057A2 (en) | 2011-02-22 | 2020-11-10 | Visa International Service Association | universal electronic payment devices, methods and systems |
WO2012118870A1 (en) | 2011-02-28 | 2012-09-07 | Visa International Service Association | Secure anonymous transaction apparatuses, methods and systems |
WO2012122060A1 (en) | 2011-03-04 | 2012-09-13 | Visa International Service Association | Cloud service facilitator apparatuses, methods and systems |
WO2012155081A1 (en) | 2011-05-11 | 2012-11-15 | Visa International Service Association | Electronic receipt manager apparatuses, methods and systems |
EP2715633A4 (en) | 2011-06-03 | 2014-12-17 | Visa Int Service Ass | Virtual wallet card selection apparatuses, methods and systems |
RU2602394C2 (en) * | 2011-06-07 | 2016-11-20 | Виза Интернешнл Сервис Ассосиэйшн | Payment privacy tokenisation apparatus, methods and systems |
US9596244B1 (en) | 2011-06-16 | 2017-03-14 | Amazon Technologies, Inc. | Securing services and intra-service communications |
US20120324225A1 (en) | 2011-06-20 | 2012-12-20 | Jason Chambers | Certificate-based mutual authentication for data security |
US9419841B1 (en) | 2011-06-29 | 2016-08-16 | Amazon Technologies, Inc. | Token-based secure data management |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
AU2012278963B2 (en) | 2011-07-05 | 2017-02-23 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
US10438176B2 (en) | 2011-07-17 | 2019-10-08 | Visa International Service Association | Multiple merchant payment processor platform apparatuses, methods and systems |
US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
US10318941B2 (en) | 2011-12-13 | 2019-06-11 | Visa International Service Association | Payment platform interface widget generation apparatuses, methods and systems |
US9117225B2 (en) | 2011-09-16 | 2015-08-25 | Visa International Service Association | Apparatuses, methods and systems for transforming user infrastructure requests inputs to infrastructure design product and infrastructure allocation outputs |
US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
US9953378B2 (en) | 2012-04-27 | 2018-04-24 | Visa International Service Association | Social checkout widget generation and integration apparatuses, methods and systems |
US10096022B2 (en) | 2011-12-13 | 2018-10-09 | Visa International Service Association | Dynamic widget generator apparatuses, methods and systems |
US10223710B2 (en) | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
US11308227B2 (en) | 2012-01-09 | 2022-04-19 | Visa International Service Association | Secure dynamic page content and layouts apparatuses, methods and systems |
US10262148B2 (en) | 2012-01-09 | 2019-04-16 | Visa International Service Association | Secure dynamic page content and layouts apparatuses, methods and systems |
AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
CN104361490B (en) * | 2014-11-03 | 2018-04-24 | 上海众人网络安全技术有限公司 | A kind of method of payment and system of sensitive information markization |
WO2016086154A1 (en) | 2014-11-26 | 2016-06-02 | Visa International Service Association | Tokenization request via access device |
US11216468B2 (en) | 2015-02-08 | 2022-01-04 | Visa International Service Association | Converged merchant processing apparatuses, methods and systems |
US11178115B2 (en) | 2016-09-21 | 2021-11-16 | Walmart Apollo, Llc | System and methods for point to point encryption and tokenization |
MX2019003187A (en) | 2016-09-21 | 2019-09-10 | Walmart Apollo Llc | System and methods for point to point encryption and tokenization using a mobile device. |
US11115397B2 (en) | 2016-09-21 | 2021-09-07 | Walmart Apollo, Llc | System and methods for point to point encryption and tokenization in a hosted environment |
TWI643148B (en) * | 2017-06-02 | 2018-12-01 | 中華電信股份有限公司 | Mobile device, method, computer program product, and distribution system thereof for configuring ticket co-branded credit card based on coding technology |
JP7230329B2 (en) * | 2018-03-02 | 2023-03-01 | 富士フイルムビジネスイノベーション株式会社 | Information processing system |
US10708050B2 (en) | 2018-06-19 | 2020-07-07 | TokenEx, LLC | Multivariate encryption systems and methods |
US11809493B2 (en) * | 2021-01-19 | 2023-11-07 | Micro Focus Llc | System and method for tokenization of data |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8458487B1 (en) * | 2010-03-03 | 2013-06-04 | Liaison Technologies, Inc. | System and methods for format preserving tokenization of sensitive information |
US20130212666A1 (en) * | 2012-02-10 | 2013-08-15 | Ulf Mattsson | Tokenization in mobile environments |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6143397A (en) * | 1984-08-08 | 1986-03-01 | 東芝テック株式会社 | Merchandize selling data processing system |
US6561428B2 (en) | 1997-10-17 | 2003-05-13 | Hand Held Products, Inc. | Imaging device having indicia-controlled image parsing mode |
US7225156B2 (en) | 2001-07-11 | 2007-05-29 | Fisher Douglas C | Persistent dynamic payment service |
US20040073688A1 (en) * | 2002-09-30 | 2004-04-15 | Sampson Scott E. | Electronic payment validation using Transaction Authorization Tokens |
US7548889B2 (en) | 2005-01-24 | 2009-06-16 | Microsoft Corporation | Payment information security for multi-merchant purchasing environment for downloadable products |
US20090171847A2 (en) * | 2005-01-24 | 2009-07-02 | Microsoft Corporation | Multi-merchant purchasing environment for downloadable products |
CN101233469B (en) * | 2005-07-21 | 2013-06-05 | 克莱夫公司 | Memory lock system |
US20080257956A1 (en) * | 2007-04-19 | 2008-10-23 | At&T Knowledge Ventures, L.P. | System for fulfilling purchases |
US20080263645A1 (en) | 2007-04-23 | 2008-10-23 | Telus Communications Company | Privacy identifier remediation |
US7770789B2 (en) | 2007-05-17 | 2010-08-10 | Shift4 Corporation | Secure payment card transactions |
DE102008000067C5 (en) * | 2008-01-16 | 2012-10-25 | Bundesdruckerei Gmbh | Method for reading attributes from an ID token |
US8578176B2 (en) | 2008-03-26 | 2013-11-05 | Protegrity Corporation | Method and apparatus for tokenization of sensitive sets of characters |
US8651374B2 (en) | 2008-06-02 | 2014-02-18 | Sears Brands, L.L.C. | System and method for payment card industry enterprise account number elimination |
US8584251B2 (en) | 2009-04-07 | 2013-11-12 | Princeton Payment Solutions | Token-based payment processing system |
US10748146B2 (en) | 2009-06-16 | 2020-08-18 | Heartland Payment Systems, Llc | Tamper-resistant secure methods, systems and apparatuses for credit and debit transactions |
-
2011
- 2011-04-13 US US13/085,843 patent/US9558494B2/en active Active
- 2011-04-19 WO PCT/US2011/032960 patent/WO2011133494A2/en active Application Filing
-
2016
- 2016-11-28 US US15/362,188 patent/US20170076281A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8458487B1 (en) * | 2010-03-03 | 2013-06-04 | Liaison Technologies, Inc. | System and methods for format preserving tokenization of sensitive information |
US20130212666A1 (en) * | 2012-02-10 | 2013-08-15 | Ulf Mattsson | Tokenization in mobile environments |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11803846B2 (en) | 2010-08-12 | 2023-10-31 | Visa International Service Association | Securing external systems with account token substitution |
US11847645B2 (en) * | 2010-08-12 | 2023-12-19 | Visa International Service Association | Securing external systems with account token substitution |
US11429749B2 (en) | 2020-07-22 | 2022-08-30 | Mastercard International Incorporated | Systems and methods for tokenization of personally identifiable information (PII) and personal health information (PHI) |
US11615206B2 (en) | 2020-07-22 | 2023-03-28 | Mastercard International Incorporated | Systems and methods for tokenization of personally identifiable information (PII) |
US11835996B2 (en) | 2020-07-22 | 2023-12-05 | Mastercard International Incorporated | Systems and methods for tokenization of personally identifiable information (PII) and personal health information (PHI) |
WO2022093851A1 (en) * | 2020-10-29 | 2022-05-05 | Pacific Investment Management Company LLC | Surrogate data generation of private data |
US11775522B2 (en) | 2020-10-29 | 2023-10-03 | Pacific Investment Management Company LLC | Surrogate data generation of private data |
US20230401181A1 (en) * | 2022-06-10 | 2023-12-14 | Capital One Services, Llc | Data Management Ecosystem for Databases |
Also Published As
Publication number | Publication date |
---|---|
US9558494B2 (en) | 2017-01-31 |
WO2011133494A2 (en) | 2011-10-27 |
WO2011133494A3 (en) | 2012-04-12 |
US20110258123A1 (en) | 2011-10-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9558494B2 (en) | Devices, systems, and methods for tokenizing sensitive information | |
US11416866B2 (en) | Systems and methods for data desensitization | |
CN109919604B (en) | Method and system for consumer initiated transactions using encrypted tokens | |
US8788429B2 (en) | Secure transaction management | |
US10275758B2 (en) | System for secure payment over a wireless communication network | |
US8069121B2 (en) | End-to-end secure payment processes | |
US20050165667A1 (en) | System and method for customer video authentication to prevent identity theft | |
AU2018210544B2 (en) | Method and system for authentication via a trusted execution environment | |
EP3017411A1 (en) | Payment card including user interface for use with payment card acceptance terminal | |
JP6483754B2 (en) | Transaction management system, transaction management method, and program thereof | |
US11868984B2 (en) | Method and system for contactless transmission using off-the-shelf devices | |
US20240005323A1 (en) | Systems and methods for chip-based identity verification and transaction authentication | |
US20220300943A1 (en) | Information processing apparatus, payment processing system, method, and program | |
CN110659890B (en) | Payment method, device, medium and electronic equipment | |
US20020169959A1 (en) | Method and system for assuring security of an IC card | |
US20230385793A1 (en) | Unattended mobile point of sale system | |
KR20210041260A (en) | Re-payment system without card approving process | |
KR20010090381A (en) | User evidence method for commercial transaction using mobile phone having function of scan |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: NOTICE OF APPEAL FILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: TOKENEX, L.L.C., OKLAHOMA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DAWKINS, JERALD;PEZOLD, ALEX;REEL/FRAME:058186/0563 Effective date: 20110412 |
|
AS | Assignment |
Owner name: TOKENEX INC., OKLAHOMA Free format text: NUNC PRO TUNC ASSIGNMENT;ASSIGNOR:TOKENEX LLC;REEL/FRAME:058247/0166 Effective date: 20191220 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:TOKENEX, INC.;REEL/FRAME:063549/0171 Effective date: 20230505 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |