DESCRIPTION OF THE PREFERRED IMPLEMENTATION

[0053] Reference will now be made to various embodiments according to this invention, examples of which are shown in the accompanying drawings and will be obvious from the description of the invention. In the drawings, the same reference numbers represent the same or similar elements in the different drawings whenever possible.

[0054] 1. Preferred Implementations for Funds Transfers

[0055] FIG. 1 is a block diagram of an implementation of a financial tender transfer system 100 consistent with the present invention. This implementation is particularly useful for executing funds transfers, such as between a buyer and a seller of an item, because, as described below, it provides a simple method for making a payment. Financial tender transfer system 100 includes a transferor 110 , a transferee 120 , a central controller 130 , and multiple credit card issuers 140 . Financial tender includes funds and/or credit lines. Thus, the transfer of financial tender can refer to the transfer of funds, the transfer of credit, or both.

[0056] In a funds transfer, transferor 110 is the buying or paying party. Transferor 110 has his 10 credit card debited by a particular transfer amount to make a purchase or pay off a debt. The transfer amount appears as a conventional transaction entry, with a corresponding transaction description of the purchase. The transferor's available credit line decreases by the transfer amount. Transferor 110 is liable to pay this amount as a conventional charge. However, the original credit line on the card remains the same.

[0057] Transferee 120 is the selling party, or the party getting credit for payment of a debt of transferor 110 . The transferee's credit card account is credited for the payment by transferor 110 in essentially the same manner as a credit appears when merchandise is returned. This credit can be used to offset other incurred charges on transferee's account or can be withdrawn from the account as cash at an Automated Teller Machine (ATM). The original credit line remains the same, but the available credit line increases in the same amount as the transfer amount. Credit card issuers 140 issue credit cards and thus give credit to transferor 110 and transferee 120 . Although FIG. 1 shows only three credit card issuers, systems consistent with the present invention may be implemented with at least one or more credit card issuers.

[0058] Central controller 130 is a credit card financial tender transfer service to facilitate the transaction between transferor 110 and transferee 120 . Central controller 130 controls the transfer of financial tender from an account corresponding to the credit card of transferor 110 to an account corresponding to the credit card of transferee 120 . This function may be performed by the credit card issuing banks, a credit card processor linked to the credit card issuing banks, a trusted clearing house for credit card funds and/or credit line transfers, or any third party that can access the credit card system to debit one credit card account and credit another given account. Central controller 130 accesses credit card issuers 140 to determine the validity of the credit card accounts, confirm availability of credit, and debit and credit the respective accounts.

[0059] FIG. 2 is a detailed block diagram of central controller 130 . Central controller 130 includes a microprocessor or central processing unit (CPU) 210 coupled to a random access memory (RAM) 215 , a read only memory (ROM) 220 , a clock 225 , a communication port 230 , and a data storage device 245 . Communication port 230 couples CPU 210 to a bank system interface 235 . Bank system interface 235 couples central controller 130 to credit card issuers 140 (not shown). An optional cryptographic processor 240 , such as the MC68HC16 manufactured by Motorola, generates an encrypted identification (ID) number to provide for a secure transaction and applies to implementations described below. Symmetric cryptography is preferably employed. The use of cryptography provides a single use transaction ID that incorporates a date and time into the ID, that in turn guarantees a unique ID for every transaction. The system prevents multiple uses of encrypted transaction IDs by only allowing each unique ID to be used once. Data storage device 245 includes a customer database 250 and a transaction database 255 .

