US20100191652A1

Movatterモバイル変換

Info

Publication number: US20100191652A1
Application number: US12/395,604
Authority: US
Inventors: Daniel J. Eckert; Hugo A. Zambrano; Douglas Peters; Stuart BAIN
Original assignee: HSBC Card Services Inc
Current assignee: HSBC Card Services Inc
Priority date: 2009-01-23
Filing date: 2009-02-27
Publication date: 2010-07-29
Also published as: US8162208B2; US20100187303A1

Abstract

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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 NOTICE

Contained 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 FIELD

Some 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).

BACKGROUND

There 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.

SUMMARY

Systems 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.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will be described and explained through the use of the accompanying drawings in which:

FIG. 1 illustrates an example of an activation environment in which some embodiments of the present invention may be utilized;

FIG. 2 illustrates an example of a user identification string (UIS) generation system with various components that can be used in accordance with some embodiments of the present invention;

FIGS. 3A-3C illustrate examples of screenshots for a user operation vehicle activation interface that may be used in accordance with some embodiments of the present invention;

FIG. 4 illustrates an example of a webpage that might include a Java™ applet for collecting a base UIS from a user along with a hyperlink in accordance with some embodiments of the present invention;

FIGS. 5A-5C illustrate examples of webpages that can convey the selected base UIS to the user without actually displaying the UIS on the webpage in accordance with some embodiments of the present invention;

FIG. 6 is a block diagram illustrating components of an activation portal that may be used in accordance with some embodiments of the present invention;

FIG. 7 is a block diagram illustrating components of a UIS generation system that may be used in accordance with some embodiments of the present invention;

FIG. 8 is a flowchart illustrating an example of a method for operation of an activation portal in accordance with some embodiments of the present invention;

FIG. 9 is a flowchart illustrating an exemplary set of UIS generation logic for generating multiple user identification strings in accordance with some embodiments of the present invention;

FIG. 10 illustrates an example of online transaction processing which may be used in some embodiments of the present invention;

FIG. 11 illustrates an example of an operating environment in which some embodiments of the present invention may be utilized;

FIG. 12 is a block diagram illustrating components of a point of interaction device that may be used in accordance with some embodiments of the present invention;

FIG. 13 is a block diagram illustrating components of a verification system that may be used in accordance with some embodiments of the present invention;

FIG. 14 is a block diagram illustrating various components that may be a part of a real-time payment processing network in accordance with some embodiments of the present invention;

FIG. 15 is a block diagram illustrating various components that may be a part of a batch payment processing network in accordance with some embodiments of the present invention;

FIG. 16 is a block diagram illustrating various components that may be a part of a parsing and authentication module in accordance with some embodiments of the present invention;

FIG. 17 is a block diagram illustrating various components that may be a part of a reward verification module in accordance with some embodiments of the present invention;

FIG. 18 is a flowchart illustrating operations for processing a transaction in accordance with some embodiments of the present invention;

FIG. 19 is a block diagram illustrating various components that may be a part of an accumulated value function processing system in accordance with some embodiments of the present invention;

FIG. 20 is an example of a promotional flyer that may be used in some embodiments of the present invention; and

FIG. 21 illustrates an example of a computer system with which some embodiments of the present invention may be utilized.

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 DESCRIPTION

Some 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.

TERMINOLOGY

Brief 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 Description

FIG. 1 illustrates an example of anactivation environment100 in which some embodiments of the present invention may be utilized. The multi-function user operation vehicle can be any device, biometric identifier, or method for conveying information that may be used to conduct a transaction. The multi-function user operation vehicle can potentially be associated and/or linked with one or more credit functions, debit functions, accumulated value functions, consumer-to-consumer payment functions, reward functions, and/or other types of payment functions. Examples of other types of payment functions include, but are not limited to, loans (e.g., funds from student loans, bank loans, etc.), flexible spending accounts for healthcare payments, payroll from an employer, reimbursements from an employer, petty cash from an employer, corporate incentives, and payments from insurance companies (e.g., automobile, health, pet, etc.).

