Source: http://www.google.com/patents/US20090037333?ie=ISO-8859-1
Timestamp: 2014-09-23 13:37:14
Document Index: 760122762

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60']

Patent US20090037333 - Credit cards system and method having additional features - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA credit card system is provided which has the added feature of providing additional limited use credit card numbers and/or cards. These numbers and/or cards can be used for a single or limited use transaction, thereby reducing the potential for fraudulent reuse of these numbers and/or cards. The credit...http://www.google.com/patents/US20090037333?utm_source=gb-gplus-sharePatent US20090037333 - Credit cards system and method having additional featuresAdvanced Patent SearchPublication numberUS20090037333 A1Publication typeApplicationApplication numberUS 12/219,952Publication dateFeb 5, 2009Filing dateJul 30, 2008Priority dateMar 25, 1998Also published asCA2322356A1, CA2322356C, CA2362033A1, CA2362033C, CN1292131A, DE1029311T1, DE69900169D1, DE69900169T2, DE69900169T3, EP1029311A1, EP1029311B1, EP1029311B2, EP1115095A2, EP1115095A3, EP1729267A2, EP1729267A3, US6636833, US7136835, US7567934, US7571142, US7593896, US8676707, US8756150, US20030028481, US20090070260, US20090134217, US20130204781, US20140122340, WO1999049424A1Publication number12219952, 219952, US 2009/0037333 A1, US 2009/037333 A1, US 20090037333 A1, US 20090037333A1, US 2009037333 A1, US 2009037333A1, US-A1-20090037333, US-A1-2009037333, US2009/0037333A1, US2009/037333A1, US20090037333 A1, US20090037333A1, US2009037333 A1, US2009037333A1InventorsDaniel Ian Flitcroft, Garry LyonsOriginal AssigneeOrbis Patents LimitedExport CitationBiBTeX, EndNote, RefManNon-Patent Citations (3), Referenced by (35), Classifications (62) External Links: USPTO, USPTO Assignment, EspacenetCredit cards system and method having additional featuresUS 20090037333 A1Abstract A credit card system is provided which has the added feature of providing additional limited use credit card numbers and/or cards. These numbers and/or cards can be used for a single or limited use transaction, thereby reducing the potential for fraudulent reuse of these numbers and/or cards. The credit card system finds application to �card remote� transactions such as by phone or Internet. Additionally, when a single use or limited use credit card is used for �card present� transactions, so called �skimming� fraud is eliminated. Various other features enhance the credit card system, which will allow secure trade without the use of elaborate encryption techniques. Methods for limiting, distributing and using a limited use card number, controlling the validity of a limited use credit card number, conducting a limited use credit card number transaction and providing remote access devices for accessing a limited use credit card number are also provided.
1. A method of implementing a transaction system using controlled payment numbers (CPNs), the method comprising:
assigning a unique CPN to a user, the CPN constituting a payment instrument for use in a financial transaction; allocating a monetary amount to the unique CPN by a funding entity; establishing limitations on use of the CPN by the funding entity; associating the unique CPN with a master account number of the user in a database of a CPN issuer, and associating the limitations on use of the CPN established by the funding entity with the unique CPN assigned to the user; issuing the unique CPN to the user by the CPN issuer; receiving an authorization request from a merchant for a transaction conducted with the CPN; and authorizing the transaction if the transaction complies with the limitations established by the funding entity. 2. The method of claim 1, wherein the limitations on use established by the funding entity include monetary restrictions to which the CPN is limited for conducting transactions with at least one merchant.
3. The method of claim 2, wherein the monetary restrictions are modifiable by the funding entity for each of the at least one merchant.
4. The method of claim 1, wherein the funding entity is an individual or organization other than the user.
5. The method of claim 1, wherein the limitations on use include a combination of a present transaction amount limit and one of a merchant and merchant type.
6. The method of claim 1, wherein the CPN issued to the user constitutes a different number than the master account number of the user and functions as an authorized substitute for the account of the customer in a credit card transaction.
7. The method of claim 1, wherein said CPN is activated and limited to a predefined monetary amount as settlement of a claim by the user against the funding party.
8. The method of claim 1, wherein the CPN is issued to the user by bearing indicia of the CPN on a financial transaction card.
9. The method of claim 1, wherein the CPN is issued to the user by transmitting the CPN to an electronic device of the user configured to connect the Internet.
10. The method of claim 1, further comprising establishing limitations on use of the CPN by the user.
11. A method of implementing a transaction system using controlled payment numbers (CPNs), the method comprising:
associating, by a CPN issuer, a unique CPN with a master account number of a user, the CPN constituting a payment instrument for use in a financial transaction and constituting an authorized substitute for the master account number of the user; and issuing the unique CPN to the user for use in a transaction with a merchant if the merchant does not accept the master account number of the user as a form of payment for transactions. 12. A method of facilitating credit card transactions between a user and a merchant, the method comprising:
linking a unique controlled payment number (CPN) with a plurality of financial accounts of a user, the CPN constituting a payment instrument for use in a financial transaction and constituting an authorized substitute for the financial accounts of the user; receiving, by a CPN issuer, routing instructions from the user defining a respective one of the plurality of financial accounts of the user is to be processed based on at least one of a type of a transaction and a monetary amount of a transaction; issuing the CPN to the user by the CPN issuer; receiving an authorization request from a merchant for a transaction conducted with the issued CPN; processing the transaction against the one of the plurality of financial accounts of the user based on information contained in the authorization request; and authorizing the transaction if the one of the plurality of financial accounts of the user is processed for the transaction. 13. The method of claim 12, wherein the one of the plurality of financial accounts of the user is processed if the one account contains sufficient funds for the transaction.
14. The method of claim 12, wherein unique purchase order information is associated with the transaction and associated with the one of the plurality of financial accounts of the user against which the transaction was processed. Description
This application claims the benefit of U.S. Provisional Application No. 60/935,187 filed Jul. 30, 2007. This application is a continuation-in-part of U.S. Non-Provisional application Ser. No. 10/160,178 filed a continuation-in-part of U.S. Non-Provisional application Ser. No. 09/506,830 filed Jan. 18, 2000, which in turn is a continuation-in-part of U.S. Non-Provisional application Ser. No. 09/235,836 filed Jan. 22, 1999 and now U.S. Pat. No. 6,636,833. This application claims the benefit of U.S. Provisional Application No. 60/935,187 filed Jul. 30, 2007; U.S. Provisional Application No. 60/295,020 filed Jun. 4, 2001; U.S. Provisional Application No. 60/120,747 filed Feb. 18, 1999; U.S. Provisional Application No. 60/134,027 filed May 13, 1999; U.S. Provisional Application No. 60/144,875 filed Jul. 20, 1999; U.S. Provisional Application No. 60/147,153 filed Aug. 4, 1999; U.S. Provisional Application No. 60/099,614 filed Sep. 9, 1998; U.S. Provisional Application No. 60/098,175 filed Aug. 26, 1998; U.S. Provisional Application No. 60/092,500 filed Jul. 13, 1998; Irish Application No. S98 0458 filed Jun. 15, 1998; Irish Application No. S98 0346 filed May 5, 1998; Irish Application No. S98 0223 filed Mar. 25, 1998. The entire contents of each of these applications are incorporated herein by reference.
This present disclosure relates to a credit card system and method, and more particularly, to a credit card system and method offering reduced potential of credit card number misuse.
The latter are equally concerned about fraud, being well aware that ultimately the user must pay for the fraud. However, there are particular personal concerns for the consumer in that the fraudulent use of the credit card by misuse of the credit card number by a third party may not become apparent for some time. This can happen even if the card is still in his or her possession. Further, when fraud does occur the consumer has the task of persuading the credit card provider that fraud by another did indeed occur.
For remote credit card use, the credit card holder has to provide details of name, master credit card number, expiration date and address and often many other pieces of information for verification; the storing and updating of the information is expensive but necessary. This in itself is a considerable security risk as anybody will appreciate that this information could be used to fraudulently charge goods and services to the card holder's credit card account. Such fraudulent use is not limited to those people to whom the credit card information has been given legitimately, but extends to anybody who can illegitimately obtain such details. A major problem in relation to this form of fraud is that the credit card may still be in the possession of the legitimate holder as these fraudulent transactions are taking place. This is often referred to as �compromised numbers� fraud. Indeed all this fraud needs is one dishonest staff member, for example in a shop, hotel or restaurant, to record the credit card number. It is thus not the same as card theft.
OBJECTS AND SUMMARY OF THE DISCLOSURE Many solutions have been proposed to the problem of security of credit card transactions. However, none of them allow the use of existing credit cards and existing credit card formats and terminal equipment in the exiting credit card system, which includes provisions for charge-backs, etc. Ideally, as realized by the present inventors, the solution would be to obtain the functionality of a credit card, while never in fact revealing the master credit card number. Unfortunately, the only way to ensure that master credit card numbers cannot be used fraudulently is to never transmit the master credit card number by any direct route, i.e., phone, mail, Internet or even to print out the master credit card number during the transaction, such as is commonly the case at present.
According to exemplary embodiments as described in U.S. non-provisional application Ser. Nos. 09/235,836 and 09/506,830, a more secure way of using existing credit cards and, in particular, using existing credit cards in remote credit card transactions was provided. These earlier applications were specifically directed towards providing a more secure way of using existing credit cards generally which will not require any major modifications to existing credit card systems. They are further directed towards providing a credit card system that will be user friendly and will provide customers with a greater confidence in the security of the system.
The present disclosure includes a number of credit card products, which have predefined characteristics.
These and other advantages of the present disclosure are satisfied by a first exemplary embodiment, which pertains to a financial transaction system capable of using at least one limited use credit card number, which is limited in use by a party other than a limited use credit card number issuer and which is associated with the master account number of a customer. The inventive method of controlling the validity of the limited use credit card number comprises the steps of: sending to a user from a limited use credit card number issuer a limited use credit card number; communicating with a limited use card number card issuer to establish limitations on the use of the limited use credit card number by a third party before it can be used in a transaction by the user; and authorizing transactions which meet the established limitations and denying other transactions by comparing at a central location the attempted use to the established limitations on use.
BRIEF DESCRIPTION OF THE DRAWINGS The foregoing, and other, objects, features and advantages of the present disclosure will be more readily understood upon reading the following detailed description in conjunction with the drawings in which:
FIG. 1 shows an exemplary system for implementing the present disclosure;
FIG. 16 is a flow chart illustrating an exemplary method of providing remote access devices for accessing limited use credit card numbers;
FIG. 17 is a diagram illustrating how the present disclosure can place limitations on an configurable plastic payment card to facilitate card-present applications;
FIG. 18 illustrate an exemplary illustration of a Controlled Payment Number (CPN);
FIG. 19 illustrates another exemplary illustration of a CPN;
FIG. 20 illustrates yet another exemplary illustration of a CPN;
FIG. 21 illustrates a CPN in use;
FIG. 22 illustrates a pay everywhere embodiment;
FIG. 23 illustrates a multi-card embodiment;
FIG. 24 illustrates Instant Credit embodiment; and
FIGS. 25-27 illustrate an exemplary embodiment described as �Pay with your Phone.�
DETAILED DESCRIPTION In this specification the term �credit card� refers to credit cards (MasterCard�, Visa�, Diners Club�, etc.) as well as charge cards (e.g., American Express�, some department store cards), debit cards such as those that are usable at ATMs and many other locations or that are associated with a particular account, and hybrids thereof (e.g., extended payment American Express�, bank debit cards with the Visa� logo, etc.) or any other present or future financial transaction card having similar characteristics. Also, the terms �master credit card number� and �master credit card� refer to the credit card number and the credit card as generally understood, namely, that which is allocated by the credit card provider to the customer for his or her account for multiple uses for a renewable period and a credit limit. It will be appreciated that an account may have many master credit cards in the sense of this specification. For example, a corporation may provide many of its employees with credit cards but essentially each of these employees holds a master credit card even if there is only one customer account. Each of these master credit cards will have a unique master credit card number, which set of master credit card numbers will be linked to the account. Similarly, in families, various members of the family may hold a master credit card, all of which are paid for out of the one customer account.
Additionally, the master credit card account can be in some embodiments something other than a credit card account. For instance, while not otherwise affecting the formatting or processing of the limited use credit card numbers as described herein, the master card number can be a prepaid account or another type of account, such as a utility, telephone service provider or Internet Service Provider (ISP) account. The utility company, telephone company, ISP or other account holder would generate a bill, which, in possible addition to or separate from the regular bill, would include a listing of limited use credit card transactions. An advantage of this type of arrangement is that the service provider already has information as to a pool of individuals and their credit worthiness, as well as low increased overhead due to the already in place billing system. In these embodiments, the master account may but likely does not have the format of a standard credit card or the like.
The term �limited-use� credit card number is used to encompass at least both the embodiment in which the credit card is designated for a single use, and the embodiment in which the credit card is designated for multiple uses provided that the charges accrued do not exceed a prescribed threshold or thresholds, such as a total single charge, total charges over a limited time period, a total charge in a single transaction, etc. A common feature is that the limited use credit card number is deactivated upon satisfaction of a limited-use condition, and not just the expiration date of the card. Stated differently, the limited-use credit card number is deactivated upon a use-triggered condition which occurs subsequent to assignment of at least one credit card number.
1. Overview of System Features There are at least two basic different ways of carrying out the present disclosure. In summary, the two ways are the allocation of additional credit card numbers for remote trade and the provision of what are effectively disposable credit cards for remote and card present trade, both of which have the feature of, in the case of single use or in the case of multiple use, protecting against the worst effects of compromised numbers fraud or skimming.
In a refinement of the present disclosure, it is possible to control the manner in which an actual transaction is carried out as a further protection against unscrupulous providers of goods and services.
Essentially, there are certain matters that will be considered in relation to the present disclosure. They are the operational or functional features insofar as they affect customers, and then there are the technical features, namely how exemplary embodiments of the present disclosure are implemented, how the exemplary embodiments are provided to the customers, and finally, how the exemplary embodiments are handled by the providers of goods and services and the processors of the credit cards, i.e., the financial institutions and/or their service providers.
The operational or functional features of the present disclosure will be discussed first in the context of a standard credit card system.
One basic feature of the present disclosure is to provide in a credit card system such that each master credit card holder could be provided with one or more of the following: 1) additional single use credit card numbers for remote transactions; 2) multiple use credit card numbers for remote transactions; 3) single use additional credit cards for remote and card present transactions; and 4) multiple use credit cards for remote and card present transactions.
Dealing first with the situation where a master credit card holder has an additional credit card number allocated to him or her for a single use, it will be appreciated that since the number can only be used for one single transaction, the fact that the number is in anybody else's hands is irrelevant as it has been deactivated and the master credit card number is not revealed to the third party. Various other features may be added to such single use credit card numbers. For example, the value of the transaction can be limited, thus the master credit card holder can have a plurality of single use credit card numbers of differing values. For example, when a remote trade is carried out, the master credit card holder will use a credit card number which has a credit card limit only marginally above or equal to that of the value of the transaction. This would reduce the chances of or prevent an unscrupulous trader from using the credit card number to supply additional goods or services over those ordered or to increase the agreed charge.
A second exemplary embodiment provides the master credit card holder with an additional credit card number for use in a remote trade, which credit card number could have, as in the previous example of the present disclosure, a credit limit for each specific transaction or a credit limit such that when the aggregate amount of a series of transactions exceeded a specific credit limit, the credit card number would be canceled, invalidated or in some other way deactivated. Similarly, the multiple use credit card number could be limited to, for example, five uses with a credit limit not exceeding $100 in each transaction and an aggregate credit limit not exceeding $400. Similarly, a time restriction could be put on such a credit card number in that it would be deactivated if it was used with frequency above (or below) a given threshold, for example, more than once a week. These limits and restrictions on the use of a limited-use credit card number can be and normally would be controlled by the consumer, such as the card holder or a person overseeing a card holder's use (e.g., a parent, employer, gift giver, etc.). Hence, for a limited-use credit card number, the limitations of which are defined by a consumer rather than a card issuer, the term Controlled Payment Number, or CPN has been coined.
It will be appreciated that the limits that can be placed on the use of a single use credit number or a multiple-use credit card number or CPN are almost limitless and those having skill in the art will consider other ways in which the use of the credit card number could be limited, whether it be by time, by amount, by frequency of use, by geographical region, by merchant, by merchant class, or by purpose or use (such as limited to Internet trade and so on), or by some combination of these separate criteria.
The third way in which the present disclosure could be carried out is by physically providing additional single use credit cards each of which would have a unique additional credit card number. Such additional single use credit cards could then be used both for remote trade by using the additional credit card numbers for respective transactions, and for �card present� trade where each card would be �swiped� in the normal manner. Such a disposable credit card could be made like any common credit card, or from a relatively inexpensive material, such as cardboard or thin plastic, with the relevant information entered into it in readable (e.g., magnetic) form, as is already the case with many forms of passes for use in public transport and the like. Again, substantially the same features as with the credit card number could be provided. Thus, for example, the disposable credit card could be limited to use geographically, to a use, to an amount, to a frequency of use, to an expiration date, and so on. Again, those skilled in the art will appreciate that there are many variations to this concept.
Another way of carrying out the present disclosure is to provide a master credit card holder with a multiple-use additional credit card, where the additional credit card provides any limitations as to limited-use triggering conditions that may be desired.
Ideally, irrespective of the manner in which the present disclosure is carried out, the master credit card holder would be provided with either a plurality of single use additional credit card numbers or multiple-use credit card numbers or a mixture of single and multiple-use credits cards. Several specific products are described in the last section of the present application.
Effectively, the present disclosure solves the problem by obtaining the functionality of a credit card while never in fact revealing the master credit card number as the master credit card number need never be given in a remote transaction. Further, the master credit card itself need never be given to a trader.
In another exemplary embodiment of the present disclosure, it is envisaged that people who do not hold master credit cards could purchase disposable credit cards which would have a credit limit for the total purchases thereon equal to the amount for which the credit card was purchased. These could then be used for both card present and card remote trade, the only proviso being that if the credit limit was not reached it will then be necessary for a refund to be given by the financial institution or credit card provider. An obvious way of obtaining such a refund would be through an automatic teller machine (ATM). In this way, the existing credit card transaction system is employed and the card holder is given the convenience of having a credit card.
As an alternative, the above-discussed cards could be, in effect, debit cards in the true sense, in which funds are withdrawn against a customer's account. In this case, the �credit card� issued, whether it be a one time use card or multi-use card, and whether it has a credit limit or not, would be used to debit the account immediately. Preferably, the credit card issued in these circumstances would be single use with or without a transaction amount limit and would be used and processed by the customer and merchant for a transaction as if it were a credit card, while in the customer's bank it would be treated like any other debit to the account.
Various aspects of the present disclosure may be embodied in a general purpose digital computer that is running a program or program segments originating from a computer readable or usable recording medium, such medium including but not limited to electrical or magnetic storage media (e.g., ROMs, EEPROMs, RAM, floppy disks, hard disks, etc.), optically readable media (e.g., CD-ROMs, DVDs, etc.), or combinations thereof. A functional program, code and code segments, used to implement the present disclosure can be derived by a skilled computer programmer from the description of the present disclosure contained herein.
FIG. 1 shows an exemplary overview of a system for implementing the limited use credit card system of the present disclosure. The system 100 comprises a central processing station 102, which, according to exemplary embodiments, may be operated by the credit card provider. Generally, this station 102 receives and processes remotely generated credit card transactions. The credit card transactions can originate from a merchant in the conventional manner, e.g., by swiping a credit card through a card swipe unit 106. Alternatively, the credit card transaction requests can originate from any remote electronic device 104 (e.g., a personal computer). These remote devices can interface with the central processing station 102 through any type of network, including any type of public or propriety networks, or some combination thereof. For instance, the personal computer 104 interfaces with the central processing station 102 via the Internet 112. Actually, there may be one or more merchant computer devices (not shown) which receive credit card transactions from the remote electronic device 104, and then forward these requests to the central processing station 102. The central processing station 102 can also interface with other types of remote devices, such as a wireless (e.g., cellular telephone) device 140, via radio communication using transmitting/receiving antenna 138. Other intermediary components can be interposed, as is conventional.
The central processing station 102 itself may include a central processing unit 120, which interfaces with the remote units via network I/O unit 118. The central processing unit 120 has access to a database of credit card numbers 124, a subset 126 of which can be designated as being available for limited use (referred to as the �available range�). Also, the central processing unit 120 has access to a central database 122, referred to as a �conditions� database. This database is a general purpose database which stores information regarding customers' accounts, such as information regarding various conditions which apply to each customer's account. Further, this database 122 may store the mapping between a customer's fixed master credit card number and any outstanding associated limited use credit cards, using, for instance, some type of linked-list mechanism. Databases 122 and 124 are shown separately only to illustrate the type of information which may be maintained by the central processing station 102; the information in these databases can be comingled in a common database in a manner well understood by those having skill in the data processing arts. For instance, each limited use credit card number can be stored with a field, which identifies its master account, and various conditions regarding its use.
Once a number is deactivated, this number can not be fraudulently reused. Hence, the risk of fraudulent capture of these numbers over the Internet (or via other transmission means) effectively disappears. In an alternative embodiment of the present disclosure, these deactivated numbers can be reactivated provided that a sufficiently long time since their first activation has transpired. Provided that there is a sufficiently large number of limited use credit card numbers to choose from, it would be possible to wait a long time before it was necessary to repeat any numbers. At this point, it would be very unlikely that someone who had wrongfully intercepted a credit card number years ago would be motivated to fraudulently use it before the rightful owner.
Having set forth a summary of how the present disclosure can be implemented, further details are provided in the following.
In relation to the actual supply of the additional credit card numbers, this will not cause any difficulties to the credit card provider. For example, with a standard master credit card number, there are up to fifteen or more digits, the first of which is used to identify the credit card provider, e.g., American Express7, VISA7, Mastercard7, etc. For major banks, three digits are used to identify the issuing bank. The last digit in a typical sixteen digit master credit card number is a checksum used to confirm that the number is a valid number. This leaves a total of up to 11 digits or more for the account identifying number and the expiration date. In some instances, the expiration date may not be sent back for clearance, while with certain credit card providers, additional credit card numbers or even additional information is required for clearance. For example, certain credit card providers print additional numbers on the card, which additional numbers are not embossed on the card and do not form part of the master credit card number. These additional printed and non-embossed credit card numbers can be used to identify that the person proffering the card for a non-present card transaction is actually in possession of the card when the order is made whether it be in writing or by phone. There are many devices, digits, pieces of information, etc. used by a credit card issuer or processor working for a credit card issuer to clear the credit card for the specific transaction. According to another embodiment, when issuing additional credit card numbers in accordance with the present disclosure, such additional credit card numbers could include a code which would identify that the person using the additional credit card number in a remote transaction is the one to whom the numbers were sent or, in the case of a disposable credit card, is the one to whom the disposable credit card was sent.
A preferred feature of these additional credit card numbers is that they be constrained to be in the correct format for a credit card number with a valid check sum, while at the same time be mathematically unrelated to each other or to the master credit card. In certain situations, for single use numbers, the expiration date is virtually irrelevant. Thus, using the month code of the expiration date with said eleven digits, there are 12�1011, i.e., 1.2�1012, i.e., 1,200 billion possible unique codes available for any given credit card provider. This would allow for 50 transactions a month for 10 years for 200 million account holders, before any codes would have to be recycled or a new header code introduced. When it is understood that there are then another 104 header numbers that a credit card provider can use, it will be appreciated that the structure and arrangement of existing master credit card numbers is sufficient to operate present disclosure with the advantage that the existing infrastructure of dealing with credit card transactions can be used with minimum modification. All that is required for the credit card provider is to store the generated numbers against the master credit card number or other type of account number.
Alternatively, an opaque removable cover can conceal a message such as �used.� The opaque removable cover can be a scratch-off layer that is scratched off before or after the card is used. The scratch-off layer can resemble the layer that is often used to cover lottery numbers or the like. Or alternatively, the single use cards can be placed in a self-contained container that resembles a razor blade dispenser. (Step 516). The owner can remove a single use card from a first compartment and then place the used card into a second compartment.
FIG. 6 is a flow chart illustrating an exemplary process for electronically using credit card numbers. The software can be launched either on its own or activated by an icon integrated into an Internet browser. (Step 602). The software can provide a simple interface with a graphical appearance that exploits familiar images of credit cards and/or ATM's. The software can be programmed using Java code or a Java core embedded in a c/c++ application or equivalent or similar programming language.
Many of the procedures associated with limited use cards represent functions already performed by the clearing systems. These existing functions include: adding new credit/debit card numbers to the processing databases; allowing these card numbers to be activated following a confirmatory call to the issuer by the customer; conferring a credit limit on a credit card number; and invalidating a credit card number from further use and marking any further use as fraudulent. This overlap represents part of the commercial value of the single use number, minimizing the required changes.
The present disclosure is not limited to the embodiments hereinbefore described but may be varied in both construction and detail. For instance, the present disclosure has been heretofore described mainly in the context of a system in which a customer receiving a single use card already has a main account with the credit card provider. But this need not be so. For example, it is envisaged that an ATM machine (or similar apparatus) could be used by people who did not have a credit card account to purchase disposable credit cards, which disposable credit cards could then be used for either card present or remote transactions. When the card had been used, the card would be simply reinserted into the ATM machine, and after a suitable period of time the purchaser's account would be credited with any money not spent. Similarly, if the person who purchases the disposable credit card does not have an account of any sort with the credit card provider, the credit card could still be purchased from the ATM machine and then any refund could take place a sufficient time after the transaction would have been cleared, which refund could be either in the form of a cash refund to the purchaser or to a crediting of that purchaser account with another financial institution. Similarly, it will be appreciated that the use of an ATM machine is not essential, as the disposable credit cards or single use credit cards could be purchased in the normal way in which one purchases any other goods or services, such as either directly in a face-to-face transaction or by post.
The properties of this validation or activation process can vary. For example, the validation could be for a specific time period, for a specific merchant or group of merchants, for a specific type of transaction, or for a specific number of transactions (authorizations and/or presentments). These properties can also be combined in any permutation. For example, a card holder could request that his or her credit card number be validated for one transaction with a specific merchant up to a specific value limit or value range (e.g., a specific value+/−a configurable range). In the event that no authorization is received within a defined period, the validity can lapse. This combination provides a solution that meets the need for a secure, flexible payment system for remote transactions.
As can be readily seen, there are fundamental differences between the system of the present disclosure and any system that uses a PIN or other number (whether constant or varying from transaction to transaction) to validate a transaction. In the present system the numerical details conveyed in the course of a transaction are identical in format to an existing credit card number but no unique account code is included. This maximizes the security and privacy of a credit/debit/charge card transaction. Within the processing system the validity of the limited use number is verified first and then the associated account identified second by examining information stored with the limited use number. With the transmission of an additional PIN or other number in addition to the account number or other unique identifier, there is a lower level of security and privacy. Within any form of PIN identification (and as described by Rahman) the associated account is identified first and then the PIN verified after this step. For this reason many card holders can share the same PIN, indeed in most cases due to the short length of PIN codes many users do have identical PINs but different account numbers. For our system each limited use number must be unique at the time of use and so the associated account can be uniquely identified.
With reference back to FIG. 1, and as described above, central processing system 100 can internally perform the approval and denial of credit card transactions or this function can be delegated to a separate clearance processing facility. In other words, central processing system can be located within the card issuer's main processing system or at a stand-alone facility. In an exemplary embodiment of the present disclosure, central processing system 100 adds additional functionality to existing credit/charge/debit card systems without any, or with minimal, alterations. In general, central processing system 100 transmits certain transaction details in a bi-directional manner, i.e., utilizing dual interfaces between central processing system 100 and the merchant and between central processing system 100 and the card issuer, without revealing the master credit card number to the merchant. The dual interface transmissions, referred to herein as remapping, allow merchants and card issuers to handle transaction details in the same manner as conventional credit card transactions. Such conventional credit card transactions may be, for example, authorizations, settlements, copy requests, and charge-backs.
FIG. 11 is a block diagram illustrating a credit card system 1100 in which a central processing system 1106 in accordance with an embodiment of the present disclosure is located within a card issuing bank's main processing system 1114. The system 1100 includes merchant acquirers 1102 connected to card issuing bank's main processing system 1114 via a credit card network 1104 and a switch 1116. The credit card network 1104 may be any type of communication network, such as the Internet, a radio network, etc. as described above. A switch 1116 includes hardware and software components. The switch 1116 may be configured to direct incoming transaction details on the basis of the card number and to direct outgoing transaction details on the basis of the merchant acquirer identification number (referred to herein as the �merchant ID�). The issuing bank's main processing system 1114 includes an issuing bank processing facility 1112 and a central processing system 1106. The central processing system 1106 includes an acquirer interface 1108 and a STIP interface 1110 for example.
As discussed above, software and limited use numbers can be issued via electronic communication media. In one embodiment, a card holder can access limited use credit card numbers during electronic transactions via a Remote Access Device, referred to herein as �RAD�, such as the Orbis Internet Card . The overall layout of the RAD system 1500 is shown in FIG. 15 and a flow chart illustrating an exemplary method of providing remote access devices for accessing limited use credit card numbers is shown in FIG. 16. In general, the operation of the complete system from registration to completion of a transaction follows.
When a user desires to register with RAD system 1500, the user submits user authentication information, the master account number and other identifying data for entry into a database 1502. (Step 1602). To register with RAD system 1500, the user must be a valid holder/user of the master credit card or account number. (Step 1604). Once registered, step 1606, the user obtains a RAD 1504, step 1608. RAD 1504 includes a software package to which enables communication with a remote access device support server, referred to herein as a RAD support server 1506, such as the Nexus User Support Servers, to enable the issuance of limited use card numbers.
To accomplish the above tasks, the RAD support server 1506 should have a high bandwidth Internet connection and highly secure firewalls to insulate critical information from undesired access. Communications between the RAD support server 1506 and the RAD 1504 may be Internet based. Communication between the RAD support server 1506 and the central processing station 1508 and the database 1502 may be secured via private networks for additional security. In addition, to provide for additional security, the RAD support server 1506, the central processing station 1508 and database 1502 may be located at the same physical location, for example, the issuer's processing facility or some other facility which meets the standards set for banking processing facilities.
As can be seen from the above, the described limited-use credit card numbers can be provided with user defined controls on how the numbers can be used. Hence, the phrase �controlled payment numbers� describes products which embody the exemplary embodiments described herein.
To appreciate how a software and hardware platform embodying the present disclosure can be used to generate a range of payment products that span the virtual, wireless and real worlds it is necessary to consider the components of the complete platform and how these can be used in various combinations. To a large extent, remarkably distinct payment products can be derived using the existing platforms such as the RAD system 1500 of FIG. 15 in a range of configurations. Addition of standard additional components and interfaces further broadens the potential scope. The RAD system platform 1500 has been designed from the outset to support such applications. This provides a rapid development path for new payment products since development requirements are limited primarily to designing new client side components for configuring and controlling CPN payments.
A card number generating and allocation system (e.g., support server 1508) that allows for additional controls to be allocated to the cards in a dynamic manner. A card issuing process for distribution of CPN's to users that supports industry standard protocols, such as shown in FIGS. 5 and 6. A card authorization and settlement process (e.g., FIGS. 7 and 8) that provides additional verification and validation of cards against the current set of controls that have been set up for that card. A mechanism for relating a specific CPN to an existing credit card, debit card or general financial account (e.g., FIGS. 11, 12 and 13). The platform may be implemented with part as a personal computer connected to the Internet to provide communication with the card issuer. The customer can set a range of limitations as determined by the issuer and the card number is issued in virtual form to the users computer (usually) for immediate use.
1. Card present Transactions;
2. MOTO (Mail Order and Telephone Order); and 3. Wireless applications.
Specifically, these applications can be implemented by varying: (1) the patterns of how the controls on specific numbers are combined, (2) the controls available to user(s), (3) who sets the controls and when, (4) how the controls are communicated to the processing system, (5) the communication device(s) or channels used to deliver an issued CPN to the user, (6) the form in which the CPN is issued (virtual via software, voice generated, text message, paper receipt, paper credit card, plastic credit card), and (7) the form in which the CPN is presented to the merchant.
There are considerable opportunities to create new payment products by issuing fixed number plastic cards with flexibility and control provided by the present disclosure. There are applications of this approach in both the consumer and business markets.
In these applications, new payment products can be created by placing �intelligence� within the card processing system. An additional step is the creation of new communication channels between these processing systems and a card issuer/card holder.
In combination with an issuer's capability to configure specific card products, these additional dynamic control features provide a mechanism for a traditional plastic payment card to be turned into a range of new products. In effect, the present disclosure creates �instantly configurable plastic payment cards�. This capability can be combined with conventional credit cards, debit cards and pre-paid cards.
There are ranges of consumer applications of which a few are listed here.
Given to employees as a bonus this limited use credit card number can be used anywhere Visa or Mastercard is accepted or alternatively limited to a particular merchant or merchant type. Cards can be issued and the company can set the reward amounts via a PC-computer interface. All charges can be billed to a central company account.
3.1.4 Telephone Interfaces for CPN Delivery Mobile telephony interfaces can allow both WAP (Web Access Protocol) and i-mode interaction with servers providing the CPN capabilities. This provides for authentication by password or PIN and delivery of a CPN via a simple interface for display on the screen. CPN's can also be issued by SMS (Silicon Integrated Systems), which has the additional benefit of providing automatic storage of the number for later use. Review of statements is also possible via this interface. The core functionality for MOTO orders are very similar to Internet orders and so no major differences are required in terms of additional functionality, though the functionality is best limited in line with the small screens of current mobile telephones. This application would also be well suited to web-kiosk applications where users may not want to enter authentication credentials into public systems. There is currently increasing interest in �in-store� kiosks to provide additional product lines. This implementation of the web-kiosk is designed specifically for making purchases and the mobile CPN will ideally suit such a combined �clicks and mortar� transaction.
It is expected that web access will increasingly involve non-PC devices such as PDA's, set-top TV boxes, Interactive TV and �smart� consumer devices. The CPN platform architecture provides for seamless integration of a wide range of web-access devices into a standard implementation. The CPN platform can be used with interactive TV, which provides for integration of the purchasing process with �TV browsing�.
Greatly reduced re-issue costs for compromised cards. This is especially true in a chip environment where card re-issue costs are greatly increased. Also it greatly reduces the inconvenience involved in re-issuing a card. A physical card is useful when collecting tickets for example. Additional controls from the platform provide for the flexible control of the overall limit. Controls can be applied to create specific mail order merchant cards with incentives by applying merchant ID controls. The CPN platform provides for simple integration into an existing credit facility or account without the need to create a separate credit line. Controls can be set-up by an issuer or via a telephone or computer interface as with other limited use credit card number products. These interfaces could provide for additional functions such as on-line statements.
The above physical manifestations of the platform for MOTO use a fixed number with variable controls. It is also possible to issue a series of numbers on a single card or device that users use one at a time. A mechanism is required to ensure that user can simply keep track of numbers that have been used. A range of options are possible for including peel of labels where after use a CPN label is removed revealing an additional number underneath. Alternatively scratch off cards like lottery cards could be used to ensure that a number is only revealed when a user wishes to use the card.
The use of Bluetooth-enabled smart card readers communicating with POS (point of sale) terminals, or mobile network operators allowing users to buy products and pay for them on their bills. However, smart cards have not yet been widely deployed, and mobile network operators do not have a track record in e-commerce payments. A better solution is offered by the present disclosure, which utilizes the existing credit card network.
1. The user would connect to the issuer's website using the WAP phone, and would log in and request a CPN. 2. The issuer's web server would communicate with the server, which would issue an CPN with the required controls and link to the users account (either set by the user at the time or using pre-determined default values). 3. The CPN would be returned to the user's WAP phone over the mobile network. 4. The user would instruct the Bluetooth-enabled WAP phone to discover the POS service of the POS terminal. 5. The phone and POS terminal would establish a Bluetooth connection, using suitable authentication security. 6. The phone would beam the CPN to the POS terminal. Signature Authentication Card Present transactions are characterized by visual signature authentication, in which the signature on the credit card is compared to the signature on the sales voucher. A different kind of authentication is required by wireless Card Present transactions. The unique SIM card in every mobile phone can be used as an identification card, and technologies such as fingerprint identification and voice recognition will insure that a stolen phone cannot be used by anyone other than the owner.
3G Phones Third generation mobile phones and hand-held devices will be capable of requesting and storing CPN's, of displaying internet content much richer than the current WAP phones, and of running feature rich applications such as the CPN system in accordance with the present disclosure. The march of technology will continue to create new opportunities for card payments, and CPN technology will be there to provide the security needed.
Additional Card Products Controlled Payment Number Technology (CPN) enables numbers to be associated with a set of controls which ensure that the number is used for the purpose it was issued for. The document outlines an extension to that patent whereby a list of controls can be associated with a number. In effect, the CPN may be partitioned across multiple sets of controls. Each set of controls is associated with a limit, a maintained balance and may be latched to a Payment Party (e.g. Merchant) or set of Payment Parties (e.g. list of merchants). The aggregated limit is the total limit the CPN can approve. The individual totals (limit, balance etc. . . . ) for a set of controls can be latched to the Payment Party for that set and may be subject to any other CPN latching rules. Each CPN partition (set of controls) may be linked to a Funding Party.
Exemplary Application (1): A Service Provider (Issuer) issues a CPN to Insurance Companies (Funding Parties) as a means for enabling payout on claims. When a claim is made, the Insurance Company may load the CPN with funds to cover payment. The CPN Application can enable the Insurance Company to control spending of the payment by splitting into separate funds; each fund being latched to a limit and merchant. This means that the claimant (cardholder) may only use the CPN to purchase goods from specific merchants (or merchant category) to a maximum value agreed by the claim and is subject to other applicable CPN controls (e.g. expiry date). The Issuer may allow multiple Insurance Companies to load funds onto a single CPN. The claimant can use a single CPN to claim from multiple insurance companies. Each insurance company claim is partitioned into a set of one or more CPN controls. This enables the insurance company to control which merchant(s) the cardholder can replace the product from and the maximum value to be paid out for a particular product.
FIG. 18 provides an exemplary illustration of a CPN that is split into 3 sets of rules (500 latched to merchant A, 750 latched to Merchant B, 400 latched to Merchant C). Each set of rules can be latched on all other CPN controls (e.g. issue/expiry date etc. . . . ) with two different issuers (1) and (2).
Exemplary Application (2) A CPN may also be backed by a fund that is not linked to a Merchant. This is to accommodate overspill on spending for a particular product at a listed merchant or may be used to purchase from any merchant to the value of the overspill fund. This enables the Issuer/Funding Party to tolerate a degree of increased spending on a particular product (or a product from any Merchant) while not affecting the aggregated value of the CPN. FIG. 19 provides an exemplary illustration of a CPN that is split into 4 sets of rules (400 latched to merchant A, 650 latched to Merchant B, 400 latched to Merchant C). Insurer (1) has loaded 200 of the claim into a fund that is not latched to a specific merchant. This allows the cardholder to spend this fund at any merchant and can be aggregated to a listed merchant fund (e.g. can be used to approve a purchase of 600 from Merchant A).
Limit Increasing Each set of controls in the list maintains individual limits & balances for a party. A Payment Party may have their limit increased by a Funding Party. This would increase the limit for the applicable Payment Party which would increase the aggregated limit of the CPN but not affect the limits set for the other Payment Parties. FIG. 19 provides an exemplary illustration of a Merchant C latched fund increased by 200.
1.1 Controlled Payment Numbers (CPN) As shown in FIG. 21, Control Payment Numbers enable cardholders to pay for card not present transactions using a unique substitute account number for each purchase. The CPN solution is accessible to consumers via a branded user interface, e.g. Mastercard�, where it can be downloaded to the customer's desktop (slim client) or served up to the customer for each purchase transaction preferably without the customer having to download software on to their PC (thin client). The slim client is configured, using, preferably, artificial intelligence, to detect a checkout situation and prompts the customer to use this card to make the payment.
Customers can generate a request for a CPN either ad hoc or during the purchase process (after being automatically prompted by the software client) and once generated, the CPN is linked to the customer's PAN. All CPN transactions made by the customer continue to post, preferably, to the primary cardholder's existing account. Transactions completed using a CPN are secure�none of the customers actual credit card details are shared with the merchant or exposed during any part of the open transaction. Merchant sites do not have to change to accept CPNs. CPNs are accepted and handled by merchants in the same way that they accept and handle real credit and debit cards. CPN details and billing profile information may be input directly by the customer or automatically by using the form fill functionality included with the ControlPay platform. Customers can set optional spending controls that allow CPNs to be used for single purchases or multiple uses at a single merchant. The slim client (download) can also be deployed as a CRM tool to deliver real-time messages to the individual customer based on a variety of communications strategies including but not limited to Rewards management and fulfillment.
The CPN e-commerce security solution can be implemented without merchant adoption and without changes to the merchant check-out process.
1.1.1 PayEverywhere As shown in FIG. 22, PayEverywhere enables the acceptance of non-traditional payment sources (e.g. e-wallet, smaller card schemes, mobile phone bill, utility bill, etc.) and less well accepted payment solution at all merchants that accept card payments without the merchant having to make changes to support the non-traditional or alternative payment solution.
For a non-traditional payment type to be accepted at a merchant that does not accept this payment type, a CPN is generated for the transaction(s). The CPN is handled by the merchant exactly as they would handle a real card payment. When the transaction arrives over the traditional card network, the exemplary system validates the number and the type of transaction and coverts the transaction into the format that the payment provider would have received if the merchant supported that payment type.
1.1.2 O-Purchase The O-Purchase product preferably drives revenue generating spending onto an issuer's Purchase Card (P-Card) program by enabling the issuer to provide solutions to their Corporate and Government customers which can: Facilitate settlement of their Accounts Payable using P-Cards; and empower employees to be able to spend via P-Cards, in line with their internal control policies, without the inherent risks associated with providing plastic to everyone.
O-Purchase, in its simplest form, supports the generation of a unique purchase card number for every transaction. When an employee wishes to make a purchase, he/she requests a purchase card number from an issuer branded web site of from within their ERP system. The O-Purchase platform authenticates the employee, seeks approval for the transaction (if required), and then attaches controls to the purchase card number (e.g. dollar limit for the transaction, use at a specified merchant, and so on). Given that there is a unique payment number for each transaction, the number acts as a unique identifier for the transaction. This unique payment number appears on the P-card statement, allowing every transaction on the statement to be automatically tied back to the approval trail. It also facilitates the capture of additional data around the transaction, such as level 3 type data, GL information and project codes which follows the transaction through the supply chain and allows reconciliation and GL updates to be entirely automated.
1.1.3 Supplier Payments Supplier Payments enables large broker-type organizations (e.g. Travel Management Companies) to pay their diverse range of suppliers using unique card numbers with associated spend controls, thereby generating process efficiencies and cash savings.
Each time a transaction is made, the broker (e.g. TMC) will calculate the amount payable to the supplier, less agency fee or the broker can aggregate payments and total the values owed to each supplier in this period's settlement run and lodge this total amount to the main card account with the Issuer. The broker will then request a CPN from a ControlPay system for each transaction (or service provider) to be paid. The broker can enforce controls on the CPN such as:
Transaction value�CPN cannot exceed this limit (tolerances are optional); Active period�the service supplier will only be able to use the CPN to debit the broker's card account for a specified time period e.g. one month, starting with a specified date; and/or Number of uses�the broker can limit the use of the CPN to one or more uses. The broker can generate a CPN for each transaction (or supplier in the case of aggregated payments)�this can be done via real time interfaces or by the broker providing a batch file of payment requests. CPNs can be made available to the supplier via a variety of channels including: a dedicated reservation and payment management systems hosted and operated by the broker and made available to service provider; and/or data interchange or messaging services such as e-mail, fax, or any electronic format. The supplier can process payment using the CPN through their existing card acceptance system. The supplier, his bank (acquirer), or card association can treat the CPN as though it were a credit card PAN. The supplier can be credited with the transaction amount (less any existing merchant/acquirer charges) as per existing card payment processing. CPN transactions received that are not within the control limits set by the broker can be declined.
1.1.4 ControlPay Multi-Card FIGS. 23A-C illustrate a Multi-Card embodiment that facilitates access to multiple funding sources via a single device (card, mobile phone, etc.) through intelligent routing of card transactions based on cardholder rules and transaction data. A transaction is routed to the appropriate funding source based on transaction characteristics and customer-set rules. Routing can be based on a variety of criteria such as:
Merchant, merchant type, POS type Value Date/time Device type Account attributes:
Balance Status Loyalty/rewards attributes
Route all transactions less than $100 to my cheque account Route all transactions between $100 and $1000 to my credit card Route all transactions greater than $1000 to my secured Personal Equity Management (PEM)/lending/HELOC/flexible mortgage Route all Internet transactions to my credit card Flexible rules engine supports transaction routing to appropriate funding account, preferably, without requiring merchant POS changes. Routing rules can be changed in real-time using web application in which changes apply immediately and the authority to change rules provided to account owner or designate(s). There can be a configurable �suspense period� that allows a user to override default routing when needed before transaction is posted to the funding account. Alternatively, the rules can allow an �always authorize policy� to remove consumer embarrassment issues and to retain the transaction. If one account is �maxed out�, instead of declining transaction, the transaction is authorized off another account that is funded.
1.1.5 ControlPay Instant Credit FIG. 24 illustrates an Instant Credit embodiment that facilitates the approval of more customers by enhancing your existing Instant Credit solution with risk management features. As an enhancement to your existing instant credit approval solution, ControlPay Instant Credit enables issuers to mitigate risk by leveraging the ControlPay Platform number generation and spending limits capabilities. Successful instant credit applicants are granted limited access to a new credit line with a temporary account number (CPN). CPNs with specific spending controls are generated and linked to the applicant's new PAN. An Issuer provides the CPN to the consumer to use immediately. Customers can be granted full access to account privileges once fully approved. The PAN is never revealed to the consumer until full credit underwriting is completed, triggering plastic or virtual fulfillment. Therefore, Issuers can implement a range of instant credit programs such as �single use� or �credit for a day�.
1.1.6 ControlPay Authorized User/Controlled Business Card ControlPay Authorized User allows issuers to significantly increase account usage by enabling primary account owners to allow themselves and others to access the spending line in a secure, controlled manner. Cardholders wishing to add an authorized user to their card account can request additional cards via all supported customer contact channels e.g. IVR/VRU, website, customer service representative, mail. The authorized user has access to the main cardholder's credit line but is limited to using the credit facility within the parameters set by the main cardholder e.g. cardholder creates authorized user account for the nanny. The nanny can use the card Monday to Friday only, only for grocery or fuel purchases and up to a limit of $800 per month. All transactions post to the primary cardholder's account so total control is retained by the primary cardholder. The authorized user request can be fulfilled immediately, issuing plastic or virtual devices. The primary cardholder has 24 hour, 7 day access to request new users or amend existing ones, deactivate accounts and/or devices, amend spending or merchant limits and view all transactions. The authorized user can be granted limited read-only access to only view transactions made by themselves.
Other Services An exemplary embodiment described as �Pay with your Phone� is illustrated in FIGS. 25-27. This exemplary embodiment enables mobile phone customers to use some of their available prepaid balance to make online purchases, e.g., book flights, purchase music, books, etc. After registering for the service, Cellular Telephone customers may request a unique payment number from their available funds to make a purchase online. This number is, preferably, only good for one transaction and is only good for the amount that the user requested. �Pay with your Phone� numbers work at every single merchant that accepts cards for payment. Cellular Telephone service provider has control of where this number can be used, e.g., can only be used at certain merchants, or cannot be used at certain types of merchants (e.g., gaming). Cellular Telephone service provider does not need to have a relationship with any merchants for your customers to be able to use this service. Cellular Telephone customers do not need to have a credit card, debit card or even a bank account to use this service. There are no technical changes to the loading mechanisms in place today�Cellular Telephone service provider may want to renegotiate the fees on the loading of higher amounts.
While the foregoing description makes reference to particular illustrative and exemplary embodiments, these examples should not be construed as limitations. Not only can the inventive system, method and computer program products be modified for other card numbered systems, they can also be modified for other computer networks or numbering schemes. Thus, the present disclosure is not limited to the disclosed embodiments, but is to be accorded the widest scope consistent with the claims below.
Non-Patent CitationsReference1 *Off-Line Generation of Limited-Use Credit Card Numbers, Aviel D. Rubin and Rebecca N. Wright, AT&T Labs - Research180 Park Avenue,Florham Park, NJ, 07932 USAP. Syverson (Ed.): FC 2001, LNCS 2339, pp. 196-209, 2002.Springer-Verlag Berlin Heidelberg 20022 *SecureClick: A Web Payment System with Disposable Credit Card Numbers, Adi Shamir, Dept. of Applied Math, The Weizmann Institute of Science, Rehovot 76100, Israel, P. Syverson (Ed.): FC 2001, LNCS 2339, pp. 232-242, 2002.Springer-Verlag Berlin Heidelberg 20023 *SNPP: A Simple Network Payment Protocol, Semyon Dukack, MIT Laboratory for Computer Science,Published in:Computer Security Applications Conference, 1992. Proceedings., Eighth Annual, Date of Conference: 30 Nov-4 Dec 1992 Page(s): 173 - 179, http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=228222.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7937324 *Sep 5, 2008May 3, 2011Visa U.S.A. Inc.Account permanenceUS8190523Mar 25, 2011May 29, 2012Visa U.S.A. Inc.Account permanenceUS8249893Apr 5, 2012Aug 21, 2012Stoneeagle Services, Inc.Automated service provider payment methodUS8265998Jul 7, 2009Sep 11, 2012Chenot Richard HSystems and methods for per-transaction financial card enabled personal financial managementUS8290868Jul 7, 2009Oct 16, 2012Chenot Richard HFinancial cards and methods for per-transaction personal financial managementUS8332238Jun 13, 2012Dec 11, 2012Stoneeagle Services, Inc.Integrated payment and explanation of benefits presentation method for healthcare providersUS8346665 *Apr 13, 2010Jan 1, 2013Enservio, Inc.Dual-activation financial productsUS8401904May 18, 2012Mar 19, 2013Google Inc.Real-time payment authorizationUS8439274Nov 6, 2009May 14, 2013Richard H ChenotFinancial card with a per-transaction user definable magnetic strip portionUS8515815Sep 11, 2012Aug 20, 2013Richard H. ChenotManagement system and method for personal per-card use subaccount transaction financial managementUS8635131 *Oct 15, 2004Jan 21, 2014American Express Travel Related Services Company, Inc.System and method for managing a transaction protocolUS8676709Dec 17, 2012Mar 18, 2014Google Inc.Merchant category codes in a proxy card transactionUS8694432 *Nov 30, 2012Apr 8, 2014Enservio, Inc.Dual-activation financial productsUS8762278 *Jun 7, 2013Jun 24, 2014Enservio, Inc.Dual-activation financial productsUS8793186 *Apr 30, 2012Jul 29, 2014Visa U.S.A. Inc.Account permanenceUS20040111329 *Dec 10, 2002Jun 10, 2004First Data CorporationRestricted-use transaction systemsUS20090106157 *Dec 17, 2008Apr 23, 2009Xatra Fund Mx, LlcFunding a Radio Frequency Device TransactionUS20090228384 *Feb 26, 2009Sep 10, 2009Stefan Melik-AslanianReal Time Replacement System and Method for Lost or Stolen Credit Cards / Debit CardsUS20110127324 *Dec 30, 2010Jun 2, 2011Hirka Jeffrey LMultiple Account Advanced Payment Card and Method of Routing Card TransactionsUS20110238511 *Mar 7, 2011Sep 29, 2011Park Steve HFuel dispenser payment system and methodUS20110251957 *Apr 13, 2010Oct 13, 2011Enservio, Inc.Dual-activation financial productsUS20110302084 *Jun 2, 2011Dec 8, 2011Stefan Melik-AslanianSystem and method for immediate replacement of lost or stolen credit cards/debit cardsUS20120016728 *Jul 13, 2010Jan 19, 2012Dfs Services LlcProcessing non-traditional transactions on a traditional payment networkUS20120072346 *Sep 16, 2010Mar 22, 2012Yomir SpSystem and method for securing and authenticating purchase transactionsUS20120116902 *Apr 30, 2009May 10, 2012Donald Michael CardinaSystems and methods for randomized mobile paymentUS20120278238 *Apr 30, 2012Nov 1, 2012Barbara PattersonAccount PermanenceUS20130036036 *Aug 4, 2011Feb 7, 2013Zoldi Scott MMultiple funding account payment instrument analyticsUS20130080270 *Sep 23, 2011Mar 28, 2013Bank Of America CorporationTransaction device and processing systemUS20130080275 *Sep 23, 2011Mar 28, 2013Bank Of America CorporationTransaction device and processing systemUS20130152185 *Dec 9, 2011Jun 13, 2013Research In Motion LimitedTransaction provisioning for mobile wireless communications devices and related methodsUS20140040118 *Jun 7, 2013Feb 6, 2014Paul Colin MillerDual-activation financial productsUSRE43904Jan 26, 2012Jan 1, 2013Stoneeagle Services, Inc.Medical benefits payment systemWO2011005848A2 *Jul 7, 2010Jan 13, 2011Chenot Richard HSystems and methods for per-transaction financial card enabled personal financial managementWO2011112502A1 *Mar 7, 2011Sep 15, 2011Gilbarco Inc.Fuel dispenser payment system and methodWO2012035536A1 *Sep 15, 2011Mar 22, 2012Daynovsky Mirit BarkanSystem and method for securing and authenticating purchase transactions* Cited by examinerClassifications U.S. Classification705/44, 705/39International ClassificationG06Q20/00, G06K19/067, H04B7/26, G07F7/08, G07F7/02, G07F19/00, G07F7/12, G07F7/10, G07F, H04L9/00Cooperative ClassificationG06Q20/28, G06Q20/382, G07F7/1008, G07F7/08, G07F19/00, G06Q20/04, G06Q20/354, G06Q20/16, G06Q40/04, G06Q40/00, G06Q20/10, G07F19/2055, G07F7/12, G06Q40/025, G07F7/025, G06Q20/342, G06Q20/357, G06Q20/385, G06Q20/3552, G06Q20/105, G06Q20/00, G07F7/122, G06Q20/24, G06Q20/40, G06Q20/4016, G06Q20/34European ClassificationG06Q20/24, G06Q20/04, G06Q20/16, G06Q20/28, G06Q40/00, G07F7/12A, G06Q20/357, G06Q20/382, G06Q20/40, G06Q20/385, G07F19/2055, G06Q20/10, G06Q40/04, G06Q20/354, G06Q40/025, G07F7/12, G06Q20/342, G06Q20/3552, G06Q20/105, G07F7/02E, G06Q20/00, G07F19/00, G07F7/10D, G07F7/08RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google