[0060] FIG. 3 is a detailed block diagram of a credit card issuer controller 300 employed by one of the credit card issuers 140 . Credit card issuer controller 300 includes a microprocessor or CPU 310 coupled to a RAM 315 , a ROM 320 , a clock 325 , a communication port 330 , a cryptographic processor 340 , and a data storage device 345 . Communication port 330 couples CPU 310 to a central controller interface 335 . Central controller interface 335 couples credit card issuer controller 300 to central controller 130 (not shown). Optional cryptographic processor 340 generates the encrypted ID number to provide for the secure transaction. Symmetric cryptography is preferably employed. The use of cryptography provides a single use transaction ID that incorporates a date and time into the ID, that in turn guarantees a unique ID for every transaction. The system prevents multiple uses of encrypted transaction IDs by only allowing each unique ID to be used once. Data storage device 345 includes a financial tender transfer database 350 and customer account database 355 .

[0061] FIG. 4 is a table illustrating an example of customer database 250 . Customer database 250 holds data for each customer registered with central controller 130 . The data for each customer includes the customer's name, ID number, credit card type, full credit card number, partial credit card number (last six digits or portion of full number), expiration data, and bank ID number.

[0062] FIG. 5 is a table illustrating an example of transaction database 255 . Transaction database 255 retains information of each transaction conducted through central controller 230 . In particular, the information held in transaction database 255 includes the transaction ID number, time and date of the received transaction, transaction amount, transferor and transferee customer ID numbers, transferor and transferee bank completion codes, and time and date of the completed transaction.

[0063] FIG. 6 is a table illustrating an example of customer account database 355 . Customer account database 355 records customer information for each credit card holder holding a credit card from the particular credit card issuer 140 . The customer information held in credit card holder database 355 includes the customer account number, the name of the customer, the customer's address and phone number, the original credit line amount, and the available credit line.

[0064] FIG. 7 is a table illustrating an example of financial tender transfer database 350 . This database holds information for each transaction conducted by a particular credit card issuer 140 . The information held includes the transaction ID number, the time and date of the transaction, transaction amount, transaction type, and credit card number.

[0065] A. General Funds Transfers

[0066] FIGS. 8A and 8B are flowcharts of the steps employed by financial tender transfer system 100 in accordance with the implementation shown in FIG. 1 . First, transferor 110 provides transferee 120 the last 6 digits or a specified portion of his credit card account number, his name as it appears on the card, and the expiration date (step 810 ). Transferee 120 contacts central controller 130 and navigates through a menu, which may be implemented using an Interactive Voice Response Unit (IVRU), to provide transaction information, including the amount to be transferred, the credit card account data from transferor 110 , and credit card account information for transferee 120 , including credit card account number to be used, and expiration date of the credit card of transferee 120 (step 815 ). Central controller 130 transmits the transaction information to credit card issuers 140 for transferor 110 and transferee 120 (step 820 ).

[0067] Credit card issuers 140 for transferor 110 and transferee 120 , respectively, execute the transaction in the following steps. First, each looks up the complete credit card information of transferor 110 and transferee 120 , respectively (step 825 ). The credit card issuer 140 for transferor 110 determines whether the partial credit card account number of transferor 110 obtained from central controller 130 corresponds to the information available within its customer account database 355 to correctly identify the transferor's credit card account (step 830 ). If the information does not match, the transaction is aborted (step 835 ). Credit card issuer 140 for transferor 110 then verifies the validity of the transferor credit card account (step 840 ) and aborts the transaction if the transferor credit card account is invalid (step 845 ), and also confirms that sufficient credit is available in the credit card account of transferor 110 (step 850 ) and aborts the transaction if transferor 110 has insufficient credit (step 855 ). Finally, credit card issuer 140 for transferee 120 checks the validity of the credit card of transferee 120 (step 860 ) and aborts the transaction if it is invalid (step 865 ).

[0068] If the conditions described above are met, credit card issuers 140 for transferor 110 and transferee 120 debit the transferor's credit card account and credit the transferee's credit card account, respectively. In particular, transferor's available credit line decreases by the transfer amount for which transferor 110 is liable to pay as a conventional charge. In addition, the transfer amount appears as a credit in transferee's credit account such that transferee's available credit line increases in the same amount as the transfer amount. Each credit card issuer 140 also reflects the result of the transaction in its respective financial tender transfer database 350 (step 870 ). Credit card issuers 140 for transferor 110 and transferee 120 then send confirmations to central controller 130 that the transaction has been executed (step 875 ). Central controller 130 subsequently sends a confirmation to transferee 120 that the transaction has been executed (step 880 ). Central controller 130 also updates transaction database 255 with the transaction information.

