System for data rotation through tokenization

Embodiments rotate data by tokenization. Embodiments determine one or more check data fields of a check such as check number and routing number; generate a PIN based on the determined check data fields; receive user input of a user PIN; compare the generated PIN with the inputted user PIN; if the generated PIN matches the inputted user PIN, proceed with the transaction; and if the generated PIN does not match the inputted user PIN, cancel the transaction. In some cases, a point of sale terminal comprising a scanner for scanning the check to determine the one or more check data fields. In some cases, receiving user input of the user PIN comprises receiving, by a communication device of the system from a mobile device of the user, a text message, SMS message or phone call comprising the user input of a user PIN.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
BACKGROUND

Although credit and debit card payments are on the rise, the expenses and additional record keeping involved with card payments are not ideal for all businesses. Checks are considered a viable option to those businesses that wish to expand customer payment options beyond cash but aren't ready to make the leap to card payments. Typically, a check is a document that orders a payment of money from a financial institution account. However, with the increase in a number of alternative payment options, the number of customers that carry their checkbook with them has decreased considerably. There is a need for a system to integrate mobile technology to generate a check as a payment option.

BRIEF SUMMARY

The following presents a simplified summary of one or more embodiments of the invention in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments, nor delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later.

The embodiments provided herein are directed to systems for A system for data rotation through tokenization, the system comprising a processor and a non-transitory computer-readable memory storing computer-executable instructions, that when executed by the processor, cause the system to determine one or more check data fields of a check such as check number and routing number; generate a PIN based on the determined check data fields; receive user input of a user PIN; compare the generated PIN with the inputted user PIN; if the generated PIN matches the inputted user PIN, proceed with the transaction; and if the generated PIN does not match the inputted user PIN, cancel the transaction.

In some embodiments, the system includes a point of sale terminal comprising a scanner for scanning the check to determine the one or more check data fields. In some embodiments, receiving user input of the user PIN comprises receiving, by a communication device of the system from a mobile device of the user, a text message, SMS message or phone call comprising the user input of a user PIN. In some embodiments, generating a PIN comprises applying a unique hash to the check number and/or the routing number, resulting in a hashed result. In some such embodiments, generating a PIN further comprises comparing the hashed result to a table of hashed results to determine the generated PIN.

In some embodiments, the computer-executable instructions comprise further instructions, that when executed by the processor, cause the system to receive a PIN change request from the user; update a table of PINs with a new PIN based on the PIN change request; and transmit a successful PIN change message to the user.

In some embodiments, the computer-executable instructions comprise further instructions, that when executed by the processor, cause the system to receive user input requesting one or more second user PINs; and update a PIN table to associate the one or more second user PINs with one or more checks, wherein the one or more checks were previously associated with at least one first PIN.

In some embodiments, the system includes a mobile device of the user comprising a digital wallet module stored in a memory, comprising executable instructions that when executed by a processor cause the processor to receive a request, from the user, to perform a transaction with a merchant; generate a virtual check comprising a checking account number, a bank routing number, and a date; and initiate display of the virtual check on a display of the mobile device. In some such embodiments, the digital wallet module stored in a memory, further comprises executable instructions that when executed by a processor cause the processor to receive input from the user corresponding to at least one of a plurality of check fields; and populate the virtual check based on the received input.

According to embodiments of the invention, a computer program product for data rotation through tokenization includes a non-transitory computer-readable medium including code causing a system to determine one or more check data fields of a check such as check number and routing number; generate a PIN based on the determined check data fields; receive user input of a user PIN; compare the generated PIN with the inputted user PIN; if the generated PIN matches the inputted user PIN, proceed with the transaction; and if the generated PIN does not match the inputted user PIN, cancel the transaction.

In some embodiments, a point of sale terminal comprises a scanner for scanning the check to for determining the one or more check data fields. In some embodiments, receiving user input of the user PIN comprises receiving, by a communication device of the system from a mobile device of the user, a text message, SMS message or phone call comprising the user input of a user PIN.

In some embodiments, generating a PIN comprises applying a unique hash to the check number and/or the routing number, resulting in a hashed result. In some such embodiments, generating a PIN further comprises comparing the hashed result to a table of hashed results to determine the generated PIN.

In some embodiments, the computer-executable instructions comprise further code, that when executed by the processor, are configured to cause the system to receive a PIN change request from the user; update a table of PINs with a new PIN based on the PIN change request; and transmit a successful PIN change message to the user.

In some embodiments, the computer-executable instructions comprise further code, that when executed by the processor, cause the system to receive user input requesting one or more second user PINs; and update a PIN table to associate the one or more second user PINs with one or more checks, wherein the one or more checks were previously associated with at least one first PIN.

According to embodiments of the invention, a computer-implemented method for data rotation through tokenization includes determining one or more check data fields of a check such as check number and routing number; generating a PIN based on the determined check data fields; receiving user input of a user PIN; comparing the generated PIN with the inputted user PIN; if the generated PIN matches the inputted user PIN, proceeding with the transaction; and if the generated PIN does not match the inputted user PIN, cancelling the transaction.

In some embodiments, a point of sale terminal comprises a scanner for scanning the check to determine the one or more check data fields.

In some embodiments, receiving user input of the user PIN comprises receiving, by a communication device of the system from a mobile device of the user, a text message, SMS message or phone call comprising the user input of a user PIN.

In some embodiments, generating a PIN comprises applying a unique hash to the check number and/or the routing number, resulting in a hashed result.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The present embodiments are further described in the detailed description which follows in reference to the noted plurality of drawings by way of non-limiting examples of the present embodiments in which like reference numerals represent similar parts throughout the several views of the drawings and wherein:

FIG. 1 is a flowchart illustrating a system and method for generating a check on a mobile device;

FIG. 2 illustrates an exemplary embodiment of a check template in accordance with various embodiments;

FIG. 3 illustrates an exemplary embodiment of an image of the generate virtual check;

FIG. 4 illustrates an exemplary system for generating a check on a mobile device;

FIGS. 5-7 illustrate a number of different ways a user may use one or more tokens to enter into a transaction; and

FIG. 8 is a flowchart illustrating a method for data rotation through tokenization.

 DETAILED DESCRIPTION

The embodiments presented herein are directed to systems, methods, and computer program products for generating a check on a mobile device. Although credit and debit card payments are on the rise, the expenses and additional record keeping involved with card payments are not ideal for all businesses. Checks are considered a viable option to those businesses that wish to expand customer payment options beyond cash but aren't ready to make the leap to card payments. Typically, a check is a document that orders a payment of money from a financial institution account. However, with the increase in a number of alternative payment options, the number of customers that carry their checkbook with them has decreased considerably. Embodiments of the present inventions disclose systems, methods, and computer program product for generating a check on a mobile device.

In accordance with embodiments of the invention, the term “financial transaction” or “transaction” refers to any transaction involving directly or indirectly the movement of monetary funds through traditional paper transaction processing systems (i.e. paper check processing) or through electronic transaction processing systems. Typical financial transactions include point of sale (POS) transactions, automated teller machine (ATM) transactions, internet transactions, electronic funds transfers (EFT) between accounts, transactions with a financial institution teller, personal checks, etc. When discussing that transactions are evaluated it could mean that the transaction has already occurred, is in the processing of occurring or being processed, or it has yet to be processed by one or more financial institutions. In some embodiments of the invention the transaction may be a customer account event, such as but not limited to the customer changing a password, ordering new checks, adding new accounts, opening new accounts, etc.

In accordance with embodiments of the invention, the term “financial institution” refers to any organization in the business of moving, investing, or lending money, dealing in financial instruments, or providing financial services. This includes commercial banks, thrifts, federal and state savings banks, savings and loan associations, credit unions, investment companies, merchants, insurance companies and the like.

In accordance with embodiments of the invention the terms “customer” and “user” and “consumer” may be interchangeable. These terms may relate to a direct customer of the financial institution or person or entity that has authorization to act on behalf of the direct customer, user, or consumer (i.e., indirect customer). In one aspect, the system may be a software application designed to run on a mobile device (e.g., a smartphone, cellular phone, personal digital assistant (PDA)) associated with the user in association with the stored digital mobile wallet. In another aspect, the system may include an interpretation algorithm designed to run on the point-of-sale device associated with the merchant designed to execute transactions using the generated bank card number.

FIG. 1 illustrates a process flow for generating a check on a mobile device 100. As shown in block 102, the process flow includes receiving a request from a user to perform a transaction with a merchant. In response, the process flow includes generating a virtual check comprising a checking account number, a banking account number, and a date, as shown in block 104. In response to generating a virtual check, the process flow includes initiating display of the virtual check on a display of the mobile device, as shown in block 106. The system may then be configured to receive input from the user corresponding to at least one of a plurality of check fields, as shown in block 108. Once the system receives the input from the user, the process flow includes populate the virtual check based on the received input, as shown in block 110.

In some embodiments, the one or more check fields may be pre-filled. In this regard, the system may be configured to initiate the display of the virtual check on the display of the mobile device with one or more pre-filled check fields and receive user input corresponding to the one or more check fields that haven't been pre-filled. For example, the system may be configured to enable the user to set up a recurring check payment such as rent with one or more specific recipients such as a landlord. In such situations, the system may be configured to pre-fill one or more check fields such as payee (e.g., landlord) and transaction amount (e.g., rent amount). The user may then provide input in the signature line to complete the virtual check.

In one aspect, the one or more check fields include at least one of a personalization field including a name field and an address field, date field, a check number, a memo field, and a signature field. In another aspect, the virtual check may include bank identification numbers such as a checking account number, a routing number, a user number, and a check number. This information may be used by a bank to identify the transaction and resolve payment issues.

In some embodiments, the system may be configured to enable the user to receive the virtual check and utilize the virtual check to execute a financial transaction. In this regard, the user may present the virtual check to a merchant at a point-of-sale terminal of the merchant to complete the transaction. In some embodiments, the point-of-sale terminal of the merchant may include one or more applications capable of working synchronously with the virtual check generated on the mobile device. In some other embodiments, the virtual check may be transmitted wirelessly to the point-of-sale terminal of the merchant. In this regard, the system may be configured to enable the merchant to receive the virtual check as a valid payment vehicle and process the received virtual check to complete the transaction. For example, the virtual check may be transmitted using Near Field Communication (NFC), such as by the user “bumping”/“tapping” the send and/or receive the virtual check and/or other information.

In some embodiments, system may be configured to receive a virtual check from another user and present the virtual check to the financial institution. In one aspect, the system may be configured to enable the user to deposit the received virtual check using the mobile device of the user. In another aspect, the system may be configured to enable the user to present the received virtual check to an ATM to deposit the virtual check. In some embodiments, depositing the check may enable the system to receive verification from the source of the virtual check. In this regard, the user associated with generating the virtual check may be contacted to verify the information (e.g., one or more check fields) associated with the check prior to authorizing the check deposit.

In some embodiment, the system may be configured to receive the input from the user corresponding to at least one of a plurality of check fields to generate a virtual check. In response, the system may determine whether the financial institution account associated with the user has sufficient funds prior to generating the virtual check. In this way, the system may reduce the chances of a bounced check. Typically, a check is considered bounced when the check deposited by the payee cannot be processed because the financial institution account associated with the writer of the check has unavailable funds. Typically, the virtual check generated may have the current date in the date field to avoid any discrepancies in the transaction process. In one aspect, the system may be configured to generate a post-dated virtual check for valued and good-standing users for up to a predetermined threshold amount. In another aspect, the system may be configured to generate a post-dated virtual check for users based on the user's credit score.

