SYSTEMS AND METHODS FOR ADDING FUNCTIONALITY TO A UIS FOR USE AT A POINT OF INTERACTION
Systems and methods for the addition of functionality to a user identification string (UIS) at a point of interaction (POI) are provided. A UIS is first requested from the user at a POI. According to some embodiments, the user enters a modified UIS (MUIS) at the POI. The MUIS can include a UIS along with a user code. An authorization request is then created by the POI device, wherein the request can include information such as, but not limited to, a vehicle code, the MUIS, POI location identifier, function deduction amounts, and/or the like. An action (e.g. rounding sweep, linking a function to the user operation vehicle, etc.) associated with the user code, if present, is determined and implemented. An approval or denial of the authorization request is then sent to the POI device after the action has been applied and the request has been processed.
This application claims the benefit of U.S. Provisional Application No. 61/147,011, filed on Jan. 23, 2009 and U.S. Provisional Application No. 61/151,480, filed on Feb. 10, 2009, both of which are hereby incorporated by reference in their entirety for all purposes.
This application is also related to the United States patent application entitled “Systems and Methods for User Identification String Generation for Selection of a Function,” with application Ser. No. ______ (Attorney Docket Number: 79964-368732), filed on the same day as the present application, which is hereby incorporated by reference in its entirety for all purposes.
COPYRIGHT NOTICEContained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright© 2009 HSBC Private Label Corporation
TECHNICAL FIELDSome embodiments of the present invention generally relate to multi-function user operation vehicles. More specifically, some embodiments of the present invention relate to systems and methods for adding functionality to a user identification string (UIS) for use at a point of interaction (POI).
BACKGROUNDThere are a variety of payment functions currently in common use. Examples include credit, debit, and prepaid. Historically, one payment function or account was associated with each card or device. Consequently, when a consumer desired to purchase an item using a particular account, the consumer was required to present the appropriate payment device to the POI system. For example, when a consumer is buying groceries with a debit card, the user would have to present the debit card. Similarly, when the consumer is shopping at a department store with a credit card, the consumer would have to present the credit card. In addition, many point of sale devices require, before completion of the transaction, the input of a user identification string that is used to identify the user and indicates that he or she is authorized to purchase items using the payment device.
Traditional infrastructure typically requires that any coupons, rewards, credits, or benefits to be entered or scanned by the cashier. As such, there are a number of challenges and inefficiencies created by traditional infrastructure for processing payments with rewards. For example, transactions with rewards through point of sale (PoS) systems require on-site processing systems.
SUMMARYSystems and methods are described for adding functionality to a user identification string (UIS) used with a user operation vehicle at a point of interaction. In some embodiments of the present invention, reward actions (or other actions) can be initiated by entering additional input characters (hereinafter, “user code”) in conjunction with the user entering a UIS at a point of interaction device. The point of interaction device creates an authorization request with information related to the details of the deduction request and the input string entered by the user. According to some embodiments, the authorization request includes a modified user identification string (MUIS) entered by the user at the point of interaction device. In some embodiments, the MUIS contains at least a user identification string (UIS) and a user code (e.g., a reward code, account activation code, and/or other codes). The authorization request, including the MUIS, can contain other information such as, but not limited to, time of purchase, purchase amount, merchant identification codes, payment function selector, and the like.
In some embodiments, the authorization request for the completion of a purchase at a point of interaction device is then transferred to a processing system. The MUIS can be identified and parsed into the UIS and the user code (e.g., a reward code, a function indicator, and/or an account activation code) entered by the user at the point of interaction device. The user can then be validated (e.g., by a verifier). In some embodiments, the verifier validates the user by comparing a user operation vehicle UIS stored in a UIS database with the UIS received in the authorization request. A user code processing system (user code processor) can be used, in accordance with some embodiments, to determine one or more actions associated with the user code. Once the one or more actions are determined, the user code processing system can implement the one or more actions before routing the authorization request to one or more function processors for payment authorization. Some examples of actions associated with the user codes include, but are not limited to, percentage discounts, crediting reward points, account activation, linking accounts to the user operation vehicle, and others.
While multiple embodiments are disclosed, still other embodiments of the present invention will become apparent to those skilled in the art from the following detailed description, which shows and describes illustrative embodiments of the invention. As will be realized, the invention is capable of modifications in various aspects, all without departing from the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not restrictive.
Embodiments of the present invention will be described and explained through the use of the accompanying drawings in which:
The drawings have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be expanded or reduced to help improve the understanding of the embodiments of the present invention. Similarly, some components and/or operations may be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments of the present invention. Moreover, while the invention is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the invention to the particular embodiments described. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.
DETAILED DESCRIPTIONSome embodiments of the present invention generally relate to multi-function user operation vehicles. More specifically, some embodiments of the present invention relate to systems and methods for the generation of user identification strings used with multi-function operation vehicles and to the addition of functionality to a user identification string for use at a point of interaction (POI) (e.g., a point of sale, computer-based interface such as a webpage, computer integrated system, telephone payment system, or others).
Various systems and methods are described for generating multiple user identification strings (UIS) for use with a multi-function user operation vehicle. In some embodiments, a user operation vehicle activation system monitors for a set UIS request or a change UIS request. When a request to set or change the UIS is detected, an interface portal is generated that allows a user to enter a new base UIS. The interface portal can be designed to allow for entry of any string of alphanumeric characters that meet preset parameters. For example, in some embodiments, the preset parameters could require the base UIS entered by the user to be a four digit numerical code (e.g., 2319). According to some embodiments, the UIS portal can be a webpage, a Java™ application, a downloadable computer program, and/or the like. Once a base UIS is received, the base UIS can be encrypted and transferred to a UIS generation system which can be part of the user activation system in some embodiments.
After the encrypted UIS is received at the user operation vehicle activation system, the encrypted UIS is decrypted and a determination can be made about which accounts and promotions are to be linked to the user operation vehicle. Various methods can be used for determining the accounts to be linked to the user operation vehicle. For example, in some embodiments, the determination can be made by searching an account database for accounts that can be linked with the received user operation vehicle identification information. Every account found can be linked automatically or a user can select which accounts should be linked through an account user interface screen that is displayed.
In some embodiments of the present invention, the account user interface screen is displayed through the interface portal and includes a list of the accounts found in the account database that can be linked with the user operation vehicle. In some embodiments, the screen allows for the user to enter additional account information (e.g., from other financial institutions) for accounts that were not found in the account database and that the user desires to be linked to the user operation vehicle.
Once the determination or selection is made about which accounts are to be linked to the user operation vehicle, the results are transferred to a UIS generation module where an account-specific UIS is generated for each account linked to the user operation. In accordance with some embodiments of the present invention, the account-specific UIS generated for each account is unique and can be generated in a variety of ways (e.g., by appending one or more additional numbers or characters to the first UIS for each account linked to the user operation vehicle). As a simple example, suppose a user entered a base UIS of 4719 for a user operation vehicle with an associated credit function, debit function, and accumulated value function. The UIS generation module could generate an account-specific UIS of 47191 for the credit function, 47192 for the debit function, and 47193 for the accumulated value function.
One advantage of some embodiments of the present invention is that a user does not have to enter more than one UIS because the system automatically creates a unique UIS for each linked account. Then, according to some embodiments, these account-specific UIS's can be used at a POI (e.g., PoS) device during a transaction (e.g., a purchase) to request which payment function(s) and/or account(s) associated with the user operation vehicle should be used.
Some embodiments of the present invention provide for systems and methods that add functionality to a user identification string for use at a POI. Accordingly, in those embodiments, a user can append a user code of additional characters (e.g., numbers, letters, special characters, and the like), to the end of the UIS at a POI device to create a modified user identification string. In some embodiments, these additional characters only include numbers. Whether the additional characters in the user code are just numbers or include some combination of numbers, letters, and/or special characters, the additional characters can be used to add functionality to the UIS at a POI. For example, in some embodiments, the additional characters could be a reward code.
The POI device takes the available information and creates a string of characters referred to as a transaction request that includes various pieces of information about the transaction such as, but not limited to, a user operation vehicle identifier or vehicle code (e.g., a primary account number), a user identification string (UIS), a function indicator, a reward code, merchant code, payment amount (function deduction amount), and/or the like. The string of characters is then transmitted to a verification network in accordance with some embodiments of the present invention. In some embodiments, the string of characters is then parsed into various tokens (e.g., pieces of information such as the user operation vehicle identifier, the UIS, the function selector, and/or the reward code) for processing.
According to some embodiments, the user can be validated using one or more of the various tokens. For example, the validation in some embodiments of the present invention can occur by comparing a UIS stored in a UIS database that is associated with the primary account number with the UIS received in the string of characters. Similarly, a determination of a reward action associated with the reward code can be made. The determination of the reward action can occur in a number of different ways according to various embodiments of the present invention. For example, in some embodiments, the reward determination can be performed by looking up the reward code in a reward code database. As another example, the reward determination can be performed by deciphering the reward code into various tokens that correspond to various reward elements and/or payment types. In some embodiments of the present invention a reward code processing system (reward code processor) can be used to determine one or more reward actions and validate and/or authorize the reward code.
In some embodiments, once the reward code is determined and applied, a payment request (function deduction request) can then be sent for processing. In some embodiments, the payment processing (function deduction processing) occurs through a function indicated by a function indicator included in the string of characters. For example, the payment processing can occur through a rewards processing system, a debit processing system, a credit processing system, a prepaid processing system, and/or the like.
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. It will be apparent, however, to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details.
Some embodiments of the present invention may be provided as a computer program product which may include a machine-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, compact disc read-only memories (CD-ROMs), and magneto-optical disks, ROMs, random access memories (RAMs), erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, embodiments of the present invention may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
While, for convenience, embodiments of the present invention are described with reference to user operation vehicles and UIS, embodiments of the present invention are equally applicable to various other areas where processing orders, rewards, selection of payment options, and selection of service options (e.g., purchase of insurance) may be beneficial. As just one example, instead of generating multiple user identification strings, the system could be used to generate multiple card security codes (i.e., the three or four digit number on the back of a payment device). As such, the security codes could be used for payment function selection.
For the sake of illustration, various embodiments of the present invention have herein been described in the context of computer programs, physical components, and logical interactions within modern computer networks. Importantly, while these embodiments describe various aspects of the invention in relation to modern computer networks and programs, the method and apparatus described herein are equally applicable to other systems, devices, and networks as one skilled in the art will appreciate. As such, the illustrated applications of the embodiments of the present invention are not meant to be limiting, but instead exemplary. Other systems, devices, and networks to which embodiments of the present invention are applicable include, but are not limited to, other types of systems and processing devices.
TERMINOLOGYBrief definitions of terms, abbreviations, and phrases used throughout this application are given below.
An “accumulated value function” generally describes a payment function that enables a merchant and/or other third party system to track and/or reward specific consumer purchases and/or purchase behavior. For example, rewards can be generated when a product or item is purchased within a certain category code such as merchant, merchant category, product category, etc. The rewards generated by the consumer purchases and/or purchase behavior allow the consumer to spend the accrued reward amounts at a POI. In some embodiments, the accumulated value function may receive rewards from one or more systems and apply the rewards to an account associated with the accumulated value function. According to some embodiments, the accrued reward can be, for example, a point-type system or cash equivalent that can be used by the consumer at the POI through the use of the accumulated value function.
The terms “connected” or “coupled” and related terms are used in an operational sense and are not necessarily limited to a direct physical connection or coupling. Thus, for example, two devices may be coupled directly, or via one or more intermediary media, modules, or devices. As another example, devices may be coupled in such a way that information can be passed therebetween, while not sharing any physical connection with one another. Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways in which connection or coupling exists in accordance with the aforementioned definition.
The phrase “in communication with” generally refers to direct and indirect communications for the exchange of information between two or more devices, modules, applications, systems, components, or the like. For example, two devices may be in communication with each other in such a way that information or access to the devices can be passed therebetween, while not sharing any direct physical connection.
The phrases “in some embodiments,” “according to some embodiments,” “in the embodiments shown,” “in other embodiments,” and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present invention, and may be included in more than one embodiment of the present invention. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments.
If the specification states a component or feature “may”, “can”, “could”, or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.
The term “module” refers broadly to software, hardware, or firmware (or any combination thereof) components. Modules are typically functional components that can generate useful data or other output using specified input(s). A module may or may not be self-contained. An application program (also called an “application”) may include one or more modules, or a module can include one or more application programs.
The phrase “user operation vehicle” generally refers to any device, biometric identifier, or method for conveying information that may be used to conduct a transaction. Examples of user operation vehicles include, but are not limited to, a plastic card with a magnetic strip, a smart card storing information in onboard memory, a card containing only an identifier and linked with a remote database, a card with radio frequency identification (RFID) technology, a fingerprint, a retina pattern, a voice pattern, or any other physical feature that is distinguishable between individuals. In some embodiments, a user operation vehicle could also be any other information such as a memorized code without a corresponding card or device to store or transfer that code.
General DescriptionThe user operation vehicle in some embodiments of the present invention includes a user operation vehicle identifier (vehicle code) that is used to identify the user operation vehicle and can be used to determine which functions are associated and/or linked to the user operation vehicle. One example of a user operation vehicle identifier is a primary account number. In some embodiments, the user operation vehicle identifiers can be the user operation vehicle itself or separate additional identifiers. Examples include, but are not limited to RFID signatures, a fingerprint of an authorized user, a retina pattern of an authorized user, a voice pattern of an authorized user, and physical identifiers.
A user operation vehicle may be issued to a user after opening one or more accounts with a financial institution or merchant and requesting a user operation vehicle to link multiple open accounts that are with one or more financial institutions, merchants, insurance carriers, employers, etc. For example, in some embodiments, a user may be issued a user operation vehicle after applying for and being granted a loan. The user operation vehicle would be linked automatically to the loan amount, allowing the user to access the funds through the user operation vehicle. As another example, a gift card ordering service may be used to associate a prepaid gift card with the user operation vehicle.
The user operation vehicle may or may not be activated initially. In addition, the user operation vehicle may or may not be initially associated and/or initially linked with any payment functions. To activate the user operation vehicle, associate payment functions, and/or link payment functions, user 105 can use an activation portal 110. The user can be directed to activation portal 110 through informational communications such as flyers, e-mails, telephone calls, or other communications that tell the user how to access the activation port 110. According to some embodiments, the informational communications can contain webpage addresses, telephone numbers, e-mail addresses, postal addresses, and the like that can be used for activating the user operation vehicle.
In accordance with some embodiments, activation portal 110 provides an interface through network 115 to activation system 120 to activate the user operation vehicles. Activation portal 110 can be any type of interface that facilitates the exchange of information required by activation system 120 for user operation vehicle activation. In some embodiments, activation portal 110 can be, but is not limited to, a telephone, a computer, a computer program, a webpage, a Java™ application, and/or the like. Examples of the types of information used for user operation vehicle activation in some embodiments of the present invention include items such as user identification information, UIS entry and/or selection, entry and/or selection of accounts to be linked to the user operation vehicle, and/or other information as will be appreciated by those of ordinary skill in the art.
Once the requested information is collected from the user through activation portal 110, the information is transferred across network 115 to activation system 120. Network 115 can be any group of interconnected devices capable of exchanging information. In some embodiments, network 115 may be as few as several personal computers on a Local Area Network (LAN) or as large as the Internet. Network 115 may also be a Voice over Internet Protocol (VoIP) network or a Voice Response Unit (VRU) according to some embodiments of the present invention. In some cases, network 115 may be comprised of multiple networks (private and/or public), even multiple heterogeneous networks, such as one or more border networks, voice networks, broadband networks, service provider networks, Internet Service Provider (ISP) networks, and/or Public Switched Telephone Networks (PSTNs), interconnected via gateways operable to facilitate communications between and among the various networks.
Activation system 120 can include, or be in communication with, various components such as a user verification system, a UIS generation system, a payment verification system, an account verification system, various databases for storing generated UIS, and/or the like. According to some embodiments, a user verification system can be used to verify user credentials or identification information (e.g., user name and password, voice authentication, calling from a known phone number, etc.) before access is allowed to activation system 120. Once access is granted, activation system 120 can use a UIS generation system to generate a UIS for each linked account, an account verification system to verify which accounts can be linked to the user operation vehicle, and/or a payment verification system with various databases to store generated UIS and account information. In addition, in some embodiments, a linkage generator can be used to link accounts/functions to the user operation vehicle. In accordance with some embodiments, the UIS can be any string of alphanumeric characters including, but not limited to, numbers, letters, special characters, etc. that can be used to identify and/or authorize the user of a user operation vehicle. For example, the UIS can be a personal identification number (PIN). In some embodiments, the UIS may indicate which function is being used to complete the transaction, a reward to be used, or other feature.
According to some embodiments, activation system 120 monitors for a set UIS request or a change UIS request from user 105. The set or change request can come through activation portal 110 via network 115. When a request to set or change the UIS is detected in some embodiments, an activation portal response is generated that allows a user to enter a new base UIS or choose a system selected UIS. The activation portal response can be designed to allow for entry of any string of alphanumeric characters that meet preset parameters. For example, in some embodiments, the activation portal response includes the display of a webpage where the preset parameters are set so that the base UIS entered by the user should be a four digit numerical code (e.g., 2319).
Once a base UIS is received from a user via activation portal 110, the base UIS can then be encrypted by an encryption/decryption module (encryptor or decryptor) associated with activation portal 110. In some embodiments, the encrypted UIS is transferred to account verification system 220 where a determination can be made as to which accounts can be associated and/or linked to the user operation vehicle. Examples of the types of accounts that can be associated and/or linked to the user operation vehicle include, but are not limited to, credit accounts, debit accounts, prepaid accounts, accumulated value accounts, store value accounts, consumer-to-consumer payment accounts, reward accounts, and/or other types of accounts.
In some embodiments, verification system 220 can identify origination information (e.g., IP address, user token, etc.). The origination information identified by verification system 220 can be used in some embodiments for tracking marketing penetration by channel (e.g., webpage, web address, phone calls, etc.).
In some cases, verification system 220 causes an account user interface screen to be displayed through the activation portal 110. In other embodiments, the account user interface screen is part of set UIS interface/applet 210. In either case, the account user interface screen is capable of receiving information from the user about one or more accounts the user desires to be associated with the user operation vehicle. In some cases, one or more sets of account information can be automatically populated from information the user supplied on an application or with information about other accounts that are already available. Examples of the types of information that can be requested from the user include, but are not limited to, account numbers, first name, last name, e-mail address, user operation vehicle identification number (if applicable), birthdays, government identification (e.g., driver's license, social security number, etc.), mother's maiden name, billing addresses, answers to security questions, user IDs, passwords and/or the like.
Once the desired account information is received, the information can be transferred to verification module (verifier) 220 where the account information entered by the user can be verified. If the account passes the verification process, then the account information is transferred to UIS generation module 240 where UIS generation module 250 generates an account (i.e., account-specific) UIS for each verified account or for a subset of the verified accounts. As one example, UIS generation module 250 can generate the account-specific UIS by appending one or more additional numbers after the base UIS entered by the user. The account-specific UIS for each verified account can then be stored in UIS database 230 for verification during transaction processing (e.g., processing an authorization request). In some embodiments, between five and twenty account-specific UIS's can be generated. In other embodiments, fewer than five or more than twenty account-specific UIS's can be generated.
Some embodiments provide for the generation of a completion screen for display through activation portal 110 once the account-specific UIS generation is completed. The completion screen can provide an indication to the user that the automatic generation of the account-specific UIS for each account (or payment function) linked to the user operation vehicle is complete. In some embodiments, the completion screen can display a list of the account-specific UIS's generated for each account. The completion screen, in some embodiments, can include a graphical user interface that allows the user to associate an account-specific UIS for one account with another account.
In some embodiments, the account or the account-specific UIS generated for each account can be associated with signature default and/or a set order of precedence to be used for transactions received from the POI. For example, if the user uses the multifunction user operation vehicle without entering a UIS for the selection of a particular function (e.g., a signature-based authorization), then the user can select which of the multiple accounts (e.g., the second credit account) will automatically or implicitly be used. The user may continue to assign a prioritization to each account (or a default sequence of account use) in the event an account with a higher priority has insufficient funds or is otherwise not able to complete the transaction individually (e.g., a maximum transaction amount has been reached).
In some embodiments, the user may also assign an individual transaction limit below a system threshold for one or more user operation vehicle functions. For example, suppose the user set an order of precedence in the following order: accumulated value, debit, and then line of credit. Further suppose that the user had a current accrued value of twenty three dollars, a system threshold debit limit of three hundred dollars, and a system threshold credit limit of five hundred dollars. The user may decide to set a limit (e.g., one hundred fifty dollar limit) for the debit line in the event that the accumulated value function has insufficient accrued value. Now, suppose the user makes a two hundred fifty dollar transaction. Twenty three dollars will be charged to the accumulated value function, one hundred and fifty to the debit function, and then the final seventy seven dollars to the credit function. As another example, instead of making a two hundred fifty dollar transaction, suppose the user made a forty dollar transaction. Then, twenty three dollars will be charged to the accumulated value function, seventeen dollars to the debit function, and nothing to the credit function.
As a further example of the generation, viewing and prioritization of account-specific UIS's, suppose a user entered a base UIS of 3892. An account-specific UIS could then be created as 38921 for a first debit function, 389212 for a second debit function, 38922 for a credit function, 38923 for a first store value function, and 389232 for a second store value function. In some embodiments, no payment function is implicit and no initial priority is associated with the payment functions. In some embodiments, an initial prioritization and implicit payment function (e.g., for signature based authorization) will be automatically assigned based on a set of assignment rules.
The user could then view the account-specific UIS assigned to each account along with the account prioritization information on the completion screen. If desired, the user could then reassociate the account-specific UIS for the credit function (i.e., 38922) with the first account to be implicitly used during a transaction and the first debit account account-specific UIS (i.e., 38921) with the next functional account to be used for a transaction requiring access to multiple accounts in order to fully complete the transaction. Similarly, for example, the user may reassociate the second debit function UIS (i.e., 389212) with the first debit function and the second store value function UIS with the first store value account, and thus change the order of account access precedence.
In some embodiments, the graphical user interface can allow the user to associate the account-specific UIS generated for one account with another account without changing the set order of precedence of account usage during a transaction. Similarly, some embodiments allow the user to change the set order of precedence to be used for transactions received from the POI without changing the account-specific UIS associated with the accounts.
The user, in some embodiments of the present invention, may select and setup one or more special features using the graphical user interface. For example, in addition to setting a base UIS, activating the user operation vehicle, setting account order precedence, setting individual transaction limits and the like, some embodiments allow for a rounding sweep. The rounding sweep allows the user to round the transaction up to a nearest amount (e.g., nearest fifty cents, whole dollar, five dollar, etc.) and have the difference between the transaction amount and the rounded amount applied to another function (e.g., accumulated value, savings account, credit account etc.). In accordance with various embodiments, the user can select the nearest amount and the destination account where the difference should be placed.
In some embodiments of the present invention, the account activation process occurs through one or more user interface screens displayed through activation portal 110. For example, a first user interface screen can be displayed on a terminal in response to a request to activate a user operation vehicle received through the activation portal 110. The first user interface screen is generally capable of receiving one or more accounts to be associated and/or linked to a user operation vehicle and is operable to send a linking request to a user operation vehicle activation system 120.
In response to the linking request, a second user interface screen can be displayed on the terminal in accordance with various embodiments of the present invention. In these embodiments, the second user interface screen is able to display the linking and/or activation status for each of the one or more accounts received on the first user interface screen. For example, in some embodiments, a label, symbol, phrase, or other indicator can be presented to the user conveying that an account is currently not linked to the user operation vehicle, linked to the user operation vehicle, or a linking request is being processed.
A request for the user to enter a base UIS to be associated with the user operation vehicle can be made through a third user interface screen displayed on the terminal. The third user interface screen can, for example, transmit the base UIS entered by the user to the UIS generation system 240 to generate the second UIS for each successfully linked account. In response to a communication from the user operation vehicle activation system 120, a fourth user interface screen can be presented which displays the second UIS for each of the one or more accounts successfully linked.
In accordance with some embodiments of the present invention, any number of different types of information can be requested from the user using account user interface screen 300. Account user interface screen 300, as illustrated, requests a user input a user operation vehicle identification number in entry box 305, loyalty number on the user operation vehicle in entry box 310, the user's first and last names in entry boxes 315 and 320, respectively, user's data of birth in entry box 325, and a current e-mail address in entry box 330. In some embodiments, the type of information requested on account user interface screen 300 may depend on the current function of the interface screen (e.g., account activation vs. account maintenance). Examples of other types of information that can be requested, include, but are not limited to, current user billing address, bank information (e.g., addresses, telephone numbers, routing numbers, etc.) for the account desired to be linked, personal identification numbers for the account desired to be linked, account numbers for the account desired to be linked, mother's maiden name, answers to security questions, user ID's, passwords, and/or the like.
According to some embodiments of the present invention, once the user hits the submit button (355 or 375) in either create UIS screen 340 or change UIS screen 360, the new base UIS can be transmitted to the UIS generation system 240 where an account-specific UIS is created for each account linked to the user operation vehicle.
As previously described, some embodiments of the present invention use an activation portal to activate a user operation vehicle that can be associated with one or more functions (e.g., credit function, debit function, accumulated value function, consumer to consumer function, reward function, store value function, and others). In particular, some embodiments of the present invention use a Java™ applet for user operation vehicle activation. UIS creation is an example of one task that can be provided during user operation vehicle activation. In some embodiments, Java™ applets are used to provide maximum security and encryption to the customer's base UIS that was entered through the activation portal. For example, in some embodiments, the applets used for account-specific UIS creation ensure that the customer's base UIS is not in clear text anywhere in the system including SSL communications between web servers and application servers.
While Java™ applets address many of the security concerns associated with activating a user operation vehicle and with generating multiple account-specific UIS's, some embodiments can use alternative systems and methods for securely activating the user operation vehicle. Some embodiments of the present invention take advantage of the RSA encryption algorithm for customer UIS encryption before transmitting the base UIS to a UIS generation system. In particular, the RSA algorithm used in some embodiments may be part of Java™ 5 and the applet classes may be complied with Java™ 5. However, if the customer's browser has any version of Java™ lower than version 5, the UIS creation page may not be displayed as desired. Hence, the customer may seek an alternative solution to the Java™ applet or download a higher version of Java™
In addition, Java™ applets are not compatible with all browsers (e.g., MAC or Safari). Moreover, in some embodiments, the applets are client side applications that are downloaded to a client browser. In some cases, the applet may be prevented from loading in the customer's browser. For example, if the applet is trying to run in a client network that restricts any outgoing connections for applets or if the security is set to a maximum level in the client browser. For these situations and others, some embodiments of the present invention provide systems and methods for automatically generating multiple account-specific UIS's in the event of an activation applet failure.
When a customer is activating a user operation vehicle in some embodiments of the present invention, the activation process can direct the customer to a UIS creation applet (e.g.,
-
- Enter Your Information
- Please enter a four-digit user identification string (UIS) in the required fields below. Your UIS can be used in lieu of a signature to authorize purchases made with your user operation vehicle and should only be known by you. Please create a UIS that is not easy for anyone else to guess and do not write or share your selected UIS with anyone. We will never ask for your UIS for any reason.
- If you are not able to create and verify your new UIS below, please review the Java™ requirements information at the bottom of this page. If you are still unable to create your UIS, or if you would like us to generate a UIS for you please click here to have our system assign your UIS.
In some embodiments, the system selected base UIS may be the last four digits of a number associated with the user (e.g., the user's social security number). The web page can have a statement indicating the selection of the base UIS (e.g., ‘Last 4 digits of your SSN have been selected as your initial, or base, UIS for the user operation vehicle. Please click confirm to continue.’). One advantage of automatically selecting the base UIS from a number associated with the user is that the UIS can be conveyed to the user without actually displaying the UIS on a webpage or other mechanism as illustrated in
According to some embodiments, the system selected base UIS selection can be randomly chosen from one or more pieces of information provided by the user. In some embodiments, a UIS single sign on (SSO) message passed from activation portal to UIS generation system contains a number of numeric fields (e.g., birthday field 325 in
For example, in some embodiments, the UIS SSO message may contain one or more of the following: social security number (SSN), main zip code, home phone number, mobile phone number, work phone number, ABA number, demand deposit account (DDA) number, birth date, street address, user name, etc. Some embodiments of the present invention may have some, all, or none of these fields along with other possible fields. Some fields may be conditional based on inputs from the user, previously entered information, attempts to link new accounts, etc.
Examples of mandatory fields in some embodiments include, but are not limited to, one or more of the following: main ZIP and home phone (M). Examples of optional fields in some embodiments include, but are not limited to, the following: work phone and mobile phone. Examples of conditional fields in some embodiments include, but are not limited to, one or more of the following: SSN, ABA, DDA, and birth date. In some embodiments, all of the fields listed above may be mandatory or optional. Still yet in some embodiments, some of the examples in one type of field may be in another field type (e.g., main ZIP may be optional, conditional, or mandatory in some embodiments).
To produce an account-specific UIS from a four digit base UIS in accordance with some embodiments of the present invention, one or more numbers, letters, and/or special characters may be appended to the base UIS. For example, the number one may be appended to the beginning of the base UIS and associated with a debit function, the number two may be appended to the beginning of the base UIS and associated with a credit function, the number three may be appended to the beginning of the base UIS and associated with an accumulated value function, the number four may be appended to the beginning of the base UIS and associated with a prepaid function, etc.
As an example, suppose the user confirmed the automatic selection of a base UIS by the UIS generation system and the base selection module selected the last four digits of the user SSN that was 123456789. As such, the system selected base UIS would be 6789. In addition, suppose a credit account, a debit account, an accumulated value account, a prepaid account, and a rewards account are linked to the user operation vehicle. Then, the following table illustrates the account-specific UIS's that would be generated:
From the four digit UIS that was selected by the base selection module, five new five digit UIS's were created. This is only one example of how some embodiments of the present invention may create account-specific UIS's in different manners. As discussed in more detail below, some embodiments may use different account-specific generation logic for the generation of account-specific UIS's.
According to some embodiments, a response can be sent back from the UIS generation system 240 to activation portal 110. The response can include a confirmation page or cause a confirmation page to be displayed through the activation portal that the UIS generation and/or card activation were successful.
Some embodiments of the present invention provide for additional approaches to solving and/or improving the problems and disadvantages associated with using a Java™ applet. In some embodiments, the random selection of the system selected base UIS can be done on demand or through a batch-processing mode. In addition, some embodiments allow for a random base UIS generation option that can be selected by the user even when no problems with the activation portal exist.
Some embodiments of the present invention use a random field selector program to generate a four digit base UIS. In other embodiments, the base UIS may be longer or shorter than four digits and may include letters and/or special characters. There are a variety of different account-specific UIS generation logic sets that can be used to generate the account-specific UIS (e.g., a 5 digit UIS) that can be used in accordance with embodiments of the present invention only one of which was discussed above.
In some embodiments, the activation portal SSO response can be generated with two extra data fields. For example, a field selection data field (e.g. RandomFieldSelected) and a selected digit data field (e.g., SelectedDigits) could be added in some embodiments. The RandomFieldSelected=1 could be used to indicate the SSN number, 2 for the main zip code, 3 for ABA, 4 for DDA, etc. Similarly, the SelectedDigits=1 can be used to indicate the selection of the first four digits of the selected field and 2 for the last four digits of the selected field. The values for these data fields indicate the requested data field that was selected and which part of the data field was used to generate the system generated base UIS. In accordance with some embodiments, the UIS generation system 240 can send a mapping list to the activation portal before using this feature. In other embodiments, the mapping can be sent with the response.
In some embodiments, activation portal 110 can send a confirmation email to the user that the card is activated, the base UIS used (whether entered by the user or system selected), a clue for the user to know which base UIS was used (e.g., the first four digits of your checking account number), and/or the account-specific UIS's that were generated for each account. In some embodiments, the activation portal may only display the confirmation page in the customer browser. One example of a message that can be used in accordance with embodiments of the present invention is “The card has been activated successfully and last four digits of your SSN were used for the user operation vehicle UIS.” In other embodiments, a confirmation screen may display only a customer care number and instruct the user to call the number (e.g., immediately, after twenty four hours, or some other time period) to receive the generated account-specific UIS.
According to some embodiments, an account boarding batch file can be sent from the multi-function user operation vehicle core platform to the UIS generation system every night (or other specified time period such as every hour, every two hours, etc.). In some embodiments, the account boarding batch file can contain any new accounts/user operation vehicles boarded in the system. This batch file can be used as a trigger to generate base UIS requests for newly boarded customers. In accordance with some embodiments, the boarding file format can include extra fields that are present in the activation portal SSO request but are not present in existing account boarding files. One example of an extra field is the ABA Number. Additional error codes can also be sent from the UIS generation system 240 to the user operation vehicle core platform for new fields. In some embodiments, the user operation vehicle core platform may contain the processing logic for these error codes.
Some embodiments include batch processing logic for UIS reject records. The UIS generation system can include a processing module to process the account boarding file (and data fields). In addition, some embodiments of the UIS generation system can include an error module to detect errors and inform the user operation vehicle core platform of all new error codes for all the new data fields. Some embodiments of the UIS generation system can select newly boarded customers from the account boarding file and generate customer base UIS's using customer data and can send these to a verification system for recordation. Any reject response from the verification system can be recorded and can be sent to the user operation vehicle core platform in a reject batch file.
Memory 610 can be any device or mechanism used for storing information. In accordance with some embodiments of the present invention, memory 610 is intended to encompass any type of, but is not limited to, volatile memory, nonvolatile memory and dynamic memory. For example, memory 610 can be random access memory, memory storage devices, optical memory devices, magnetic media, floppy disks, magnetic tapes, hard drives, SIMMs, SDRAM, DIMMs, RDRAM, DDR RAM, SODIMMS, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), compact disks, DVDs, and/or the like. In accordance with some embodiments, memory 610 may include one or more disk drives, flash drives, databases, local cache memories, processor cache memories, relational databases, flat databases, and/or the like. In addition, those of ordinary skill in the art will appreciate many additional devices and techniques for storing information can be used as memory 610.
Memory 610 may be used to store instructions for running one or more applications or modules on processor 620. For example, memory 610 could be used in some embodiments to house all or some of the instructions needed to execute the functionality of activation interface module 630, account entry and verification module 640, encryption/decryption module 650, and/or communications module 660.
Activation interface module 630, according to some embodiments of the present invention, provides an interface for user 105 to access activation portal 110 and communicate with activation system 120, verification system 220, UIS generation system 240, and/or other components or systems. In some embodiments, activation interface module 630 provides one or more graphical user interfaces that can be displayed on a terminal and allow for interaction from user 105. For example, activation interface module 630 may display account user interface screen 300 as illustrated in
In accordance with some embodiments of the present invention, account entry and verification module 640 is operable to receive account information from the user through activation interface module 630. This can be done, for example, through one or more graphical user interfaces (e.g., account user interface screen 300), numerical pad on the phone, or the like. The account information can be the user operation vehicle account information in some embodiments. Accordingly, account entry and verification module 640 takes the received user operation vehicle account information and any additional verification information (e.g., user's birthday, answers to security questions, telephone numbers, and/or the like) and performs a verification check that the user is authorized to access the account.
Once the user operation vehicle account information is verified and the user is granted access to the account, some embodiments allow the user to submit account information about one or more payment functions that the user desires to link to the user operation vehicle. For example, the user could enter account information for one or more credit functions, reward functions, debit functions, prepaid functions, and/or the like. Then account entry and verification module 640 could process the request to verify the authenticity of each account and then link the desired accounts. In accordance with some embodiments, account entry and verification module 640 could use rules set up by system administrators to process the request to verify the accounts can be linked to the user operation vehicle. Examples of the types of rules that may be used include, but are not limited to, correct routing numbers, correct account numbers, only participating institutional accounts can be linked, only accounts from a single user, and/or the like.
In some embodiments, activation interface module 630 is operable to receive a base user identification string from user 105. As described in more detail below, the UIS generation module 250 can use UIS generation logic and the base UIS to generate a unique account-specific UIS for each function linked (or a subset of the functions linked) to the user operation vehicle.
The account information received through account entry and verification module 640 is usually encrypted before it is transferred over network 115 to activation system 120, verification system 220, or UIS generation system 240. This encryption can be done using encryption/decryption module 650. In some embodiments, the encryption/decryption may be a soft encryption using software. In other embodiments, the encryption/decryption may be done using only hardware components or a combination of hardware and software components. In some embodiments, encryption/decryption module 650 can include one or more nCipher host security modules (HSM) (e.g., a cluster of nCipher HSMs). Examples of the types of encryption schemes that can be used include, but are not limited to, triple data encryption standard (DES3), advanced encryption standard (AED), Hypertext Transfer Protocol over Secure Socket Layer (https), secured socket layer (SSL), transport layer security (TLS), public/private key encryption, and others known to those of ordinary skill in the art.
Communications module 660 in some embodiments of the present invention is configured to manage and translate any requests from user 105, from a graphic interface screen, into a format required by the destination component and/or system. Similarly, communications module 660 may be used to communicate between systems and/or modules that use different communication protocols, data formats, or messaging routines. According to some embodiments, system components can communicate through one or more of the following messaging methods: ISO 8583 Standard for Financial Transaction Card Originated Messages, extensible markup language (XML), proprietary message formats, and/or others known to those of ordinary skill in the art.
Memory 710 can be any device or mechanism used for storing information as described above with reference to memory 610. Memory 710 may be used to store instructions for running one or more applications or modules on processor 720. For example, memory 710 could be used in some embodiments to house all or some of the instructions needed to execute the functionality of UIS generation module 250, base selection module 740, encryption/decryption module 750, communications module 760, random field selection module 770, random field portion generator 780, and/or random mapping generator 790.
Base selection module 740, according to some embodiments of the present invention, could be used to select a set of digits (e.g., last four digits, first four digits, etc.) from one of the fields populated by the user through activation portal 110. In some embodiments, the field being randomly selected from the available fields by random field selection module 770. Once the field is selected, the random field portion generator selects which portion of the field will be used as the base UIS. For example, the last four digits, the first four digits, the third through sixth digit, etc. In other embodiments, the random field portion generator may select a set of letters, numbers, special characters, and/or a combination thereof as the portion to be used as the base UIs.
In some embodiments, encryption/decryption module 750 can encrypt and/or decrypt any messages sent or received by communication module 760 and between individual components of the UIS generation system. In some embodiments, the encryption/decryption may be a soft encryption using software. In other embodiments, the encryption/decryption may be done using only hardware components or a combination of hardware and software components. Examples of the types of encryption schemes include, but are not limited to, those listed for encryption/decryption module 650 in
As previously described, the activation portal SSO response sent from UIS generation system 240 can be generated with two extra data fields (e.g., RandomFieldSelected and SelectedDigits). In accordance with some embodiments, the mapping between the extra two data fields and the corresponding fields from which the information is gathered can be changed periodically to increase security. In some embodiments, random mapping generator 790 determines the mapping scheme currently being used. For example, the RandomFieldSelected=1 could be initially set to indicate the SSN number, 2 for the main zip code, 3 for ABA, 4 for DDA, etc. A new mapping can be generated by random mapping generator 790 and communicated to activation portal 110 using communications module 760.
Once a request to set a UIS or change a UIS occurs during receiving operation 810, a response can be generated that is appropriate to the system through which the request originated. For example, if the request originated from a web page, a set/change UIS webpage can be generated and forwarded to the user 105 in forwarding operation 820. In this case, user 105 enters a base UIS on the set/change UIS webpage which is then encrypted and returned to activation system 120. Activation system 120 receives the encrypted UIS at receipt operation 830 and then decrypts the encrypted UIS during production operation 840. Once the base UIS is decrypted, some embodiments provide for UIS generation logic to be applied to the base UIS to generate an account-specific UIS for each account linked to the user operation vehicle. Each account-specific UIS is then encrypted and stored.
According to some embodiments that will be discussed below, various types of UIS generation logic can be used to create the account-specific UIS for each account linked to the user operation vehicle. Once an account-specific UIS is generated for each function, confirmation operation 850 can be used to generate a completion screen and/or send a confirmation e-mail or other type of message (e.g., letter, automated phone call, etc.).
For example, in accordance with some embodiments of the present invention, a user operation vehicle may be pre-associated with one or more payment functions before the user operation vehicle is offered to a user. One or more user operation vehicle type codes can be associated with the user operation vehicle offered to the user in some embodiments. The one or more type codes indicate pre-associated functions that can be linked to the user operation vehicle. For example, if there was a debit function, a credit function, and a prepaid function, there would be at most seven combinations of functions that are pre-associated and that can be linked (i.e., credit function, debit function, prepaid function, credit and debit function, credit and prepaid function, debit and prepaid function, and credit, debit and prepaid function). According to some embodiments, a type code can be associated with one or more of these options allowing a user to quickly link the desired combination of associated functions in a quick manner.
During the activation process, the user operation vehicle type code can be used to access (e.g., from a database) a list of the functions, corresponding to the user operation vehicle type code, that are to be linked to the user operation vehicle. In other embodiments, the user operation vehicle type codes may be used at a POI to activate a set of functions (or those functions associated with the code that are not yet activated). In some embodiments, a user may go to a store that is having a special promotion involving providing linking a new line of credit (or even a prepaid card) to the user operation vehicle subject to qualification of the user. The store can provide a promotion code that the user submits to associate and/or link the new payment function (e.g., store credit) that may not already be associated and/or linked to the user operation vehicle. In some embodiments, the promotion code can be entered during a purchase at the store. If the promotion code is accepted, the code may be processed immediately or stored for processing (e.g., credit approval, association, linking, etc.) in a batch mode at some later time or after the occurrence of some triggering event.
In some embodiments, the user is shown different accounts and doesn't activate all of them. The user can then be provided activation codes which the user can send to activate an account at a later time. According to some embodiments, these activation codes may be processed through a variety of systems including, but not limited to, telephone systems, internet accessed systems, through appending the activation code to a UIS at a POI device, interactions with a customer service representative, and others systems, methods, and means.
Using the base UIS and the determined authorized payment types, account-specific UIS generation operation 930 creates a unique account-specific UIS for each account associated with the user operation vehicle. According to some embodiments, the account-specific UIS can be generated by appending one more additional numbers, letters, special characters and/or the like to the end of a base UIS entered by the user for each account linked to the user operation vehicle. For example, to produce an account-specific UIS in one or more embodiments, the number one is appended to the end of the base UIS and associated with a debit function, the number two is appended to the end of the base UIS and associated with a credit function, the number three is appended to the end of the base UIS and associated with an accumulated value function, the number four is appended to the end of the base UIS and associated with a prepaid function, etc. The following table illustrates this idea where the user entered the original UIS once as 2254 and a credit account, a debit account, an accumulated value account, a prepaid account, and a rewards account are linked to the user operation vehicle:
From the four digit UIS that the user entered, five new five digit UIS's were created. In accordance with some embodiments, any set of different numbers (or even letters and/or special characters) may be appended at the end of the UIS to indicate these functions. For example, the letter “c” could be used for credit, the letter “d” could be used for debit, the letters “av” could be used for accumulated value, the letter “p” could be used for a prepaid function, and the letter “r” could be used for a reward function.
If there are more than one function type (e.g., two debit functions) to be associated with the user operation, one or more additional numbers could be appended after the payment type in some embodiments. The following table illustrates this idea where the user entered the original UIS once as 2254 and there are three credit functions, two debit functions, no accumulated value functions, one prepaid function, and one rewards function:
From the four digit base UIS that the user entered, seven new six digit UIS's were created where the first four numbers are the base UIS, the fifth number corresponds to a payment type and the sixth number refers to the account within that payment type. Of course, any number, character, special character, or string thereof could be used to indicate payment type and account number. In accordance with some embodiments, any set of different numbers (or even letters and/or special characters) may be appended at the end of the base UIS to indicate these functions. For example, the characters “c1”, “c2”, and “c3” could be used for a first, second, and third credit, the characters “d1” and “d2” could be used for a first and second debit, the characters “p1” could be used for a first prepaid function, and the characters “r1” could be used for a first reward function.
Another example of the type of UIS generation logic that could be applied to generate account-specific UIS's for each function is adding or subtracting a value to the base UIS (i.e., incrementing the base UIS) entered by the user. As a simple example, the number one could be added to the base UIS and the result associated with a debit function, the number two could be added to the base UIS and the result associated with a credit function, the number three could be added to the original UIS and the result associated with an accumulated value function, etc. The following chart illustrates this idea:
In other cases, offsets could be used. For example, any set of numbers such as 100, 200, 300, etc. could be used for credit, debit, accumulated value, etc. Similarly, where the user operation vehicle has more than one of the same function, additional numbers could be added and/or subtracted. For example, an additional 10 for each account. The following table illustrates this idea where the user entered the base UIS once as 2254 and there are two credit functions, three debit functions, no accumulated value functions, one prepaid function, and one rewards function:
From the four digit base UIS that the user entered, seven new four digit UIS's were created from the one base UIS. Again, these examples are meant to be exemplary of the types of UIS generation logic that might be applied and are not meant to be limiting in any way. In fact, any operation (e.g., add, subtract, multiply, divide, etc.) or combination of operations that result in a unique account-specific UIS for each account associated with the user operation vehicle would work. In addition, the illustrations shown show a four digit numerical UIS being entered by the user and numerical account-specific UIS's. This is not the case in every embodiment and is only meant to illustrate various ideas and, in some embodiments, letters, numbers, special characters, and the like may be used for the base UIS and/or the additional characters used to generate the account-specific UIS.
In accordance with some embodiments, the user is able to select from a set of UIS generation logic options for the creation of the multiple account-specific UIS's that will be associated with the user's user operation vehicle. In addition, the users of some embodiments of the present invention are provided with an option to decide how the accounts of a similar type are ordered, how the function types are ordered, the offset associated with each function type, and/or other parameters in the creation of the multiple account-specific UIS.
In addition to credit, debit, prepaid, rewards, accumulated value and other payment functions with immediate processing, other different payment processing options can be linked to or used with the user operation vehicle in accordance with some embodiments of the present invention. For example, payment options or arrangements such as sixty days same as cash, ninety days same as cash, one-hundred eight days same as cash and the like may be available to be linked and/or used. Similarly, for debit functions, prepaid functions, reward functions, and other functions, the user payment options may include a delayed deduction meaning the payment will not be processed for a specified period of time (e.g., three days, seven days, thirty days, and the like). A determination can be made that the user is credit worthy for these options, but the options are not activated until a code is entered by the user at a POI. Some options may have expiration dates while others may not.
For example, suppose a user has been granted a sixty days same as cash offer and the user has the following UIS strings associated with the user operation vehicle:
When a user goes to a store to purchase merchandise and wants to pay using the sixty days same as cash offer, the user can enter the account-specific UIS choosing the payment function followed by a payment option code (e.g., “60” to indicate sixty days same as cash) which has been communicated to the user. To activate this payment option the user would enter the modified UIS as 2254260 to pay with credit using the sixty days same as cash option. These payment codes can be anything that indicates payment options. Some examples of payment option codes include, but are not limited to, “90” to indicate ninety days, “180” to indicate one-hundred eighty days, “s” to indicate sixty days, “n” to indicate ninety days, “o” to indicate one-hundred eighty days.
In some embodiments, the account-specific UIS's are stored in an encrypted system possibly managed by a third party. As a result, in some embodiments, there might not be a way of determining the base UIS after the card activation or change UIS events have occurred. In order to offer special promotions via UIS some embodiments set up additional UIS's when the customer selects their base UIS. In some cases, the number of additional UIS's set up are based on a set of promotions planned in advance. In some embodiments, as additional new promotions are planned beyond the scope of the original set of planned promotions, the user can be requested to change the UIS's associated with the user operation vehicle. One advantage of this approach is the enhanced security that is created by the user being encouraged to change their UIS's regularly in order to be able to take advantage of new promotions. In some embodiments, the system allows the customer to select their own UIS during card activation that can then be used for special offers, transactions, etc.
In some embodiments, the base UIS can be determined by decrypting an encrypted base UIS, if stored, or one or more of the account-specific UIS's. Then, promotion-specific UIS's can be created that are associated with one or more promotions. In some embodiments, the promotion-specific UIS's can be generated based on the automatic UIS generation system described above. For example, using the automatic UIS generation, a one time UIS can be created from the customer's data. Suppose a promotion to give a customer a percentage point bonus (e.g., ten percent), percentage discount, etc after a number (e.g., 10) of successfully processed transactions. A promotion-specific UIS could be generated from the customer's data (e.g., last four-digits of a phone) followed by the number 10. An email, SMS, outbound voice message from a voice response unit, letter, fact, etc could be sent to the customer to advise them that if they enter that promotion-specific UIS on a transaction of their choice, they'll get the bonus. In addition, the term account-specific UIS's can include promotion-specific UIS's in some embodiments of the present invention since the reward or reward actions can be viewed as the account balance.
The purchase details (e.g., purchase amount, user operation vehicle identification information, etc.) and the UIS entered by the customer can then be sent to the user operation vehicle platform 1020. In accordance with some embodiments, user operation vehicle platform 1020 validates the purchase details and the user operation vehicle information. If the details and information are not corrupted, a user operation vehicle purchase transaction request can be generated by user operation vehicle platform 1020. In some embodiments, the user operation vehicle transaction request is transferred to bank network switch 1025 over a communications network, leased line, dedicated communications channel, or the like.
Once the user operation vehicle transaction request is received, bank network switch 1025 routes the transaction to verification system 1030 over a communications network, leased line, dedicated communications channel, or the like. Verification system 1030 can then validate the UIS entered by the customer, determine the function associated with the UIS (e.g., debit, credit, accumulated value, etc.), and generate a function payment authorization request. Once generated, the function payment authorization request can be transferred to bank network switch 1025.
In accordance with various embodiments, bank network switch 1025 can determine which function is authorized to be charged. In some embodiments, the determination is made based on the message format and/or message content. Once a determination is made, the function payment authorization request can be routed to the corresponding user operation vehicle function system 1035 that can include one or more function processing systems (e.g., credit processing system, debit processing system, etc.). The selected function processing system processes the request and returns an authorization response back to bank network switch 1025.
In some embodiments, the authorization response can be routed from bank network switch 1025 to verification 1030, where the response is processed and then returned to bank network switch 1025. From the bank network switch, the authorization response is routed to user operation vehicle platform 1020 which generates and returns an approval or denial message back to online retailer 1010.
According to some embodiments, a daily settlement process 1050 occurs between online retailer 1010, user operation vehicle function systems 1035 (e.g., accumulated value processing system, debit processing system, credit processing system, etc.), and verification system 1030. In some embodiments, daily settlement files are generated based on the payments processed. Some embodiments use bank settlement control module 1040, verification settlement control module 1045, and retailer settlement control module 1055 to generate daily settlement files which are processed through daily settlement process 1050 between the online retailer and function account holders. While not illustrated in
According to some embodiments, a user can append additional characters to the end of the UIS at POI device 1105. In some embodiments, POI device 1105 can be a point of sale device, or comprised of components and/or software, purchased from Advanced Retail Management Systems, Microsoft dynamics RMS, Retail Pro, CounterPoint or other vendors.
By appending additional characters to the end of the UIS, the user creates a modified UIS (MUIS). However, according to some embodiments of the present invention, POI device 1105 treats a MUIS and a UIS in the same manner. POI device 705 processes all of the information received (e.g., the user operation vehicle account number, modified UIS, transaction information, merchant information, and possibly other information) and generates a total string of characters. The total string of characters can include various pieces of information such as, but not limited to, a primary account string, a user identification string (UIS), a function selector, a reward code, a modified UIS, merchant code, and/or the like.
The string of characters is typically partially encrypted by an encryption/decryption module associated with the POI, although in some embodiments it may be entirely encrypted or not encrypted at all. For example, in some embodiments, the UIS (or MUIS) would be encrypted, the account number would not be encrypted, and other pieces may or may not be encrypted depending on the technology, administrator preferences, and/or protocols set in place. The string of characters is then transmitted across network 1115 to verification system 220 in accordance with various embodiments of the present invention. Then, the string of characters can be parsed into the various tokens (e.g., the primary account string, the UIS, the function selector, and/or the reward code) using parsing logic.
In some embodiments of the present invention, the user and/or reward code can be validated using one or more of the various tokens. For example, the validation can occur by comparing a user operation vehicle UIS stored in UIS database 230 that is associated with the primary account number with the UIS received in the string of characters. Similarly, a determination of a reward action associated with the reward code can be made. The determination of the reward action can occur in a number of different ways according to various embodiments of the present invention. For example, in some embodiments, the reward determination can be performed by looking up the reward code in reward code database 1120. As another example, the reward determination can be performed by deciphering the reward code into various tokens that correspond to various reward elements.
Once the reward code is determined and applied, a payment request can then be sent for processing. In some embodiments, the payment processing occurs through a function indicated by a function selector. For example, the function selector can indicate that payment processing occur through a credit processing system 1130, a debit processing system 1135, a rewards processing system 1140, other processing systems 1145 (e.g., store value, gift card, consumer to consumer, prepaid, etc.), and/or the like.
In some embodiments, the user can select a rounding sweep option that will result in a set of UIS's being generated that will result in a rounding sweep for a particular account. In some embodiments, however, no additional UIS's are generated, but a user code is supplied to the user allowing the user to create a MUIS at the merchant that will result in the rounding sweep. In accordance with some embodiments, the amounts set for the rounding sweep can be one dollar, five dollars, and ten dollars. In some embodiments, the corresponding user code can be the numbers one, five, and ten. However, in other embodiments, different user codes and amounts may be used, and more or less rounding options may be available. In accordance with some embodiments, the account specified by the user for the rounding sweep deposit could be a savings account, or any other account, from any bank, merchant, etc. As a result of the rounding sweep in some embodiments a decoupled savings or independent savings is created.
As such, the user can select, at a POI, an account-specific UIS for debit (e.g., 3345) would result in an ACH debit of that amount. For example, when the user makes a $33.37 purchase through a POI and uses the account-specific UIS for debit, a corresponding $33.37 ACH debit would be generated. In some embodiments, an MUIS corresponding to the account-specific UIS for debit followed by the number one (e.g., 33451) would result in a round up to the nearest dollar and the difference between the transaction amount at the merchant and the rounded amount being deposited in a specified account. So, for example, a $33.37 purchase through a POI using the MUIS of account-specific UIS for debit followed by the number one (e.g., 33451) would result in a $34.00 ACH Debit and $0.63 would be deposited into the accumulated value account, a savings account, etc. that was specified by the user.
In some embodiments, an MUIS corresponding to the account-specific UIS for debit followed by the number five (e.g., 33455) would result in a round up to the nearest five dollars. So, a $33.37 purchase using the MUIS of account-specific UIS for debit followed by the number five (e.g., 33455) would result in a $35.00 ACH Debit and $1.63 would be placed in an accumulated value account, a savings account, etc. that was specified by the user. In some embodiments, an MUIS corresponding to the account-specific UIS for debit followed by the number ten for debit followed by the number five (e.g., 334510) would result in a round up to the nearest ten dollars. So, a $33.37 purchase using the MUIS of account-specific UIS followed by the number five (e.g., 334510) would result in a $40.00 ACH debit and $6.63 would be placed in an accumulated value account, a savings account, or other account that was specified by the user.
In some embodiments, part of the MUIS contains an identifier identifying the system for processing and possibly a delayed payment option. For example, a user may enter a MUIS as “987613.” In some embodiments, the first four characters are the user identification string, the fifth character is the processing identifier, and the sixth character as the payment option. In this example, the system will recognize that “9876” is the user identification string. The system will also identify “1” as an identifier identifying, e.g., the debit processing system. In some embodiments, the payment option “3” means that the funds will be processed three days later. If the customer is not eligible for the delayed payment option, or if the token is not valid or unrecognized, the system can ignore the token and continue to process the transaction or, in some embodiments, decline the transaction. The delayed payment option can be set up to be anything. For example, the delayed payment option token can correspond to equal monthly installment payments (e.g., “5” means five equal monthly installments), delayed payments (e.g., “4” means a four day delay before processing), as well as others. According to some embodiments, the delayed payments may be processed in a batch processing mode discussed in more detail below with regard to
In the embodiments illustrated in
In some embodiments, the processing systems 1130-1145 are in communication with one another (e.g., through network 1125, through a dedicated communications channel, etc.). Accordingly, this allows the processing systems to interact in the application of rewards, in facilitating the splitting of payment across one or more payment functions, and/or the like.
Memory 1210 can be any device or mechanism used for storing information. In accordance with some embodiments of the present invention, memory 1210 is intended to encompass any type of, but is not limited to, volatile memory, nonvolatile memory and dynamic memory. For example, memory 1210 can be random access memory, memory storage devices, optical memory devices, magnetic media, floppy disks, magnetic tapes, hard drives, SIMMs, SDRAM, DIMMs, RDRAM, DDR RAM, SODIMMS, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), compact disks, DVDs, and/or the like. In accordance with some embodiments, memory 1210 may include one or more disk drives, flash drives, databases, local cache memories, processor cache memories, relational databases, flat databases, and/or the like. In addition, those of ordinary skill in the art will appreciate many additional devices and techniques for storing information can be used as memory 1210.
In some embodiments, memory 1210 can be used to store instructions for running one or more applications or modules on processor 1220. For example, memory 1210 could be used to house all or some of the instructions needed to execute the functionality of POI application 1110, user interface module 1240, and/or communications module 1260.
Some embodiments of POI device 1105 include power supply 1230 which can be any type of device that supplies the necessary power required by POI device 1105. For example, power supply 1230 may be an independent rechargeable battery, multiple batteries, and/or other external power supplies. The power supply may be internal or external to POI device 1105. For example, external power may be supplied by accessing a power generator, solar grid, power line, and/or the like.
POI application 1110 can, in accordance with some embodiments, offer additional intelligence to POI device 1105. For example, POI application 1110 can include intelligence systems such as real-time inventory information. In some embodiments, part of the reward verification system in verification system 220 may be accessed through POI application 1110. For example, each store could create a reward system through which additional strings of numbers appended to the beginning, end, or within the UIS could be validated and applied to the transaction.
User interface module 1240 includes any hardware and software components for interaction with a user. For example, in some embodiments, user interface module 1240 is a numerical keypad with software running on processor 1220 which monitors for entry of UIS. Decryption/encryption module 1250 is used to encrypt any information that has to be transferred across network 1115 and decrypt any incoming messages that are encrypted. Communications module 1260 in some embodiments of the present invention is configured to translate any messages from POI device 1105 into a format required by the destination component and/or system. For example, communication protocols for peripheral devices and/or computers include, but are not limited to, ADM 787/788, AEDEX, CD 5220, DSP-800, EPSON Esc/POS, UPOS, industry standard PoS protocols, proprietary protocols and the like. Similarly, communications module 1260 can route encrypted messages to decryption module 1250 and can request encryption module 1250 encrypt outgoing messages.
According to some embodiments of the present invention, an authorization request (or a transaction request) is received at verification system 220 from a POI device. All requests may be received through communications module 1310 which is able to receive all incoming requests and/or messages, and direct the requests and/or messages to the correct module for processing.
In some embodiments, an incoming authorization request may be encrypted. When such a request is received at communications module 1310, the request is routed to encryption/decryption module 1320 if the request is encrypted. Encryption/decryption module 1320 decrypts the request. Also, in some embodiments, communication module 1310 sends the payment request to a function processing system to determine an approval or denial of a transaction if the UIS verification module 1340 determines the UIS corresponds to the primary account UIS. Similarly, communication module 1310 can send the reward code to a rewards processing system, in some embodiments, where a determination of the type and amount of reward associated with the reward code.
In accordance with some embodiments, the incoming authorization or transaction request includes an encrypted string of characters. The authorization request can also include various types of information such as a payment request amount, a primary account string, a user identification string (UIS), transmission time and date, payment device expiration date, processing code, and/or the like. The string of encrypted characters can include a function selector, a reward code and other tokens. The authorization request can be parsed using parsing module 1330 in embodiments of verification system 220. For example, parsing module 1330 can use parsing logic to turn the authorization request into various tokens such as primary account string, the MUIS, the UIS, the function selector, the reward code and/or the like that are contained within the string of characters.
The UIS entered by the user, in some embodiments of the present invention, allows for the user to enter a reward code with the UIS thus generating a modified UIS (MUIS). In some cases, traditional parsing logic is used to extract, in part, the MUIS not knowing that it contains special reward code information. The MUIS can then be passed through an additional set of parsing logic where the UIS and the reward code are separated. In some embodiments, parsing the reward code and UIS is not necessary. For example, the MUIS can be directly compared to a preset UIS that includes the UIS and reward code stored in a UIS database. In some embodiments, the UIS database is encrypted.
UIS verification module 1340 validates a user, in some embodiments, by comparing a primary account UIS stored in a UIS database and associated with the primary account string with the UIS received in the encrypted string of characters. If the UIS stored in the UIS database does not match the UIS received, then the transaction is denied. If there is a match, then function determination module 1350 can be used to determine the desired function if a function indicator is present in the string of characters. If a function indicator is not present, then a set of pre-determined rules (e.g., associated with the individual user operation vehicle or a default across all user operation vehicles) could be followed for processing the transaction request. In some embodiments, the UIS is the function indicator with a unique UIS associated with each payment function linked to the user operation vehicle. Using either the determined function, UIS, or the pre-determined processing rules, function routing module 1360 routes the transaction to the appropriate payment processing system.
In some embodiments, when a reward code is present in the string of characters, reward verification module 1370 determines if the reward code is valid and what action is associated with the reward code. For example, the action could apply a certain percentage discount (e.g., ten percent off), give a certain amount off (e.g., five dollars off), free shipping, generate a reward credit, and the like. In some embodiments, determining the action associated with the reward code includes transmitting the reward code to a reward code verification module (reward code verifier) that is external to verification system 220 (e.g., the module is managed by a particular store or bank). The external reward code verification module determines the amount and value, if any, of the benefit and what action should be taken. This action is then transferred back to verification system 220, in some embodiments, and the benefit is applied.
Once the action or benefit is implemented, the transaction can be processed through the appropriate payment processing system. In some embodiments, the payment processing system includes a transaction type authorizer which can approve or decline the authorization request.
The user's primary account number is received at a POI device through POI user interface 1410 in some embodiments of the present invention. For example, depending on the type of user operation vehicle being used, POI user interface 1410 can be a card reader, a magnetic strip reader, a fingerprint reader, manual entry key pad, a computer keyboard, voice recognition software, any biometric identifying device, and/or the like. A primary account number could be read directly from the user operation vehicle (e.g., when reading a card) or retrieved from a database. In some cases, a primary account number could be generated through unique characteristics of the user operation vehicle (e.g., applying a processing algorithm to a fingerprint). According to some embodiments, the primary account number can be associated with a single account or with one or more accrued value, reward, prepaid, credit, debit, and/or other payment accounts.
POI user interface 1410, in some embodiments, is in communication with a POI application 1110 which can be used for managing one or more peripheral devices such as a touch screen for order entry, printers, electronic cash registers, and/or the like. In some embodiments, POI application 1110 is a software application running on a computer through the Internet.
User 1405 can be prompted to enter a UIS that can be used to verify the identity of the user and/or select a payment function if the user operation vehicle is a multi-function user operation vehicle. User 1405 enters a UIS along with additional reward numbers. Once the primary account, UIS, and additional reward numbers are received along with any other information required by POI application 1110, POI application 1110 sends the primary account number, UIS, and reward numbers to decryption/encryption module 1250 where the information is encrypted to generate an encrypted input string of numbers before being transferred over network 1115 to a transaction processing system (an authorization request processing network). This information is typically partially encrypted, although in some embodiments it may be entirely encrypted. For example, in some embodiments, the UIS (or MUIS) would be encrypted, the account number would not be encrypted, and other pieces may or may not be encrypted depending on the technology, administrator preferences, and/or protocols set in place.
The encrypted input string of numbers from the POI device is received and then decrypted using decryption/encryption module 1420. In the embodiments illustrated in
If a determination is made that reward numbers or code exist in the input string, the reward numbers are passed to reward verification module (reward verifier) 1430. Module 1430 uses the information provided by UIS parsing and authentication module 1425 to determine the reward and/or action associated with the reward numbers in the input string. Reward application module 1435, in accordance with some embodiments, is configured to apply the reward, or take the reward action. For example, if the reward was an immediate ten percent discount, then the discount would be applied immediately to the transaction.
Once the application of the reward is complete, payment authorization module (function deduction authorizer) 1440 determines the appropriate payment processing network, transmits a request for payment to the determined payment processing network, and receives a payment authorization response (e.g., authorization, denial, partial denial indicating the amount that would be allowed, etc.). Determining the appropriate payment processing network can occur in a variety of ways depending on the embodiments in use. For example, in some embodiments, a function selector, that was included in the string of numbers, can be supplied to payment authorization module 1440 by UIS parsing and authentication module 1425. As another example, a unique UIS can be supplied to payment authorization module 1440 by UIS parsing and authentication module 1425. The unique UIS can then be used to determine which function associated with the primary account should be charged. In other embodiments, the primary account number includes routing information for payment processing that can be used by payment authorization module 1440 for routing the payment request. When the request to fund the transaction is approved or denied, the result is passed to the POI device.
As discussed above, some embodiments of the present invention include a delayed payment option that allows a customer who wants to process the transaction today but have the funds withdrawn from available accounts a few days later, set up recurring payments, have installment payments, and/or the like. Batch payment processing network 1500 describes some ways these transactions can be processed in accordance with various embodiments of the present invention.
Unlike the real-time payment processing network 1400, some piece of the transactional information (e.g., the application of the reward code) is not processed immediately but is stored in payment database 1545. According to various embodiments, the information could be sorted and stored based on one or more features of the requested transactions. Examples of features of the requested transactions include, but are not limited to, payment type, reward code present, merchant, authorizing financial institution, payment amount, and the like. Then, when a triggering event occurs, reward verification module 1430 pulls the information from payment database 1545 and determines if a reward code is present and what reward action, if any, should be taken. Examples of triggering events include, but are not limited to, timed intervals (e.g., every 5 seconds, every two minutes, every fifteenth day of the month, every two weeks, etc.), request from authorizing institutions, request from a specific payment network (e.g., credit network), a specified number of requests have been stored, and/or the like. The reward information can then be passed onto reward application module 1435 where the reward action is applied and the transaction requests are passed onto payment authorization module 1440.
The transaction request, including the input string of characters, is received at UIS/Primary account identification module 1645. According to some embodiments of the present invention, the transaction request can include a payment request amount, primary account string, a user identification string (UIS), input string of characters, a function selector, a merchant identification code, a reward code, and/or other pieces of information. Module 1645 identifies the UIS and the primary account identification code in the transaction request. The identification of the UIS and primary account identification code can be done in many ways. For example, the transaction request can have a fixed structure (e.g., first sixteen characters are always the primary account identification code immediately followed by four characters which are the UIS entered by the user) allowing the parts to be easily identified. In some cases, the transaction request can include identification sub-strings which identify the organization, type of information, and/or the length of each of the sub-strings.
Reward code parsing module 1650 determines if any reward code is present in the input string of characters associated with the transaction request. The identification of the reward code can be done using many methods. For example, in some embodiments, the string of characters has a fixed structure (e.g., first eight characters are a reward code) allowing the parts to be easily identified. In some embodiments, the string of characters include identification sub-strings which identify the organization, type of information, and the length of each of the sub-strings. According to some embodiments, reward code parsing module 1650 can also identify customer and merchant information stored within the string of characters. This feature can be useful in embodiments where the same reward code can result in a different reward action for different merchants and/or customers.
Function identification module 1655, in some embodiments of the present invention, determines which payment function account associated with the user operation vehicle should be used if more than one account is available. This can be done in a variety of ways. For example, the UIS identified by UIS/Primary account identification module 1645 can be used to determine the payment function and account to be used in completing the authorization request. In some embodiments, a function selector can be provided by the user.
According to some embodiments, function identification module 1655 is in communication with account database 1660. Using the unique UIS, the function selector, or some other means of account identification, module 1655 is able to look up account information in database 1660 and verify that the user is authorized to request a transaction.
In some embodiments, reward verification module 1430 receives information about the transaction request. For example, reward verification module 1430 can receive the entire account string and/or various tokens from the string of characters (e.g., reward string, primary account, merchant code, etc.). Once the information is received, customer/merchant identification module 1735 and reward string identification module 1730 can be used to determine the appropriate reward action in accordance with various embodiments of the present invention.
Reward string identification module 1730 identifies the reward string or code from the information received. Then, according to some embodiments, determines if the reward string is customer and/or merchant specific. If so, then reward string identification module 1730 requests that customer/merchant identification module 1735 verify that the reward string is valid with the current customer and/or merchant. In accordance with some embodiments of the present invention, this type of information can be encoded in the reward code. In some embodiments, little (or no) information is encoded in the reward code and a lookup must be performed using reward database 1440 to determine the appropriate reward action and requirements.
For example, a particular reward code may provide for a twenty dollar discount on a purchase of seventy-five dollars or more only at Merchant A. Consequently, when reward string identification module 1730 determines that this code is only valid at Merchant A, a request can be made for merchant identification through customer/merchant identification module 1735. Once the request is received, then module 1735 determines whether the user is making the purchase specifically from Merchant A and returns the merchant identification to module 1730.
During verification operation 1830, the UIS and account information are verified and a determination is made if the user is authorized to complete the transaction. For example, in some embodiments, a secure database is accessed which stores account identification information (e.g., account numbers) with one or more UIS's. The UIS included in the received input string is compared with the account identification information found in the input string. The secure database can also include, in some embodiments, routing and processing information for each account. If a decision is made that the user is not authorized, then the processing of the transaction ends.
Once verification operation 1830 is complete, determination operation 1840 determines if the received input string includes a reward number or code. If a reward code is present, then the code may be stored for later determination of the reward action. If a determination is made that no reward code is present, then no recording action is taken.
Once the account information and UIS are verified and a determination is made that the user is authorized, the processing operations branch to valid reward number decision operation 1850. According to some embodiments, valid reward number decision operation 1850 determines if the reward number in the input string is valid. If no reward number is present or a determination is made that the reward code is not valid, then the operations branch to funds verification operation 1870. If a determination is made that a valid reward number exists, then the reward action is determined and the processing operations branch to reward application operation 1860 where the reward action is applied. In some embodiments, decision operation 1850 determines if the reward number is valid by decoding the reward string, accessing a database and looking up part or all of the reward string, and/or using other methods.
Once the reward application operation 1860 finishes applying the reward action (e.g., five percent discount, ten dollars off, etc.), the transaction processing operations branch to funds verification operation 1870. Funds verification operation 1870 verifies the funds are available in the account (e.g., using a payment processing system). If the funds are available, then authorization operation 1880 completes the transaction between the POI device and the payment function. If sufficient funds are not available, or the transaction request is denied for any other reason (e.g., daily limit exceeded), then authorization operation 1880 terminates the transaction request and notifies the POI device that the transaction cannot be completed. In some embodiments, funds may be obtained from different accounts, according to a predetermined order, in order to complete the transaction. The transaction may be partially approved using only the funds available in the account in some embodiments. If the transaction is only partially approved, the user may be notified that additional funds are needed for the transaction to be completed.
A determination is made within the processing and routing network to route the authorization request to accumulated value authorizer 1920 for processing. Once the authorization request is received, accumulated value authorizer 1920 queries account and balances database 1925 to determine the available balance for the accumulated value function. The authorization request can also be logged in authorization log 1930 along with the action taken by accrued value authorizer 1920.
If the balance of the account is determined to have insufficient accrued value to cover the purchase, the accumulated value authorizer 1920 can deny the transaction, partially approve the transaction, or apply the balance and return a modified authorization request to the processing and routing network 1915 where another function associated with the user operation vehicle can be charged, or the balance can be returned to the processing and routing network 1915 where a decision is made on how to process the charge (e.g., submit part to the accumulated value function and part to another function).
If the accumulated value authorizer 1920 determines there is a sufficient balance (e.g., in rewards, cash equivalents, cash values, etc.) associated with the accumulated value function account, then the authorization request can be submitted to batch accumulated value processing module 1935. The batch accumulated value processing module 1935 updates or refreshes the account and balance file associated with the user once the processing occurs. The result (e.g., successful, failed, try again, etc.) can be communicated to the accrued value authorizer which communicates the result to the merchant processors 1910.
In addition to processing transaction using accumulated value functions, the accumulated value function processing system 1900 also credits accrued value to the accumulated value function account. For example, when user 1905 makes a purchase from a particular merchant and/or for an item within a particular category (e.g., food, gas, automotive, etc.) an accrued value can be generated. The purchase information (e.g., amount, identification, etc.) is transmitted to the accumulated value authorizer 1920. The accumulated value authorizer 1920 makes a determination using accumulation logic of the amount that the accumulated value account should be credited. This information is passed to the batch accumulated value processing module 1935 where the user operation vehicle information is verified using the user operation vehicle database 1945 and the accrued value amount is updated.
In some embodiments, the user can access account history, the reconciliation process, the settlement process, statements, and other information through a remote interface in communication with the accumulated value function processing system 1900. Examples of a remote interface include, but are not limited to a webpage, Java™ application, a downloadable computer program, cell phone applet, dedicated terminal, and/or the like.
Within each reward region is a description of the type of reward (2015a-2015c). However, in other embodiments, no description may be present and the reward may remain unknown to the user until the user enters the reward code during a transaction. In addition to a description, the reward regions include at least one reward code (2020a-2020c) and possibly an expiration date (2025a and 2025c) after which the reward codes will no longer be valid. In the embodiments shown, the reward codes are completely numerical. However, according to some embodiments, the reward codes can be of any length and can, in some cases, include letters.
In some embodiments, the reward codes may be presented to users through the POI device or a screen attached to the POI or POI system. According to some embodiments, the POI can download various advertisements during the day (e.g., at night, periodically throughout the day, once a day, on a predetermined schedule, etc.). Associated with each advertisement is an advertising code. The system will send advertising codes to the POI that will trigger these advertising components to be shown on the POI device itself or a device in communication with the system. One advantage of downloading the advertisements and allowing the system to send advertising codes to trigger the advertisements is the ability to display the advertisements quicker since they have been previously downloaded.
Exemplary Computer System OverviewSome embodiments of the present invention include various steps, some of which may be performed by hardware components or may be embodied in machine-executable instructions. These machine-executable instructions may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware. In addition, some embodiments of the present invention may be performed or implemented, at least in part (e.g., one or more modules), on one or more computer systems, mainframes (e.g., IBM mainframes such as the IMB zSeries, Unisys ClearPath Mainframes, HP Integrity NonStop servers, NEC Express series, and others), or client-server type systems. In addition, specific hardware aspects of embodiments of the present invention may incorporate one or more of these system, or portions thereof.
As such,
Processor(s) 2102 can be any known processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s), or AMD® Opteron® or Athlon MP® processor(s), or Motorola® lines of processors. Communication port(s) 2103 can be any of an RS-232 port for use with a modem based dialup connection, a 10/100 Ethernet port, or a Gigabit port using copper or fiber. Communication port(s) 2103 may be chosen depending on a network such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 2100 connects.
Main memory 2104 can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known in the art. Read only memory 2106 can be any static storage device(s) such as Programmable Read Only Memory (PROM) chips for storing static information such as instructions for processor 2102.
Mass storage 2107 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of SCSI drives, an optical disc, an array of disks such as RAID, such as the Adaptec family of RAID drives, or any other mass storage devices may be used.
Bus 2101 communicatively couples processor(s) 2102 with the other memory, storage and communication blocks. Bus 2101 can be a PCI/PCI-X or SCSI based system bus depending on the storage devices used.
Removable storage media 2105 can be any kind of external hard-drives, floppy drives, flash drives, IOMEGA® Zip Drives, Compact Disc-Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM).
The components described above are meant to exemplify some types of possibilities. In no way should the aforementioned examples limit the scope of the invention, as they are only exemplary embodiments.
In conclusion, embodiments of the present invention provide novel systems, methods and arrangements for the generation of user identification strings used with multi-function operation vehicles and to the addition of functionality to a user identification string for use at a POI. While detailed descriptions of one or more embodiments of the invention have been given above, various alternatives, modifications, and equivalents will be apparent to those skilled in the art without varying from the spirit of the invention. Therefore, the above description should not be taken as limiting the scope of the invention, which is defined by the appended claims.
Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations as fall within the scope of the claims, together with all equivalents thereof.
Claims
1. An authorization request processing network comprising:
- a point of interaction (POI) device to generate an authorization request that includes 1) a vehicle code identifying a user operation vehicle and 2) a modified user identification string (MUIS) that includes a user code and a user identification string (UIS) provided by a user at the POI device, wherein the POI device includes an encryptor to encrypt at least part of the authorization request;
- a verifier in communication with the POI device through a communication network, and wherein the verifier includes: a decryptor to decrypt the authorization request generated by the POI device; and a parsing module to parse the authorization request into a function deduction request, the vehicle code, and the MUIS; and wherein the verifier verifies the UIS corresponds to a primary account UIS associated with the user operation vehicle;
- a user code processing system to determine an action associated with the user code and to implement the action;
- one or more function processors in communication with the verifier, wherein the verifier requests, from the one or more function processors, an approval or a denial of the authorization request originating from the POI device if the verifier determines the UIS corresponds to the primary account UIS.
2. The authorization request processing network of claim 1, wherein the user code includes one or more of a reward code, a function indicator, or an account activation code.
3. The authorization request processing network of claim 1, wherein the user code includes a savings indicator to cause an amount of the authorization request to be rounded to an indicated dollar increment amount and cause the difference between the amount of the authorization request and the indicated dollar increment dollar amount to be deposited into a function account.
4. The authorization request processing network of claim 3, wherein the indicated dollar increment amount is one dollar, five dollars, or ten dollars.
5. The authorization request processing network of claim 1, wherein the user code processing system is a reward code processing system.
6. The authorization request processing network of claim 5, wherein the user code includes a reward code and the POI device further comprises a POI application to access the reward code processing system and process the reward code before transmitting the authorization request to the verifier.
7. The authorization request processing network of claim 1, wherein the verifier further comprises:
- a function determination module to determine a payment function associated with the user operation vehicle by a payment function indicator; and
- a switch to route the request for the approval or the denial of the transaction to the determined payment function of the one or more function processors.
8. The authorization request processing network of claim 1, wherein the POI device is a point of sale device.
9. The authorization request processing network of claim 1, wherein the POI device is a computer integrated system.
10. The authorization request processing network of claim 1, wherein the POI device includes a computer connected to the internet or a telephone payment system.
11. The authorization request processing network of claim 1, wherein the decryptor includes one or more nCipher host security modules.
12. A system for processing authorization requests originating from a point of interaction (POI) device, the system comprising:
- a communication device in communication with the POI device;
- a processor in communication with the communication device and a memory, wherein when an authorization request is received at the communication device from the POI device, the processor processes the authorization request, and wherein the authorization request includes a modified user identification string (MUIS) entered by the user at the POI device and the MUIS contains at least a user identification string (UIS) and a user code; and
- the processor also parses the MUIS into the UIS and the user code, determines an action associated with the user code, applies the action associated with the user code, and routes the authorization request to a function processor for payment authorization.
13. The system of claim 12, wherein the authorization request is at least partially encrypted and the processor routes the authorization to a decryptor to be decrypted.
14. The system of claim 13, wherein the decryptor includes only hardware components.
15. The system of claim 13, wherein the decryptor includes one or more nCipher host security modules.
16. The system of claim 12, wherein the user code includes a function indicator and the processor also:
- determines a payment function based on the function indicator that is included in the user code; and
- determines the function processor that is associated with the payment function and wherein the function processor is used in processing the authorization request.
17. The system of claim 12, wherein the user code includes a reward code and to determine the action associated with the reward code, the processor also:
- transmits the reward code to a reward code verifier, wherein the reward code verifier determines if the actions include one or more reward benefits; and
- receives the one or more reward benefits from the reward code verifier.
18. The system of claim 17, wherein to determine the one or more reward benefits associated with the reward code, the processor also:
- accesses a reward database that has stored thereon a plurality of stored reward codes each associated with the one or more reward benefits;
- locates the stored reward code in the reward database that corresponds to the reward code provided within the user code entered at the POI device; and
- determines, from the stored reward code, the one or more reward benefits associated with the reward code.
19. The system of claim 12, wherein the user code includes an account activation code and to determine the action associated with the account activation code, the processor also:
- determines an inactive account associated with the account activation code; and
- activates the inactive account.
20. A function deduction verification system comprising:
- a receiver to receive, from a point of interaction (POI) device through a communication network, a string of characters that includes a function deduction request, a primary account string, and an encrypted modified user identification string (MUIS) that includes a user identification string (UIS) and a reward code entered by a user in response to a request by the POI device to enter the UIS associated with a user operation vehicle presented to the POI device;
- a decryptor to decrypt the string of characters including at least the encrypted MUIS;
- a parsing module configured to parse the string of characters received from the decryptor into the function deduction request, the primary account string, the UIS, and the reward code;
- a verifier to receive the primary account string and the UIS from the parsing module, and wherein the verifier verifies the UIS corresponds to a primary account UIS;
- a communications module to send the function deduction request to a function processor for approval or denial if the verifier determines the UIS corresponds to the primary account UIS, and wherein the communication module sends the reward code to a rewards processor to determine a type and amount of reward associated with the reward code; and
- a function deduction authorizer to apply credit for the reward and communicate the approval or denial of the function deduction request to the POI device.
21. The function deduction verification system of claim 20, wherein the string of characters also includes a function indicator and the function deduction verification system further comprises:
- a function determination module to determine a function associated with the primary account indicated by the function indicator; and
- a switch to route the payment request to the function processor corresponding to the determined function.
22. The function deduction verification system of claim 20, wherein the function processor and the rewards processor are integrated into a single system.
23. The function deduction verification system of claim 20, wherein the function processor includes a rewards function processing module, a debit function processing module, and a credit function processing module.
24. The function deduction verification system of claim 20, further comprising a merchant identification module capable of determining if the string of characters includes a merchant identification code.
25. The function deduction verification system of claim 24, wherein the merchant identification module is further operable to determine if the reward code applies only to one or more specific merchants and wherein the merchant identification module is able to determine the type and amount of reward allowed by the reward code with the merchant identified by the merchant identification code.
26. The function deduction verification system of claim 20, wherein the communication network includes at least one of a dedicated communication channel, a local area network (LAN), a public switched telephone network (PSTN), a broadband network, an internet service provider (ISP) network, or a voice network.
27. The function deduction verification system of claim 20, wherein the decryptor includes one or more nCipher host security modules.
28. A computer-implemented method comprising:
- receiving an authorization request that is at least partially encrypted and includes 1) a vehicle code identifying a user operation vehicle supplied by a user at a point of interaction (POI) device and 2) a modified user identification string (MUIS) entered by the user at the POI device, wherein the MUIS contains at least a user identification string (UIS) and a user code;
- utilizing a decryptor to decrypt any part of the authorization request that is encrypted;
- parsing, using one or more parsing modules, the MUIS into the UIS and the user code;
- validating the user, using a verifier, by comparing a primary account UIS stored in a UIS database with the UIS received in the authorization request;
- determining an action associated with the user code; and
- implementing the action associated with the user code and routing the authorization request to a function processor for payment authorization.
29. The computer-implemented method of claim 28, further comprising:
- transmitting the vehicle code to the verifier; and
- selecting the primary account UIS that is associated with the user operation vehicle identified by the vehicle code.
30. The computer-implemented method of claim 28, wherein the user code includes a reward code.
31. The computer-implemented method of claim 30, wherein the action associated with the reward code is a percentage discount on a total price, a percentage discount on a particular item, multiple reward points, a dollar amount discount on a total price, buy one get one free of a particular item, or a free delivery of one or more items.
32. The computer-implemented method of claim 28, wherein the MUIS also includes a function indicator indicating a selected function of a plurality of functions linked to a user operation vehicle, the method further comprising:
- determining the selected function based on the function indicator that is included in the MUIS;
- selecting the function processor that is associated with the selected function; and
- utilizing a switch to route the authorization request to the function processor for payment authorization.
33. The computer-implemented method of claim 32, wherein payment authorization comprises:
- generating, by the function processor, a settlement file indicating approval or denial of the authorization request;
- transferring the settlement file to a settlement controller for submission to a merchant settlement controller associated with the POI device.
34. The computer-implemented method of claim 32, wherein a first set of characters as the function indicator indicates the selection of a debit payment function, a second set of characters as the function indicator indicates the selection of a credit payment function, a third set of characters as the function indicator indicates the selection of an accumulated value payment function, and a fourth set of characters as the function indicator indicates the selection of a prepaid payment function.
35. The computer-implemented method of claim 34, wherein the first set of characters is the number one, the second set of characters is the number two, the third set of characters is the number three, and the fourth set of characters is the number four.
36. The computer-implemented method of claim 32, wherein the action associated with the user code provides a predetermined payment arrangement that differs from the standard terms of the selected function.
37. The computer-implemented method of claim 36, wherein the predetermined payment arrangement is thirty days same as cash, ninety days same as cash, or one hundred eighty days same as cash.
38. The computer-implemented method of claim 28, wherein determining an action associated with the user code comprises parsing the user code into one or more tokens.
39. The computer-implemented method of claim 28, wherein the user code is a reward code and determining an action associated with the reward code comprises:
- transmitting the reward code to a reward code verifier, wherein the reward code verifier determines or authorizes one or more reward benefits associated with the reward code; and
- receiving from the reward code verifier an indication of the one or more reward benefits that were determined or authorized.
40. The computer-implemented method of claim 39, wherein determining the one or more reward benefits associated with the reward code comprises:
- accessing a reward database that has stored thereon a plurality of stored reward codes each associated with one or more reward actions;
- locating a stored reward code in the reward database corresponding to the reward code parsed from the MUIS; and
- determining, from the stored reward code, the one or more reward benefits associated with the reward code.
41. The computer-implemented method of claim 39, wherein the authorization request includes a merchant code associated with a merchant where the authorization request originated, wherein at least one of the one or more benefits associated with the reward code can only be applied at a particular merchant or set of merchants, and wherein determining the one or more reward benefits associated with the reward code comprises determining if each of the one or more reward benefits associated with the reward code can be applied to the merchant indicated by the merchant code.
42. The computer-implemented method of claim 28, wherein before determining and applying the action associated with the user code, the method further comprises:
- storing the authorization request in a batch processing database that includes one or more additional pending authorization requests; and
- monitoring for a triggering event before processing the authorization request and the one or more additional pending authorization requests stored in the batch processing database.
43. The computer-implemented method of claim 42, wherein the triggering event is a timed interval or a request from a processing system.
44. The computer-implemented method of claim 28, wherein the user code includes an account activation code and the method further comprises:
- validating the account activation code by accessing an activation code database that has stored thereon a plurality of authorized activation codes and comparing the activation code with the plurality of authorized activation codes; and
- activating one or more non-activated accounts associated with the activation code if the activation code matches one of the plurality of authorized activation codes stored on the activation code database.
45. The computer-implemented method of claim 28, further comprising providing the user code to the user through a flyer.
46. The computer-implemented method of claim 28, further comprising providing the user code to the user through a communication format selected from a short messaging system (SMS) message, an e-mail, or an outbound voice response unit message.
47. The computer-implemented method of claim 28, wherein the user code includes a savings indicator, wherein the method further comprises:
- rounding a function deduction amount associated with the authorization request to an indicated dollar increment amount;
- amending the authorization request to indicate the rounding of the function deduction amount for processing by the function processor;
- computing the difference between the amount of the authorization request and the indicated dollar increment amount; and
- depositing the difference into a function account.
48. The computer-implemented method of claim 47, wherein the indicated dollar increment amount is one dollar, five dollars, or ten dollars.
49. A computer-readable storage medium containing a set of instructions capable of causing one or more processors to:
- receive, from a point of interaction (POI) device, an authorization request that includes 1) a vehicle code identifying a user operation vehicle and 2) a modified user identification string (MUIS) that includes a user identification string (U IS) and a user code entered as a single input string by a user at the POI device;
- determine an action associated with the user code; and
- send an approval or denial of the authorization request to the POI device after the action has been applied.
50. The computer-readable storage medium of claim 49, wherein the set of instructions are further capable of causing one or more processors to:
- verify the UIS received from the POI device matches a stored UIS associated with a primary account identified with the vehicle code; and
- deny the authorization request if the UIS is not successfully verified.
51. The computer-readable storage medium of claim 49, wherein the set of instructions are further capable of causing one or more processors to:
- determine if the authorization request includes a function indicator indicating a selected function type; and
- process the authorization request by sending the authorization request to a function authorizer able to process the selected function type by approving or declining the authorization request based on pre-set processing rules.
52. The computer-readable storage medium of claim 49, wherein the set of instructions are further capable of causing one or more processors to:
- determine if the authorization request includes a merchant identification code;
- determine if the user code requires successful merchant identification before application of the action associated with the user code; and
- determine if the merchant identification code identifies a merchant to which the user code is applicable.
53. The computer-readable storage medium of claim 49, wherein the user code is a reward code and wherein the set of instructions are further able to determine a reward action associated with the reward code by causing one or more processors to:
- transmit the reward code to a reward code verifier, wherein the reward code verifier determines the amount and value of the reward action; and
- receive from the reward code verifier the determined amount and value of the benefit.
54. A system comprising:
- a receiving means for receiving an authorization request that includes a modified user identification string (MUIS) entered by a user at a point of interaction (POI) device, wherein the MUIS contains at least a user identification string (UIS) and a user code;
- an action determination means for determining an action associated with the user code;
- an action implementation means for implementing the action associated with the user code; and
- a routing means for routing the authorization request to a function processor for payment authorization.
55. The system of claim 54, wherein the authorization request further comprises a vehicle code identifying a user operation vehicle supplied by the user at the POI.
56. The system of claim 54, further comprising a parsing means for parsing the MUIS into the UIS and the user code.
57. The system of claim 54, further comprising a verification means for validating the user by comparing a primary account UIS stored in a UIS database with the UIS received in the authorization request.
58. The system of claim 54, wherein the authorization request is at least partially encrypted and the system further comprises a decryption means to decrypt any part of the authorization request that is encrypted.
59. The system of claim 58, wherein the decryption means includes one or more nCipher host security modules.
60. The system of claim 54, wherein the user code includes a reward code.
61. The system of claim 60, wherein the action associated with the reward code is a percentage discount on a total price, a percentage discount on a particular item, multiple reward points, a dollar amount discount on a total price, buy one get one free of a particular item, or a free delivery of one or more items.
62. The system of claim 54, wherein the MUIS also includes a function indicator indicating a selected function of a plurality of functions linked to a user operation vehicle, and wherein the routing means comprises:
- a function indicator module for determining the selected function based on the function indicator that is included in the MUIS;
- a function selection module for selecting the function processor that is associated with the selected function; and
- a switch to route the authorization request to the function processor for payment authorization.
63. The system of claim 54, wherein the function processor comprises:
- a settlement generation means for generating a settlement file indicating approval or denial of the authorization request;
- a transfer means for transferring the settlement file to a settlement controller for submission to a merchant settlement controller associated with the POI device.
64. The system of claim 62, wherein a first set of characters as the function indicator indicates the selection of a debit payment function, a second set of characters as the function indicator indicates the selection of a credit payment function, a third set of characters as the function indicator indicates the selection of an accumulated value payment function, and a fourth set of characters as the function indicator indicates the selection of a prepaid payment function.
65. The system of claim 62, wherein the action associated with the user code provides a payment arrangement that differs from a standard payment terms of the selected function.
66. The system of claim 65, wherein payment arrangement is thirty days same as cash, ninety days same as cash, or one hundred eighty days same as cash.
Type: Application
Filed: Feb 27, 2009
Publication Date: Jul 29, 2010
Inventors: Daniel J. Eckert (Chicago, IL), Hugo A. Zambrano (Skokie, IL), Douglas Peters (Trout Valley, IL), Stuart Bain (Martinsville, NJ)
Application Number: 12/395,604
International Classification: H04L 9/32 (20060101); G06Q 10/00 (20060101); G06F 17/30 (20060101); G06F 17/40 (20060101); G06Q 20/00 (20060101); G06Q 30/00 (20060101);