[0069] This implementation provides a simple method for executing the funds transfer between transferor 110 and transferee 120 . In particular, only one party needs to access central controller 130 . In addition, the transferee cannot repudiate the transaction because the transaction is executed when transferee 120 contacts central controller 130 . For example, transferor 110 is required to provide transferee 120 with a specified portion of transferor's credit card number. Alternative implementations described below provide additional security features.

[0070] B. Payment of Debt

[0071] FIG. 9 is a block diagram of another implementation of financial tender transfer system 100 consistent with the invention. This implementation is preferably practiced in cases where a transferee is owed money by a transferor and provides enhanced security features by eliminating the need for either party to provide credit card information to the other party. As an alternative to writing a check to the transferee, the transferor settles his debt by receiving an identification number from the transferee and calling, for example, a toll free number to access central controller 130 to conduct the transaction described below with reference to FIGS. 10A and 10B . Similar to FIG. 1 , financial tender transfer system 100 of FIG. 9 includes a transferor 110 , a transferee 120 , a central controller 130 , and multiple credit card issuers 140 .

[0072] FIGS. 10A and 10B are flowcharts of the steps employed by financial tender transfer system 100 in accordance with the implementation shown in FIG. 9 . First, transferee 120 registers with central controller 130 operated by a trusted third party by providing it with relevant credit card information including the transferee's name and the transferee's credit card number and expiration date (step 1010 ). Central controller 130 records this information in customer database 250 and issues a Transferee Identification (ID) Number to transferee 120 (step 1015 ). Transferee 120 then provides this Transferee ID Number to transferor 110 (step 1020 ). After receiving the Transferee ID Number, transferor 110 contacts central controller 130 and navigates through a menu to provide transaction information, including the amount to be transferred, the credit card account information for transferor 110 , including name, credit card number, and expiration date, and the Transferee ID Number (step 1025 ).

[0073] Central controller 130 looks up and matches the transferee credit card account information -with the Transferee ID Number in customer database 250 (step 1030 ) and aborts the transaction if the information fails to match (step 1035 ). Central controller 130 then transmits the identified transferee credit card information along with the above transferor credit card information and the transaction information of transferor 110 and transferee 120 to credit card issuers 140 for transferor 110 and transferee 120 (step 1040 ).

[0074] After receiving the information from central controller 130 , credit card issuers 140 for transferor 110 and transferee 120 , respectively, execute the transaction in the following steps. First, credit card issuer 140 for transferor 110 verifies the validity of the transferor's credit card account (step 1045 ) and aborts the transaction if it is invalid (step 1050 ). Credit card issuers 140 for transferor 110 also determines if transferor 110 has sufficient credit (step 1055 ) and aborts the transaction if transferor 110 lacks sufficient credit (step 1060 ). Finally, credit card issuer 140 for transferee 120 verifies the validity of the transferee's credit card account (step 1065 ) and aborts the transaction if it is invalid (step 1070 ).

[0075] Assuming the transaction is valid, credit card issuers 140 for transferor 110 and transferee 120 debit the transferor's credit card account and credit the transferee's credit card account, respectively. In particular, transferor's available credit line decreases by the transfer amount for which transferor 110 is liable to pay as a conventional charge. In addition, the transfer amount appears as a credit in transferee's credit account such that transferee's available credit line increases in the same amount as the transfer amount. Each credit card issuer 140 also updates its respective financial tender transfer database 350 to reflect the completed transaction (step 1075 ). Credit card issuers 140 for transferor 110 and transferee 120 then confirm the transaction with central controller 130 , which in turn sends a confirmation to transferee 120 that the transaction has been executed (step 1080 ). Central controller 130 also records the transaction information in transaction database 255 .