Referring now to FIG. 2, a check template 200 illustrated. In the illustrated embodiment, the check template 200 corresponds to the entire front portion of a check, but it will be understood that the check template 200 may also correspond to individual pieces of check information, portions of a check, or the like. The check template, in some embodiments, includes the format of certain types of checks associated with a bank, a merchant, an account holder, types of checks, style of checks, check manufacturer, and so forth. By using the check template, the system of process 100 any other system can “learn” to retrieve the key attributes of the check for faster and more accurate processing. In some embodiments, financial records are categorized by template. The check template 200 is only an exemplary template for a financial record, and other check templates or other financial record templates may be utilized to categorize checks or other financial records. The check template 200 can be used in the OCR processes, image overlay techniques, and the like.

The check template 200 comprises check information, wherein the check information includes, for example, a contact information field 205, a payee line field 210, a memo description field 215, an account number and routing number field 220 associated with the appropriate user or customer account, a date line field 225, a check number field 230, an amount box field 235, a signature line field 240, or the like.

Referring now to FIG. 3, an exemplary image of the generated virtual check 300 is illustrated. The image of virtual check 300 may comprise an image of the entire virtual check, a thumbnail version of the image of the virtual check, individual pieces of virtual check information, all or some portion of the front of the virtual check, all or some portion of the back of the virtual check, or the like. Virtual check 300 comprises check information, wherein the check information comprises contact information 205, the payee 210, the memo description 215, the account number and routing number 220 associated with the appropriate user or customer account, the date 225, the check number 230, the amount of the check 235, the signature 240, or the like. In some embodiments, the check information may comprise text. In other embodiments, the check information may comprise an image. The user may utilize the generated virtual check to conduct the financial transaction.

In some embodiments, the system may collect the check information from the image of the generated virtual check 300 and store the check information in a database as metadata (e.g., the database 438 of FIG. 4) for future use. In some embodiments, the pieces of check information may be stored in the database individually. In other embodiments, multiple pieces of check information may be stored in the database together.

Mobile Check Generator

FIG. 4 presents an exemplary block diagram of the system environment 400 for implementing the process flows described herein in accordance with embodiments of the present invention. As illustrated, the system environment 400 includes a network 410, a system 430, and a user input system 440. Also shown in FIG. 4 is a user of the user input system 440. The user input system 440 may be a mobile device or other non-mobile computing device. The user may be a person who uses the user input system 440 to execute a user application 447. The user application 447 may be an application to communicate with the system 430, perform a transaction, input information onto a user interface presented on the user input system 440, or the like. The user application 447 and/or the system application 437 may incorporate one or more parts of any process flow described herein.

As shown in FIG. 4, the system 430, and the user input system 440 are each operatively and selectively connected to the network 410, which may include one or more separate networks. In addition, the network 410 may include a telecommunication network, local area network (LAN), a wide area network (WAN), and/or a global area network (GAN), such as the Internet. It will also be understood that the network 410 may be secure and/or unsecure and may also include wireless and/or wired and/or optical interconnection technology.

The user input system 440 may include any computerized apparatus that can be configured to perform any one or more of the functions of the user input system 440 described and/or contemplated herein. For example, the user may use the user input system 440 to transmit and/or receive information or commands to and from the system 430. In some embodiments, for example, the user input system 440 may include a personal computer system (e.g. a non-mobile or non-portable computing system, or the like), a mobile computing device, a personal digital assistant, a mobile phone, a tablet computing device, a network device, and/or the like. As illustrated in FIG. 4, in accordance with some embodiments of the present invention, the user input system 440 includes a communication interface 442, a processor 444, a memory 444 having an user application 447 stored therein, and a user interface 449. In such embodiments, the communication interface 442 is operatively and selectively connected to the processor 444, which is operatively and selectively connected to the user interface 449 and the memory 444. In some embodiments, the user may use the user application 447 to execute processes described with respect to the process flows described herein. Specifically, the user application 447 executes the process flows described herein.

Each communication interface described herein, including the communication interface 442, generally includes hardware, and, in some instances, software, that enables the user input system 440, to transport, send, receive, and/or otherwise communicate information to and/or from the communication interface of one or more other systems on the network 410. For example, the communication interface 442 of the user input system 440 may include a wireless transceiver, modem, server, electrical connection, and/or other electronic device that operatively connects the user input system 440 to another system such as the system 430. The wireless transceiver may include a radio circuit to enable wireless transmission and reception of information. Additionally, the user input system 440 may include a positioning system. The positioning system (e.g. a global positioning system (GPS), a network address (IP address) positioning system, a positioning system based on the nearest cell tower location, or the like) may enable at least the user input system 440 or an external server or computing device in communication with the user input system 440 to determine the location (e.g. location coordinates) of the user input system 440.

Each processor described herein, including the processor 444, generally includes circuitry for implementing the audio, visual, and/or logic functions of the user input system 440. For example, the processor may include a digital signal processor device, a microprocessor device, and various analog-to-digital converters, digital-to-analog converters, and other support circuits. Control and signal processing functions of the system in which the processor resides may be allocated between these devices according to their respective capabilities. The processor may also include functionality to operate one or more software programs based at least partially on computer-executable program code portions thereof, which may be stored, for example, in a memory device, such as in the user application 447 of the memory 444 of the user input system 440.

Each memory device described herein, including the memory 444 for storing the user application 447 and other information, may include any computer-readable medium. For example, memory may include volatile memory, such as volatile random access memory (RAM) having a cache area for the temporary storage of information. Memory may also include non-volatile memory, which may be embedded and/or may be removable. The non-volatile memory may additionally or alternatively include an EEPROM, flash memory, and/or the like. The memory may store any one or more of pieces of information and data used by the system in which it resides to implement the functions of that system.

As shown in FIG. 4, the memory 444 includes the user application 447. In some embodiments, the user application 447 includes an interface for communicating with, navigating, controlling, configuring, and/or using the user input system 440. In some embodiments, the user application 447 includes computer-executable program code portions for instructing the processor 444 to perform one or more of the functions of the user application 447 described and/or contemplated herein. In some embodiments, the user application 447 may include and/or use one or more network and/or system communication protocols.

Also shown in FIG. 4 is the user interface 449. In some embodiments, the user interface 449 includes one or more output devices, such as a display and/or speaker, for presenting information to the user. In some embodiments, the user interface 449 includes one or more input devices, such as one or more buttons, keys, dials, levers, directional pads, joysticks, accelerometers, controllers, microphones, touchpads, touchscreens, haptic interfaces, microphones, scanners, motion detectors, cameras, and/or the like for receiving information from the user. In some embodiments, the user interface 449 includes the input and display devices of a mobile device, which are operable to receive and display information.

FIG. 4 also illustrates a system 430, in accordance with an embodiment of the present invention. The system 430 may refer to the “apparatus” described herein. The system 430 may include any computerized apparatus that can be configured to perform any one or more of the functions of the system 430 described and/or contemplated herein. In accordance with some embodiments, for example, the system 430 may include a computer network, an engine, a platform, a server, a database system, a front end system, a back end system, a personal computer system, and/or the like. Therefore, the system 430 may be a server managed by the entity. The system 430 may be located at the facility associated with the entity or remotely from the facility associated with the entity. In some embodiments, such as the one illustrated in FIG. 4, the system 430 includes a communication interface 432, a processor 434, and a memory 434, which includes a system application 437 and a structured database 438 stored therein. As shown, the communication interface 432 is operatively and selectively connected to the processor 434, which is operatively and selectively connected to the memory 434.

It will be understood that the system application 437 may be configured to implement any one or more portions of the various user interfaces and/or process flow described herein. The system application 437 may interact with the user application 447. It will also be understood that, in some embodiments, the memory includes other applications. It will also be understood that, in some embodiments, the system application 437 is configured to communicate with the structured database 438, the user input system 440, or the like.

It will be further understood that, in some embodiments, the system application 437 includes computer-executable program code portions for instructing the processor 434 to perform any one or more of the functions of the system application 437 described and/or contemplated herein. In some embodiments, the system application 437 may include and/or use one or more network and/or system communication protocols.

In addition to the system application 437, the memory 434 also includes the structured database 438. As used herein, the structured database 438 may be one or more distinct and/or remote databases. In some embodiments, the structured database 438 is not located within the system and is instead located remotely from the system. In some embodiments, the structured database 438 stores information or data described herein.

It will be understood that the structured database 438 may include any one or more storage devices, including, but not limited to, datastores, databases, and/or any of the other storage devices typically associated with a computer system. It will also be understood that the structured database 438 may store information in any known way, such as, for example, by using one or more computer codes and/or languages, alphanumeric character strings, data sets, figures, tables, charts, links, documents, and/or the like. Further, in some embodiments, the structured database 438 may include information associated with one or more applications, such as, for example, the system application 437. It will also be understood that, in some embodiments, the structured database 438 provides a substantially real-time representation of the information stored therein, so that, for example, when the processor 434 accesses the structured database 438, the information stored therein is current or substantially current.

It will be understood that the embodiment of the system environment illustrated in FIG. 4 is exemplary and that other embodiments may vary. As another example, in some embodiments, the system 430 includes more, less, or different components. As another example, in some embodiments, some or all of the portions of the system environment 400 may be combined into a single portion. Likewise, in some embodiments, some or all of the portions of the system 430 may be separated into two or more distinct portions.

In addition, the various portions of the system environment 400 may be maintained for and/or by the same or separate parties. It will also be understood that the system 430 may include and/or implement any embodiment of the present invention described and/or contemplated herein. For example, in some embodiments, the system 430 is configured to implement any one or more of the embodiments of the process flows described and/or contemplated herein in connection any process flow described herein. Additionally, the system 430 or the user input system 440 is configured to initiate presentation of any of the user interfaces described herein.

In accordance with embodiments of the invention, the term “module” with respect to a system may refer to a hardware component of the system, a software component of the system, or a component of the system that includes both hardware and software. As used herein, a module may include one or more modules, where each module may reside in separate pieces of hardware or software.

In accordance with embodiments of the invention, the term “financial transaction” or “transaction” refers to any transaction involving directly or indirectly the movement of monetary funds through traditional paper transaction processing systems (i.e. paper check processing) or through electronic transaction processing systems. Typical financial transactions include point of sale (POS) transactions, automated teller machine (ATM) transactions, internet transactions, electronic funds transfers (EFT) between accounts, transactions with a financial institution teller, personal checks, etc. When discussing that transactions are evaluated it could mean that the transaction has already occurred, is in the processing of occurring or being processed, or it has yet to be processed by one or more financial institutions. In some embodiments of the invention the transaction may be a customer account event, such as but not limited to the customer changing a password, ordering new checks, adding new accounts, opening new accounts, etc.

Tokenization

In accordance with embodiments of the invention, the term “financial institution” refers to any organization in the business of moving, investing, or lending money, dealing in financial instruments, or providing financial services. This includes commercial banks, thrifts, federal and state savings banks, savings and loan associations, credit unions, investment companies, merchants, insurance companies and the like.

