[19]
`United States Patent
`6,000,832
`[11] Patent Number:
`[45] Date of Patent: Dec. 14, 1999
`Franklin et al.
`
`
`
`US006000832A
`
`[54] ELECTRONIC ONLINE COMMERCE CARD
`WITH CUSTOMER GENERATED
`TRANSACTION PROXY NUMBER FOR
`ONLINE TRANSACTIONS
`
`[75]
`
`Inventors: D. Chase Franklin, Seattle; Daniel
`Rosen, Bellevue; Josh Benaloh; Daniel
`R. Simon, both of Redmond, all of
`Wash.
`
`[73] Assignee: Microsoft Corporation, Redmond,
`Wash.
`
`[21] Appl. No.: 08/935,485
`
`[22]
`
`Filed:
`
`Sep. 24, 1997
`
`Int. Cl.6 ...................................................... G06F 17/00
`[51]
`[52] US. Cl.
`...................... 364/479.02; 235/379; 235/380
`[58] Field of Search ..................................... 235/379, 380;
`364/479.02
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,831,862
`
`11/1998 Hetricue et a1.
`
`................... 364/479.02
`
`Primary Examiner—Harold I. Pitts
`Attorney, Agent, or Firm—Lee & Hayes, PLLC
`
`[57]
`
`ABSTRACT
`
`An online commerce system facilitates online commerce
`over a public network using an online commerce card. The
`“card” does not exist in physical form, but instead exists in
`digital form. It is assigned a customer account number that
`includes digits for a prefix number for bank-handling
`information, digits for a customer identification number,
`digits reserved for an embedded code number, and a digit for
`check sum. The bank also gives the customer a private key.
`During an online transaction,
`the customer computer
`retrieves the private key and customer account number from
`storage. The customer computer generates a code number as
`a function of the private key, customer-specific data (e.g,
`card-holder’s name, account number, etc.) and transaction-
`specific data (e.g., transaction amount, merchant ID, goods
`ID,
`time,
`transaction date, etc.). The customer computer
`embeds the code number in the reserved digits of the
`customer account number to create a transaction number
`
`specific to the transaction. The customer submits that trans-
`action number to the merchant as a proxy for a regular card
`number. When the merchant submits the number for
`
`the issuing institution recognizes it as a proxy
`approval,
`transaction number, indexes the customer account record,
`and looks up the associated private key and customer-
`specific data. The institution computes a test code number
`using the same function and input parameters as the cus-
`tomer computer. The issuing institution compares the test
`code number with the code number embedded in the trans-
`
`the issuing
`action number. If the two numbers match,
`institution accepts the transaction number as valid.
`
`53 Claims, 5 Drawing Sheets
`
`f 20
`
`in
`Customer
`
`
`
`
`
`
`
`
`Merchant
`
`
`
`
`
`24
`
`3O
`
`36
`
`
`
`Payment
`Network
`
`
`
`
` .v——
`
`/—26/\
`Issuing Bank
`
`1 of 15
`
`10f15
`
`APPLE 1032
`
`APPLE 1032
`
`

`

`US. Patent
`
`Dec. 14,1999
`
`Sheet 1 0f5
`
`6,000,832
`
`
`
`
`
`
`
`
`
`26
`
`Issuing Bank
`
`75¢. I
`
`2 of 15
`
`20f15
`
`

`

`US. Patent
`
`Dec. 14, 1999
`
`Sheet 2 0f 5
`
`6,000,832
`
`28:
`
`(——
`
`Customer Com uter
`
`fiZO
`
`kA
`
`
`H
`
`64
`
`Processor
`
`Volatile
`Memory
`
`Network |/O
`
`40
`
`44
`
`50
`
`46
`
`58
`
`1
`
`
`
`System
`
`Operating
`
`
`
`
`MAC
`
`Coding Unit
`
`
`
`
`
`Module@Q
`
`Browser
`
`R
`
`egistration
`
`42
`
`52
`
`54
`
`56
`
`—34
`
`i
`
`r32
`
`
`Bank Computing Center
`
`
`
`
`Manager
`
`Account
`
`62
`
`Customer
`
`Database
`
`
`
`
`
`
`
`REGISTRATION PHASE
`
`759. 2
`
`3 of 15
`
`30f15
`
`

`

`US. Patent
`
`Dec. 14,1999
`
`Sheet 3 0f5
`
`6,000,832
`
`28 :
`
`Customer Computer
`
`40
`
`
`
`54
`
`— 58
`
`
`
`{
`
`
`
` Volatile Memory
`
`Order Form
`
`Network l/O
`
`66
`
`46
`
`1
`
`34
`
`42
`
`Y 52
`
`Memory
`48
`
`
`System
`
`Button Ul
`
`
`
`
`
`MAC
`
`Coding Unit
`5O
`\_______J
`
`__j
`
`30
`
`
`
`Merchant
`
`
`Comguter
`
`
`2
`
`TRANSACTION PHASE
`
`4 of 15
`
`40f15
`
`

`

`US. Patent
`
`Dec. 14,1999
`
`Sheet 4 0f5
`
`6,000,832
`
`Private Key, Transaction—Specific Data, Customer—Specific Data
`k,
`
`J
`
`\— 68
`
`58
`
`
`
`
`MAC Coding Unit
`
`MAC
`
`XXXX XXXX XXXX XXXX
`
`\
`V
`A
`V
`A
`V W
`
`Prefix
`
`Customer ID
`
`MAC
`
`Sum Check
`
`/— 70
`
`75¢. 5
`
`/—72
`
`XXXX XXXX XXXX XXXX
`
`x
`v
`A
`V
`A
`Y W
`
`Prefix
`
`Customer ID
`
`MAC
`
`Sum Check
`
`79. 6
`
`5 of 15
`
`50f15
`
`

`

`US. Patent
`
`Dec. 14, 1999
`
`Sheet 5 0f 5
`
`6,000,832
`
`30
`
`Merchant Com uter
`
`201‘
`
`Payment Network
`
`
`
`Transaction
`
`Number
`
`Identifier
`
`1_
`
`
`Transaction
`Number
`
`Customer
`
`62
`
`82
`
`Account
`
`
`
`2
`Transaction
`Number
`
`Comparator
`
`
`
`
`
`Bank Comguting Center
`
`Database
`
`
`
`
` Manager
`
`MAC Coding
`Unit and
`
`
`84
`
`Number
`
`I Account
`CL Processing System
`
`
`
`
`
`AUTHORIZATION PHASE
`
`7a. 7
`
`6 of 15
`
`60f15
`
`

`

`6,000,832
`
`1
`ELECTRONIC ONLINE COMMERCE CARD
`WITH CUSTOMER GENERATED
`TRANSACTION PROXY NUMBER FOR
`ONLINE TRANSACTIONS
`
`TECHNICAL FIELD
`
`This invention relates to systems and methods for facili-
`tating online commerce over a public network (such as the
`Internet or an Interactive TV/Cable Network) using credit
`cards, debit cards, and other types of financial/banking
`cards. More particularly, this invention relates to systems
`and methods for conducting online transactions using an
`electronically realizable card that enables a customer to
`generate temporary transaction numbers on a transactional
`basis that are embedded in a “normal”-looking card account
`number.
`
`BACKGROUND OF THE INVENTION
`
`Online commerce is experiencing dramatic growth in
`recent years. More merchants are developing sites on the
`World Wide Web (or simply “W” or “Web”)
`that
`consumers can access and order goods and/or services. It is
`fairly common for a consumer to browse a merchant’s
`catalog, select a product, place an order for the product, and
`pay for the product all electronically over the Internet.
`Typically, the consumer pays for the goods and/or ser-
`vices ordered over the Internet with a credit card. During the
`online transaction, the merchant sends an order form and
`requests the consumer to enter personal data (e.g., name,
`address, and telephone number) and credit card information
`(e.g., account number and expiration date). The consumer
`returns the completed order form containing the credit card
`information to the merchant over the Internet. The merchant
`verifies that the credit card number is valid and can be
`
`charged the payment amount. The card verification is usu-
`ally conducted on a well-established card network, such as
`the VisaNet® network or the Veriphone® network.
`One problem with this traditional online commerce model
`concerns the security of the credit card data as it travels over
`the Internet. The credit card information can be intercepted
`in route, copied into a database, and used to make unautho-
`rized purchases. In an automated environment, an imposter
`can repeatedly use the stolen credit card data to conduct
`many online transactions before the consumer ever becomes
`aware that the credit card data has been stolen.
`
`Another concern is that dishonest merchants may re-use
`or re-distribute an individual’s credit card information.
`
`It would be desirable to develop a new online commerce
`model that reduces or eliminates the incentive for stealing
`credit card data. Ideally, a secure online commerce model
`would render the credit card data hard to steal, and if stolen,
`worthless to the thief.
`
`Afurther concern is that any new online commerce model
`should integrate well with existing proprietary card network
`systems. There are well-established systems that verify
`credit card purchases and subsequently settle accounts.
`These systems and associated protocols are entrenched in
`the merchant and banking communities and experience a
`high level of acceptance and trust. A new online commerce
`model should not usurp these systems, nor require mer-
`chants to change their existing practices to implement com-
`pletely different systems and protocols.
`The inventors have developed a card-based online com-
`merce system that improves security and integrates with
`existing card verification and settlement systems.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`SUMMARY OF THE INVENTION
`
`This invention concerns a system and method for facili-
`tating online commerce over a public network (such as the
`Internet or Interactive TV/Cable Network) using an online
`commerce card. The “card” of this system does not exist in
`physical form, but instead exists in a digital form that can be
`electronically realized for online commerce.
`The online commerce card is issued electronically to a
`customer by an issuing institution, such as a bank or third
`party certifying authority. The issued card is assigned a
`permanent customer account number that is maintained on
`behalf of the customer by the issuing institution. The N-digit
`customer account number includes digits for a prefix number
`for bank-handling information, digits for a customer iden-
`tification number, digits reserved for an embedded code
`number, and a digit for a check sum. The customer account
`number and a private key unique to the customer are issued
`to the customer. The issuing bank also supplies a software
`module used to create the embedded code number for each
`online commerce transaction.
`When the customer desires to conduct an online
`transaction, the customer invokes the software module and
`enters a “weak” password, PIN (personal
`identification
`number), or pass phrase to obtain access to the module. If the
`password is proper, the customer computer retrieves the
`private key and customer account number from storage. The
`customer computer then generates a code number as a
`function of the private key, customer-specific data (e.g.,
`card-holder’s name, account number, etc.) and transaction-
`specific data (e.g., transaction amount, merchant ID, goods
`ID,
`time,
`transaction date, etc.). The customer computer
`embeds the code number in the digits reserved in the
`customer account number to effectively create a temporary
`transaction number that is specific to one transaction. The
`customer submits that transaction number to the merchant as
`
`a proxy for the customer account number during the trans-
`action.
`The transaction number looks like a real card number. In
`the credit card case, the transaction number has the same
`format and 16 digits as a regular credit card number. To the
`merchant, the transaction number is treated the same as any
`regular credit card number. The merchant handles the proxy
`transaction number according to traditional protocols,
`including seeking authorization from the issuing institution
`to honor the card number.
`
`During the authorization phase, the merchant submits an
`authorization request containing the transaction number and
`the transaction-specific data to the issuing institution for
`approval. The issuing institution recognizes the number as a
`proxy transaction number for an online commerce card. The
`issuing institution uses the customer identification number
`contained within the transaction number to index the cus-
`
`tomer account record and lookup the associated private key
`and customer-specific data. The issuing institution then
`computes its own test code number using the same function
`utilized by the customer computer and the same input
`parameters (i.e., the private key, the customer-specific data
`from the account record, and the transaction-specific data
`received in the authorization request).
`The issuing institution compares the test code number
`with the code number embedded in the transaction number.
`
`If the two numbers match, the issuing institution accepts the
`transaction number as valid and authentic.
`
`The issuing institution substitutes an internal customer
`account number for the transaction number and processes
`the authorization request. In this manner, the issuing insti-
`
`7 of 15
`
`70f15
`
`

`

`6,000,832
`
`3
`tution can use its existing processing system to check
`account information, spending limits, and so forth. Once the
`authorization request is processed,
`the issuing institution
`once again exchanges the transaction number for the cus-
`tomer account number and sends an authorization reply back
`to the merchant under the transaction number.
`
`the merchant never needs to know if the
`As a result,
`number is a legitimate card account number, or a proxy
`number for a card account number. The merchant does not
`
`need to implement any new devices, software, or protocols
`to participate in the new online commerce system.
`The online commerce system substantially reduces the
`value of a stolen number since the transaction number that
`
`is held by the merchant and transmitted over the Internet (or
`other network) is only a proxy number for a single purchase.
`Stealing the proxy number would not greatly benefit a thief
`because it cannot be repeatedly used for other purchases or
`transactions. In addition, the system seamlessly integrates
`with existing card verification and settlement protocols.
`Software modules are implemented at
`the customer and
`issuing institution, but no additional components are imple-
`mented at the merchant, settlement participants, or any other
`member in the online commerce transaction.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`the
`
`The same reference numbers are used throughout
`figures to reference like components and features.
`FIG. 1 is a diagrammatic illustration of an online com-
`merce system.
`FIG. 2 is a block diagram of a customer computing unit
`and bank computing center. FIG. 2 shows an information
`exchange between the customer computing unit and the
`bank computing center during an online commerce card
`registration phase.
`FIG. 3 is a block diagram of the customer computing unit
`and a merchant computing unit. FIG. 3 shows an informa-
`tion exchange between the customer computing unit and
`merchant computing unit during a transaction request phase.
`FIG. 4 is a functional block diagram of a unit for creating
`a code value based on a customer-related secret and
`
`transaction-specific data.
`FIG. 5 is a diagrammatic illustration of a 16-digit cus-
`tomer account number according to one implementation.
`FIG. 6 is a diagrammatic illustration of a 16-digit cus-
`tomer account number according to another implementation.
`FIG. 7 is a block diagram of the bank computing center
`and the merchant computing unit. FIG. 7 shows an infor-
`mation exchange between the merchant computing unit and
`the bank computing center during a payment authorization
`phase.
`
`DETAILED DESCRIPTION
`
`the reader is
`The following discussion assumes that
`familiar with cryptography. For a basic introduction of
`cryptography,
`the reader is directed to a text written by
`Bruce Schneier and entitled “Applied Cryptography:
`Protocols, Algorithms, and Source Code in C,” published by
`John Wiley & Sons with copyright 1994 (with a second
`edition in 1996), which is hereby incorporated by reference.
`FIG. 1 shows an online commerce system 20 for con-
`ducting online commerce transactions. For general discus-
`sion purposes,
`three participants to an online commerce
`transaction are shown: a customer 22, a merchant 24, and an
`issuing bank 26. These three participants play the primary
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`roles in the online commerce transaction. The customer and
`merchant may represent individual people, entities, or busi-
`nesses. Although labeled as a “bank”, the issuing bank 26
`may represent other types of card-issuing institutions, such
`as credit card companies, card sponsoring companies, or
`third party issuers under contract with financial institutions.
`It is further noted that other participants may be involved in
`some phases of the transaction, such as an intermediary
`settlement institution, but these participants are not shown.
`Each participant is equipped with a computing system to
`facilitate online commerce transactions. The customer 22
`has a computing unit 28 in the form of a personal computer,
`although other types of computing units may be used
`including laptops, notebooks, handheld computers, set-top
`boxes, and the like. The merchant 24 has a computing unit
`30 implemented in the form of a computer server, although
`other implementations are possible. The bank 26 has a
`computing center 32 shown as a mainframe computer.
`However, the bank computing center 32 may be imple-
`mented in other forms, such as a minicomputer, a PC server,
`a networked set of computers, and the like.
`The computing units 28, 30, and 32 are connected with
`each other via a data communication network 34. The
`
`network 34 is a public network and assumed to be insecure
`and open to eavesdroppers.
`In the illustrated
`implementation, the network is embodied as the Internet. In
`this context, the computers may or may not be connected to
`the Internet 34 at all
`times. For instance,
`the customer
`computer 28 may employ a modem to occasionally connect
`to the Internet 34, whereas the bank computing center 32
`might maintain a permanent connection to the Internet 34. It
`is noted that the network 34 may be implemented as other
`types of networks, such as an interactive television (ITV)
`network.
`
`The merchant computer 30 and the bank computer 32 may
`be interconnected via a second network, referred to as a
`“payment networ ” 36. The payment network 36 represents
`existing proprietary networks that presently accommodate
`transactions for credit cards, debit cards, and other types of
`financial/banking transactions. The payment network 36 is
`closed network that is assumed to be secure from eaves-
`
`droppers. Examples of the payment network 36 include the
`VisaNet® network and the Veriphone® network.
`The electronic commerce system 20 is implemented at the
`customer 22 and issuing bank 26.
`In the preferred
`implementation,
`the electronic commerce system 20 is
`implemented as computer software modules loaded onto the
`customer computer 28 and the bank computing center 32.
`The merchant computer 30 does not require any additional
`software to participate in the online commerce transaction
`supported by the online commerce system 20.
`General Operation
`There are three distinct phases supported by the online
`commerce system 20: a registration phase, a transaction
`phase, and a payment-authorization phase. During the reg-
`istration phase, the customer 22 requests an online com-
`merce card from the issuing bank 26. The issuing bank 26
`creates an online commerce card for the customer and
`
`assigns a customer account number to the card. Additionally,
`a customer-related secret, such as a private encryption key
`unique to the customer, is associated with the online com-
`merce card. This customer-related secret can be generated
`by the issuing bank or selected by the customer. The
`customer account number and private key are retained in a
`customer account data record at the issuing bank 26.
`The “online commerce card” does not necessarily exist in
`physical form, but in digital form for use in online transac-
`
`8 of 15
`
`80f15
`
`

`

`6,000,832
`
`5
`tions. The N—digit customer account number assigned to the
`online commerce card includes digits for a prefix number for
`bank-handling information, digits for a customer identifica-
`tion number, digits for an embedded code number, and a
`digit for a check sum. The number of digits for each portion
`of the number vary depending upon the card format and
`control parameters. The commerce card can be configured,
`for example, to resemble a credit card, a debit card, a bank
`card, or other type of financial services card. Specific digit
`formats compatible with a standard 16-digit credit card
`number are discussed below with reference to FIGS. 5 and
`6.
`
`The customer account number and customer-related
`
`in a
`the customer computer
`secret are also stored at
`password-secured storage location. The issuing bank sup-
`plies a software module used to create an embedded code
`number for each online commerce transaction on the Inter-
`
`net 34. It is noted, however, that the software module may
`alternatively be packaged as part of can operating system or
`other product. In this alternative case, the customer may
`only need an account number and a private key from the
`issuing bank. The registration phase is described below in
`more detail with reference to FIG. 2.
`
`During the transaction phase, the customer 22 invokes the
`software module and enters a weak password to gain access
`to the secure storage location. If the password is correct, the
`customer computer retrieves the private key and customer
`account number from storage. The customer computer gen-
`erates a code number as a function of the private key,
`customer-specific data (e.g., card-holder’s name, account
`number, etc.) and transaction-specific data (e.g., transaction
`amount, merchant ID, goods ID, time, transaction date, etc.).
`Preferably,
`the customer computer uses a cryptographic
`hashing function to create a unique, multi-digit MAC
`(message authentication code) from the various input param-
`eters. The customer computer embeds the code number (or
`MAC) in the reserved digits of the customer account number
`to create a temporary transaction number that is specific to
`a single transaction. It may also be necessary to produce a
`“check sum” consistent with a proper credit card number.
`The customer submits the transaction number, with
`embedded MAC, to the merchant as a proxy for the cus-
`tomer account number during the transaction. The transac-
`tion number resembles a real account number. In the case of
`
`a credit card, for example, the transaction number resembles
`a 16-digit, mod 10, credit card number identically formatted
`with four spaced sets of 4-digits. To the customer, merchant,
`and every other participant in the transaction, the transaction
`number appears to be a valid credit card number. Only the
`issuing bank 26 needs to differentiate the transaction num-
`bers from other real customer account numbers. The cus-
`
`tomer 22 uses the proxy transaction number in the transac-
`tion with the merchant 24. Since the transaction number is
`
`issued in place of the customer number for only a single
`transaction and with a limited life, a thief that intercepts the
`transaction number is prevented from using it for illicit gain.
`The transaction phase is described below in more detail with
`reference to FIGS. 3—6.
`
`During the payment authorization phase, the merchant 24
`submits an authorization over the conventional payment
`network 36 to the issuing bank 26 for approval. The autho-
`rization request contains the transaction number and the
`transaction-specific data. The issuing bank 26 identifies the
`number as a transaction number, as opposed to a real
`customer account number. The issuing bank 26 locates the
`customer’s data record using the prefix and customer iden-
`tification portions of the transaction number. The issuing
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`
`bank 26 retrieves the customer-related secret (i.e., the cus-
`tomer’s private key) and customer-specific data from the
`account data record. The issuing bank 26 then computes a
`test code number (i.e., a test MAC) as a function of the
`private key, the customer-specific data, and the transaction-
`specific data. The issuing bank uses the same cryptographic
`hashing function as the customer computers. If the test MAC
`matches the MAC contained in the transaction number
`
`received with the authorization request, the issuing bank
`accepts the authorization request, swaps the customer
`account number for the transaction number, and processes
`the request using the customer account number.
`After the processing, the issuing bank 26 substitutes the
`transaction number back for the customer account number
`
`and returns the authorization reply to the merchant 24 under
`the transaction number. In this manner, only the issuing bank
`is aware that the transaction number is a proxy for the
`customer account number. The merchant 24 need not be
`aware that the transaction number is not a true customer
`
`account number, but simply handles the number its it would
`any other card number. The authorization phase is described
`below in more detail with reference to FIG. 7.
`
`Registration Phase
`FIG. 2 shows the online commerce system 20 during a
`registration phase. This phase involves the customer 22
`requesting an online commerce card from the issuing bank
`26, and the issuing bank creating and issuing the online
`commerce card to the customer. The information exchange
`between the customer computer 28 and the bank computer
`32 during the registration phase are illustrated as enumerated
`lines between the two entities.
`
`The customer computer 28 has a central processing unit
`comprising a processor 40, a volatile memory 44 (e.g.,
`RAM), and a non-volatile memory 42 (e.g., ROM, hard disk
`drive, floppy disk drive, CD-ROM, etc.). The customer
`computer 28 also has a network I/O 46 (input/output) for
`accessing the Internet 34. The network I/O 46 can be
`implemented, for example, as a dial-up modem or as a
`permanent network connection.
`The customer computer 28 runs an operating system 48
`that supports multiple applications. The operating system 48
`is preferably a multitasking operating system that allows
`simultaneous execution of multiple applications in a graphi-
`cal windowing environment. One preferred operating sys-
`tem is a Windows® brand operating system sold by
`Microsoft Corporation, such as Windows® 95, Windows®
`NT, Windows® CE, or other derivative versions of Win-
`dows®. It is noted, however, that other operating systems
`that provide windowing environments may be employed,
`such as the Macintosh operating system from Apple
`Computer, Inc.
`The operating system 48 includes a private key store 50
`to securely hold one or more private keys used for
`encryption, decryption, digital signing, and other crypto-
`graphic functions. The private key store 50 is a password-
`protected storage location that grants access upon entry of an
`appropriate password. The customer selects the password as
`part of the registration process.
`Several software components are stored in memory 42
`including a browser 52, a button user interface (UI) 54, a
`registration module 56, and a MAC coding unit 58. These
`software components load into volatile memory when
`launched and execute on the processor 40 atop the operating
`system 48. The browser software 52 originally exists on the
`customer computer 28, whereas the button UI 54, registra-
`tion module 56, and MAC coding unit 58 may be supplied
`
`9 of 15
`
`90f15
`
`

`

`6,000,832
`
`7
`to the customer computer 28 during the registration process.
`It is further noted that the button UI 54 may be integrated
`into, or reliant on, the graphical user interfaces supported by
`the operating system 48, but is shown separately for expla-
`nation purposes.
`The bank computer 32 has an account manager 60 and a
`customer database 62. The account manager 60 is preferably
`implemented in software that executes on the bank computer
`32, such as a relational database program that manages the
`database 62.
`
`The registration phase between the customer and issuing
`bank will now be described with respect to FIG. 2. During
`normal operation on the Web, the customer comes across a
`banner advertising an online commerce card sponsored by
`the issuing bank. The banner may be part of the bank’s Web
`site, or part of a statement to its customers, or included as
`advertisement in other Web content. The customer activates
`
`the banner by clicking the banner icon with a mouse pointer.
`This action submits a request for an online commerce card
`application. In response, the customer downloads the regis-
`tration module 56 from the Web to the customer computer
`28. This initial registration step is illustrated by flow arrow
`1 from the Internet 34 to the customer computer 28. It is also
`noted that the registration may be initiated by other means
`such as mail, broadcast, telephone, and so forth.
`The registration module 56 automatically launches to aid
`the customer in the completion of the online application. The
`registration module is preferably configured to provide
`step-by-step instructions, such as a Help Wizard. The cus-
`tomer fills out various fields related to personal and financial
`matters and enters customer-specific data, such as name,
`address, telephone number, social security number, pres-
`ently owned credit cards, bank affiliations, and the like.
`The customer also supplies a password during registra-
`tion. The customer-selected password will be used to unlock
`the private key store 50 to gain access to the private key or
`customer-related secret.
`
`The customer completes the online commerce card appli-
`cation using the registration wizard and submits the appli-
`cation to the issuing bank (flow arrow 2 in FIG. 2). The
`registration module 56 facilitates this communication and
`any future interaction between the consumer and the issuing
`bank. The application itself, or the registration module 56,
`contains the necessary routing information to direct
`the
`application over the Internet 34 to the bank computing
`center 32. The issuing bank reviews the application to
`determine whether the customer is credit worthy and pend-
`ing the analysis, whether to grant or deny a commerce card.
`If a new card is denied, the issuing bank returns a message
`to the customer indicating that the card application has been
`denied and no card will be issued. Conversely, if a new card
`is to be granted, the issuing bank returns a message indi-
`cating that a card will be granted assuming the remaining
`registration steps are satisfied.
`Assuming that a card account is granted, the issuing bank
`creates a customer account record in the customer database
`
`62 and assigns a customer account number to the data
`record. The customer account number uniquely associates
`all relevant database records to a specific customer. Ideally,
`the customer account number is some number that is com-
`
`patible with the bank’s existing processing system. In this
`manner, the bank can utilize its existing processing system
`that might rely on conventional account or card numbers.
`For example, suppose the bank is issuing a credit card-like
`online commerce card having a 16-digit number. The
`account number assigned to the customer account might
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`comprise the 16-digit number. The first five-to-seven digits
`are a bank related prefix, the next four digits are a customer
`identification number, the next four-to-six digits are reserved
`for a MAC number, and the last digit is a check sum value.
`During the registration phase, the four-to-six digits for the
`MAC number have no meaning (as they only have meaning
`in the context of a transaction), and hence, these digits are
`only placeholders in the customer account number. Thus, for
`the credit card example, one possible customer account
`number might be as follows:
`1234 56789 1230 0004
`
`The “0” digits represent placeholders where a uniquely
`generated MAC will eventually be embedded for each
`online transaction.
`
`The customer account number may exist in other forms.
`For instance, if the customer already possesses a real credit
`card or debit card from the bank, the number from the credit
`card or debit card might be the customer account number. In
`this manner, the customer can use the digital online com-
`merce card concurrently with the physical credit or debit
`card. As another implementation, the public key, private key,
`or a mathematical derivation of one or both keys (e.g., a hash
`value of one or both keys) might be employed to represent
`the customer account number. Another alternative is for the
`
`bank to generate an internal number that is used for solely
`for record keeping purposes.
`The issuing bank adds the customer-specific data to the
`account record and associates the customer-related secret to
`
`the data account record. The issuing bank supplies the
`customer’s password and a MAC coding unit 58 to the
`customer. The MAC coding unit 58 is a software module that
`generates the embedded code numbers in transaction card
`numbers. The issuing bank also supplies the button UI 54,
`which can be added to the browser’s toolbar (and/or toolbars
`of other applications). The button UI 54 enables the cus-
`tomer to invoke a wizard when conducting an online com-
`merce transaction. The issuing bank may digitally sign the
`public/private key pair so that the customer can verify that
`the signed key pair originated from the bank. One technique
`for forming this digital signature is to hash the one or both
`keys and encrypt the resulting hash value using the bank’s
`private signing key.
`In the preferred implementation, the bank supplies the
`private key, MAC coding unit 58, and button UI 54 using
`some means other than online transmission. FIG. 2 shows a
`
`floppy disk 64, which stores the private key and software,
`being mailed to the customer using conventional postal
`carriers (flow arrow 3 in FIG. 2). Using regular mail
`provides an added level of security in that the bank can
`verify through the mailing address that a customer having
`the registered name and address truly lives at the place
`inscribed on the online registration form. This increases the
`bank’s confidence that the customer did not submit a fraudu-
`
`is that the software on
`lent application. Another benefit
`floppy disk 64 contains cryptograph