[0076] This implementation provides more security than the implementation described in connection with FIG. 1 . For example, neither party needs to provide any portion of a credit card number to the other party. Also, since transferor 110 executes the transaction, transferee 120 will be unable to overcharge transferor 110 by transferring more than the agreed upon funds.

[0077] C. Purchase of Goods or Services

[0078] FIG. 11 is a block diagram of another implementation of financial tender transfer system 100 . This implementation is preferably practiced in cases where transferor 110 is buying goods or services from transferee 120 and also provides enhanced security features by eliminating the need for either party to provide credit card information to the other party. As an alternative to providing a portion of credit card number to transferee 120 , transferor 110 provides a Transferor ID Number to transferee 120 and transferee 120 contacts central controller 130 by, for example, calling a toll free number, to conduct the transaction described below with reference to FIGS. 12A and 12B . Like FIG. 1 , financial tender transfer system 100 of FIG. 11 includes a transferor 110 , a transferee, 120 , a central controller 130 , and a plurality of credit card issuers 140 .

[0079] FIGS. 12A and 12B are flowcharts of the steps employed by financial tender transfer system 100 in accordance with the implementation shown in FIG. 11 . First, transferor 110 registers with central controller 130 operated by a trusted third party by providing it with relevant credit card information, including transferor's name and transferor's credit card number and expiration date (step 1210 ). Central controller 130 records this information in customer database 250 and issues a Transferor Identification Number (ID Number) to transferor 110 (step 1215 ). Transferor 110 then provides transferee 120 with the Transferor ID Number (step 1220 ). Transferee 120 subsequently contacts central controller 130 and navigates through a menu to provide the transaction information, including the amount to be transferred, the Transferor ID Number, and the credit card account information for transferee 120 , including name, credit card number, and expiration date (step 1225 ). Central controller 130 identifies and matches the transferor credit card account information with the transferor ID Number in customer database 250 , and transmits the identified transferor credit card information along with the above transferee credit card information and the transaction information of transferor 110 and transferee 120 to credit card issuers 140 for transferor 110 and transferee 120 (step 1230 ).

[0080] After receiving the information from central controller 130 , credit card issuers 140 for transferor 110 and transferee 120 , respectively, execute the transaction in the following steps. First, credit card issuer 140 for transferor 110 verifies the validity of the transferor's credit card account (step 1235 ) and aborts the transaction if it is invalid (step 1240 ). Credit card issuer 140 for transferor 110 also determines if transferor 110 has sufficient credit (step 1245 ) and aborts the transaction if transferor 110 lacks sufficient credit (step 1250 ). Finally, credit card issuer 140 for transferee 120 verifies the validity of the transferee's credit card account (step 1255 ) and aborts the transaction if it is invalid (step 1260 ).

[0081] Assuming the transaction is valid, credit card issuers 140 for transferor 110 and transferee 120 debit the transferor's credit card account and credit the transferee's credit card account, respectively. In particular, transferor's available credit line decreases by the transfer amount for which transferor 110 is liable to pay as a conventional charge. In addition, the transfer amount appears as a credit in transferee's credit account such that transferee's available credit line increases in the same amount as the transfer amount. Each credit card issuer 140 also updates its respective financial tender transfer database 350 to reflect the completed transaction (step 1265 ). Credit card issuers 140 for transferor 110 and transferee 120 then confirm the transaction with central controller 130 (step 1270 ), which sends a confirmation to transferee 120 that the transaction has been executed (step 1275 ). Central controller 130 also updates transaction database 255 to reflect the transaction. As explained above, this implementation also provides more security than the implementation described in connection with FIG. 1 since neither party provides any portion of a credit card number to the other party.

[0082] D. Secure Transactions