In accordance with embodiments of the invention the terms “customer” and “user” and “consumer” may be interchangeable. These terms may relate to a direct customer of the financial institution or person or entity that has authorization to act on behalf of the direct customer, user, or consumer (i.e., indirect customer).

Various embodiments of the present invention relate to tokenization, which is generally described in the area of financial transactions as utilizing a “token” (e.g., an alias, substitute, surrogate, or other like identifier) as a replacement for sensitive account information, and in particular account numbers. As such, tokens or portions of tokens may be used as a stand in for a user account number, user name, pin number, routing information related to the financial institution associated with the account, security code, or other like information relating to the user account. The one or more tokens may then be utilized as a payment instrument to complete a transaction. The one or more tokens may be associated with one or more payment devices directly or within one or more digital wallets associated with the payment devices. In other embodiments, the tokens may be associated with electronic transactions that are made over the Internet instead of using a physical payment device. Utilizing a token as a payment instrument instead of actual account information, and specifically an account number, improves security, and provides flexibility and convenience in controlling the transactions, controlling accounts used for the transactions, and sharing transactions between various users.

Tokens may be single-use instruments or multi-use instruments depending on the types of controls (e.g., limits) initiated for the token, and the transactions in which the token is used as a payment instrument. Single-use tokens may be utilized once, and thereafter disappear, are replaced, or are erased, while multi-use tokens may be utilized more than once before they disappear, are replaced, or are erased.

Tokens may be 16-digit numbers (e.g., like credit, debit, or other like account numbers), may be numbers that are less than 16-digits, or may contain a combination of numbers, symbols, letters, or the like, and be more than, less than, or equal to 16-characters. In some embodiments, the tokens may have to be 16-characters or less in order to be compatible with the standard processing systems between merchants, acquiring financial institutions (e.g., merchant financial institution), card association networks (e.g., card processing companies), issuing financial institutions (e.g., user financial institution), or the like, which are used to request authorization, and approve or deny transactions entered into between a merchant (e.g., a specific business or individual user) and a user. In other embodiments of the invention, the tokens may be other types of electronic information (e.g., pictures, codes, or the like) that could be used to enter into a transaction instead of, or in addition to, using a string of characters (e.g., numbered character strings, alphanumeric character strings, symbolic character strings, combinations thereof, or the like). In a case where a PIN is tokenized, the tokenized PIN may be four (4) digits, six (6) digits or otherwise.

A user may have one or more digital wallets on the user's payment device. The digital wallets may be associated specifically with the user's financial institution, or in other embodiments may be associated with a specific merchant, group of merchants, or other third parties. The user may associate one or more user accounts (e.g., from the same institution or from multiple institutions) with the one or more digital wallets. In some embodiments, instead of the digital wallet storing the specific account number associated with the user account, the digital wallet may store a token or allow access to a token (e.g., provide a link or information that directs a system to a location of a token), in order to represent the specific account number during a transaction. In other embodiments of the invention, the digital wallet may store some or all of the user account information (e.g., account number, user name, pin number, or the like), including the user account number, but presents the one or more tokens instead of the user account information when entering into a transaction with a merchant. The merchant may be a business, a person that is selling a good or service (hereinafter “product”), or any other institution or individual with which the user is entering into a transaction.

The digital wallet may be utilized in a number of different ways. For example, the digital wallet may be a device digital wallet, a cloud digital wallet, an e-commerce digital wallet, or another type of digital wallet. In the case of a device digital wallet the tokens are actually stored on the payment device. When the device digital wallet is used in a transaction the token stored on the device is used to enter into the transaction with the merchant. With respect to a cloud digital wallet the device does not store the token, but instead the token is stored in the cloud of the provider of the digital wallet (or another third party). When the user enters into a transaction with a merchant, transaction information is collected and provided to the owner of the cloud to determine the token, and thus, how the transaction should be processed. In the case of an e-commerce digital wallet, a transaction is entered into over the Internet and not through a point of sale terminal. As was the case with the cloud digital wallet, when entering into a transaction with the merchant over the Internet the transaction information may be captured and transferred to the wallet provider (e.g., in some embodiments this may be the merchant or another third party that stores the token), and the transaction may be processed accordingly.

Specific tokens, in some embodiments, may be tied to a single user account, but in other embodiments, may be tied to multiple user accounts, as will be described throughout this application. In some embodiments a single tokens could represent multiple accounts, such that when entering into a transaction the user may select the token (or digital wallet associated with the token) and select one of the one or more accounts associated with the token in order to allocate the transaction to a specific account. In still other embodiments, after selection of the token by the user the system may determine the best account associated with the token to use during the transaction (e.g., most cash back, most rewards points, best discount, or the like). In addition, the tokens may be associated with a specific digital wallet or multiple digital wallets as desired by the institutions or users.

Moreover, the tokens themselves, or the user accounts, individual users, digital wallets, or the like associated with the tokens, may have limitations that limit the transactions that the users may enter into using the tokens. The limitations may include, limiting the transactions of the user to a single merchant, a group of multiple merchants, merchant categories, single products, a group a products, product categories, transaction amounts, transaction numbers, geographic locations, or other like limits as is described herein.

FIGS. 5 through 7 illustrate a number of different ways that the user 502, 602, 702 may use one or more tokens in order to enter into a transaction, as well as how the parties associated with the transaction may process the transaction. FIG. 5, illustrates one embodiment of a token system process 501, wherein the token system process 501 is used in association with a tokenization service 550. The tokenization service 550 may be provided by a third-party institution, the user's financial institution, or another institution involved in a transaction payment process. As illustrated in FIG. 5 (as well as in FIGS. 6 and 7), a user 502 may utilize a payment device 504 (or in other embodiments a payment instrument over the Internet) to enter into a transaction. FIG. 5 illustrates the payment device 504 as a mobile device, such as a smartphone, personal digital assistant, or other like mobile payment device. Other types of payment devices 504 may be used to make payments, such as but not limited to an electronic payment card, key fob, a wearable payment device (e.g., watch, glasses, or the like), or other like payment devices 504. As such, when using a payment device 504 the transaction may be made between the point of sale (POS) and the payment device 504 by scanning information from the payment device 504, using near field communication (NFC) between the POS and the payment device 504, using wireless communication between the POS and the payment device 504, or using another other type of communication between the POS and the payment device 504. When entering into an e-commerce transaction over the Internet, for example using the payment device 4 or another device without a POS, a payment instrument (e.g., a payment application that stores the token) may be used to enter into the transaction. The payment instrument may be the same as the token or digital wallet associated with the payment device 504, except they are not associated with specific payment device. For example, the token or digital wallet may be associated with a payment application that can be used regardless the device being used to enter into the transaction over the Internet.

The token can be associated directly with the payment device 504, or otherwise, through one or more digital wallets associated with the payment device 504. For example, the token may be stored on one or more payment devices 504 directly, and as such any transaction entered into by the user 502 with the one or more payment devices 4 may utilize the token. Alternatively, the payment device 4 may have one or more digital wallets stored on the payment device 504 that allow the user 502 to store one or more user account numbers, or tokens associated with the user account numbers, on the one or more digital wallets. The user may select a digital wallet or account within the digital wallet in order to enter into a transaction using a specific type of customer account. As such, the digital wallets may be associated with the user's issuing financial institutions 540, other financial institutions, merchants 510 with which the user enters into transactions, or a third party institutions that facilitates transactions between users 502 and merchants 510.

As illustrated in FIG. 5, a tokenization service 550 may be available for the user 5022 to use during transactions. As such, before entering into a transaction, the user 502 may generate (e.g., create, request, or the like) a token in order to make a payment using the tokenization service 550, and in response the tokenization service 550 provides a token to the user and stores an association between the token and the user account number in a secure token and account database 552. The token may be stored in the user's payment device 504 (e.g., on the digital wallet) or stored on the cloud or other service through the tokenization service 550. The tokenization service 550 may also store limits (e.g., geographic limits, transaction amount limits, merchant limits, product limits, any other limit described herein, or the like) associated with the token that may limit the transactions in which the user 502 may enter. The limits may be placed on the token by the user 502, or another entity (e.g., client, administrator, person, company, or the like) responsible for the transactions entered into by the user 502 using the account associated with the token. The generation of the token may occur at the time of the transaction or well in advance of the transaction, as a one-time use token or multi-use token.

After or during creation of the token the user 502 enters into a transaction with a merchant 510 using the payment device 504 (or payment instrument over the Internet). In some embodiments the user 502 may use the payment device 504 by itself, or specifically select a digital wallet or user account stored within the digital wallet, to use in order to enter into the transaction. The token associated with payment device, digital wallet, or user account within the wallet is presented to the merchant 510 as payment in lieu of the actual user account number and/or other user account information. The merchant 510 receives the token, multiple tokens, and/or additional user account information for the transaction. The merchant 510 may or may not know that the token being presented for the transaction is a substitute for a user account number or other user account information. The merchant also captures transaction information (e.g., merchant, merchant location, transaction amount, product, or the like) related to the transaction in which the user 502 is entering with the merchant 510.

The merchant 510 submits the token (as well as any user account information not substituted by a token) and the transaction information for authorization along the normal processing channels (also described as processing rails), which are normally used to process a transaction made by the user 502 using a user account number. In one embodiment of the invention the acquiring financial institution 520, or any other institution used to process transactions from the merchant 510, receives the token, user account information, and transaction information from the merchant 510. The acquiring financial institution 520 identifies the token as being associated with a particular tokenization service 550 through the token itself or user account information associated with the token. For example, the identification of the tokenization service 550 may be made through a sub-set of characters associated with the token, a routing number associated with the token, other information associated with the token (e.g., tokenization service name), or the like. The acquiring financial institution 520 may communicate with the tokenization service 550 in order to determine the user account number associated with the token. The tokenization service 550 may receive the token and transaction data from the acquiring financial institution 520, and in response, provide the acquiring financial institution 20 the user account number associated with the token as well as other user information that may be needed to complete the transaction (e.g., user name, issuing financial institution routing number, user account number security codes, pin number, or the like). In other embodiments, if limits have been placed on the token, the tokenization service 550 may determine whether or not the transaction information meets the limits and either allows or denies the transaction (e.g., provides the user account number or fails to provide the user account number). The embodiment being described occurs when the token is actually stored on the payment device 504. In other embodiments, for example, when the actual token is stored in a cloud the payment device 504 may only store a link to the token or other token information that allows the merchant 510 or acquiring financial institution to acquire the token from a stored cloud location.

If the acquiring financial institution 520 receives the user account number from the tokenization service 550 (e.g., the tokenization service indicates that the transaction meets the limits), then the acquiring financial institution 520 thereafter sends the user account number, the other user information, and the transaction information directly to the issuing financial institution 540, or otherwise indirectly through the card association networks 530. The issuing financial institution 540 determines if the user 502 has the funds available to enter into the transaction, and if the transaction meets other limits on the user account, and responds with approval or denial of the transaction. The approval runs back through the processing channels until the acquiring financial institution 520 provides approval or denial of the transaction to the merchant 510 and the transaction between the merchant 510 and the user 502 is completed. After the transaction is completed the token may be deleted, erased, or the like if it is a single-use token, or stored for further use if it is a multi-use token.