The 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, user105 can use anactivation portal110. The user can be directed toactivation portal110 through informational communications such as flyers, e-mails, telephone calls, or other communications that tell the user how to access theactivation port110. 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 portal110 provides an interface throughnetwork115 toactivation system120 to activate the user operation vehicles.Activation portal110 can be any type of interface that facilitates the exchange of information required byactivation system120 for user operation vehicle activation. In some embodiments,activation portal110 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 throughactivation portal110, the information is transferred acrossnetwork115 toactivation system120.Network115 can be any group of interconnected devices capable of exchanging information. In some embodiments,network115 may be as few as several personal computers on a Local Area Network (LAN) or as large as the Internet.Network115 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,network115 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 toactivation system120. Once access is granted,activation system120 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 system120 monitors for a set UIS request or a change UIS request from user105. The set or change request can come throughactivation portal110 vianetwork115. 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).

FIG. 2 illustrates an example of a user identification string (UIS)generation environment200 with various components that can be used in accordance with some embodiments of the present invention. One ormore activation portals110a-110ncan use set UIS interface/applets210a-210nfor the entry of a new base UIS. According to some embodiments, set UIS interface/applet210 can be displayed in response to a set or change UIS request. The set UIS interface/applet can be a webpage, a part of a webpage, a Java™ application, a downloadable computer program, a computer application, and/or the like.

Once a base UIS is received from a user viaactivation portal110, the base UIS can then be encrypted by an encryption/decryption module (encryptor or decryptor) associated withactivation portal110. In some embodiments, the encrypted UIS is transferred to accountverification system220 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 system220 can identify origination information (e.g., IP address, user token, etc.). The origination information identified byverification system220 can be used in some embodiments for tracking marketing penetration by channel (e.g., webpage, web address, phone calls, etc.).

In some cases,verification system220 causes an account user interface screen to be displayed through theactivation portal110. In other embodiments, the account user interface screen is part of set UIS interface/applet210. 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 toUIS generation module240 whereUIS generation module250 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 module250 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 inUIS database230 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 throughactivation portal110 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 throughactivation portal110. 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 theactivation portal110. 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 operationvehicle activation system120.

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 theUIS generation system240 to generate the second UIS for each successfully linked account. In response to a communication from the user operationvehicle activation system120, a fourth user interface screen can be presented which displays the second UIS for each of the one or more accounts successfully linked.

FIGS. 3A-3C illustrate examples of screenshots for the account activation process that can occur through one or more user interface screens displayed throughactivation portal110 that may be used in accordance with some embodiments of the present invention.FIG. 3A shows an example of an accountuser interface screen300 that can be used in some embodiments. Accountuser interface screen300 as illustrated inFIG. 3A can be used for collecting account information about accounts to be potentially linked to a user operation vehicle, for verifying a user and user operation vehicle for activation purposes, and/or for creating a new UIS.

In accordance with some embodiments of the present invention, any number of different types of information can be requested from the user using accountuser interface screen300. Accountuser interface screen300, as illustrated, requests a user input a user operation vehicle identification number inentry box305, loyalty number on the user operation vehicle inentry box310, the user's first and last names in

entry boxes

315 and320, respectively, user's data of birth inentry box325, and a current e-mail address inentry box330. In some embodiments, the type of information requested on accountuser interface screen300 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.

FIG. 3B shows an example of acreate UIS screen340 that may be used with a user operation vehicle activation interface in accordance with some embodiments of the present invention. According to some embodiments, createUIS screen340 can be displayed after the account verification process is completed and a determination was successfully made that the user is authorized to activate the account. In the embodiments shown inFIG. 3B, the user is required to enter a four digit numerical number without spaces or special characters inentry box345 andentry box350. However, in other embodiments the code can be of any specified length and/or include special characters, letters, and/or spaces, or be system generated based on the user information provided.

FIG. 3C shows an example of achange UIS screen360 that may be used with a user operation vehicle activation interface in accordance with some embodiments of the present invention. According to some embodiments, change UISscreen360 can be displayed after a user successfully logs into the user's account. In the embodiments shown inFIG. 3C, the user is required to enter a four digit numerical number without spaces or special characters inentry box365 andentry box370. However, in other embodiments the code can be of any specified length and/or include special characters, letters, and/or spaces.

According to some embodiments of the present invention, once the user hits the submit button (355 or375) in either createUIS screen340 or change UISscreen360, the new base UIS can be transmitted to theUIS generation system240 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.,FIG. 3A). In some cases, the user activating the user operation vehicle may desire and alternative to using the applet (e.g., if the user has an incompatible browser). Some embodiments of the present invention provide a hyperlink that the user can select if the user desires an alternate solution to using the Java™ applet. For example, the hyperlink in some embodiments might say, “Having issues seeing the applet? Click here to receive a system generated UIS.”