[0083] FIG. 13 is a block diagram of another implementation of financial tender transfer system 100 . -This implementation is preferably practiced for transactions between transferor 110 and transferee 120 that require a high level of security because it provides a cryptographically secure, non-reputable, authenticatable credit card funds and/or credit line transfer from transferor 110 to transferee 120 via central controller 130 . Like FIG. 1 , financial tender transfer system 100 of FIG. 13 includes a transferor 110 , a transferee 120 , a central controller 130 , and a plurality of credit card issuers 140 .

[0084] FIGS. 14A and 14B are flowcharts of the steps employed by financial tender transfer system 100 in accordance with the implementation shown in FIG. 13 . First, transferee 120 provides transferor 110 with the last 6 digits or some specified portion of his credit card number, his name, and the name of transferee's credit card issuer (step 1410 ). Transferor 110 registers the credit card transaction to be effected with central controller 130 operated by a trusted third party by providing it with information including transferor information, such as transferor's name, transferor's credit card account number and expiration date, transferee information, such as transferee's name and the last 6 digits of transferee's credit card account number, and the transaction information, such as the amount to transfer. The date and time of registration are also recorded by central controller 130 (step 1415 ). Central controller 130 records the transferor information in customer database 250 and issues an encrypted Identification Number (ID Number), to transferor 110 (step 1420 ). This encrypted ID Number contains all the information provided to central controller 130 including the date and time information. The encrypted ID Number denotes the intention of transferor 110 to pay the transfer amount to transferee 120 . The ID Number is encrypted by using a cryptographic key (issuer key) available to all issuers participating in the system. Any conventional cryptography protocol can be used. The practice of using cryptographic protocols to ensure the authenticity of senders as well as the integrity of messages is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Bruce Schneier, Applied Cryptography, Protocols, Algorithms, And Source Code In C, (2d Ed, John Wiley & Sons, Inc., 1996). Alternatively, central controller 130 may issue a non-encrypted ID Number that is preferably a pointer to all the information given to central controller 130 .

[0085] Transferor 110 provides transferee 120 with the encrypted ID Number (step 1425 ). Transferee 120 then contacts central controller 130 and provides the encrypted ID Number and transferee's name and transferee's full credit card account number (step 1430 ). Central controller 130 decrypts the ID Number with the issuer key and matches the decrypted name of transferee 120 and the last 6 digits of transferee's credit card with information input by transferee 120 (step 1435 ). Central controller 130 then transmits the identified transferee credit card information along with the above transferor credit card information and the transaction information of transferor 110 and transferee 120 to credit card issuers 140 for transferor 110 and transferee 120 (step 1440 ).

[0086] After receiving the information from central controller 130 , credit card issuers 140 for transferor 110 and transferee 120 , respectively, execute the transaction in the following steps. First, credit card issuer 140 for transferor 110 verifies the validity of the transferor's credit card account (step 1445 ) and aborts the transaction if it is invalid (step 1450 ). Credit card issuer 140 for transferor 110 also determines if transferor 110 has sufficient credit (step 1455 ) and aborts the 20 transaction if transferor 110 lacks sufficient credit (step 1460 ). Finally, credit card issuer 140 for transferor 120 verifies the validity of the transferee's credit card account (step 1465 ) and aborts the transaction if it is invalid (step 1470 ).

[0087] Assuming the transaction is valid, credit card issuers 140 for transferor 110 and transferee 120 debit the transferor's credit card account and credit the transferee's credit card account, 25 respectively (step 1475 ). In particular, transferor's available credit line decreases by the transfer amount for which transferor 110 is liable to pay as a conventional charge. In addition, the transfer amount appears as a credit in transferee's credit account such that transferee's available credit line increases in the same amount as the transfer amount. Each credit card issuer 140 also updates its respective financial tender transfer database 350 to reflect the completed transaction. Credit card issuers 140 for transferor 110 and transferee 120 then confirm the transaction with central controller (step 1480 ), which sends a confirmation to transferee 120 that the transaction has been executed (step 1485 ). Central controller 130 also updates transaction database 255 to reflect the completed transaction.