Instead of the process described above, in which the acquiring financial institution 20 requests the token from the tokenization service 550, in some embodiments the tokenization service 550 may receive the transaction request and transaction information from the merchant 10 or acquiring financial institution 520. Instead of providing the account number to the acquiring financial institution 520, the tokenization service 550 may send the transaction request and transaction information to the issuing financial institution 540 directly, or indirectly through the payment association networks 530.

The embodiment illustrated in FIG. 5 prevents the user account number and other user information from being presented to the merchant 510; however, the tokenization service 550, acquiring financial institution 520, the card association networks 530, and the issuing financial institution 540 may all utilize the actual user account number and other user information to complete the transaction.

FIG. 6 illustrates another embodiment of a token system process 601, in which the user 602 may utilize a payment device 604 (or payment instrument over the Internet) to enter into transactions with merchants 610 utilizing tokens instead of user account numbers. As illustrated in FIG. 6, the user may have one or more tokens, which may be associated with the payment device 604, one or more digital wallets within the payment device 604, or one or more user accounts associated with the digital wallets. The one or more tokens may be stored in the user's payment device 604 (or on the digital wallet), or stored on a cloud or other service through the issuing financial institution 640 or another institution. The user 602 may set up the digital wallet by communicating with the issuing financial institution 640 (e.g., the user's financial institution) to request a token for the payment device, either for the device itself, or for one or more digital wallets or one or more user accounts stored on the payment device. As previously discussed, a wallet may be specifically associated with a particular merchant (e.g., received from the merchant 610) and include one or more tokens provided by the issuing financial institution 640 directly (or through the merchant as described with respect to FIG. 7). In other embodiments, the issuing financial institution 640 may create the digital wallet for the user 602 (e.g., through a wallet created for a business client or retail client associated with the user 602) and include one or more tokens for various types of transactions, products, or the like. The issuing financial institution 640 may store the tokens, the associated user account information (e.g., including the user account number), and any limits on the use of the tokens, as was previously described with respect to the tokenization service 650 in FIG. 5. In one embodiment the tokens may include user account information or routing information within the token or tied to the token, which allows the merchants 610 and other institutions in the payment processing systems to route the token and the transaction information to the proper institutions for processing. In other embodiments a tokenization routing database 632 may be utilized to determine where to route a transaction using a token, as described in further detail later.

The user 602 may enter into a transaction with the merchant 610 using a payment device 604 (or a payment instrument through the Internet). In one embodiment the user 602 may enter into the transaction with a token associated with the payment device 604 itself (or a payment instrument through the Internet). In other embodiments, a specific digital wallet and/or a specific account within the digital wallet may be selected for a particular merchant with whom the user 602 wants to enter into a transaction. For example, the user 602 may select “wallet 1” to enter into a transaction with “merchant 1” and “token 1” to utilize a specific account. The merchant 610 identifies the token, and sends the token and the transaction information to the acquiring financial institution 620. If the token has routing information the acquiring financial institution 620 may route the token and transaction data to the issuing financial institution 640 directly or through the card association networks 630. In situations where the token does not have associated routing information, the acquiring financial institution 620 may utilize a tokenization routing database 632 that stores tokens or groups of tokens and indicates to which issuing financial institutions 640 the tokens should be routed. One or more of the acquiring financial institutions 620, the card association networks 630, and/or the issuing financial institutions 640 may control the tokenization routing database in order to assign and manage routing instructions for tokenization across the payment processing industry. The tokenization routing database 632 may be populated with the tokens and the corresponding issuing financial institutions 640 to which transactions associated with the tokens should be routed. However, in some embodiments no customer account information would be stored in this tokenization routing database 632, only the instructions for routing particular tokens may be stored.

Once the token and transaction details are routed to the issuing financial institution 640, the issuing financial institution 620 determines the user account associated with the token through the use of the token account database 642. The financial institution determines if the funds are available in the user account for the transaction and if the transaction information meets other limits by comparing the transaction information with the limits associated with the token, the user account associated with the token, or other limits described herein. If the transaction meets the limits associated with the token or user account, then the issuing financial institution 620 allows the transaction. If the transaction information does not meet one or more of the limits, then the issuing financial institution 620 denies the transaction. The issuing financial institution sends a notification of the approval or denial of the transaction back along the channels of the transaction processing system to the merchant 610, which either allows or denies the transaction.

The embodiment illustrated in FIG. 6 allows the user and the financial institution to shield the user's account number and other user information from all of the entities in the payment processing system because the merchant 610, acquiring merchant bank 620, payment association networks 630, or other institutions in the payment processing system only use the token and/or other shielded user information to process the transaction. Only the issuing financial institution 640 has the actual account number of the user 602.

FIG. 7 illustrates another embodiment of the token system process 701, in which the user 702 may utilize a payment device 704 (or payment instrument over the Internet) to enter into transactions with a merchant 710 utilizing a token instead of a user account number and/or other user account information. As illustrated in FIG. 7, the user 702 may have one or more tokens associated with the payment device 702, the one or more digital wallets, or one or more user accounts within the digital wallets. The one or more tokens may be stored in the user's payment device 704 (or within the digital wallet), or stored on a cloud or other service through the issuing financial institution 740 or another institution. The user 702 may set up the digital wallet by communicating with the issuing financial institution 740 (e.g., the user's financial institution) and/or the merchant 710 to request a token for the payment device 4, either for the payment device 704 itself, for the one or more digital wallets stored on the payment device 704, or for user accounts within the digital wallet. The financial institution 740 may have a dedicated group of tokens that are associated with a specific merchant, and as such the merchant 710 and the issuing financial institution 740 may communicate with each other to provide one or more tokens to the user 702 that may be specifically associated with the merchant 710. For example, the issuing financial institution may provide a set of tokens to “merchant 1” to associate with “wallet 1” that may be used by one or more users 702. As such “Token 10” may be associated with “wallet 1” and be specified only for use for transactions with “merchant 1.”

The merchant 710 may provide the specific tokens from the financial institution 740 to the user 702, while the financial institution 740 may store the user account information with the token provided to the user 702. The financial institution may communicate directly with the user 702, or through the merchant 710 in some embodiments, in order to associate the token with the user 702. Since the merchant 710 provides, or is at least notified by the financial institution 740, that a specific token, or groups of tokens, are associated with a specific issuing financial institution 740, then the merchant 710 may associate routing information and transaction information with the token when the user 2 enters into a transaction with the merchant 710 using the token.

The merchant 710 passes the token (and potentially other user account information), routing information, and transaction information to the acquiring financial institution 720 using the traditional payment processing channels. The acquiring financial institution 720, in turn, passes the token (and potentially other user account information) and transaction information to the issuing financial institution 740 directly, or indirectly through the payment association networks 730 using the routing information. The issuing financial institution 740 accesses the token and account database 742 to identify the user account associated with the token and determines if the transaction information violates any limits associated with the token or the user account. The issuing financial institution 740 then either approves or denies the transaction and sends the approval or denial notification back through the payment processing system channels to the merchant 710, which then notifies the user 702 that the transaction is allowed or denied.

As is the case with the token system process 601 in FIG. 6, the token system process 701 in FIG. 7 allows the user 702 and the financial institution 740 to shield the user's account number and other user information from all of the entities in the payment processing system because the merchant 710, acquiring merchant bank 720, payment association networks 730, or other institutions in the payment processing system only use the token and/or other shielded user information to process the transaction. Only the issuing financial institution 40 has the actual account number of the user 702.

The embodiments of the invention illustrated in FIGS. 5 through 7 are only example embodiments of the invention, and as such it should be understood that combinations of these embodiments, or other embodiments not specifically described herein may be utilized in order to process transactions between a user 702 and merchant 710 using one or more tokens as a substitute for user account numbers or other user account information, such that the merchant 710, or other institutions in the payment processing system do not have access to the actual user accounts or account information.

As briefly discussed above, if the issuing financial institution 740 creates the digital wallet not only does the issuing financial institution 740 receive transaction information along the normal processing channels, but the financial institution 750 may also receive additional transaction information from the user 702 through the digital wallet using the application program interfaces (APIs) or other applications created for the digital wallet. For example, geographic location information of the user 702, dates and times, product information, merchant information, or any other information may be transmitted to the issuing financial institution 740 through the APIs or other applications to the extent that this information is not already provided through the normal transaction processing channels. This additional transaction information may assist in determining if the transactions meet or violate limits associated with the tokens, user accounts, digital wallets, or the like.

Alternatively, if the merchant 710 or another institution, other than the issuing financial institution 740, provides the digital wallet to the user 702, the issuing financial institution 740 may not receive all the transaction information from the traditional transaction processing channels or from the digital wallet. As such, the issuing financial institution 740 may have to receive additional transaction information from another application associated with the user 702 and compare the transaction information received through the traditional channels in order to associate the additional information with the transaction. In other embodiments, the issuing financial institutions 740 may have partnerships with the merchants 710 or other institutions to receive additional transaction information from the digital wallets provided by the merchants or other institutions when the users 702 enter into transactions using the digital wallets.

Moreover, when there is communication between the digital wallets of the users 702 and the issuing financial institution 40 or another institution, transactions in which the user 702 may enter may be pre-authorized (e.g., pre-qualified) to determine what accounts (e.g., tokens) may be used to complete the transaction, without having to arbitrarily choose an account for the transaction. In the case when there are multiple digital wallets or multiple accounts, the account that is pre-authorized or the account that provides the best rewards may be automatically chosen to complete the transactions.

Additional embodiments of the invention will now be described in further detail in order to provide additional concepts and examples related to how tokens may be utilized in these illustrated token system processes 501, 601, 701 or in other token system processes not specifically described in FIGS. 5 through 7.

Data Rotation Through Tokenization

Embodiments of the invention provide for electronic processing of a physical transaction instrument (such as a check) using an electronic system. The system uses a tokenized PIN to authenticate a check at a point of sale (POS) either utilizing existing POS readers or modified readers configured to enable recognition of a check's number to be read then authenticated with a “rotating” or changing PIN.

In general, checks associated with this invention have no value even if they have a “valid” signature on them, but rather, they are only valuable when a holder (i.e., the signee), can provide a valid PIN associated with the check as well. A user may enter a PIN locally using the POS or a system for accepting debit card PINs. Alternatively, a user may enter a PIN using his or her mobile device via mobile app, text message, SMS message or by phone call during the transaction. Each check may have one or more valid PINs associated with it and/or a group of checks may have a common PIN or PINs that are valid. This system allows for a customer of a financial institution to send a check to someone to use without fear of compromising all their other checks. The PIN may be changed using a mobile device via mobile app, phone call, using online banking or the like.

In some cases, a customer would like to issue additional “second” tokenized PINs. Such second PINs may be helpful in protecting the elderly, dependents, special needs or other client from misuse or stolen checks. Other uses of a second PIN may be for a guardian, power of attorney, government agency (e.g., in the case of a government instrument) or the like.

In some embodiments, a check may be printed utilizing the mobile check generator as described above with reference to FIGS. 1-4. In other cases, a check may be an on-demand use check or standard pre-printed checks may be used in the system.