FIG. 4 illustrates an example of awebpage400 that might include aJava™ applet410 for collecting a base UIS from a user along with ahyperlink420 in accordance with some embodiments of the present invention. According to some embodiments, link420 can point to another web page that can display a message asking the user to confirm the automatic generation of the multiple account-specific UIS's using a system selected base UIS. In some embodiments, additional or different text can be provided throughwebpage400. For example, some embodiments might include the following text on webpage400:

- 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 inFIG. 5A-5C. Some embodiments provide for a confirmation button to be provided on this page for the user to confirm that they have noted the base UIS number.

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 field325 inFIG. 3A). In accordance with various embodiments, some fields may be mandatory while other fields may be optional. In accordance with some embodiments, a base selection module could be used to select the four digits (e.g., last four digits, first four digits, etc.) from one of those fields (with the field being randomly selected from the available fields) and then use that as the base UIS. In other embodiments, a set of letters, numbers, special characters, and/or a combination thereof may be selected from within the fields.

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:


Function Types Linked to the		Account-
User Operation Vehicle	Base UIS	Specific UIS

Debit	6789	16789
Credit	6789	26789
Accumulated Value	6789	36789
Prepaid	6789	46789
Rewards	6789	56789

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 theUIS generation system240 toactivation portal110. 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, theUIS generation system240 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 portal110 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 theUIS generation system240 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.

FIG. 6 is a block diagram600 illustrating components of anactivation portal110 that may be used in accordance with some embodiments of the present invention. According to the embodiments shown inFIG. 6,activation portal110 can includememory610,processor620,activation interface module630, account entry andverification module640, encryption/decryption module650 (sometimes called an encryptor or decryptor), andcommunications module660. Other embodiments of the present invention may include some, all, or none of these modules and components along with other modules or application components. Still yet, some embodiments may incorporate two or more of these modules into a single module and/or associate a portion of the functionality of one or more of these modules with a different module. For example, in some embodiments, the account entry andverification module640 can be separated into two or more modules. According to some embodiments,activation portal110 is a component that includes hardware such asmemory610 andprocessor620. However, in other embodiments,activation portal110 refers to a software application that can be run on hardware such as a personal computer.

Memory

610 can be any device or mechanism used for storing information. In accordance with some embodiments of the present invention,memory610 is intended to encompass any type of, but is not limited to, volatile memory, nonvolatile memory and dynamic memory. For example,memory610 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,memory610 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 asmemory610.

Memory

610 may be used to store instructions for running one or more applications or modules onprocessor620. For example,memory610 could be used in some embodiments to house all or some of the instructions needed to execute the functionality ofactivation interface module630, account entry andverification module640, encryption/decryption module650, and/orcommunications module660.

Activation interface module

630, according to some embodiments of the present invention, provides an interface for user105 to accessactivation portal110 and communicate withactivation system120,verification system220,UIS generation system240, and/or other components or systems. In some embodiments,activation interface module630 provides one or more graphical user interfaces that can be displayed on a terminal and allow for interaction from user105. For example,activation interface module630 may display accountuser interface screen300 as illustrated inFIG. 3A, createUIS screen340, change UISscreen360, or others.

In accordance with some embodiments of the present invention, account entry andverification module640 is operable to receive account information from the user throughactivation interface module630. This can be done, for example, through one or more graphical user interfaces (e.g., account user interface screen300), 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 andverification module640 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 andverification module640 could process the request to verify the authenticity of each account and then link the desired accounts. In accordance with some embodiments, account entry andverification module640 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 module630 is operable to receive a base user identification string from user105. As described in more detail below, theUIS generation module250 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 andverification module640 is usually encrypted before it is transferred overnetwork115 toactivation system120,verification system220, orUIS generation system240. This encryption can be done using encryption/decryption module650. 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 module650 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 user105, from a graphic interface screen, into a format required by the destination component and/or system. Similarly,communications module660 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.