[0088] In this implementation, transferee 120 cannot misuse the transferor's ID Number by repeating the transaction multiple times because the Transferor ID Number is a single use, transaction specific ID Number which incorporates the date, the time, and the amount of the transaction. At the same time, transferor 110 cannot repudiate intent to pay once transferor 110 gives the ID Number to transferee 120 . Hence, the transaction is limited to a one-time use because the ID Number is a proxy for an authorization to transferee 120 to effect a deposit of the transaction amount into the designated transferee credit card account. The ID Number is useful only to transferee 120 because of the matching performed by central controller 140 . Hence, this is a secure transaction.

[0089] In any of the above implementations, transaction information can also be exchanged via the -Internet. When the Internet is used, transferee 120 or transferor 110 access central controller 130 through a web-site to input transaction information via a secure Internet transmission protocol to enable financial tender transactions, such as the transfer of funds and/or credit line amounts, as described above. Information transaction between central controller 130 and the issuing banks may be encrypted for security. In all cases, any issuing bank can abort a transaction because of the various verifications that are performed. The abort transaction information is transmitted to central controller 130 which then transmits this information to the transferee/transferor.

[0090] 2. Preferred Implementations for Credit Line Transfers

[0091] In addition to funds transfers for debiting and crediting a transferor and transferee account, respectively, systems consistent with the present invention can also execute credit line transfers. In a credit line transfer, the transfer amount appears as a conventional transaction entry in transferor's account, with a transaction description stating “credit line transfer to transferee's account.” In contrast to a funds transfer, transferor's available credit line and transferor's original credit line decrease by the transfer amount. Transferor 110 may be charged a service fee, but otherwise no charge is incurred.

[0092] The transfer amount is added to the original credit line of transferee's account. Thus, the available credit line increases in the same amount as the transfer amount. If transferee 120 defaults or becomes bankrupt, transferee's credit card issuer can claim up to the credit line transfer amount from transferor's credit card issuer, who then claims the same from transferor 110 . While the credit line increases, there is no dollar credit applied as with the funds transfer situation described above.

[0093] The credit line transfers will be for a certain dollar amount and a specified time. After the specified time, the credit line transferred will automatically revert to the original transferor. When the transfer is made, transferee 120 has the option to use the transferred credit line. Transferee's credit card issuer can track the usage on the original authorized credit line and the transferred credit line either jointly or separately and reflect the same on a monthly billing statement to transferee 120 .

[0094] A. Secure Transactions

[0095] FIG. 15 is a block diagram of an implementation of a financial tender transfer system 1500 consistent with the invention. This implementation is preferably practiced for credit line transfers, as well as funds transfers, between transferor 110 and transferee 120 that require a high level of security because it provides a cryptographically secure, non-repudiatable, authenticatable credit line transfer from transferor 110 to transferee 120 . Financial tender transfer system 1500 includes a transferor 1510 , a transferee 1520 , a transferor's credit card issuer 1530 , and transferee's credit card issuer 1540 . In this implementation, the functions of central controller 130 of financial tender transfer system 100 are incorporated into both transferor's credit card issuer 1530 and transferee's credit card issuer 1540 . As a result, the aforementioned functions performed by central controller 130 are assumed by transferor's credit card issuer 1530 and transferee's credit card issuer 1540 , either solely or in combination, depending on the steps used for conducting a transfer of financial tender.

[0096] FIG. 16 is a detailed block diagram of a credit card issuer controller 1600 employed by transferor's credit card issuer 1530 and transferee's credit card issuer 1540 . Credit card issuer controller 1600 includes a microprocessor or CPU 1610 coupled to a RAM 1615 , a ROM 1620 , a clock 1625 , a cryptographic processor 1630 , and a data storage device 1635 . Cryptographic processor 1630 encrypts the ID number with the issuer key for the secure transaction described above. Data storage device 1635 includes a customer account database 1640 , a transaction database 1645 , and a financial tender transfer database 1650 .