Referring now to FIG. 8, a method 800 for data rotation by tokenization is illustrated. The first step, represented by block 802, is to determine one or more check data fields such as check number and/or routing number. Other fields may also be used. The next step, represented by block 804, is to generate a PIN based on the determined check data fields. Generation of the PIN may include applying an algorithm such as a hash and/or otherwise to “encode” or tokenize the PIN so that the system will recognize the user inputted PIN. Alternatively, the user inputted PIN may be “decoded” or de-tokenized so that the two PINs may be compared. In yet other embodiments, an algorithm or multiple algorithms are applied to one or both the PINs so that they may be compared accurately. In some embodiments, however, the PIN is not necessarily generated, but rather, the system merely takes one or more pieces of data from the scanned check and looks up the data in a database table to match the data with the corresponding PIN (or a tokenized version of the PIN).

The next step, represented by block 806, is to receive user input of a user PIN. This PIN may be supplied by the user using his or her mobile device, such as by way of a mobile app, text message, phone call, email or otherwise, or may be input into a keypad that is part or separate from the POS.

The next step, represented by block 808, is to compare the generated PIN with the inputted user PIN, and finally, as represented by block 810, the last step is to proceed, in response to determining a match, with the transaction. The comparison of PINs, as noted above may involve conversion of one or more of the PINs into the same format by application of one or more algorithms to the input PIN and/or the generated or retrieved PIN.

In various embodiments, the PINs are constantly, regularly or periodically changed. In other words, the underlying PIN associated with a payment instrument may be the same, but an algorithm for creating a tokenized PIN may regularly result in a different tokenized PIN. For example, the algorithm may calculate a different tokenized PIN every ten (10) seconds when it is applied to the underlying PIN. In some such cases, the user may carry a keyfob that calculates a PIN and/or use a mobile app that calculates a PIN. Furthermore, in some cases, the user must input one or more of a password (that is not dynamic, but may in some cases, be changed manually), a fixed portion of the PIN (that is also not dynamic, but that may in some cases be changed manually), and/or a dynamic or “rotating” PIN that is calculated based on an applied algorithm as noted above.

In various embodiments, the instrument (e.g., check) may include electronics or other components (e.g., magnetic components such as a magnetic strip, RFID or otherwise) that may be read by a POS device or otherwise (similar to the way a credit card or debit card magnetic strip or chip are read) in order to determine the appropriate PIN to be entered in order to complete a transaction using the check. In various embodiments, the check includes a PIN generator that applies the algorithm(s) to generate the PIN so that the POS or other reader receives a PIN that has been dynamically generated, and the user, in order to provide a valid PIN to use the check, must use a keyfob, mobile app or other PIN generator to generate the user inputted PIN that will validate with the check PIN.

More specifically, embodiments rotate data by tokenization. Embodiments determine one or more check data fields of a check such as check number and routing number; generate a PIN based on the determined check data fields; receive user input of a user PIN; compare the generated PIN with the inputted user PIN; if the generated PIN matches the inputted user PIN, proceed with the transaction; and if the generated PIN does not match the inputted user PIN, cancel the transaction. In some cases, a point of sale terminal comprising a scanner for scanning the check to determine the one or more check data fields. In some cases, receiving user input of the user PIN comprises receiving, by a communication device of the system from a mobile device of the user, a text message, SMS message or phone call comprising the user input of a user PIN.

In some cases, generating a PIN comprises applying a unique hash to the check number and/or the routing number, resulting in a hashed result. In some such cases, generating a PIN further comprises comparing the hashed result to a table of hashed results to determine the generated PIN.

In some cases, embodiments also receive a PIN change request from the user; update a table of PINs with a new PIN based on the PIN change request; and transmit a successful PIN change message to the user. In some cases, embodiments receive user input requesting one or more second user PINs; and update a PIN table to associate the one or more second user PINs with one or more checks, wherein the one or more checks were previously associated with at least one first PIN.

In some cases, a mobile device of the user includes a digital wallet module stored in a memory, comprising executable instructions that when executed by a processor cause the processor to receive a request, from the user, to perform a transaction with a merchant; generate a virtual check comprising a checking account number, a bank routing number, and a date; and initiate display of the virtual check on a display of the mobile device. In some such cases, the digital wallet module stored in a memory, further comprises executable instructions that when executed by a processor cause the processor to receive input from the user corresponding to at least one of a plurality of check fields; and populate the virtual check based on the received input.

In various embodiments, a dual- or multiple-PIN authentication is required before a check is authorized for a transaction according to this system. The dual-PIN authentication may require not only a PIN entry from the customer or owner of the account the check is drawing from but also from a person holding the check, for example, an agent of the customer who is attempting to use the check in a transaction where the customer is not present. For example, if the customer gives a check to a family member for use and provides a “secondary” PIN to the family member, when a POS validates the secondary PIN, the system will then communicate with the customer, such as via mobile device app, text message, email, or online banking message, in order to receive and validate the customer's PIN in addition to the secondary PIN. In this regard, three, four or more PINs could be authenticated to continue to build on the level of security provided for a particular check and transaction.

One advantage of this system is that it provides the receiving party with assurances that the check is valid, the money to pay for the check is available and that when the receiving party cashes the check, they will receive the funds owing to them. In other words, this system alleviates the problem where checks are used for a transaction and there is inadequate money in the bank account to be drawn. Of course, this system also minimizes or eliminates check fraud by implementing a system whereby a check is no accepted as a payment instrument unless one or more required PINs are entered and validated.

CONCLUSION

Although many embodiments of the present invention have just been described above, the present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Also, it will be understood that, where possible, any of the advantages, features, functions, devices, and/or operational aspects of any of the embodiments of the present invention described and/or contemplated herein may be included in any of the other embodiments of the present invention described and/or contemplated herein, and/or vice versa. In addition, where possible, any terms expressed in the singular form herein are meant to also include the plural form and/or vice versa, unless explicitly stated otherwise. Accordingly, the terms “a” and/or “an” shall mean “one or more,” even though the phrase “one or more” is also used herein. Like numbers refer to like elements throughout.

As will be appreciated by one of ordinary skill in the art in view of this disclosure, the present invention may include and/or be embodied as an apparatus (including, for example, a system, machine, device, computer program product, and/or the like), as a method (including, for example, a business method, computer-implemented process, and/or the like), or as any combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely business method embodiment, an entirely software embodiment (including firmware, resident software, micro-code, stored procedures in a database, or the like), an entirely hardware embodiment, or an embodiment combining business method, software, and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product that includes a computer-readable storage medium having one or more computer-executable program code portions stored therein. As used herein, a processor, which may include one or more processors, may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more general-purpose circuits perform the function by executing one or more computer-executable program code portions embodied in a computer-readable medium, and/or by having one or more application-specific circuits perform the function.

It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, electromagnetic, infrared, and/or semiconductor system, device, and/or other apparatus. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as, for example, a propagation signal including computer-executable program code portions embodied therein.

One or more computer-executable program code portions for carrying out operations of the present invention may include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, JavaScript, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.

Some embodiments of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of apparatus and/or methods. It will be understood that each block included in the flowchart illustrations and/or block diagrams, and/or combinations of blocks included in the flowchart illustrations and/or block diagrams, may be implemented by one or more computer-executable program code portions. These one or more computer-executable program code portions may be provided to a processor of a general purpose computer, special purpose computer, and/or some other programmable data processing apparatus in order to produce a particular machine, such that the one or more computer-executable program code portions, which execute via the processor of the computer and/or other programmable data processing apparatus, create mechanisms for implementing the steps and/or functions represented by the flowchart(s) and/or block diagram block(s).

The one or more computer-executable program code portions may be stored in a transitory and/or non-transitory computer-readable medium (e.g. a memory) that can direct, instruct, and/or cause a computer and/or other programmable data processing apparatus to function in a particular manner, such that the computer-executable program code portions stored in the computer-readable medium produce an article of manufacture including instruction mechanisms which implement the steps and/or functions specified in the flowchart(s) and/or block diagram block(s).

The one or more computer-executable program code portions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus. In some embodiments, this produces a computer-implemented process such that the one or more computer-executable program code portions which execute on the computer and/or other programmable apparatus provide operational steps to implement the steps specified in the flowchart(s) and/or the functions specified in the block diagram block(s). Alternatively, computer-implemented steps may be combined with, and/or replaced with, operator- and/or human-implemented steps in order to carry out an embodiment of the present invention.

While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations, modifications, and combinations of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.

Claims

1. A system for data rotation through tokenization, the system comprising:

one or more processors; and
one or more non-transitory computer-readable memories;
computer-executable instructions stored within the one or more non-transitory computer-readable memories, that when executed by the one or more processors, cause the system to: determine one or more check data fields, including at least a check account number and a bank routing number; generate a PIN; associate the generated PIN with the one or more check data fields; in response to initiating a transaction with a merchant, generate and display, on a mobile device of a user, a virtual check with the one or more check data fields including at least the check account number and the bank routing number; receive a user PIN; compare the generated PIN with the user PIN; if the generated PIN matches the user PIN, proceed with the transaction; and if the generated PIN does not match the user PIN, cancel the transaction.

2. The system of claim 1, wherein the transaction is initiated at a point of sale terminal comprising a scanner for scanning the virtual check to determine the one or more check data fields.

3. The system of claim 1, wherein receiving the user PIN comprises receiving the user PIN captured from the mobile device of the user, a text message, SMS message or phone call comprising the user PIN.

4. The system of claim 1, wherein generating the PIN comprises applying a unique hash to the check account number and/or the bank routing number, resulting in a hashed result.

5. The system of claim 4, wherein generating the PIN further comprises comparing the hashed result to a table of hashed results to determine the PIN.

6. The system of claim 1, wherein the computer-executable instructions comprise further instructions, that when executed by the one or more processors, cause the system to:

receive a PIN change request from the user;
update a table of PINs with a new PIN based on the PIN change request; and
transmit a successful PIN change message to the user.

7. The system of claim 1, wherein the computer-executable instructions comprise further instructions, that when executed by the one or more processors, cause the system to:

receive user input requesting one or more second user PINs;
update a PIN table to associate the one or more second user PINs with one or more checks, wherein the one or more checks were previously associated with at least one first PIN.

8. The system of claim 1, wherein the mobile device of the user comprises a digital wallet module stored in a memory of the mobile device, and wherein the memory stores the virtual check.

9. The system of claim 8, wherein the digital wallet module stored in the memory, further comprises executable instructions that when executed by a processor of the mobile device cause the processor to:

receive input from the user corresponding to at least one of a plurality of check fields; and
populate the virtual check based on the input received.

10. A computer program product for data rotation through tokenization, the computer program product comprising a non-transitory computer-readable medium comprising code causing one or more processors of a system to:

determine one or more check data fields, including at least a check account number and a bank routing number;
generate a PIN;
associate the generated PIN with the one or more check data fields;
in response to initiating a transaction with a merchant, generate and display, on a mobile device of a user, a virtual check with the one or more check data fields including at least the check account number and the bank routing number;
receive a user PIN;
compare the generated PIN with the user PIN;
if the generated PIN matches the user PIN, proceed with the transaction; and
if the generated PIN does not match the user PIN, cancel the transaction.

11. The computer program product of claim 10, wherein the transaction is initiated at a point of sale terminal comprising a scanner for scanning the virtual check to for determining the one or more check data fields.