FIG. 7 is a block diagram700 illustrating components of a UIS generation system (UIS generator)240 that may be used in accordance with some embodiments of the present invention. According to the embodiments shown inFIG. 7,UIS generation system240 can includememory710,processor720,UIS generation module250,base selection module740, encryption/decryption module750,communications module760, randomfield selection module770, randomfield portion generator780, andrandom mapping generator790. Other embodiments of the present invention may include some, all, or none of these modules and components along with other modules or application components. Still yet, some embodiments may incorporate two or more of these modules into a single module and/or associate a portion of the functionality of one or more of these modules with a different module. For example, in some embodiments, randomfield selection module770, randomfield portion generator780, andrandom mapping generator790 may be combined into a single module. According to some embodiments,UIS generation system240 is a component that includes hardware such asmemory710 andprocessor720. However, in other embodiments,UIS generation system240 refers to a software application that can be run on hardware such as a personal computer.

Memory

710 can be any device or mechanism used for storing information as described above with reference tomemory610.Memory710 may be used to store instructions for running one or more applications or modules onprocessor720. For example,memory710 could be used in some embodiments to house all or some of the instructions needed to execute the functionality ofUIS generation module250,base selection module740, encryption/decryption module750,communications module760, randomfield selection module770, randomfield portion generator780, and/orrandom mapping generator790.

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 throughactivation portal110. In some embodiments, the field being randomly selected from the available fields by randomfield selection module770. 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 module750 can encrypt and/or decrypt any messages sent or received bycommunication module760 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 module650 inFIG. 6. Similar tocommunications module660,communications module760 may be used to communicate between systems and/or modules that use different communication protocols, data formats, or messaging routines.

As previously described, the activation portal SSO response sent fromUIS generation system240 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 generator790 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 byrandom mapping generator790 and communicated toactivation portal110 usingcommunications module760.

FIG. 8 is a flowchart illustrating one example of amethod800 for operation ofactivation portal110 in accordance with some embodiments of the present invention. As indicated previously,activation portal110 facilitates the exchange of information betweenactivation system120 and user105 for the activation of a user operation vehicle. Referring toFIG. 8 in conjunction withFIG. 1, according to some embodiments of the present invention,activation system120 can receive a set UIS request or a change UIS request throughactivation portal110 during receivingoperation810. The request can come from a software program for changing or setting a UIS, a graphical user interface screen, a webpage, a telephone call with navigation through menus using the numerical keypad on the phone, a proprietary interface, and/or the like.

Once a request to set a UIS or change a UIS occurs during receivingoperation810, 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 user105 in forwardingoperation820. In this case, user105 enters a base UIS on the set/change UIS webpage which is then encrypted and returned toactivation system120.Activation system120 receives the encrypted UIS atreceipt operation830 and then decrypts the encrypted UIS duringproduction operation840. 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 operation850 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.).

FIG. 9 is a flowchart illustrating an exemplary set ofUIS generation logic900 for generating multiple user identification strings in accordance with some embodiments of the present invention. A base UIS is received atreceipt operation910. As previously discussed, the base, or original, UIS can originate from a user activating the user operation vehicle or requesting a UIS change. In the embodiments illustrated inFIG. 9, once the base UIS is received and processed,user determination operation920 determines the authorized payment types (or functions) associated with the user operation vehicle.

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-specificUIS generation operation930 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:


Function Types Linked to the User		Account-Specific
Operation Vehicle	Base UIS	UIS

Debit	2254	22541
Credit	2254	22542
Accumulated Value	2254	22543
Prepaid	2254	22544
Rewards	2254	22545

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:


Function Types Linked to the User		Account-Specific
Operation Vehicle	Base UIS	UIS

Debit 1	2254	225411
Debit 2	2254	225412
Credit 1	2254	225421
Credit 2	2254	225422
Credit 3	2254	225423
Prepaid	2254	225441
Rewards	2254	225451

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:


Function Types Linked to the User	Base		Account-Specific
Operation Vehicle	UIS	Offset	UIS

Credit	2254	+1	2255
Debit	2254	+2	2256
Accumulated Value	2254	+3	2257
Prepaid	2254	+4	2258
Rewards	2254	+5	2259

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:


				Account-
Function Types Linked to the	Base	Function	Account	Specific
User Operation Vehicle	UIS	Offset	Number	UIS

Credit 1	2254	100	1	2355
Credit 2	2254	100	2	2356
Debit 1	2254	200	1	2455
Debit 2	2254	200	2	2456
Debit 3	2254	200	3	2457
Prepaid	2254	400	1	2655
Rewards	2254	500	1	2755

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:


Function Types Linked to the		Account-
User Operation Vehicle	Base UIS	Specific UIS

Debit	2254	22541
Credit	2254	22542
Prepaid	2254	22543
Rewards	2254	22544

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 thenumber 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.

FIG. 10 illustrates an example of online transaction processing (online authorization request processing) which may be used in some embodiments of the present invention. When a user makes a purchase through an online retailer or merchant1010 a single sign on (SSO) message can be generated. In some embodiments, the SSO message can include various types of information about the transaction or purchase including, for example, purchase amounts. Once generated, the SSO message can be passed to UISpurchase page module1015.Module1015 generates a UIS purchase page that can be displayed through a webpage to the customer making a purchase fromonline retailer1010. The UIS purchase page in some embodiments of the present invention can include a section for the customer to enter user operation vehicle identification information along with a UIS. The customer can then enter the UIS corresponding to the payment function the customer desires to use to complete the purchase.

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 useroperation vehicle platform1020. In accordance with some embodiments, useroperation vehicle platform1020 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 useroperation vehicle platform1020. In some embodiments, the user operation vehicle transaction request is transferred tobank network switch1025 over a communications network, leased line, dedicated communications channel, or the like.

Once the user operation vehicle transaction request is received,bank network switch1025 routes the transaction toverification system1030 over a communications network, leased line, dedicated communications channel, or the like.Verification system1030 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 tobank network switch1025.

In accordance with various embodiments,bank network switch1025 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 operationvehicle function system1035 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 tobank network switch1025.

In some embodiments, the authorization response can be routed frombank network switch1025 toverification1030, where the response is processed and then returned tobank network switch1025. From the bank network switch, the authorization response is routed to useroperation vehicle platform1020 which generates and returns an approval or denial message back toonline retailer1010.

According to some embodiments, adaily settlement process1050 occurs betweenonline retailer1010, user operation vehicle function systems1035 (e.g., accumulated value processing system, debit processing system, credit processing system, etc.), andverification system1030. In some embodiments, daily settlement files are generated based on the payments processed. Some embodiments use banksettlement control module1040, verification settlement control module1045, and retailersettlement control module1055 to generate daily settlement files which are processed throughdaily settlement process1050 between the online retailer and function account holders. While not illustrated inFIG. 10, in some embodiments,daily settlement process1050 is routed to the retailersettlement control module1055 throughbank switch1025.

FIG. 11 illustrates an example of anoperating environment1100 in which some embodiments of the present invention may be utilized. In the embodiments illustrated inFIG. 11, a user can make a purchase atPOI device1105 after activating the user operation vehicle. According to some embodiments, using one of the generated account-specific UIS's, the user can select which payment function will be used to process the transaction. In addition, some embodiments of the present invention provide for the addition of functionality (e.g., rewards, rounding sweep, etc.) to the UIS for use at aPOI device1105.

FIG. 11 includes various components including aPOI device1105,POI application1110,network1115, UIS andreward verification system220,UIS database230, rewardsdatabase1120,network1125,credit processing system1130,debit processing system1135, rewards processing system1140, and other processing systems represented by1145. Examples of other processing systems include, but are not limited to, store value processing systems, gift card processing systems, consumer to consumer payment systems, proprietary payment systems, as well as others.