[0097] FIG. 17 is a table illustrating an example of customer accounts database 1640 . Customer account database 1640 holds data for each customer registered with credit card issuer controller 1600 . The data for each customer includes the customer account number, the customer's name, address, and phone number, the original credit line, and the available credit line.

[0098] FIG. 18 is a table illustrating an example of a conventional transaction database 1645 . Transaction database 1645 retains information of each transaction conducted through credit card issuer controller 1600 . In particular, the information in transaction database 1645 includes the customer account number, the date and time of the transaction, the transaction amount, the merchant identification number, and the name of the merchant.

[0099] FIG. 19 is a table illustrating an example of financial tender transfer database 1650 . Financial tender transfer database 1650 records all information related to a credit line transfer to or from a credit cardholder holding a credit card from the credit card issuer associated with credit card issuer controller 1600 . The credit line transfer information in credit line transfer database 1650 includes the credit card number, the credit line transfer amount, the authorization code, the completion code, the corresponding account number for which the transferred credit line is credited or debited, and the transaction type. A positive dollar amount in the credit line transfer amount indicates an amount credited to the customer account number, whereas a negative dollar amount indicates an amount debited.

[0100] FIGS. 20A and 20B are flowcharts of the steps employed by financial tender transfer system 1500 in accordance with the implementation shown in FIG. 15 . First, transferor 1510 initiates a credit line transfer by providing credit line transfer information to transferor's credit card issuer 1530 including the credit line amount or financial tender value to be transferred, the name of transferor 1510 , the credit card account to transfer from, and the expiration date of that credit card (step 2010 ). Transferor's credit card issuer 1530 checks the validity of transferor's credit card against customer account database 1640 (step 2015 ) and aborts the transaction if it is invalid (step 2020 ). Transferor's credit card issuer 1530 also determines if transferor 1510 has sufficient credit available by checking against the available credit line in customer account database 1640 (step 2025 ). If the credit is insufficient, the transaction is aborted (step 2030 ).

[0101] Transferor's credit card issuer 1530 receives the credit line transfer information and generates an encrypted code which contains the credit line transfer information and issuer identification information (step 2035 ), and may also include transaction date and time information. This authorization code for the credit line transfer is given to transferor 1510 . Transferor 1510 provides this authorization code to transferee 1520 (step 2040 ), who in turn contacts transferee's credit card issuer 1540 and provides the encrypted authorization code and transferee's credit card account number, name, and expiration date to execute the credit line transfer (step 2045 ).

[0102] After receiving the information from transferee 1520 , transferee's credit card issuer 1540 decrypts the authorization code with the issuer key (step 2050 ). The validity of the code is determined by successful decryption. Transferee's credit card issuer 1540 , in addition to confirming the code's validity, confirms the identification of transferor's issuing bank (step 2055 ) and aborts the transaction if the code is invalid (step 2060 ). If the authorization code is valid, transferee's credit card issuer 1540 completes the credit line transfer by increasing transferee's credit line by the amount specified in the decrypted code and updating transferee's records in its financial tender transfer database 1650 (step 2065 ). Transferee's credit card issuer 1540 then generates, stores, and transmits a credit line transfer completion code to transferor's credit card issuer 1530 (step 2070 ). Lastly, transferor's credit card issuer 1530 decreases transferor's credit limit and updates transferor's records in its financial tender transfer database 1650 (step 2075 ).

[0103] In this implementation, like the implementation described in connection with FIG. 13 , transferee 1520 cannot misuse the transferor's ID Number by repeating the transaction multiple times because the Transferor ID Number, in this case, is a single use, transaction specific encrypted code which incorporates transaction specific information, such as the date and the time, and possibly other information including, for example, the amount of the transaction. The encrypted transaction ID that incorporates a date and time guarantees a unique ID for every transaction. The system prevents multiple uses of encrypted transaction IDs by only allowing each unique ID to be used once. At the same time, transferor 1510 cannot repudiate intent to transfer a credit line amount once transferor 1510 gives the encrypted code to transferee 1520 . The encrypted code is a proxy for an authorization to transferee 1520 to effect a credit line transfer into the designated transferee credit card account.