12. The computer program product of claim 10, wherein the user PIN comprises receiving the user PIN captured from the mobile device of the user, a text message, SMS message or phone call comprising the user PIN.

13. The computer program product of claim 10, wherein generating the PIN comprises applying a unique hash to the check account number and/or the bank routing number, resulting in a hashed result.

14. The computer program product of claim 13, wherein generating the PIN further comprises comparing the hashed result to a table of hashed results to determine the PIN.

15. The computer program product of claim 10, wherein the computer-readable medium comprises further code, that when executed cause the one or more processors of the system to:

receive a PIN change request from the user;
update a table of PINs with a new PIN based on the PIN change request; and
transmit a successful PIN change message to the user.

16. The computer program product of claim 10, wherein the computer-readable medium comprises further code, that when executed cause the one or more processors of the system to:

receive user input requesting one or more second user PINs;
update a PIN table to associate the one or more second user PINs with one or more checks, wherein the one or more checks were previously associated with at least one first PIN.

17. A computer-implemented method for data rotation through tokenization, the method comprising:

determining, by one or more processors, one or more check data fields, including at least a check account number and a bank routing number;
generating, by the one or more processors, a PIN;
associating, by the one or more processors, the generated PIN with the one or more check data fields;
in response to initiating a transaction with a merchant, generating and displaying, by the one or more processors, on a mobile device of the user, a virtual check with the one or more check data fields including at least the check account number and the bank routing number;
receiving, by the one or more processors, a user PIN;
comparing, by the one or more processors, the generated PIN with the user PIN;
if the generated PIN matches the user PIN, proceeding, by the one or more processors, with the transaction; and
if the generated PIN does not match the user PIN, cancelling, by the one or more processors, the transaction.

18. The method of claim 17, wherein the transaction is initiated at a point of sale terminal comprising a scanner for scanning the virtual check to determine the one or more check data fields.

19. The method of claim 17, wherein receiving the user PIN comprises receiving the user PIN captured from the mobile device of the user, a text message, SMS message or phone call comprising the user PIN.

20. The method of claim 17, wherein generating the PIN comprises applying a unique hash to the check account number and/or the bank routing number, resulting in a hashed result.

