Abstract:
A payment card that facilitates use of a plurality of bankcards of a customer, at a point of sale terminal has a payment card with a front side and a backside with a substrate, the substrate encodes a customer identifier as a payment card data that is without a bankcard data, and maps the customer to a plurality of bankcards data in a third party system database. The payment card is enabled to be used at a merchant point-of-sale (POS) terminal with a customer entered PIN, enabling the POS terminal to transfer a payment authorization request record incident to a sales transaction, from the POS to a merchant gateway for routing to a card-issuing banks, thereby enabling use of the payment card in lieu of the customer bankcards at the merchant POS terminal.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application is a continuation application of U.S. application Ser. No. 12/012,345 which was filed on Feb. 1, 2008. 
         [0002]    U.S. application Ser. No. 12/012,345 is a divisional application of U.S. application Ser. No. 09/891,913 (U.S. Pat. No. 8,195,568) filed on Jun. 26, 2001. 
         [0003]    U.S. application Ser. No. 09/891,913 is a non-provisional application of U.S. Provisional Application No. 60/237,328, filed on Oct. 2, 2000. 
         [0004]    Further, U.S. application Ser. No. 09/891,913 is a non-provisional application of U.S. Provisional Application No. 60/215,261, filed on Jun. 30, 2000. 
     
    
     FIELD OF THE INVENTION 
       [0005]    The present invention is directed to a method and apparatus for facilitating payment transactions to merchants using existing bankcards and bank accounts of a customer. Further, the present invention is directed to a method and apparatus for protecting the privacy and private data of a customer in data storage and during transactions. 
       BACKGROUND 
       [0006]    People usually carry multiple types of bankcards. The multiple types of bankcards can include charge cards, debit cards, check cards, and merchant cards specific to a merchant. These types of bankcards have become very popular and a large number of people carry multiple different bankcards. 
         [0007]    Unfortunately, existing bankcards are not entirely satisfactory, and have a number of deficiencies. For example, existing bankcards suffer from ever changing security issues that the banking industry is always working to solve. Also, it is inconvenient for the customer to carry multiple different bankcards. Existing bankcards have other additional deficiencies than those detailed herein. 
       SUMMARY 
       [0008]    This invention is directed to a payment card that can be used by a customer to perform a transaction with a merchant. In some of the embodiments provided herein, the payment card facilitates the use of an existing bankcard of the customer to conduct a particular transaction. In some of the embodiments, the payment card provides a level of security to the customer because the payment card does not identify the customer. Further, the card number and/or the expiration date of the payment card is not disclosed to the merchant. 
         [0009]    The use of the payment card is facilitated by a payment system. The payment system allows the customer to open a payment card account. In one of the embodiments provided herein, the payment system stores private data of the customer that is not directly recognizable and traceable to the customer. 
         [0010]    As used herein the term “bank card” shall mean and include charge cards, debit cards, and check cards issued by banks and/or other institutions, and merchant cards specific to a merchant. A number of alternate types of bankcards are already in existence. 
         [0011]    Further, as used herein, the term “privacy payment” shall mean and include a form of payment that does not specifically identify the customer to the merchant. For example, the privacy payment does not include and/or disclose the physical address, the social security number, the electronic mail address, and/or information of the bankcards of the customer to the merchant. 
         [0012]    Moreover as used herein, the term “private data” shall mean and include data that when taken alone can be used to specifically identify the customer. Private data can include the physical address, the social security number, the electronic mail address, the driver&#39;s license number, and/or the information of the bankcards of the customer. Private data is also sometimes referred to as identifying data. 
         [0013]    As provided herein, some embodiments of the present invention can allow the customer to purchase one or more items or services from the merchant without the merchant knowing the identity, bankcard information and/or address of the customer. Stated another way, the payment system allows the customer to purchase one or more items or services from the merchant without disclosing the name, physical address, electronic mail address, and bankcard information of the customer to the merchant. As a result thereof, the payment system minimizes the number of people, businesses and institutions that have access to the private data of the customer. This minimizes the opportunity for the private data of the customer to be improperly disseminated. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    The novel features of this invention, as well as the invention itself, both as to its structure and its operation, will be best understood from the accompanying drawings, taken in conjunction with the accompanying description, in which similar reference characters refer to similar parts, and in which: 
           [0015]      FIG. 1A-1E  is block diagrams that illustrate an apparatus and method having features of the present invention; 
           [0016]      FIG. 2  is a block diagram that illustrates a payment system having features of the present invention; 
           [0017]      FIGS. 3A-3E  are block diagrams that illustrate databases having features of the present invention; 
           [0018]      FIG. 4A-4C  illustrates a customer identifier having features of the present invention; 
           [0019]      FIGS. 5A and 5B  are simplified examples of web pages that can be generated by the payment system; and 
           [0020]      FIGS. 6A-6C  and  7  are block diagrams that outline the operation of a method and apparatus having features of the present invention. 
       
    
    
     DESCRIPTION 
     Introduction 
       [0021]    Referring initially to  FIGS. 1A-1C , a method and apparatus  10  having features of the present invention can include a payment system  12 , a payment system interface  12 A, at least one customer interface  20 A for a customer  20 , one or more merchant interfaces  22 A (two are illustrated) for two merchants  22 . In some of the embodiments, a payment card  30  (illustrated in  FIG. 1B ) (i) facilitates the anonymous use of one or more bankcards  31  (illustrated in  FIG. 1C ) of the customer  20  and (ii) provides anonymity and security to the customer  20  in transactions between the customer  20  and the merchant  22 . 
         [0022]    As an overview, the present invention allows the customer  20  to maintain private data  25  (illustrated in  FIG. 2 ) of the customer in the payment system  12 , and to use the payment card  30  in place of other bankcards  31  of the customer. Preferred and optional aspects of the method and apparatus  10  are described below. The headings are provided for the convenience of the reader. 
         [0023]    Payment System  12   
         [0024]    Referring to  FIG. 2 , the payment system  12  includes (i) a payment system storage device  26 , (ii) a payment system operating system  27  stored in the payment system storage device  26 , (iii) a payment system program  28  stored in the payment system storage device  26 , (iv) and a payment system processor  29  connected to the payment system storage device  26 . 
         [0025]    The payment system processor  29  can include one or more conventional CPU&#39;s. The payment system processor  29  can be capable of high volume processing and database searches. 
         [0026]    The payment system storage device  26  can, for example, include one or more magnetic disk drives, magnetic tape drives, optical storage units, CD-ROM drives and/or flash memory. The payment system storage device  26  also contains a plurality of databases used in the processing of transactions pursuant to the present invention. For example, as illustrated in  FIG. 2 , the payment system storage device  26  can include a merchant database  40 , and a customer database  38 . As outlined below, the customer database  38  can retain information regarding one or more existing bankcards  31  of the customer  20 . The information can include the customer name, the number for each bankcard  31 , and/or the expiration date of each bankcard  31 . 
         [0027]    Referring back to  FIG. 1A , the payment system  12  includes a system network interface  12 B that allows the payment system  12  to communicate with the customer  20 . Conventional internal or external modems may serve as the system network interface  12 B. In one embodiment, the system network interface  12 B is connected to the customer interface  20 A on a global network  24 . Alternately, the system network interface  12 B can be connected by an electronic, a voice and/or a traditional communication system that allows the payment system  12  to interact with, the customer interface  20 A. For example, the payment system  12  can be connected to the customer interface  20 A with one or more phone lines. 
         [0028]    The payment system interface  12 A can include an input device (not shown), such as a keyboard, mouse or voice recognition software and a display that allows access to the payment system  12 . As illustrated in  FIGS. 1A ,  1 D and  1 E, the payment system interface  12 A interfaces with a gateway  23 , which interfaces with a bank card authorization network  21 . The gateway  23  is a computer system that routs the data for payment authorization to the bank card authorization network  21 , based on the bank routing number, usually the first 4 digits of the bankcard number. The bankcard authorization network  21  is computer systems that process data from an existing bankcard  31 . The bankcard authorization network  21  receives the payment transaction data regarding the bankcard  31  and returns payment authorization data. The gateway  23  and network  21  can be similar to existing prior art devices used to process existing bankcards. 
         [0029]    The payment system processor  29  is operative with the payment system program  28  to perform the steps outlined in  FIGS. 6A-6C  and  7 . 
         [0030]    A customer network interface  20 B allows the customer  20  to communicate with the payment system  12  and/or the merchant  22 . Conventional internal or external modems may serve as the customer network interface  20 B. In one embodiment, the customer network interface  20 B is connected to the merchant interface  22 A and the payment system interface  12 A on the global network  24 . Alternately, the customer network interface  20 B can be connected by other electronic, voice and/or traditional communication systems that allow the customer  20  to interact with the merchant interface  22 A and the payment system interface  12 A. 
         [0031]    The customer interface  20 A can include an input device, such as a keyboard, mouse or voice recognition software and a display that allows the customer  20  to interact with the customer network interface  20 B. 
         [0032]    A merchant network interface  22 B allows the merchant  22  to communicate with the gateway  23 . Conventional internal or external modems may serve as the merchant network interface  22 B. The merchant network interface  22 B can be connected to the customer interface  20 A on the global network  24 . Alternately, the merchant network interface  22 B can be connected by other electronic, voice and/or traditional communication systems that allow the merchant  22  to interact with the gateway  23 . 
         [0033]    The merchant system interface  22 A can include an input device, such as a keyboard, mouse or voice recognition software and a display that allows access to the gateway  23 . 
         [0034]    Payment Card  30   
         [0035]    With reference to  FIG. 1B , the payment card  30  has front side  30 A and back side  30 B. The front side  30 A can include the name of the card  32 A, and the customer name  32 B. The customer name  32 B can be a chosen alias  354 B of the customer as described later with reference to  FIGS. 3D and 5B . The back side  30 B can include a machine readable area  33  such as a magnetic strip. The magnetic strip can include data in an encoded form. The data can include a customer identifier  320 . One form of the customer identifier  320  is described later with reference to  FIG. 4C . 
         [0036]    In some of the embodiments, the information and data contained in the magnetic strip does not contain any of the private data  25  of the customer such as the name, the customer address, the card number(s) of the existing bank cards  31  of the customer  20  and/or the expiration date of the existing bank cards  31  of the customer  20 . With this design, if the payment card  30  fell into wrong hands, it does not identify the name of the customer and the existing bank card(s) of the customer  20 . 
         [0037]    Bank Card  31   
         [0038]      FIG. 1C  illustrates a bankcard  31  that can be used in conjunction with the present invention. The bankcard  31  can be a debit card, a credit card, a check card, or another type of card already obtained by the customer. The bank card  31  can include private data  25  of the customer  20  including the name, number of the bank card, expiration date of the bank card  31  and signature as illustrated on front and back sides  31 A and  31 B of the bank card  31 . 
         [0039]    Payment Card  30  Usage 
         [0040]    With reference to  FIG. 1D , when the customer  20  is using the payment card  30  at the location of the merchant  22 , the payment card  30  can be swiped in a card reader  34  that is at the location of the merchant  22 . The card reader  34  is adapted to read the readable area  33  of the payment card  30 . The card reader  34  can include a display window  34 A, a card slide slot  34 B, function buttons  34 C that enables the selection of one of the bank cards, a numeric keypad  34 D, an enter button  34 E and Yes/No button  34 F. Subsequently, the customer  20  uses the buttons  34 C to select the type of transaction and enters a PIN number using the numeric keypad  34 D. The merchant interface  22 A generates a merchant identifier and a total payment amount for the transaction. The merchant identifier can be any combination of characters that identifies the merchant  22 . The total payment amount for the transaction will vary according to the transaction. The transaction can be for one or more purchased item(s) and/or services from the merchant. 
         [0041]    Next, the data from the payment card  30 , the merchant identifier and payment amount is then sent to the gateway  23  using the merchant network interface  22 B. In this embodiment, the gateway  23  is adapted to recognize and/or identify the payment card  30  relative to other bankcards  31 . When the gateway  23  detects that the payment card  30  is being used, the gateway  23  connects to and sends the payment card number and PIN data to the payment system  12  and waits for the payment system  12  to send the customer name, the number of the bank card and the expiration date of the bank card  31  from the payment system  12  to the gateway  23 . The adapted gateway  23  then reassembles the payment transaction data of name, the bankcard number, expiration date, merchant identifier and amount and sends that to the bankcard authorization network  21 . The bankcard authorization network  21  uses this information to determine if the bankcard is good to cover the transaction. If acceptable the authorization network  21  provides a payment authorization number that is forwarded to the merchant via the gateway  23 . Additionally, the bankcard of the customer is charged or debited by the authorization network  21 . 
         [0042]    Alternately, referring to  FIG. 1D , the customer  20  can use the payment card  30  to make a transaction in a location, away from the merchant using the World Wide Web. In this version, the customer  20 , instead of being physically at the location of the merchant  22 , is making a payment through a merchant web page  36 , that displays the merchant identifier  36 A, the payment amount  36 B, a space for entry of card number  36 C of the payment card  30 , the expiration data  36 D of the payment card  30 , the name  36 E of the customer and the e-mail address  36 F of the customer. The customer  20  enters the payment card  30  data such as card number, expiration date, name and e-mail. Some of the data to be entered here is illustrated later with reference to  FIG. 4B . 
         [0043]    Subsequently, the information is transferred to the gateway  23 . When the gateway  23  receives the connection and data from the merchant web page  36 , the adapted gateway  23  detects the use of the payment card  30  and forwards the data to the payment system  12 . The payment system  12 , using the data received via the gateway  23 , searches the payment system databases  38 A- 38 D (illustrated in  FIG. 2 ), and assembles the pieces of a payment transaction including customer name, the number of the bank card, the expiration date of the bank card, and forwards that to gateway  23 , which completes the assembly of payment transaction record along with merchant identifier and amount forwards to the bank card authorization network  21 . The bankcard authorization network  21  processes a payment from one of the bankcards  31  of the customer and generates a payment authorization number. For each payment transaction, the gateway  23  or the merchant interface  22 A generates a reference number. The reference number is used to reference a particular payment from other payments processed through the gateway  23  and the authorization network  21 . On payment approval, the reference number, and a payment authorization number are returned to the merchant interface  22 A. The reference number and the payment authorization number is a “privacy payment” that does not identify the customer to the merchant. 
         [0044]    The card authorization network  21  cannot distinguish this payment transaction from any other card payment transaction it may receive directly from the gateway  23 . The card authorization network  21  processes the transaction and responds with the payment authorization and reference number for the transaction. On receiving the payment authorization number, the gateway  23  forwards the information to the merchant  22 . Additionally, the bankcard of the customer is charged or debited by the authorization network  21 . 
         [0045]      FIG. 1E  illustrates an alternative way to conduct a transaction using the payment card  30 . In this alternative embodiment, the payment transaction data is directly received by the payment system  12  with the help of a wireless network without it first going to the gateway  23 . The payment system  12 , with this payment data, is able to assemble the complete payment data of the customer including the customer name, bank card number, expiration date, and amount and merchant identifier and forward that to the gateway  23 , which in turn forwards it to the authorization network  21 . In this embodiment, the gateway  23  need not be adapted to recognize a payment card. 
         [0046]    Further, in this embodiment, a merchant computer system  100 , a wireless data input device  104  and a docking station  102 , can be utilized. The docking station  102  is used to charge the device  104  and to transfer data  102 A between the input device  104  and the merchant computer system  100 . The input device  104  can include privacy shields  106  that are hinged to the left and/or right sides of the device  104 . The shields  106  may be folded when the device  104  is put in the docking station  102 . The shields  106  may be unfolded when used by the customer  20 . 
         [0047]    The device  104  can include a display screen  104 A, a keypad  104 B, a card reader mechanism  104 C and antenna  104 D. The device  104  can include memory for storing details of multiple transactions (not shown). The device  104  may also have a printing mechanism (not shown). 
         [0048]    The merchant  22  can pre-program the device  104  with the merchant identifier  51  that enables the payment system  12  to identify the merchant. The merchant, at the time of a payment transaction with the customer, may remove the device  104  from the docking station  102 , enter the dollar amount of the transaction using keypad  104 B and display screen  104 A, and then transfer the device  104  to the customer  20 . 
         [0049]    The device  104  enables the customer  20 , to review the dollar amount of the transaction and to swipe the payment card  30  and then enter a personal identification number in the device  104 . The device  104  forwards the customer data and merchant data as a data block  122  to the payment system  12  using a wireless cellular network  130 . 
         [0050]    The payment system  12 , using the customer data and merchant data, as described elsewhere in this application, runs a credit card transaction using the gateway  23  and the payment network  21  and returns the reference number and the payment authorization number for this transaction  124  to the device  104 . The customer reviews the authorization. The device  104  can include a printer (not shown) for printing a confirmation slip that lists the date, the merchant, the dollar amount and/or the reference number. The customer subsequently transfers the device  104  to the merchant. The merchant may return the device  104  back to the docking station  102  or use the device  104  for another transaction with another customer. The docking station  102  reads the payment data of each transaction from the device  104  by the transaction&#39;s date/time, reference numbers and authorization numbers, dollar amount  120  and transfers the data to the merchant computer system  100 . 
         [0051]    System Program  28   
         [0052]    The payment system program  28  is operative with the payment system processor  29  to provide the functions of (i) interfacing with the customer  20  to receive and save customer private data  25  in databases  38 A- 38 D via web pages  500 A- 500 B, (ii) interface with the gateway  23  to receive payment transaction data from the merchant  22 , (iii) process payment transaction data by searching databases  38 A- 38 D to assemble an existing card payment transaction data, and (iv) to interface with the card networks  21  to send the transaction data and receive payment authorization number and a reference number. Further, the system program  28  is operated with the payment system processor  29  to perform the tasks of the payment system  12  provided herein. 
         [0053]    Customer Database  38   
         [0054]    With reference to  FIG. 2 , the customer database  38  within the payment system  12  contains private data  25  specifically related to the customer  20  that is transferred to the privacy system  12  from the customer. The private data  25  related to the customer  20  can be separated and stored in at least four separate sub-databases, namely, (i) an identifier sub-database  38 A, (ii) identifying data sub-database  38 B, (iii) existing bank card data sub-database  38 C, and (iv) payment card PIN data sub-database  38 D of each customer  20 . The sub-databases are explained below. 
         [0055]    Identifier Database  38 A 
         [0056]    Referring to  FIGS. 2 and 3A , the payment system  12  can store a customer identifier  320  for each of the customers  20  in the identifier database  38 A. As provided herein, the customer identifier  320  can be used to anonymously identify and verify the customer  20  for gaining access to and interacting with the payment system  12 . The customer identifier  320  enables the customer  20  to interact with and use the payment system  12  without revealing private data of the customer. Stated another way, the customer identifier  320  enables the customer  20  to be anonymously identified to the payment system  12 . 
         [0057]    The customer identifier  320  can be any number of characters that can be used to identify and verify the customer  20  for gaining access to and interacting with the payment system  12 . The customer identifier  320  can be self-created by the customer  20 . More specifically, the customer  20  can create the exact characters that make up the customer identifier  320  without the aid or authority of any business, the payment system  12  or government entity. However, as provided herein, the payment system  12  can provide a guideline for the format of the customer identifier  320 . The details of the customer identifier  320  are explained in more detail below. 
         [0058]    The payment system  12  can also assign and associate a unique sequence number  330  for each customer identifier  320 . The sequence number  330  can include any number of characters. The sequence number  330  is subsequently used as a reference to save and retrieve the private data  25  of the customer  20  in the identifying database  38 B, existing bankcard data database  38 C and payment card data database  38 D. The sequence number  330  can also be stored with the customer identifier  320  in the identifier database  38 A. 
         [0059]    The customer  20  can access the payment system  12  using the customer network interface  20 B. Upon the entry of the customer identifier  320  by the customer  20  via the customer interface  20 A, the payment system program  28  operates with the payment system processor  29  to review the identifier database  38 A to check for the existence of the customer identifier  320 . Upon the location of an existing customer identifier  320 , the payment system  12  allows the customer  20  to have access to the private data  25  that is tied to the customer identifier  320 . The identifier database  38 A is also used to store the new customer identifier  320  for each new customer  20  that creates a new customer identifier  320 . 
         [0060]    Identifying Database  38 B 
         [0061]    Referring to  FIG. 3B , the payment system  12  can store any identifying data  322  of the customer  20  in the identifying database  38 B of the storage device  26 . Identifying data  322 , as used herein, shall mean any information or data of the customer  20  that if used independently is sufficient to positively identify the customer  20  to a third party. Examples of identifying data  322  can include, a name, an address, a telephone number, a facsimile number, an e-mail address, a social security number, credit card number, and/or a driver license number of the customer  20 . 
         [0062]    The identifying data  322  can be kept in the identifying database  38 B of the payment system  12  in a manner that safeguards the privacy of the identifying data  322  in the storage device. Many approaches may be used to safeguard the privacy of identifying data  322 . For example, access to the identifying database  38 B can be controlled by a password (not shown). 
         [0063]    The present invention also discloses a method that may be used in conjunction with and/or separately from any other methods to make the identifying data  322  stored in the identifying database  38 B more secure. This method uses separate databases for each piece of the data. As a simplified illustration, referring to  FIG. 3B , the name  350 A, street address  350 B, city/state/zip address  350 C, e-mail address  350 D, and telephone number  350 E of the customer may be kept in physically separate databases  322 A to  322 E respectively. The data pieces within the separate sub-databases are referenced to the customer by the sequence number  330  and are accessible by using the sequence number  330 . In this method, the identifying data of the customer is fragmented over many databases and storage devices, such that one database only stores partial information of the customer. 
         [0064]    Existing Bank Card Data Database  38 C 
         [0065]    With reference to  FIG. 3C , the information and data relating to the existing bankcards  31  of the customer  20  can be stored as multiple partial card data in multiple databases of the payment system. As a simplified illustration, for each bankcard  31 , the customer name is stored as data  322 A in database  38 B (illustrated in  FIG. 3B ) and the card number and card expiration as data  324 A and  324 B in database  38 C. The database  324 A may store card numbers  352 A. The data relating to the multiple bankcards of the customer can be stored and anchored by sequence number  330 . Database  324 B can store for each of the bank cards, its corresponding expiration date  352 B and for those bank cards for which a PIN is used, the PIN of the bank card  352 C. 
         [0066]    Existing Card Data Security Methods 
         [0067]    To provide yet another level of security, for each bankcard  31 , the card number and the expiration date may be partitioned, as partial data elements into separate databases. There are many methods of creating partial data elements, some of them are described herein. The details of breaking the data into partial data elements and then reconstructing the original data from the partial data elements are exclusively embedded in the logic of the payment system program which stores and retrieves the data and is not part of the data itself. This provides a level of security to the data of the bankcard that is stored in the payment system. Some examples of logic that may be used in creating partial data elements are described as follows: 
         [0068]    Method 1: partial data elements are 16 digits of the card number and expiration date of the bankcards. 
         [0069]    Method 2: partial data elements are the first 4 digits of the 16 digits of the card number and remainder 12 digits added to the 4 digits of the expiration date. 
         [0070]    Method 3: partial data elements are the first 8 digits of the 16 digits of the card number and the remainder 8 digits added to the 4 digits of the expiration date. 
         [0071]    Method 4: partial data elements are five sequences of four 4-digits of the 16 digits of the card number and 4 digits of the expiration date. 
         [0072]    Method 5: partial data elements are five sequences of four 4-digits of the 16 digits of the card number and 4-digits of the expiration date. Wherein the five sequences are stored in a random order, the order of randomness being part of data storage and data retrieval logic. 
         [0073]    Method 6: partial data elements are five sequences of four 4-digits of the 16 digits of the card number and 4-digits of the expiration date. Wherein any one 4-digit number, selected in a random order is offset by an offset number, the random order and offset number being part of data storage and data retrieval logic. 
         [0074]    Method 7: Any permutation or combination of the methods  1  to  6  discussed above. 
         [0075]    One of the data security methods described above is illustrated with a simplified illustration in  FIG. 3E . The number  352 A of the bankcard is referenced by the sequence number  330 . As detailed below, the original information is transferred into equivalent information that is indistinguishable in format to the original information. To be indistinguishable, for example, (i) numbers in the original information are replaced with alternate numbers in the equivalent information, and (ii) letters in the original information are replaced with alternate letters in the equivalent information. The bankcard number  352 A is broken into four original elements A, B, C and D. The element A is a bank code that identifies the bank that issued the bankcard. The expiration date  352 B is called original element E. 
         [0076]    A transformation logic  310  within the system program  28  is used to transform the bankcard data  352 A and  352 B into equivalent data elements  314  for storage. The transformation logic  310  takes the original bankcard data elements and transforms the data into an equivalent bankcard data elements that is indistinguishable from the original bankcard data in format. Subsequently, the equivalent data elements are stored in the payment system. 
         [0077]    This method of data storage obviates the need and expense for extra-ordinary measures to secure and safeguard the databases. The transformation logic  310  is the only knowledge that needs to be protected. The transformation logic  310  is only known to the creators of the logic design and is further stored in the computer system as complied code, and thus not accessible for theft directly from the computer system. 
         [0078]    The transformation logic  310  has a forward transform logic  310 A, a reverse transform logic  310 B, a bank code table  310 C listing all the possible bank codes, an expiration date table  310 D, listing all the possible expiration dates and an offset table  310 E, listing the offsets that are applied to the elements A, B, C, D, and E for a range of sequence numbers. 
         [0079]    For a bankcard data that is input to the logic  310 , the forward transform logic  310 A, determines the range of the sequence number. Then using this range it reads the offsets for that range from table  310 E. Offset  1  is applied to original element A to get equivalent element A, offset  2  is applied to original element B to get equivalent element B, offset  3  is applied to original element C to get equivalent element C, offset  4  is applied to original element D to get equivalent element D and offset  5  is applied to original element E to get equivalent element E. 
         [0080]    These offsets can be of many types. For example, the offsets for element A and E enable an equivalent bank code and expiration date from the tables  310 C and  310 D. Offsets for element B, C and D provide a means for new equivalent elements B, C and D. 
         [0081]    The reverse transform logic  310 B, using the sequence number  330  as an input parameter, enables the equivalent bank card data  314  to be converted back to the original bank card data of  352 A and  352 B. 
         [0082]    It is believed, using this type of transformation logic, there is no correlation between the equivalent bankcard data and the original bankcard data, such that a thief or hacker cannot determine the original bankcard data. It obviates the need for extra-ordinary measures to safeguard the bankcard databases. 
         [0083]    Payment Card Data Database  38 D 
         [0084]    With reference to  FIG. 3D , the data of the payment card  30  of the customers  20  can be stored within two databases  326 A and  326 B. The database  326 A may store PIN numbers  354 A for each bank card  31  in database  324 A that have been self-selected by the customer  20 . The sequence number  330  anchors the PIN data of each customer. Database  326 B may store for each customer the self-selected alias name  354 B of the customer. The sequence number  330  also anchors the alias name data  326 B of the customer. 
         [0085]    Customer Identifier 
         [0086]      FIG. 4A  illustrates one embodiment of a customer identifier  320 . The customer identifier  320  illustrated in  FIG. 4  utilizes a single data string  400  that can be used to anonymously verify the customer  20  to the payment system  12 . Because there is no public identification step, the identity of the customer  20  can be maintained within the payment system  12  without formally and publicly identifying the customer  20  to the payment system  12 . Further, the customers  20  can access the payment system  12  without personally identifying themselves to the payment system  12 . 
         [0087]    The anonymous identifier  320  can include one or more elements  408 ,  410 ,  412 ,  414 ,  416  that are separated by a delimiter  404 . The elements  408 - 416  make it easy for the customer  20  to create, use and remember the anonymous identifier  320 . Each of the elements  408 - 416 , for example, can include one or more easy to remember characters. 
         [0088]    As provided herein, a first element  408  can include the sub-elements of a calendar date. A second element  410  may be a class code of the customer  20 . A third element  412  may be in the form of a location code of the customer  20 . A fourth element  414  may be a name abbreviation of the customer  20 . A fifth element  416  can be a sequence code. 
         [0089]    Any combination and/or organization of one or more of the elements  408 - 416  as described above may be used as the customer identifier  320 . The customer identifier  320  can be self-created by the customer  20  the first time the customer  20  interacts with the payment system  12 . After the customer identifier  320  is created, it can be stored in the identifier database  38 A by the payment system  12 . Subsequently, the customer identifier  320  is used to verify the customer  20  to the payment system  12  so that the customer has access to the private data  25  of the customer in the payment system  12 . 
         [0090]      FIG. 4B  illustrates a form of the customer identifier  320  that may be used for a web based payment transaction, where the card number, expiration date, and name need to be provided. It may also be used where the customer  20  has established a voice communication with an employee of the merchant to process the payment transaction. A sixteen digit payment card number  418  is provided. This card number has the customer identifier  320  that includes elements of date  408 , personal code  410 , zip code  412 , and name initials  414  as one continuous string. A card expiration date string  420  of 4 digits may be provided. This string  420  may be the payment card PIN  354 A that identifies the particular existing bankcard the customer may choose for this transaction. For the name, the customer may provide an alias name  354 B. The payment card PIN  354 A and alias name  354 B are illustrated in  FIGS. 3D and 5B . 
         [0091]      FIG. 4C  illustrates a form of customer identifier  320  that may be stored in the readable area  33  of the payment card  30 . The customer identifier is encoded  422  and the code number  424  used for encoding is embedded by appending it as part of the encoded customer identifier. 
         [0092]    Referring to  FIG. 3D , the payment card database  38 D maintains the encoding data  326 C as data items code number  354 C and the code algorithm  354 D. When a transaction using the card  30  is received at the payment system  12  via the gateway  23 , the corresponding algorithm is retrieved from database  326 C to decode the customer identifier. This can provide a level of security to the customer, if the card  30  falls in the possession of a dishonest person. 
       Merchant Database  40   
       [0093]    The merchant database  40  maintains data on all of the merchants  22  that interact with the payment system  12 . The merchant database  40  can store (i) a merchant identifier  51  and (ii) the merchant date  40 A, e.g. the name, address, phone, facsimile, web page, and/or electronic mail address of the merchant together in one sub-database. A merchant  22  may connect to payment system  12  and enter/update merchant data. In one of the embodiments, the merchant database  40  may be used to verify that the merchant identifier  51  is correct when the payment system  12  receives the payment transaction data from the merchant  22 . It may also be used for billing purposes if a merchant is charged fees for interfacing with the payment system  12 . Additionally, the merchant database  40  may be used to keep payment transaction data such as merchant identifier, reference number, authorization number, date, time, and amount for archival enabling later retrieval and or reference by the merchant. 
       Payment System Web Pages  500   
       [0094]    In an optional version of the present invention, the payment system program  28  is operative with the payment system processor  29  to generate one or more web pages  500 A on the World Wide Web. The web pages  500 A allow each customer  20  to provide information through the customer interface  20 A to the payment system  12 . Alternately, for example, instead of the World Wide Web, the customer  20  can provide some or all of the information to the payment system  12  via voice mail, facsimile, or postal mail transmissions. 
         [0095]      FIG. 5A  illustrates an example of an initial payment system web page  500 A. The initial system web page  500 A can be displayed on the customer interface  20 A when the customer  20  first registers with the payment system. 
         [0096]    The initial payment system web page  500 A illustrated in  FIG. 5A  includes (i) an area for entry of the customer identifier  320 , including areas for entering the data element  408 , the personal element  410 , the location element  412 , the name element  414  and the number element  416  of the customer identifier  320  of the customer  20  and (ii) a SEND icon  514 . 
         [0097]    After the customer  20  enters the required information and clicks the SEND icon  514 , the payment system  12  receives and validates the customer identifier  320 . Subsequently, the payment system  12  generates a data type page  536  that allows the customer  20  to select data type to enter/retrieve  522  from (i) identifying data  322 , (ii) existing bank card data  324  and payment card data  326 . After selection of a data type and clicking SEND icon  534 , a data web page  500 B with the corresponding data type forms  524 A,  524 B and  524 C, are displayed.  FIG. 5B  illustrates a data web page  500 B for entering customer private data  25 . Form  524 A on the web page allows entry of identifying data  322 A-E such as name  350 A, address  350 B, city/state/zip  350 C, telephone  350 D and e-mail address  350 E. Form  524 B on the web page allows entry of existing bank card data  324 A-C such as card number  352 A, card expiration date  352 B and a bank PIN  352 C, if required for the specific bank card. Form  524 C allows entry of payment card PIN  354 A and alias name  354 B. The payment card PIN  354 A is created and entered for each of the existing card numbers  352 A of the customer and enables the customer to select any one of the existing cards when conducting a payment transaction using the payment card. 
         [0098]    Operation 
         [0099]    The operation of the apparatus  10  and payment system  12  for a payment transaction can be further understood with reference to the flow charts illustrated in  FIGS. 6A-7 . The operation of the payment card in processing a payment transaction can be better understood with reference to  FIGS. 6A ,  6 B and  6 C. The method for the customer  20  to establish an account with the payment system  12  is illustrated in  FIG. 7 . Importantly, the order of some or all of the steps can be varied. Further, not all of the steps outlined below are necessary to perform a transaction pursuant to the present invention. 
         [0100]    More specifically,  FIG. 6A  outlines the steps for using the payment system  12  when the customer is at the location of the merchant. Referring initially to  FIG. 6A , at step  600  the customer  20  is at the site of the merchant  22 , ready to make a payment. At step  602 , the customer selects the type of bankcard using the reader as a debit card because a debit card requires entry of PIN to complete the transaction. At step  604 , the customer swipes the payment card through the reader. At step  606 , the card reader logic reads the payment card number. At step  608 , the logic prompts the customer for a PIN number. At step  610 , the customer enters the PIN specific to one of the bankcards that the customer wishes to use for this particular payment. At step  612 , the logic sends the payment card number, PIN, dollar amount that has been entered by the merchant, and the merchant identifier to the adapted gateway  23 . At step  614 , the adapted gateway detects the use of a payment card and forwards data to the payment system  12 . At step  616  the payment system  12  receives this data, decodes the card number, finds the sequence number. At step  618 , the payment system uses the sequence number to get and verify the PIN. 
         [0101]    At step  620 , the payment system assembles the specific card data for one of the bankcards of the customer  20 , as identified by the PIN and sends that data to the adapted gateway  23 . The card data can include the name, card number, expiration date. The adapted gateway using that data and merchant identifier and the amount, forwards the information to the card network  21 . At step  622 , the card network  21  processes the transaction and returns an authorization number to the gateway  23 . At step  624 , the gateway  23  forwards the authorization number to the merchant system. At step  626 , the card reader displays that the transaction is approved. 
         [0102]      FIG. 6B  outlines the steps for using the payment system when the customer is at a location away from that of the merchant. With reference to  FIG. 6B , at step  630 , the customer is ready to make a payment. At step  632 , the customer has shopped at the web page of the merchant and/or viewed a catalog of the merchant and enters the 16-digit card number of the payment card on the merchant web page or conveys it on a voice telephone to the merchant. At step  634 , the customer enters 4-digit expiration date field as 4 digit PIN or conveys it on voice telephone to the employee of the merchant. At step  636 , the customer  20  enters the name and e-mail address on web page or conveys it on voice telephone to the employee of the merchant. At step  638 , the Merchant or web logic sends the payment card number, pin, amount and merchant identifier to the gateway. At step  640 , the adapted gateway  23  detects the use of a payment card  30  and forwards data to the payment system  12 . At step  642 , the payment system receives the data, the payment card number, and finds the sequence number. At step  644 , the payment system uses the sequence number to get and verify the PIN number. At step  646 , the payment system  12  assembles specific card data of name, card number, expiration date, and sends the information to the adapted gateway  23 , which assembles the complete payment transaction data including merchant identifier and payment amount and forwards the information to bankcard authorization network  21 . At step  648 , the adapted gateway  23  waits and receives the authorization number and at step  650 , forwards the authorization number to the merchant system  22 A. At step  652 , the web logic displays card approved. 
         [0103]      FIG. 6C  outlines alternate steps for using the payment system  12  when the customer is at the location of the merchant. In this embodiment, by using a wireless network the merchant interfaces directly with the payment system  12  and bypassing the gateway  23 . Hence, the gateway  23  need not be adapted to recognize a payment card number in this embodiment. Here, the payment system assembles a complete payment transaction data and forwards the information to the gateway  23  to be forwarded to network  21 . Alternatively the payment system may directly connect to the network  21 , bypassing the prior art gateway  23  entirely. 
         [0104]    Referring to  FIG. 6C , at step  660 , the customer is at the site of the merchant  22  and ready to conduct a transaction. At step  662 , the Merchant removes the wireless device  104  from the docking station  102  and enters the dollar amount of the transaction into the device  104  and hands the device  104  to the customer  20 . At step  664 , the customer reviews the dollar amount and swipes the payment card. At step  666 , the device  104  logic reads the card number. At step  668 , the logic prompts for a card PIN. At step  670 , the customer enters a PIN specific to a bankcard. At step  672 , the logic sends the payment card number, PIN, amount and merchant identifier to the payment system  12  via the cellular network. At step  674 , the payment system  12  receives the data, decodes the payment card number, and finds the sequence number. At step  676 , the payment system, with the sequence number, verifies the PIN and identifies the specific bankcard. At step  678 , the payment system assembles the specific card data of name, card number, expiration date, merchant identifier and amount and sends the data to payment network  21 . At step  680 , the payment system waits/receives the authorization number. At step  682 , the payment system saves the authorization number and forwards the data to the device  104 . At step  684 , the merchant  22 , using the docking station, transfers data from the device  104  to the merchant system  100 . 
         [0105]    One method used by the customer  20  to establish an account with the payment system  12  is illustrated in  FIG. 7 . At step  702 , the customer selects to connect to the payment system  12 . At step  704 , the payment system web page  500 A is displayed. At step  706 , the customer enters/creates the customer identifier and submits the customer identifier. At step  708 , the payment system checks for the existence of the customer identifier in the identifier database  38 A and sends validation by displaying data screen  536 . At step  710 , the customer selects “enter identifying data”. At step  712 , the payment system displays identifying data form  524 A. At step  714 , the customer enters identifying data and selects SEND. At step  716 , the payment system does optional address verification from the United States Postal Service database and then saves the identifying data in the identifying-database  38 B. At step  718 , the customer selects existing card data. At step  720  the payment system displays existing card data form  524 B. At step  722 , the customer enters existing card data and selects SEND. At step  724 , the payment system checks existing bankcard data and saves the existing bankcard data in database  38 C. The checking of existing bankcard data may include checking for correct format and optionally may also include checking for stolen and duplicate data by connecting to the bankcard authorization network  21 . At step  726 , the customer selects payment card data. At step  728 , the payment system displays payment card data form  524 C. At step  730 , the customer enters payment card PIN data  554 A for each of the existing cards and alias name  354 B and selects SEND. At step  732 , the payment system saves PIN data and alias name in database  38 D. At step  734 , the payment system notifies the customer that the card account has been established and a payment card will be mailed to the customer. This notification can be by e-mail, U.S. mail or a sign off message on the web page  500 A. At step  736 , the payment system creates a payment card  30  and mails it to the customer  20 . 
         [0106]    In summary, the payment system  12  allows the customer  20  to maintain one payment card  30  that can be used to facilitate the anonymous use of the other existing bankcards  31  of the customer. The payment system can store the private data  25  of the customer anonymously by separating the data elements in separate databases. The customer can conduct a transaction and receive a service or product from the merchant  22  without disclosing the name, address, private data and credit card information of the customer  20  to the merchant  22 . The payment system  12  minimizes the number of people, businesses and institutions that have access to the private information of the customer  20 . This minimizes the opportunity for the private information of the customer  20  to be improperly disseminated. 
         [0107]    While the particular apparatus  10  and method as illustrated herein and disclosed in detail is fully capable of obtaining the objects and providing the advantages herein before stated, it is to be understood that it is merely illustrative of the presently preferred embodiments of the invention and that no limitations are intended to the details of construction or design herein shown other than as described in the appended claims.