[0104] B. Sale of Unused Credit Line

[0105] FIG. 21 is a block diagram of another implementation of financial tender transfer system 1500 consistent with the invention. This implementation is preferably practiced in cases where a transferor is selling his unused credit line because the transferor is the party through which the transaction is executed. In other words, a transferor transfers an unused credit line amount to a transferee for a certain amount of consideration, but the transferor retains responsibility for payment of any debt on the unused credit line amount transferred. Similar to FIG. 15 , financial tender transfer system 1500 of FIG. 21 includes a transferor 1510 , a transferee, 1520 , a transferor's credit card issuer 1530 , and transferee's credit card issuer 1540 .

[0106] FIGS. 22A, 22B , and 22 C are flowcharts of the steps employed by financial tender transfer system 1500 in accordance with the implementation shown in FIG. 21 . First, transferee 1520 provides transferor 1510 with the last 6 digits or some specified portion of his credit card number, his issuing bank identification, and his name (step 2210 ). Transferor 1510 then initiates the credit line transfer by providing credit line transfer information to transferor's credit card issuer 1530 including the financial tender value to be transferred, the name of transferor 1510 , the credit card account to transfer from, the expiration date of that credit card, the name of transferee 1520 , the last 6 digits of the transferee's credit card account, and the name of transferee's credit card issuer 1540 (step 2215 ).

[0107] After receiving the credit line transfer information, transferor's credit card issuer 1530 verifies the validity of the transferor's credit card and availability of credit line against customer account database 1640 (step 2220 ). First, transferor's credit card issuer 1530 determines if transferor's credit card is valid (step 2225 ) and aborts the transaction if it is not (step 2230 ). If valid, transferor's credit card issuer 1530 also determines if transferor's credit card has sufficient credit available (step 2235 ) and aborts the transaction if it is insufficient (step 2240 ). If transferor's credit card is both valid and has sufficient credit available, transferor's credit card issuer 1530 generates a credit line transfer authorization code (step 2245 ). Transferor's credit card issuer 1530 then transmits the credit line transfer information to transferee's credit card issuer 1540 along with the authorization code (step 2250 ).

[0108] Transferee's credit card issuer 1540 matches the received last 6 digits or portion of the transferee's account number with the actual account number in its customer account database 1640 (step 2255 ). Transferee's credit card issuer 1540 determines whether to proceed with the transaction by matching the last 6 digits to the actual account number (step 2260 ). The transaction is aborted if they do not match (step 2265 ). Otherwise, transferee's credit card issuer 1540 completes the credit line transfer by increasing the transferee's credit line by the amount specified and by updating the transferee's records in its credit line transfer database 1640 (step 2270 ). The transferee's credit card issuer 1540 also generates, stores, and transmits a credit line transfer completion code to the transferor's credit card issuer 1530 (step 2275 ), who in turn decreases transferor's credit line and updates its credit line transfer database 1650 (step 2280 ).

[0109] Conclusion

[0110] The financial tender transfer system according to this invention allows a transferor to transfer credit or make payment to a transferee by debiting the credit card of the transferor and crediting the credit or debit card of the transferee. The financial tender transfer system gives the transferee immediate access to the transferred funds and/or credit line, ensures the transferor's credit card is valid, and preserves security.

[0111] It will be apparent to those skilled in the art that various modifications and variations can be made to disclosed embodiments of the present invention without departing from the scope or spirit of the invention. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments of the invention disclosed herein. The specification and examples should be considered exemplary, with the true scope and spirit of the invention being indicated by the following claims and their full range of equivalents.