According to some embodiments, a user can append additional characters to the end of the UIS atPOI device1105. In some embodiments,POI device1105 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 device1105 treats a MUIS and a UIS in the same manner. POI device705 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 acrossnetwork1115 toverification system220 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 inUIS database230 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 inreward code database1120. 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 acredit processing system1130, adebit processing system1135, a rewards processing system1140, other processing systems1145 (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 toFIG. 15.

In the embodiments illustrated inFIG. 11, the processing systems1130-1145 are different entities and may be located at different physical locations or use unique routing information. In some embodiments, however, the processing systems are part of a centralized system which includes one or more payment processing subsystems for processing credit, debit, rewards, prepaid, consumer to consumer payments, and the like. As such, when the payment is received at the centralized system, a determination is made as to how the payment should be processed.

In some embodiments, the processing systems1130-1145 are in communication with one another (e.g., throughnetwork1125, 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.

FIG. 12 is a block diagram illustrating components of a POI device1205 that may be used in accordance with some embodiments of the present invention. POI device1205 can be a standard POI device currently in use today, or a new device with increased functionality. According to the embodiments shown inFIG. 12,POI device1105 includesmemory1210,processor1220,power supply1230,POI application1110,user interface module1240, encryption/decryption module1250, andcommunications module1260. Other embodiments of the present invention may include some, all, or none of these modules and components along with other modules and/or application components. Still yet, some embodiments may incorporate two or more of these modules into a single module and/or associate a portion of the functionality of one or more of these modules with a different module. For example, in some embodiments,user interface module1240 can be combined withPOI application1110.

Memory

1210 can be any device or mechanism used for storing information. In accordance with some embodiments of the present invention,memory1210 is intended to encompass any type of, but is not limited to, volatile memory, nonvolatile memory and dynamic memory. For example,memory1210 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,memory1210 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 asmemory1210.

In some embodiments,memory1210 can be used to store instructions for running one or more applications or modules onprocessor1220. For example,memory1210 could be used to house all or some of the instructions needed to execute the functionality ofPOI application1110,user interface module1240, and/orcommunications module1260.

Some embodiments ofPOI device1105 includepower supply1230 which can be any type of device that supplies the necessary power required byPOI device1105. For example,power supply1230 may be an independent rechargeable battery, multiple batteries, and/or other external power supplies. The power supply may be internal or external toPOI device1105. 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 toPOI device1105. For example,POI application1110 can include intelligence systems such as real-time inventory information. In some embodiments, part of the reward verification system inverification system220 may be accessed throughPOI application1110. 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 module1240 is a numerical keypad with software running onprocessor1220 which monitors for entry of UIS. Decryption/encryption module1250 is used to encrypt any information that has to be transferred acrossnetwork1115 and decrypt any incoming messages that are encrypted.Communications module1260 in some embodiments of the present invention is configured to translate any messages fromPOI device1105 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 module1260 can route encrypted messages todecryption module1250 and can requestencryption module1250 encrypt outgoing messages.

FIG. 13 is a block diagram illustrating components of averification system1300 that may be used in accordance with some embodiments of the present invention. According to the embodiments shown inFIG. 13,verification system220 can includecommunications module1310, encryption/decryption module1320,parsing module1330,UIS verification module1340,function determination module1350, function routing module (switch)1360, and rewardverification module1370. Other embodiments of the present invention may include some, all, or none of these modules along with other modules and/or application components. Still yet, some embodiments may incorporate two or more of these modules into a single module and/or associate a portion of the functionality of one or more of these modules with a different module.

According to some embodiments of the present invention, an authorization request (or a transaction request) is received atverification system220 from a POI device. All requests may be received throughcommunications module1310 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 atcommunications module1310, the request is routed to encryption/decryption module1320 if the request is encrypted. Encryption/decryption module1320 decrypts the request. Also, in some embodiments,communication module1310 sends the payment request to a function processing system to determine an approval or denial of a transaction if theUIS verification module1340 determines the UIS corresponds to the primary account UIS. Similarly,communication module1310 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 usingparsing module1330 in embodiments ofverification system220. For example,parsing module1330 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 functiondetermination module1350 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 module1360 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 module1370 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 system220 (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 toverification system220, 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.

FIG. 14 is a block diagram illustrating various components that may be a part of a real-timepayment processing network1400 in accordance with some embodiments of the present invention. Embodiments of the real-timepayment processing network1400 use various methods for processing a reward code which is presented by the user. The reward code may be presented in conjunction with a user's UIS (e.g., in a MUIS) to add functionality to the UIS when the user purchases goods or services at a POI. According to some embodiments, the user operation vehicle (e.g., card) can be associated with one or more accrued value or payment accounts (e.g., prepaid, debit, credit, etc.) and is presented at aPOI user interface1410 byuser1405.

The user's primary account number is received at a POI device throughPOI user interface1410 in some embodiments of the present invention. For example, depending on the type of user operation vehicle being used,POI user interface1410 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 aPOI application1110 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 application1110 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.User1405 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 byPOI application1110,POI application1110 sends the primary account number, UIS, and reward numbers to decryption/encryption module1250 where the information is encrypted to generate an encrypted input string of numbers before being transferred overnetwork1115 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 module1420. In the embodiments illustrated inFIG. 14, after the string of numbers is decrypted (e.g., by decryptor1420) the result is communicated to UIS parsing andauthentication module1425.Module1425 parses the decrypted input string into the various tokens and verifiesuser1405 is authorized to use the user operation vehicle by verifying the UIS provided corresponds with the primary account number. A determination is made as to whether input string contains reward numbers using reward determination logic.

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.Module1430 uses the information provided by UIS parsing andauthentication module1425 to determine the reward and/or action associated with the reward numbers in the input string.Reward application module1435, 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 topayment authorization module1440 by UIS parsing andauthentication module1425. As another example, a unique UIS can be supplied topayment authorization module1440 by UIS parsing andauthentication module1425. 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 bypayment authorization module1440 for routing the payment request. When the request to fund the transaction is approved or denied, the result is passed to the POI device.

FIG. 15 is a block diagram illustrating various components that may be a part of a batchpayment processing network1500 in accordance with some embodiments of the present invention. According to the embodiments illustrated inFIG. 15, batch processing of payment requests occur in much the same way as real-time payment processing requests up untilpayment authorization module1440. Atpayment authorization module1440, various pieces of transaction information are received from the UIS parsing andauthentication module1425. Examples of the transaction information include, but are not limited to, the primary account number, UIS, reward code, function selection, payment request amount, merchant information, and/or the like.

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. Batchpayment processing network1500 describes some ways these transactions can be processed in accordance with various embodiments of the present invention.

Unlike the real-timepayment processing network1400, some piece of the transactional information (e.g., the application of the reward code) is not processed immediately but is stored inpayment database1545. 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 module1430 pulls the information frompayment database1545 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 ontoreward application module1435 where the reward action is applied and the transaction requests are passed ontopayment authorization module1440.

FIG. 16 is a block diagram illustrating various components that may be a part of a UIS parsing andauthentication module1425 in accordance with some embodiments of the present invention. According to some embodiments, an incoming authorization or transaction request that includes a string of characters can be received from a POI device.Module1425 can parse the string into the various tokens, verify whether a user is authorized to use the user operation vehicle, and determine whether an input string of characters contains a reward code. According to the embodiments shown inFIG. 16, UIS parsing andauthentication module1425 can include the following components: UIS/Primaryaccount identification module1645, rewardcode parsing module1650, functionidentification module1655, andaccount database1660.

The transaction request, including the input string of characters, is received at UIS/Primaryaccount identification module1645. 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.Module1645 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.

Rewardcode parsing module1650 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, rewardcode parsing module1650 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/Primaryaccount identification module1645 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 module1655 is in communication withaccount database1660. Using the unique UIS, the function selector, or some other means of account identification,module1655 is able to look up account information indatabase1660 and verify that the user is authorized to request a transaction.

FIG. 17 is a block diagram illustrating various components that may be a part ofreward verification module1430 in accordance with some embodiments of the present invention. According to some embodiments of the present invention, if a determination is made that reward numbers exist in the input string, the reward numbers are passed to rewardverification module1430.Module1430 uses the information provided by UIS parsing andauthentication module1425 to determine the reward and/or action associated with the reward numbers in the input string.

In some embodiments,reward verification module1430 receives information about the transaction request. For example,reward verification module1430 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 module1735 and rewardstring identification module1730 can be used to determine the appropriate reward action in accordance with various embodiments of the present invention.

Rewardstring identification module1730 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 rewardstring identification module1730 requests that customer/merchant identification module1735 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 usingreward database1440 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 rewardstring identification module1730 determines that this code is only valid at Merchant A, a request can be made for merchant identification through customer/merchant identification module1735. Once the request is received, thenmodule1735 determines whether the user is making the purchase specifically from Merchant A and returns the merchant identification tomodule1730.

FIG. 18 is aflowchart illustrating operations1800 for processing a transaction from a POI device (e.g., a point of sale device) in accordance with some embodiments of the present invention. According to the embodiments of the present invention illustrated inFIG. 18, an input string is received from a POI device during receivingoperation1810. The input string may include one or more of a reward code, delayed payment option, a function selector, and/or a UIS. The POI device can be any mechanism, from a card reader to a personal computer, that can be used to facilitate the completion of a transaction with a merchant. According to some embodiments, once the input string is received it may or may not be encrypted before being transferred to the processing network. If the input string is encrypted, then a decryption can occur duringdecryption operation1820 in accordance with some embodiments of the present invention before further processing of the input string.

Duringverification operation1830, 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.

Onceverification operation1830 is complete,determination operation1840 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 rewardnumber decision operation1850. According to some embodiments, valid rewardnumber decision operation1850 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 tofunds verification operation1870. If a determination is made that a valid reward number exists, then the reward action is determined and the processing operations branch to rewardapplication operation1860 where the reward action is applied. In some embodiments,decision operation1850 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 thereward application operation1860 finishes applying the reward action (e.g., five percent discount, ten dollars off, etc.), the transaction processing operations branch tofunds verification operation1870.Funds verification operation1870 verifies the funds are available in the account (e.g., using a payment processing system). If the funds are available, thenauthorization operation1880 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), thenauthorization operation1880 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.

FIG. 19 is a block diagram illustrating various components that may be a part of an accumulated value function processing system (accumulated value function processor)1900 in accordance with some embodiments of the present invention. In accordance with the embodiments illustrated inFIG. 19, a user1905 makes a purchase at a merchant using an accumulated value function associated with a user operation vehicle. Merchant processors1910 (e.g., processors within a POI) generate an authorization request and transmit the authorization request to processing androuting network1915. Processing androuting network1915 can include, for example,network1115,verification system220, and processing systems1130-1145.

A determination is made within the processing and routing network to route the authorization request to accumulatedvalue authorizer1920 for processing. Once the authorization request is received, accumulatedvalue authorizer1920 queries account and balancesdatabase1925 to determine the available balance for the accumulated value function. The authorization request can also be logged inauthorization log1930 along with the action taken by accruedvalue authorizer1920.

If the balance of the account is determined to have insufficient accrued value to cover the purchase, the accumulatedvalue authorizer1920 can deny the transaction, partially approve the transaction, or apply the balance and return a modified authorization request to the processing androuting network1915 where another function associated with the user operation vehicle can be charged, or the balance can be returned to the processing androuting network1915 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 accumulatedvalue authorizer1920 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 accumulatedvalue processing module1935. The batch accumulatedvalue processing module1935 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 themerchant processors1910.

In addition to processing transaction using accumulated value functions, the accumulated valuefunction processing system1900 also credits accrued value to the accumulated value function account. For example, when user1905 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 accumulatedvalue authorizer1920. The accumulatedvalue authorizer1920 makes a determination using accumulation logic of the amount that the accumulated value account should be credited. This information is passed to the batch accumulatedvalue processing module1935 where the user operation vehicle information is verified using the useroperation vehicle database1945 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 valuefunction processing system1900. 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.

FIG. 20 is an example of apromotional flyer2000 that includes reward codes that may be used in some embodiments of the present invention. WhileFIG. 20 illustrates apromotional flyer2000 that includes reward codes, the reward codes can come from any number of places. For example, according to some embodiments, reward codes can be found on food packaging (e.g., under a bottle cap, the back of a box, etc.), television advertisements, promotional flyers, coupon book, newspaper advertisements, automated telephone calls (e.g., from outbound voice response units), promotional emails, short messaging system (SMS) message, and/or the like. In some embodiments, the promotional flyers can be created with paper, plastic, or other material. The promotional codes can take any form from solely numerical strings to alphanumeric strings.

FIG. 20 shows acommunication region2005 where text, graphics, drawings, pictures, and/or the like can be used to convey information about the promotion to the viewer. In the embodiments shown inFIG. 20, belowcommunication region2005 are three reward regions2010a-2010c. However, in other embodiments, the place of the reward regions and the number of coupons can vary.

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 (2025aand2025c) 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 Overview

Some 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,FIG. 21 is an example of acomputer system2100 with which embodiments of the present invention may be utilized. According to the present example, the computer system includes abus2101, at least oneprocessor2102, at least onecommunication port2103, amain memory2104, aremovable storage media2105, a read onlymemory2106, and amass storage2107. In some embodiments, an encryption/decryption hardware component (not shown) may be present or associated with thecomputer system2100. Examples of commercially available components are currently available from ATALLA, THALES, and IBM. In some embodiments one or more nCipher host security modules can be used.

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 thecomputer system2100 connects.

Main memory

2104 can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known in the art. Read onlymemory2106 can be any static storage device(s) such as Programmable Read Only Memory (PROM) chips for storing static information such as instructions forprocessor2102.

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.Bus2101 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.