Referenced Cited
U.S. Patent Documents
3119103 January 1964 Fertig
3245915 April 1966 Rai et al.
3254000 May 1966 Chibret
3256670 June 1966 Tersigni
3330546 July 1967 Bryan
3422462 January 1969 Finnieston
3516056 June 1970 Matthews
3651168 March 1972 Stoessel et al.
3658393 April 1972 Luthi
3718328 February 1973 Comstock
3748367 July 1973 Lamme et al.
4630201 December 16, 1986 White
4766293 August 23, 1988 Boston
5438186 August 1, 1995 Nair et al.
5589271 December 31, 1996 Watanabe et al.
5770533 June 23, 1998 Franchi
5781654 July 14, 1998 Carney
5884289 March 16, 1999 Anderson et al.
5892900 April 6, 1999 Ginter et al.
5949044 September 7, 1999 Walker et al.
6119103 September 12, 2000 Basch et al.
6236981 May 22, 2001 Hill
6254000 July 3, 2001 Degen et al.
6256670 July 3, 2001 Davies
6330546 December 11, 2001 Gopinathan et al.
6341353 January 22, 2002 Herman et al.
6422462 July 23, 2002 Cohen
6487540 November 26, 2002 Smith et al.
6516056 February 4, 2003 Justice et al.
6536659 March 25, 2003 Hauser et al.
6609654 August 26, 2003 Anderson et al.
6651168 November 18, 2003 Kao et al.
6658393 December 2, 2003 Basch et al.
6718328 April 6, 2004 Norris
6748366 June 8, 2004 Hurwitz et al.
6748367 June 8, 2004 Lee
6748533 June 8, 2004 Wu et al.
6913194 July 5, 2005 Suzuki
6999943 February 14, 2006 Johnson et al.
7031945 April 18, 2006 Donner
7058806 June 6, 2006 Smeets et al.
7082406 July 25, 2006 Dickson
7103576 September 5, 2006 Mann, III et al.
7111323 September 19, 2006 Bhatia et al.
7114079 September 26, 2006 Cook et al.
7136835 November 14, 2006 Flitcroft et al.
7177838 February 13, 2007 Ling
7328189 February 5, 2008 Ling
7337144 February 26, 2008 Blinn et al.
7398250 July 8, 2008 Blinn et al.
7406434 July 29, 2008 Chang et al.
7487912 February 10, 2009 Seifert et al.
7596516 September 29, 2009 Starkowsky et al.
7596530 September 29, 2009 Glasberg
7606560 October 20, 2009 Labrou et al.
7610040 October 27, 2009 Cantini et al.
7627505 December 1, 2009 Yoshida et al.
7657489 February 2, 2010 Stambaugh
7676432 March 9, 2010 Ling
7693771 April 6, 2010 Zimmerman et al.
7698221 April 13, 2010 Blinn et al.
7698443 April 13, 2010 Yaffe et al.
7716091 May 11, 2010 Ross
7739169 June 15, 2010 Hammad
7742967 June 22, 2010 Keresman, III et al.
7783281 August 24, 2010 Cook et al.
7784684 August 31, 2010 Labrou et al.
7810720 October 12, 2010 Lovett
7835960 November 16, 2010 Breck et al.
7848980 December 7, 2010 Carlson
7857489 December 28, 2010 Zhu et al.
7877288 January 25, 2011 Cunningham et al.
7883007 February 8, 2011 Crews et al.
7907926 March 15, 2011 Rofougaran
7929910 April 19, 2011 Chen
7937107 May 3, 2011 Rofougaran et al.
7946480 May 24, 2011 Miller et al.
7962419 June 14, 2011 Gupta et al.
7992779 August 9, 2011 Phillips et al.
8012219 September 6, 2011 Mendez et al.
8031207 October 4, 2011 Phillips
8032414 October 4, 2011 Payne et al.
8032932 October 4, 2011 Speyer et al.
8060413 November 15, 2011 Castell et al.
8104674 January 31, 2012 Smith et al.
8171531 May 1, 2012 Buer
8200582 June 12, 2012 Zhu
8238825 August 7, 2012 Rofougaran et al.
8245915 August 21, 2012 Ramachandran et al.
8249500 August 21, 2012 Wilson
8249805 August 21, 2012 de Silva et al.
8272562 September 25, 2012 Ziegler
8307413 November 6, 2012 Smadja et al.
8311895 November 13, 2012 Murugan et al.
8327428 December 4, 2012 Bailey et al.
8327429 December 4, 2012 Speyer et al.
8332329 December 11, 2012 Thiele
8346666 January 1, 2013 Lindelsee et al.
8380177 February 19, 2013 Laracey
8395242 March 12, 2013 Oliver et al.
8407142 March 26, 2013 Griggs
8418917 April 16, 2013 Lewis et al.
8422462 April 16, 2013 Kobayashi
8423466 April 16, 2013 Lanc
8459560 June 11, 2013 Mineo-Goggin
8474700 July 2, 2013 Lewis et al.
8494958 July 23, 2013 Schoenberg et al.
8498940 July 30, 2013 Pelegero et al.
8516056 August 20, 2013 Allen, Jr. et al.
8522039 August 27, 2013 Hyndman et al.
8538591 September 17, 2013 Klughart
8540142 September 24, 2013 Lewis et al.
8551186 October 8, 2013 Strand
8572689 October 29, 2013 Radhakrishnan
8577804 November 5, 2013 Bacastow
8583498 November 12, 2013 Fried et al.
8584251 November 12, 2013 McGuire et al.
8589266 November 19, 2013 Liu et al.
8589271 November 19, 2013 Evans
8590008 November 19, 2013 Ellmore
8595812 November 26, 2013 Bomar et al.
8600883 December 3, 2013 Wong
8612351 December 17, 2013 Liu et al.
8620790 December 31, 2013 Priebatsch
8631089 January 14, 2014 Pereira et al.
8658393 February 25, 2014 Reik et al.
8682802 March 25, 2014 Kannanari
8683571 March 25, 2014 Zapata et al.
8694366 April 8, 2014 Barnes, Jr.
8714445 May 6, 2014 Katz et al.
8768838 July 1, 2014 Hoffman
8788333 July 22, 2014 Alba et al.
8788429 July 22, 2014 Tieken
8789162 July 22, 2014 Radhakrishnan
8839383 September 16, 2014 Van Horn
8850575 September 30, 2014 Magi Shaashua et al.
8930271 January 6, 2015 Ellis et al.
8943574 January 27, 2015 Bailey et al.
8973102 March 3, 2015 Jakobsson
8985442 March 24, 2015 Zhou et al.
8996423 March 31, 2015 Johnson et al.
9002750 April 7, 2015 Chu et al.
9055053 June 9, 2015 Radhakrishnan et al.
9069943 June 30, 2015 Radhakrishnan et al.
9171296 October 27, 2015 Kurian
9195984 November 24, 2015 Spector et al.
9412106 August 9, 2016 Laracey
9640001 May 2, 2017 Vazquez et al.
20010029483 October 11, 2001 Schultz et al.
20010029485 October 11, 2001 Brody et al.
20010034720 October 25, 2001 Armes
20010054111 December 20, 2001 Lee et al.
20020032612 March 14, 2002 Williams et al.
20020032662 March 14, 2002 Maclin et al.
20020046341 April 18, 2002 Kazaks et al.
20020056756 May 16, 2002 Cameron et al.
20020072379 June 13, 2002 Chen et al.
20020096570 July 25, 2002 Wong et al.
20020111907 August 15, 2002 Ling
20020129255 September 12, 2002 Tsuchiyama et al.
20020152179 October 17, 2002 Racov
20020157029 October 24, 2002 French et al.
20020174073 November 21, 2002 Nordman et al.
20020186845 December 12, 2002 Dutta et al.
20030004866 January 2, 2003 Huennekens et al.
20030009355 January 9, 2003 Gupta
20030045328 March 6, 2003 Natsuno
20030055733 March 20, 2003 Marshall et al.
20030061170 March 27, 2003 Uzo
20030105714 June 5, 2003 Alarcon-Luther et al.
20030163787 August 28, 2003 Hay et al.
20030177090 September 18, 2003 Eden
20030225625 December 4, 2003 Chew et al.
20040030645 February 12, 2004 Monaghan
20040098308 May 20, 2004 Okano
20040153410 August 5, 2004 Nootebos
20040254868 December 16, 2004 Kirkland et al.
20050049977 March 3, 2005 Suisa
20050080730 April 14, 2005 Sorrentino
20050131820 June 16, 2005 Rodriguez et al.
20050131834 June 16, 2005 Rodriguez
20050154670 July 14, 2005 Heitz et al.
20050165651 July 28, 2005 Mohan
20050171849 August 4, 2005 Brissette
20050222961 October 6, 2005 Staib et al.
20050240498 October 27, 2005 Thaler
20050246234 November 3, 2005 Munyon
20050246275 November 3, 2005 Nelson
20050283621 December 22, 2005 Sato et al.
20060036868 February 16, 2006 Cicchitto
20060089893 April 27, 2006 Joseph et al.
20060095369 May 4, 2006 Hofi
20060161501 July 20, 2006 Waserstein
20060163345 July 27, 2006 Myers et al.
20060206709 September 14, 2006 Labrou et al.
20060218577 September 28, 2006 Goodman et al.
20060237531 October 26, 2006 Heffez et al.
20060259390 November 16, 2006 Rosenberger
20060287004 December 21, 2006 Fuqua
20070055594 March 8, 2007 Rivest et al.
20070073585 March 29, 2007 Apple et al.
20070073685 March 29, 2007 Thibodeau
20070083465 April 12, 2007 Ciurea et al.
20070100773 May 3, 2007 Wallach
20070106611 May 10, 2007 Larsen
20070118747 May 24, 2007 Pintsov
20070130315 June 7, 2007 Friend et al.
20070130463 June 7, 2007 Law
20070156517 July 5, 2007 Kaplan et al.
20070156842 July 5, 2007 Vermeulen et al.
20070162337 July 12, 2007 Hawkins et al.
20070174082 July 26, 2007 Singh
20070175977 August 2, 2007 Bauer et al.
20070192245 August 16, 2007 Fisher et al.
20070194884 August 23, 2007 Didier et al.
20070198921 August 23, 2007 Collison et al.
20070203835 August 30, 2007 Cai
20070219984 September 20, 2007 Aravamudan et al.
20070220597 September 20, 2007 Ishida
20070223706 September 27, 2007 Gantman et al.
20070239473 October 11, 2007 Picolli
20070250920 October 25, 2007 Lindsay
20070265984 November 15, 2007 Santhana
20070276764 November 29, 2007 Mann, III et al.
20070293192 December 20, 2007 De Groot
20080010193 January 10, 2008 Rackley, III et al.
20080021772 January 24, 2008 Aloni et al.
20080040274 February 14, 2008 Uzo
20080040276 February 14, 2008 Hammad et al.
20080073422 March 27, 2008 Zhou
20080109319 May 8, 2008 Foss
20080141117 June 12, 2008 King et al.
20080162338 July 3, 2008 Samuels et al.
20080162589 July 3, 2008 Rodeheffer et al.
20080167965 July 10, 2008 Von Nothaus et al.
20080189169 August 7, 2008 Turpin et al.
20080189210 August 7, 2008 Sawhney
20080195499 August 14, 2008 Meredith et al.
20080195517 August 14, 2008 Minerley
20080195536 August 14, 2008 Karns et al.
20080197192 August 21, 2008 Lindahl et al.
20080217397 September 11, 2008 Degliantoni et al.
20080275748 November 6, 2008 John
20080281722 November 13, 2008 Balasubramanian et al.
20080288396 November 20, 2008 Siggers et al.
20080293397 November 27, 2008 Gajdos et al.
20080296368 December 4, 2008 Newsom
20080301057 December 4, 2008 Oren
20080307515 December 11, 2008 Drokov et al.
20080308628 December 18, 2008 Payne et al.
20080313087 December 18, 2008 Joseph et al.
20080319889 December 25, 2008 Hammad
20090006230 January 1, 2009 Lyda et al.
20090012898 January 8, 2009 Sharma et al.
20090019534 January 15, 2009 Bakshi et al.
20090048953 February 19, 2009 Hazel et al.
20090057396 March 5, 2009 Barbour et al.
20090063353 March 5, 2009 Viidu et al.
20090070219 March 12, 2009 D'Angelo et al.
20090100529 April 16, 2009 Livnat et al.
20090119190 May 7, 2009 Realini
20090121012 May 14, 2009 Beemer et al.
20090150286 June 11, 2009 Barton
20090164327 June 25, 2009 Bishop et al.
20090187508 July 23, 2009 Placide
20090192900 July 30, 2009 Collison et al.
20090201149 August 13, 2009 Kaji
20090222353 September 3, 2009 Guest et al.
20090254440 October 8, 2009 Pharris
20090261158 October 22, 2009 Lawson
20090271265 October 29, 2009 Lay et al.
20090281904 November 12, 2009 Pharris
20090289764 November 26, 2009 Chiu
20090307132 December 10, 2009 Phillips
20090313109 December 17, 2009 Bous et al.
20090319352 December 24, 2009 Boyle et al.
20090327308 December 31, 2009 Carter et al.
20090328186 December 31, 2009 Pollutro et al.
20100010918 January 14, 2010 Hunt
20100023449 January 28, 2010 Skowronek et al.
20100023455 January 28, 2010 Dispensa et al.
20100036741 February 11, 2010 Cleven
20100042517 February 18, 2010 Paintin et al.
20100051686 March 4, 2010 Obi
20100064345 March 11, 2010 Bentley et al.
20100070376 March 18, 2010 Proud et al.
20100076833 March 25, 2010 Nelsen
20100078762 April 1, 2010 Wang
20100082481 April 1, 2010 Lin et al.
20100091763 April 15, 2010 Thompson
20100121767 May 13, 2010 Coulter et al.
20100122333 May 13, 2010 Noe
20100125509 May 20, 2010 Kranzley et al.
20100133334 June 3, 2010 Vadhri
20100138344 June 3, 2010 Wong et al.
20100138347 June 3, 2010 Chen
20100145854 June 10, 2010 Messerges et al.
20100217670 August 26, 2010 Reis et al.
20100228614 September 9, 2010 Zhang et al.
20100235283 September 16, 2010 Gerson
20100235882 September 16, 2010 Moore
20100241571 September 23, 2010 McDonald
20100257099 October 7, 2010 Bonalle et al.
20100262830 October 14, 2010 Kusakawa et al.
20100268645 October 21, 2010 Martino et al.
20100274610 October 28, 2010 Andersen et al.
20100312636 December 9, 2010 Coulter et al.
20110015980 January 20, 2011 Li
20110022483 January 27, 2011 Hammad
20110040684 February 17, 2011 Beck et al.
20110047075 February 24, 2011 Fourez
20110055008 March 3, 2011 Feuerstein et al.
20110060653 March 10, 2011 King et al.
20110078004 March 31, 2011 Swanson, Sr.
20110099104 April 28, 2011 Nybom
20110103586 May 5, 2011 Nobre
20110106631 May 5, 2011 Lieberman et al.
20110108622 May 12, 2011 Das et al.
20110113064 May 12, 2011 Govindachetty et al.
20110119156 May 19, 2011 Hwang et al.
20110131089 June 2, 2011 Walker et al.
20110131128 June 2, 2011 Vaananen
20110137470 June 9, 2011 Surnilla et al.
20110137742 June 9, 2011 Parikh
20110137797 June 9, 2011 Stals et al.
20110137804 June 9, 2011 Peterson
20110143663 June 16, 2011 Renard et al.
20110153437 June 23, 2011 Archer et al.
20110153441 June 23, 2011 Smith et al.
20110161150 June 30, 2011 Steffens et al.
20110166922 July 7, 2011 Fuerstenberg
20110166931 July 7, 2011 Joa et al.
20110166992 July 7, 2011 Dessert et al.
20110168781 July 14, 2011 Akesson
20110173055 July 14, 2011 Ross et al.
20110178889 July 21, 2011 Abraham et al.
20110184790 July 28, 2011 Brar et al.
20110184855 July 28, 2011 Webber et al.
20110191149 August 4, 2011 Blackhurst et al.
20110191161 August 4, 2011 Dai
20110191173 August 4, 2011 Blackhurst et al.
20110196790 August 11, 2011 Milne
20110202462 August 18, 2011 Keenan
20110213665 September 1, 2011 Joa et al.
20110213700 September 1, 2011 Sant'anselmo
20110218884 September 8, 2011 Kothari et al.
20110218907 September 8, 2011 Dessert et al.
20110231268 September 22, 2011 Ungos
20110231305 September 22, 2011 Winters
20110246279 October 6, 2011 Joa et al.
20110246306 October 6, 2011 Blackhurst et al.
20110251892 October 13, 2011 Laracey
20110251965 October 13, 2011 Holm et al.
20110258031 October 20, 2011 Valin et al.
20110270749 November 3, 2011 Bennett et al.
20110276410 November 10, 2011 Hjelm et al.
20110277016 November 10, 2011 Hockings et al.
20110282729 November 17, 2011 Gnanasambandam et al.
20110282733 November 17, 2011 Gnanasambandam et al.
20110288998 November 24, 2011 McGraw et al.
20110302089 December 8, 2011 McKenzie
20120012651 January 19, 2012 Kenna, III et al.
20120016731 January 19, 2012 Smith et al.
20120018506 January 26, 2012 Hammad et al.
20120022944 January 26, 2012 Volpi
20120023022 January 26, 2012 Carroll et al.
20120023567 January 26, 2012 Hammad
20120028609 February 2, 2012 Hruska
20120030032 February 2, 2012 Zurada
20120030047 February 2, 2012 Fuentes et al.
20120030109 February 2, 2012 Dooley Maley et al.
20120030110 February 2, 2012 Prakash et al.
20120035997 February 9, 2012 Burgess et al.
20120036205 February 9, 2012 Cole
20120047022 February 23, 2012 Shamim et al.
20120054046 March 1, 2012 Albisu
20120054057 March 1, 2012 O'Connell et al.
20120055983 March 8, 2012 Wellborn et al.
20120066064 March 15, 2012 Yoder et al.
20120078751 March 29, 2012 MacPhail et al.
20120078762 March 29, 2012 Valin et al.
20120078782 March 29, 2012 Schoenberg et al.
20120080517 April 5, 2012 Braunstein
20120084162 April 5, 2012 Smith et al.
20120085829 April 12, 2012 Ziegler
20120089471 April 12, 2012 Comparelli
20120096499 April 19, 2012 Dasher et al.
20120111934 May 10, 2012 Herzig
20120116956 May 10, 2012 Altman et al.
20120123857 May 17, 2012 Surve et al.
20120130788 May 24, 2012 Winslade et al.
20120150728 June 14, 2012 Isaacson et al.
20120150747 June 14, 2012 Carey
20120158540 June 21, 2012 Ganti et al.
20120158584 June 21, 2012 Von Behren et al.
20120158586 June 21, 2012 Ganti et al.
20120160911 June 28, 2012 Smith et al.
20120160912 June 28, 2012 Laracey
20120166261 June 28, 2012 Velusamy et al.
20120166298 June 28, 2012 Smith et al.
20120166334 June 28, 2012 Kimberg et al.
20120171237 July 5, 2012 Ching et al.
20120173431 July 5, 2012 Ritchie et al.
20120179558 July 12, 2012 Fischer
20120185317 July 19, 2012 Wong
20120185354 July 19, 2012 Crucs
20120191522 July 26, 2012 McLaughlin et al.
20120191597 July 26, 2012 Capel et al.
20120191606 July 26, 2012 Milne
20120197743 August 2, 2012 Grigg et al.
20120197794 August 2, 2012 Grigg et al.
20120197797 August 2, 2012 Grigg et al.
20120200386 August 9, 2012 Robshaw et al.
20120203700 August 9, 2012 Ornce et al.
20120203707 August 9, 2012 Hungerford et al.
20120209630 August 16, 2012 Ihm et al.
20120209749 August 16, 2012 Hammad et al.
20120209773 August 16, 2012 Ranganathan
20120209775 August 16, 2012 Milne
20120209842 August 16, 2012 Bettridge et al.
20120214571 August 23, 2012 Oakes et al.
20120215610 August 23, 2012 Amaro et al.
20120221421 August 30, 2012 Hammad
20120222055 August 30, 2012 Schaefer et al.
20120230577 September 13, 2012 Calman et al.
20120232981 September 13, 2012 Torossian et al.
20120239417 September 20, 2012 Pourfallah et al.
20120252365 October 4, 2012 Lam
20120253852 October 4, 2012 Pourfallah et al.
20120253905 October 4, 2012 Darragh
20120253913 October 4, 2012 Richard
20120253917 October 4, 2012 Cho et al.
20120253958 October 4, 2012 Sock et al.
20120253974 October 4, 2012 Haikonen et al.
20120254941 October 4, 2012 Levien et al.
20120258660 October 11, 2012 Rajendran et al.
20120258776 October 11, 2012 Lord et al.
20120260318 October 11, 2012 Fromentoux et al.
20120265623 October 18, 2012 Zhu et al.
20120265679 October 18, 2012 Calman et al.
20120265688 October 18, 2012 Dinan
20120265689 October 18, 2012 Routhenstein et al.
20120265694 October 18, 2012 Tuchman et al.
20120265819 October 18, 2012 McGann et al.
20120267432 October 25, 2012 Kuttuva
20120271712 October 25, 2012 Katzin et al.
20120278201 November 1, 2012 Milne
20120278242 November 1, 2012 Griffith
20120284127 November 8, 2012 Heiser, II et al.
20120284130 November 8, 2012 Lewis et al.
20120290482 November 15, 2012 Atef et al.
20120303425 November 29, 2012 Katzin et al.
20120303528 November 29, 2012 Weiner et al.
20120316963 December 13, 2012 Moshfeghi
20120316992 December 13, 2012 Oborne
20120317034 December 13, 2012 Guha et al.
20120323783 December 20, 2012 Canetto
20120330846 December 27, 2012 Light et al.
20130006736 January 3, 2013 Bethke et al.
20130006756 January 3, 2013 Heo
20130006776 January 3, 2013 Miller et al.
20130013499 January 10, 2013 Kalgi
20130018706 January 17, 2013 Bortolin et al.
20130018738 January 17, 2013 Faires et al.
20130018791 January 17, 2013 Mendicino et al.
20130024360 January 24, 2013 Ballout
20130024379 January 24, 2013 Di Tucci et al.
20130031623 January 31, 2013 Sanders
20130032634 February 7, 2013 McKirdy
20130036000 February 7, 2013 Giordano et al.
20130036048 February 7, 2013 Campos et al.
20130036050 February 7, 2013 Giordano et al.
20130041811 February 14, 2013 Vazquez et al.
20130045760 February 21, 2013 Obermeyer et al.
20130046645 February 21, 2013 Grigg et al.
20130048714 February 28, 2013 Sharma et al.
20130048724 February 28, 2013 Burnside et al.
20130054336 February 28, 2013 Graylin
20130054470 February 28, 2013 Campos et al.
20130057897 March 7, 2013 Park et al.
20130060689 March 7, 2013 Oskolkov et al.
20130060708 March 7, 2013 Oskolkov et al.
20130073365 March 21, 2013 McCarthy
20130073546 March 21, 2013 Yan et al.
20130079037 March 28, 2013 Dobyns
20130085927 April 4, 2013 Scott
20130096996 April 18, 2013 Tabor et al.
20130097031 April 18, 2013 Royyuru et al.
20130097034 April 18, 2013 Royyuru et al.
20130097683 April 18, 2013 Davis et al.
20130109412 May 2, 2013 Nguyen et al.
20130110607 May 2, 2013 Basmajian et al.
20130110658 May 2, 2013 Lyman et al.
20130117170 May 9, 2013 Coppinger
20130124346 May 16, 2013 Baldwin et al.
20130124396 May 16, 2013 Loff
20130124855 May 16, 2013 Varadarajan et al.
20130143600 June 6, 2013 Jan et al.
20130150139 June 13, 2013 Oakes
20130159178 June 20, 2013 Colon et al.
20130159186 June 20, 2013 Brudnicki et al.
20130166332 June 27, 2013 Hammad
20130166384 June 27, 2013 Das
20130179254 July 11, 2013 Joa et al.
20130179341 July 11, 2013 Boudreau
20130179954 July 11, 2013 Bidare
20130191227 July 25, 2013 Pasa et al.
20130202185 August 8, 2013 Irwin, Jr. et al.
20130204775 August 8, 2013 Midkiff et al.
20130204787 August 8, 2013 Dubois
20130212007 August 15, 2013 Mattsson et al.
20130212019 August 15, 2013 Mattsson et al.
20130226799 August 29, 2013 Raj
20130238503 September 12, 2013 Patel
20130246147 September 19, 2013 Chen et al.
20130246171 September 19, 2013 Carapelli
20130246258 September 19, 2013 Dessert
20130246260 September 19, 2013 Barten et al.
20130254052 September 26, 2013 Royyuru et al.
20130254115 September 26, 2013 Pasa et al.
20130256403 October 3, 2013 Keith
20130262198 October 3, 2013 Chung
20130262315 October 3, 2013 Hruska
20130267224 October 10, 2013 Krishnaswamy et al.
20130268437 October 10, 2013 Desai et al.
20130282577 October 24, 2013 Milne
20130290101 October 31, 2013 Arini et al.
20130304637 November 14, 2013 McCabe et al.
20130304651 November 14, 2013 Smith
20130311365 November 21, 2013 Miller et al.
20130318627 November 28, 2013 Lundkvist et al.
20130324166 December 5, 2013 Mian et al.
20130339122 December 19, 2013 Truitt et al.
20130339165 December 19, 2013 Calman
20130346171 December 26, 2013 Wright
20130346302 December 26, 2013 Purves et al.
20140006273 January 2, 2014 Gopinath et al.
20140012647 January 9, 2014 Hecht
20140019352 January 16, 2014 Shrivastava
20140019358 January 16, 2014 Priebatsch
20140025581 January 23, 2014 Calman
20140025958 January 23, 2014 Calman
20140040001 February 6, 2014 Harvey et al.
20140048595 February 20, 2014 Grigg et al.
20140058946 February 27, 2014 Paranjape
20140067661 March 6, 2014 Elischer
20140067678 March 6, 2014 Lee et al.
20140095383 April 3, 2014 Rao
20140118719 May 1, 2014 Frogget et al.
20140122331 May 1, 2014 Vaish et al.
20140129357 May 8, 2014 Goodwin
20140130127 May 8, 2014 Toole et al.
20140136323 May 15, 2014 Zhang et al.
20140136405 May 15, 2014 DuCharme et al.
20140143089 May 22, 2014 Campos et al.
20140143145 May 22, 2014 Kortina
20140156535 June 5, 2014 Jabbour et al.
20140164243 June 12, 2014 Aabye et al.
20140172707 June 19, 2014 Kuntagod et al.
20140187147 July 3, 2014 Rochberger et al.
20140187148 July 3, 2014 Taite et al.
20140188719 July 3, 2014 Poomachandran et al.
20140208401 July 24, 2014 Balakrishnan et al.
20140214640 July 31, 2014 Mallikarjunan et al.
20140231527 August 21, 2014 Anderson et al.
20140244493 August 28, 2014 Kenyon et al.
20140244503 August 28, 2014 Sadlier
20140244510 August 28, 2014 de Beasley
20140245391 August 28, 2014 Adenuga
20140250009 September 4, 2014 Carlson
20140258157 September 11, 2014 Pridmore et al.
20140279476 September 18, 2014 Hua
20140279494 September 18, 2014 Wiesman et al.
20140279554 September 18, 2014 Priebatsch et al.
20140279566 September 18, 2014 Verma et al.
20140279688 September 18, 2014 Ginsberg et al.
20140310764 October 16, 2014 Tippett et al.
20140315159 October 23, 2014 Mukherjee et al.
20140324690 October 30, 2014 Allen et al.
20140330721 November 6, 2014 Wang
20140337175 November 13, 2014 Katzin et al.
20140344153 November 20, 2014 Raj et al.
20140351125 November 27, 2014 Miller et al.
20140359709 December 4, 2014 Nassar et al.
20140365334 December 11, 2014 Hurewitz
20150019317 January 15, 2015 Mitchell
20150019439 January 15, 2015 Phillips
20150032621 January 29, 2015 Kar et al.
20150032625 January 29, 2015 Dill et al.
20150032627 January 29, 2015 Dill et al.
20150039601 February 5, 2015 Harrang et al.
20150081557 March 19, 2015 Kinfoil et al.
20150081567 March 19, 2015 Boyle et al.
20150088740 March 26, 2015 Doyle et al.
20150100495 April 9, 2015 Salama et al.
20150100788 April 9, 2015 Chastain et al.
20150106275 April 16, 2015 Wolfs et al.
20150120569 April 30, 2015 Belshe et al.
20150120572 April 30, 2015 Slade
20150161610 June 11, 2015 Sahadevan et al.
20150170149 June 18, 2015 Sharma et al.
20150199679 July 16, 2015 Palanisamy et al.
20150206131 July 23, 2015 Phillips et al.
20150206137 July 23, 2015 Mazarim Fernandes
20150220914 August 6, 2015 Purves et al.
20150254648 September 10, 2015 Clements et al.
20150254650 September 10, 2015 Bondesen et al.
20150254653 September 10, 2015 Bondesen et al.
20150254664 September 10, 2015 Bondesen et al.
20150269542 September 24, 2015 Katz et al.
20150278814 October 1, 2015 Jaffe
20160117660 April 28, 2016 Prakash et al.
20160210652 July 21, 2016 Boyle et al.
20160224977 August 4, 2016 Sabba
Foreign Patent Documents
101599151 December 2009 CN
1132876 September 2001 EP
2008225832 September 2008 JP
9907121 February 1999 WO
03007221 January 2003 WO
2012058099 May 2012 WO
2013095486 June 2013 WO
Other references
  • Simon, “Credit-Card Reward Programs: A Short History”; Credi; Creditcards.com, Nov. 2006, 4 pages.
  • Lane, “History of APIs”; APIE; APIEvangelist.com; Dec. 2012, 11 pages.
  • ‘Digital Wallet’ to pay for travel hasn't arrived yet, Orlando Sentinel [Orlando, Fla], Jan. 27, 2013; p. J.6.
  • Business Wire, “World's First and Only Global Mobile Wallet Sees Strong User Adoption with 150 Million Miles Loaded to Cash in First Month of Launch”, Nov. 28, 2012, Zurich.
Patent History
Patent number: 10268635
Type: Grant
Filed: Jun 17, 2016
Date of Patent: Apr 23, 2019
Patent Publication Number: 20180181938
Assignee: BANK OF AMERICA CORPORATION (Charlotte, NC)
Inventor: Manu Jacob Kurian (Dallas, TX)
Primary Examiner: Olusegun Goyea
Application Number: 15/186,079
Classifications
Current U.S. Class: Reading Bank Checks (e.g., Documents Bearing E-13b Type Characters) (382/137)
International Classification: G06F 16/22 (20190101); G06Q 20/04 (20120101); G06Q 20/32 (20120101); G06F 17/30 (20060101); G06F 16/23 (20190101); G06Q 20/38 (20120101); G06Q 20/40 (20120101);