Source: http://www.google.com/patents/US20040199469?dq=7557380
Timestamp: 2014-03-14 22:58:18
Document Index: 210623393

Matched Legal Cases: ['art 17', 'art 27', 'art 33', 'art 42', 'art 52', 'art 58']

Patent US20040199469 - Biometric transaction system and method - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA method and system for authentication of online commercial transactions between a customer and a merchant using a computer system is provided. According to a preferred embodiment, the method comprises the steps of registering a customer, wherein the customer is given a money tag device by a communication...http://www.google.com/patents/US20040199469?utm_source=gb-gplus-sharePatent US20040199469 - Biometric transaction system and methodAdvanced Patent SearchPublication numberUS20040199469 A1Publication typeApplicationApplication numberUS 10/393,884Publication dateOct 7, 2004Filing dateMar 21, 2003Priority dateMar 21, 2003Publication number10393884, 393884, US 2004/0199469 A1, US 2004/199469 A1, US 20040199469 A1, US 20040199469A1, US 2004199469 A1, US 2004199469A1, US-A1-20040199469, US-A1-2004199469, US2004/0199469A1, US2004/199469A1, US20040199469 A1, US20040199469A1, US2004199469 A1, US2004199469A1InventorsKatrina Barillova, Robert MichalkoOriginal AssigneeBarillova Katrina A., Robert MichalkoExport CitationBiBTeX, EndNote, RefManReferenced by (20), Classifications (16), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetBiometric transaction system and methodUS 20040199469 A1Abstract A method and system for authentication of online commercial transactions between a customer and a merchant using a computer system is provided. According to a preferred embodiment, the method comprises the steps of registering a customer, wherein the customer is given a money tag device by a communication information center (CIC) and the customer registers with the CIC a PIN, at least one registration biometric sample, and at least one customer financial account. The method may also includes a merchant registration step, wherein the merchant registers with the CIC at least one merchant financial account. In a customer identification step, the customer sends personal authentication information comprising a PIN, at least one biometric sample that is obtained from the customer's person, and money tag ID to the CIC. Images(12) Claims(53)
BRIEF DESCRIPTION OF THE APPENDICES [0057] The following appendices are incorporated herein by this reference thereto. [0058] Appendix 1 is a document entitled �Preferred System Architecture� which describes an architecture for the system of the present invention, in accordance with one embodiment. DESCRIPTION OF THE PREFERRED EMBODIMENTS [0059] The detailed description set forth below is intended as a description of presently-preferred embodiments of the invention and is not intended to represent the only forms in which the present invention may be constructed and/or utilized. The description sets forth the functions and the sequence of steps for constructing and operating the invention in connection with the illustrated embodiments. However, it is to be understood that the same or equivalent functions and sequences may be accomplished by different embodiments that are also intended to be encompassed within the spirit and scope of the invention. [0060] The objective of this invention is to provide a secure, reliable, safe, and consistent, method for identifying customers for the purpose of authorizing financial transactions. The system is inherently secure, such that customers' records and biometric information remain confidential and safe, both within the computer system that authenticates the customer, as well as during collection and transfer of authentication information between the computer system and the remote sites with which the computer system communicates. [0061] Turning now to the figures, the overall configuration of the invention and its components are shown in FIG. 1, in accordance with a preferred embodiment. Essentially a central unit or Communication Information Center (CIC) 1 is connected to the customer computer(s) 2 and to the merchant server(s) 3 through the Internet 4. The CIC is also connected to and communicates with independent computer networks 5, such as credit/debit networks. The CIC 1 contains several databases and software execution modules as shown in FIG. 2. A Firewall Computer 7 is responsible for prevention of electronic intrusion of the system while a Gateway Computer 8 is responsible for routing all requests from the user, including adding, deleting and otherwise modifying all databases. The Gateway Computer 8 is also responsible for decryption and de-packaging of data that has arrived from the customer and other computers. As shown in FIG. 3, the customer's computer 2 interfaces with the money tag 6, which has a biometric scanner 9 and a display 10. The biometric scanner 9 comprises at least one biometric input element such as a fingerprint scanner or voice input device (microphone). The money tag is further equipped with computing modules, device drivers, and erasable and non-erasable memory modules. The money tag communicates with the customer's computer through an IrDA or serial port. The customer's computer 2 communicates with the CIC 1 and with the merchant's server 3 through the Internet 4. The merchant's server 3 also communicates with the customer's computer 2 and with the CIC 1 through the Internet 4. FIG. 4 shows the steps taken to process a commercial transaction, according to a preferred embodiment, from registration through presentation of results. [0062] The components and the method of the invention are described in detail as follows. [0063] 1. Money tag [0064] The money tag 6 is a combination of hardware and software whose job is to scan and encrypt customer biometric data for use in commercial transaction, to receive a PIN from the customer's computer, to send encrypted authentication information (i.e. PIN, biometric data and money tag ID) through the customer's computer to the CIC 1, to receive an encrypted private code from the CIC 1, and to provide the private code in encrypted form to a computer. It should be noted that a password or alphanumeric combination may also be used instead of a PIN. [0065] The public key cryptography is preferably used for encryption of the authentication information and private code during transfer from the CIC 1 to the money tag 6 and also from the money tag 6 to the CIC 1. The money tag 6 is a physically separate device from the customer's computer. The computer communicates with the money tag 6 by sending commands and receiving results over the serial port or standard infrared IrDA port. [0066] Preferably, the money tag's external interface is strictly limited and the construction of the money tag 6 makes it extremely difficult to tamper with the contents. Each money tag 6 has its unique encryption key pair, known only to the money tag 6 and the CIC 1, and a hardware identification code previously registered with the CIC 1. The money tag 6 is only allowed to perform operations limited to its designated function. [0067] The money tag 6 is constructed with the assumption that the controlling computer can be a source for fraud, so that the money tag 6 never reveals unencrypted biometric data and the unencrypted private code to the controlling computer. The money tag 6 shows only information messages to the customer on its display 10. [0068] The money tag 6 is a multichip module combined with a fingerprint scanner, a speaker/microphone, or other biometric inpute element, a display, a serial port and/or an IrDA port encased in a hard tamper-resistant case that makes attempts to penetrate obvious. The critical components such as processors, memories, fingerprint scanner and A/D converter are amalgamated into a multichip module (a process for encapsulating several processors in one physical shell, well known in the industry), constructed to protect the communications pathways between the devices from easy wiretapping. [0069] The money tag's memory is preferably divided into groups so that it is hard to reverse engineer critical data. Only the noncritical commonly available code such as embedded operating system, device drivers and encryption library is stored in mask ROM. The mask ROM is cheaper than other types of read only memory, but it is easily reverse engineered, and is not electronically erasable. [0070] The more critical information and software packages such as biometric encoding algorithm, random number generator, command functions, the unique encryption key pair and the hardware identification code are stored in flash ROM. Flash ROM is more expensive, but it is much more difficult to reverse engineer, and most importantly, it is electronically erasable. [0071] The use of Flash ROM makes it more difficult to duplicate a customer's money tag. Only noncritical data such as setup constants are stored in the EEPROM. EEPROM can be erased many times, but is also nonvolatile�its contents remain valid across power interruptions. The most critical data such as PIN, private code and biometric data are stored in RAM. RAM is temporary in nature, and its contents are lost whenever power is lost. [0072] The critical software and data may only be downloaded once into the device, at the time of manufacture. All registers and variables are explicitly cleared when a transaction is canceled or completed. The software does not keep copies of registers in stack variables. [0073] The money tag's enclosure is designed so that upon detecting any opening of the enclosure, the money tag 6 performs an emergency electronic zero of all data residing in flash ROM, EEPROM and RAM followed by all of the software libraries. [0074] 2. Customer's Computer [0075] The purpose of this computer is to provide the customer with the ability to purchase products from a remote merchant's web server, to control the money tag 6 and to provide the customer with the ability to authenticate through the CIC 1 via the Internet 4. [0076] The customer's computer may be a standard personal computer with an available Internet connection, HTTP and HTTPS network ports, and a serial or infrared port. The computer should be capable of running ordinary web browser software with ActiveX controls and/or Java enablement. [0077] 3. The Communication Information Center (CIC) [0078] The CIC handles financial commercial transactions and customer registration as its main responsibilities. [0079] The CIC 1 may be made up of a number of computers and databases 11 connected together over a Local Area Network (LAN) as illustrated in FIG. 2. The CIC 1 preferably has electrical power backup and multiple redundancy in all of its critical hardware and database systems. [0080] The entry point of the CIC 1 is preferably a Firewall computer 7. It provides a first line of defense against network viruses and computer hackers. All communication links into or out of the CIC 1 first pass through this computer. The firewall also disallows any undesirable transmissions from the internal network to the rest of the Internet. [0081] The CIC system coordinator and request processor is a gateway computer 8. It links the outside world (money tag equipped customer computers and other computers) to the internal components of the CIC 1, supervises the processing of each received request, communicates with the various CIC components as necessary, and sends the encrypted reply back to the sender. All received requests and any warnings from the CIC components are logged. [0082] The CIC 1 may comprise several databases, each fulfilling a specific purpose. These include: a Registration database 12 which has a list of valid customers with each customer's biometric data, PIN code, money tag ID, and financial account(s); a Merchant Database 13 which has information about merchants necessary to process transactions, such as the merchant financial account information; an Issuer Database 14 which identifies issuing banks that participate with the system; a Defrauders Database 15 which has a list of known system defrauders; and a Transaction Database 16 which records all transactions. [0083] The customer's and merchant's computers accomplish their tasks by sending requests to the CIC site. The CIC site sends back a reply containing the status on the success or failure of the operation. [0084] If a customer is found to have defrauded the system, the CIC 1 may institute a biometric database search for the customer. These searches are preferably performed each night during conditions of light activity. Such search may reveal potential inconsistencies, such as significantly different credit card use patterns by a specific customer, which may indicate credit card fraud. [0085] 4. Preferred Method Steps [0086] In a registration step, personal information from new customers is obtained which may include the customer's biometric data, PIN or other information known to the user, mailing address and at least one financial account. [0087] The registration institution may use its standard customer identification procedure (signature cards, employee records, personal information, etc.) before registering the customer on the system. It is important for the institution to thoroughly verify customer identity, since the registered customer will be empowered to make purchases and transfer money from those financial accounts at will. [0088] During registration, the customer selects a PIN and enters at least one registration biometric sample, such as index finger prints or next innermost finger prints if the customer is missing index fingers, or a voice sample such as a password phrase spoken into a recording machine. Requiring specific fingers to be used (such as the index finger) allows the prior fraud check to work. The registration biometric samples are then stored into the CIC database. [0089] If a financial account number is registered without the participation of the issuing institution, the financial account owner may be required to sign an agreement at the time of registration authorizing the release of funds whenever a properly authorized transaction is received by the system. Confirmation of identity should preferably be required to validate the signature, either through a telephone contact or an in-person examination of the registrant's identity documents. [0090] The ability to authenticate transactions will only be enabled once the registration is confirmed. The customer is also issued a money tag device upon registration. [0091] In an authentication step, the customer must be authenticated by the CIC 1 in order to obtain the temporary private code for the transaction. The customer's computer connects to the CIC web server using the Internet, and downloads and installs software such as Java or ActiveX control that enables communication with the money tag 6 from web browser. This operation is required to be performed only once, upon the customer's first connection with the CIC. Once a connection is established and Java or ActiveX control is present on the customer's computer, the unsecured HTTP connection is changed to a secure HTTPS using SSL protocol, wherein the customer's computer secures the Internet connection by generating and then sending a Session Key to the CIC 1. In order to assure that the session key is protected from disclosure, it is encrypted with the CIC's Public Key using Public Key Encryption. When the CIC 1 receives this encrypted Session Key, it decrypts it using its Private Key. Then both computers announce that future communication will be encrypted with the Session Key and that the Session Key is no longer being transferred. This process is called securing a connection through a Public Key Encrypted secret key exchange. Once securely connected the identification web page is displayed on the customer's computer, where the customer is asked to enter the PIN through the computer keyboard and the money tag 6 is instructed to scan customer's biometric data. [0092] The PIN is sent from the computer to the money tag 6. Once the money tag 6 obtains the PIN and biometric data, it sends authentication information (i.e. PIN, biometric data and money tag ID) in encrypted form to the customer's computer. Upon receiving encrypted authentication information, the computer forwards it as a request to the CIC web server. The CIC 1 decrypts the authentication information and looks up the registration database for producing either a successful or failed identification of the customer. In the case of successful identification a temporary random private code is generated by the CIC 1 and sent in encrypted form as a reply to the customer's computer. The customer's computer then forwards the encrypted private code to the money tag 6. The money tag 6 decrypts the private code and stores it into RAM. [0093] In a proposal step, the customer connects to the merchant's web server using the Internet and the merchant's offer, typically comprising price information, is displayed to the customer. [0094] If the customer accepts the merchant's proposal, in an acceptance step, the unsecured HTTP connection is changed to secure HTTPS using SSL protocol in the above described way (this time the Session key is sent to merchant's server not the CIC) and the customer's computer sends to the money tag 6 the merchant's identification code, and transaction information which may comprise product information and price. Other items of transaction information may be included, such as a list of goods and/or services, a merchant name, a date and time, a location, or an invoice number. [0095] The money tag 6 then adds to the received commercial transaction data the private code generated previously by the CIC 1, encrypts the transaction data including the private code, and sends such encrypted transaction information to the customer's computer. Upon receiving the encrypted transaction information, the computer forwards it as a request to the merchant's web server. [0096] The merchant's server is connected to the CIC via the same sort of secure connection that the customer's computer has with the CIC. Upon receiving encrypted transaction information from customer's computer, the merchant's server, in a transmission step, forwards the transaction information to the CIC 1 for validation. The merchant's server secures the connection to the CIC using the session key. [0097] In a payment step the CIC 1 decrypts the transaction information, validates the private code, cross-checks the merchant identification code contained in the request with the merchant identification code stored under the hostname that was sent in the request, then constructs a transaction draft given the customer and merchant financial accounts and the associated transaction information, and forwards the transaction to a credit/debit network where the authorization and money transfer occurs. [0098] Once the credit/debit network responds, in a presentation step, the CIC 1 constructs a response message including the credit/debit authorization and address of the customer, and sends that message back to the merchant's server. Once the merchant's server receives the response, it copies the customer's address out of the response and forwards the response message to the customer's computer. The customer's computer browser shows the result of the transaction, be it success or failure. [0099] Since the system in general assumes that an adversary inhabiting the network can hijack network connections at any point, all parties must have secure communications during their real-time interactions. The main concern is not disclosure of information, but rather insertion or redirection of messages. [0100] The whole system of Public Key Encryption relies on having a trusted source for the Public Keys. These trusted sources are called Certifying Authorities (CA), one of which is the company VeriSign, Inc. [0101] Use Cases [0102] The following provides practical examples of how the system of the present invention may be implemented. Also, these examples could be a guide for the designed solution completeness check. [0103] 1. Registration Processes for Bank Clients [0104] Registration processes for external users of the system of the present invention (e.g. bank clients) are described below. Possible registration scenarios include the following: [0105] a) Client's personal visit to a branch office: [0106] to i. a distant registration process for external clients with software certificates [0107] ii. a face-to-face registration process for external clients with software certificates [0108] iii. a face-to-face registration process for external clients with Biometric Credit Card certificates [0109] iv. a distant registration process for external clients with Biometric Credit Card certificates [0110] b) Client's personal visit to an unattached business place: [0111] i. personal registration process for external clients with software certificates [0112] ii. distant registration for external clients with software certificates [0113] iii. personal registration process for external clients with certificates [0114] iv. distant registration process for external clients with certificates [0115] The final step of each registration process will be a validation process initiated by a client. The purpose of the validation process is for verification of an issued certificate. The validation process begins after receipt of the installed certificate. The validation process (described below) may be the same for different types of registration processes. [0116] 1.1 Distant Registration Process for External Clients with Software Certificates [0117] This process fills in a demand for a certificate and generates keys in the client's PC. Thereafter, a form is transferred to the biometric credit card via Internet. [0118] The Bank's registration operator may approve the demand for a certificate upon the client's personal visit to the bank wherein the operator verifies the client's identity. The client may also be required to sign an agreement regarding the banks certificate granting policies. [0119] A special application (or part of an application) will provide the distant registration process for both the client and the biometric credit card. [0120] The Application generates a data message containing a demand for a certificate in PKCS#10 format. The demand for a certificate will be transferred by an application to the Registration FrontEnd (RFE) Server that will transfer the data to the Registration BackEnd (RBE) Server where the data from the demand will be preprocessed and sent to the Advanced Registration Module (ARM) database. ARM will provide further processing of data and will resend data for further processing to the Registration Authority (RA). [0121]FIG. 4 is a flow chart 17 illustrating the registration process of external clients with software certificates, according to one embodiment. The steps for this process, numbered (1) through (19) in the figure, are as follows: [0122] (1) The Bank's client 18 activates Java application for a distant registration process at home. The client may download the application from a bank's freely accessible web page (RFE Server 19). [0123] (2) The client fills in an electronic registration form (including revocation password and password for accessing keys' storage) and generates keys. Keys are saved on a floppy disk or hard disc. Applet generates a �fingerprint� that will be used in a process of personal verification of the client's identity at a registration place, and writes it on the screen so the client can copy it. Thereafter the �fingerprint� may be printed and saved to a file, say �demands.txt,� which may include other client data. When identifying the client (during client's personal visit of the bank), the client will have to produce the demands.txt file in printed or in electronic form, or fingerprints copied from the screen. (The last alternative is least preferred due to possible error in copying). [0124] (3) The application completes the demand for the certificate and transfers it to the RFE server 19. [0125] (4) The RFE server 19 resends the demand for the certificate to RBE Server 20. [0126] (5) The RBE formats the demand for the certificate to an appropriate format for ARM and saves the data to the ARM database 21. [0127] (6) The ARM takes over the data from the ARM database 21 wherein the data is processed. [0128] (7) The ARM will resend the output from the processed data to the RA (or to RA database 23). [0129] (8) The client personally visits the branch office 24. [0130] (9) A registration operator obtains the demand for the software certificate from the RA database 23. [0131] (10) The registration operator verifies the client's identity and fingerprint generated with the client and compares them with the data saved in the demand. The client signs an agreement concerning granting certificates. [0132] (11) The registration operation submits the processing of the demand for certificate to the RA. [0133] (12) The RA automatically signs the demand. [0134] (13) The RA sends the signed demand to the certificate authority (CA) 25. [0135] (14) The CA 25 issues a new certificate signed by a private CA key. [0136] (15) The CA 25 publishes the newly issued certificate in an LDAP directory 26. [0137] (16) The CA 25 sends the newly issued certificate to the RA 23. [0138] (17) The registration operator picks up the newly issued certificate. [0139] (18) The registration operator exports the certificate to a floppy disk and hands it over to the client. The certificate may also be distributed via e-mail, if the client so requests. [0140] (19) The client installs the new certificate to his keys storage. [0141] 1.2 Personal Registration Process for External Clients with Software Certificates [0142] The basic principle of a face-to-face registration process with software certificates is generation of keys and a demand for the software certificate at a bank's registration place. A client personally visits the bank's registration place, and produces the necessary information for issuing the demand to the registration operator. The registration operator verifies the client's identity and the client signs the agreement regarding issuing certificates. The registration operator generates the demand for the certificate based on the information from the client. The registration operator further generates the keys, saves them on a floppy disk, and hands them to the client. [0143]FIG. 6 is a flow chart 27 illustrating the steps for the above described face-to-face registration process for external clients with software certificates, wherein the steps are numbered (1) through (12) in the figure. The steps of the process are as follows: [0144] (1) The client visits the bank's registration place 28. [0145] (2) The client fills in a paper form with a demand for a certificate, and signs the agreement with the bank. [0146] (3) A registration operator fills in the electronic form with the demand for a certificate based on the form filled in by the client. The registration operator also generates the keys in his computer and saves them on a floppy disk assigned for the client. [0147] (4) The registration operator submits the processing of the demand for the certificate to the RA 29. [0148] (5) The RA 29 automatically signs the demand. [0149] (6) The RA 29 sends the signed demand to the CA 30. [0150] (7) The CA 30 issues a new certificate signed by a private CA key. [0151] (8) The CA 30 publishes the new certificate in an LDAP directory 31. [0152] (9) The CA 30 sends the newly issued certificate to the RA. [0153] (10) The registration operator picks up the newly issued certificate. [0154] (11) The registration operator exports the certificate to a floppy disk and hands it to the client 32. The certificate may also be sent via e-mail, if the client so requests. [0155] (12) The client 32 installs the newly issued certificate to his keys storage. [0156] Steps 2 and 3 of this procedure may be altered wherein the registration operator fills in the electronic demand for the certificate based on an ID (e.g. passport) and an e-mail address, which may be offered to clients in a paper form, for exactness. This demand will be printed and consequently signed by the client. [0157] 1.3 Face-to-Face Registration Process for External Clients with BCC Certificates [0158] This process is similar to the previous process of face-to-face registration with software certificates. This process assumes that the client does not dispose of the safety object or BCC. [0159] A preferred registration process enables the client to visit the bank's registration place only once, in which visit the bank will settle all necessary matters concerning issuing of an electronic certificate on the BCC, including handing in the demand for a certificate, signing the agreement regarding granting electronic certificates, verification of data in the demand, issuing a BCC and installing the certificate. Demand for the certificate and the generation of keys on the BCC is ensured by the registration operator on the assigned computer and in the bank's registration place. After issuing the certificate, the registration operator installs the certificate on the BCC of the customer (the certificate will also be distributed electronically by sending a notification with a web link to the certificate). The whole process will be completed during the same visit. [0160] This process is similar to the �face-to-face� registration process for external clients with software certificates. The steps of this process comprise: [0161] (1) The client visits the bank's registration place. [0162] (2) The client fills in the form with the demand for a certificate and a BCC, and signs the agreement with the bank. [0163] (3) A registration operator fills in the electronic form with the demand for a certificate based on the form signed by the client. The registration operator also generates the keys on client's BCC. [0164] (4) The registration operator submits the processing of the demand for the certificate to the RA. [0165] (5) The RA automatically signs the demand. [0166] (6) The RA sends the signed demand to the CA. [0167] (7) The CA issues a new certificate signed by a private CA key. [0168] (8) The CA publishes the new certificate in an LDAP directory. [0169] (9) The CA sends the newly issued certificate to the RA. [0170] (10) The registration operator picks up the newly issued certificate. [0171] (11) The registration operator installs the certificate on the BCC and hands it to the client (the certificate may also be distributed electronically by an e-mail). The client receives the BCC with keys, certificate, and a standard PIN. The client is provided with detailed instructions on how to change the PIN, which is most preferably changed on the client's own computer. [0172] (12) The client installs the newly issued certificate from the BCC to the system. [0173] Steps 2 and 3 of this procedure can be modified without, wherein the registration operator fills in the electronic demand for the certificate based on an ID (e.g. passport) and an e-mail address (preferably offered to clients in a paper form, for exactness). This demand will be printed and consequently signed by the client. [0174] 1.4 Distant Registration Process for External Clients with BCC Certificates [0175] A client that wishes to demand a certificate on a BCC with a medium level of security would be required to have the BCC available at the time of generating the demand for the certificate. Also, based on the BCC request, he may be required to come to the registration place to verify his identity and sign the agreement. The visit to the registration place is meaningful only if the client has already demanded a certificate (distantly). Based on these conditions, possible alternatives for a distant registration process with Certificates include the following: [0176] a) The Client visits the bank's registration place twice: [0177] During his first visit the client asks for and receives a BCC. Then, at home, the client generates a demand for a certificate and keys for a BCC (with the help of a special application that sends the demand via the Internet to the Registration FrontEnd Server). During the client's second visit, a registration operator verifies the client's identity, checks the contents of the demand for the certificate, and the client signs an agreement regarding certificates. After this step, the registration operator shifts the certificate demand for further processing to the RA. [0178] b) The registration process does not include distribution of the BCC and the client visits the bank's registration place only once: [0179] In this case, the registration process will assume that the client has received a BCC by another method from the bank. The client receives a pure initialized BCC. Consequently, he generates the demand for the certificate and keys for the BCC at home (with the help of a special application that sends the demand via the Internet to the Registration FrontEnd Server). The client visits the bank's registration place where his identity is verified, and signs the agreement regarding certificates. The registration operator than shifts the certificate demand for further processing to the RA. [0180]FIG. 7 is a flow chart 33 illustrating the steps for the first procedure, wherein the client visits the bank's registration place twice. The procedural steps, numbered (1) through (19) in the figure, are as follows: [0181] (1) The client 34 visits the bank's registration place 35 for the first time for the purpose of receiving a BCC. [0182] (2) The client 34 signs the demand for the BCC and the registration operator fills the demand. [0183] (3) The client 34 goes home with the BCC (the BCC is �pure,� initialized with a standard PIN). [0184] (4) The client 34 runs Java application from his home for the distant registration process. The application can be downloaded from bank's freely accessible web page. [0185] (5) The client fills in the electronic registration form (including revocational password) and generates keys for the BCC. Applet generates a �fingerprint� to be used in the personal verification of the client's identity at a registration place. It writes the �fingerprint� on the screen for the client to copy, permits the fingerprint to be printed, and saves it to a file, (say �demands.txt�) which includes other data about the client. When identifying the client during client's personal visit to the bank, the client will have to produce the demands.txt file in printed or in electronic form, or fingerprint copied from the screen. (The last alternative is not recommended because of the likelihood of error in copying the fingerprint from the screen) [0186] (6) Applet completes the demand for the certificate to PKCS#7 format and sends it to the RFE Server 36. The RFE Server 36 and RBE Server 37 logically form one Registration Server. [0187] (7) The RBE processes the demand and sends it to the ARM database 38. The ARM loads the data from the database, processes the data and sends the processing output to the RA (or RA database 39). [0188] (8) The client visits the bank's registration place for the second time (with the purpose of confirming identity and checking the demand for the certificate). [0189] (9) The registration operator acquires the demand for the SC from the RA database 39. [0190] (10) The registration operator verifies the client's identity and fingerprints generated for the client, the client signs the agreement regarding granting certificates. [0191] (11) The registration operator submits the processing for the certificate demand to the RA 39. [0192] (12) The RA 39 automatically signs the demand. [0193] (13) The RA 39 sends the signed demand to the CA 40. [0194] (14) The CA issues a new certificate signed by a private CA key. [0195] (15) The CA publishes the newly issued certificate in the LDAP directory 41. [0196] (16) The CA sends the newly issued certificate to the RA. [0197] (17) The registration operator picks up the newly issued certificate and exports it to a floppy disk. The certificate may also be sent by e-mail depending on the client's request. [0198] (18) The client leaves the bank with a floppy disk, wherein the newly issued certificate is saved. [0199] (19) The client installs the new certificate on the BCC. [0200]FIG. 8 is a flow chart 42 illustrating the steps for the second procedure, wherein the registration process does not include distribution of the BCC and the client visits the bank's registration place only once. This alternative is similar to the distant registration process for software certificates. The difference between the two processes is that the client generates keys on the BCC and consequently installs the certificate on the BCC. The procedural steps, numbered (1) through (20) in the figure, are as follows: [0201] (1) The client 43 executes the Java application for a distant registration process at home. The client can download the application from the bank's freely accessible web page. [0202] (2) The client fills in the electronic registration form (including the revocational password), and generates keys on BCC. Applet generates a �fingerprint� that will be used in the personal verification process of the client's identity at the registration place. The applet writes the �fingerprint on the screen for the client to copy, allows him to print it, and saves it to a file (say �demand.txt�), which may include additional data regarding the client. When identifying the client during client's personal visit to the bank, the client will be required to produce the demend.txt file in printed or electronic form, or the copied fingerprint (the last alternative is not recommended because of possible error in copying the fingerprint). [0203] (3) The application completes the-demand for the certificate and sends it to the RFE server 44. [0204] (4) RFE Server resends the demand to RBE Server 45. [0205] (5) The RBE formats the demand for the certificate to the format useful for the ARM and saves the data to the ARM database 46. [0206] (6) The ARM 47 takes over the data from the ARM database and processes the data. [0207] (7) The ARM resends the output from the data processing to The RA (or RA database 48). [0208] (8) The client personally visits the branch office 49. [0209] (9) An employee of the branch office 49 receives the sent demand for the certificate from the RA 48. [0210] (10) The registration operator verifies the client's identity and fingerprint generated for the client, and compares them with the data saved in the demand. The client signs the agreement regarding granting certificates. [0211] (11) The registration operator submits the processing of the certificate demand to the RA 48. [0212] (12) The RA 48 automatically signs the demand. [0213] (13) The RA 48 sends the signed demand to the CA 50. [0214] (14) The CA 50 issues a new certificate signed by a private CA key. [0215] (15) The CA publishes a new certificate in the LDAP directory 51. [0216] (16) The CA sends the newly issued certificate to the RA. [0217] (17) The registration operator picks up the newly issued certificate. [0218] (18) The registration operator exports the certificate to a floppy disk. The certificate may also be distributed via e-mail depending on the client's request. [0219] (19) The client leaves the bank with a floppy disk, wherein the newly issued certificate is saved. [0220] (20) The client installs the newly issued certificate on BCC. [0221] 1.5 Distant Offline Registration Process [0222] The bank may be requested to prepare a process of registration for external clients where the registration place may not be connected the BCC net (offline OM, connection failure). Possible alternatives with this process for generating keys include: a) the client generates software keys at home; and b) the client generates SC keys at home. The general steps for this process include: [0223] (1) The client executes Java application for a distant registration process from home. The client can download the application from the bank's freely accessible web page. [0224] (2) The client fills in the electronic registration form (including the revocational password), and generates keys. Applet generates a �fingerprint� that will be used in the personal verification process of the client's identity at the registration place. The applet writes the fingerprint on the screen for the client to copy, allows him to print it, and saves it to a file called demand.txt (with additional data about the client). [0225] (3) When identifying the client during the client's personal visit to the bank, the client will be required to produce the demend.txt file in printed or electronic form, or copied fingerprint. [0226] (4) The application completes the demand for the certificate and sends it to the RFE Server. [0227] (5) The RFE Server resends the demand to the RBE Server. [0228] (6) The RBE formats the demand for the certificate to the format useful for ARM and saves the data to the ARM database. [0229] (7) The ARM takes over the data from the ARM database and processes the data. [0230] (8) The ARM resends the output from the data processing to the RA (or do RA database). [0231] (9) The client personally visits the OM where he fills in the demand in the paper form (since an electronic form is not available). This form also contains information that creates a clear interface between the client's identity and the demand sent electronically (fingerprint). [0232] (10) An employee of the OM verifies the client's identity and compares the information with the data in the demand. [0233] (11) The OM employee submits the processing of the certificate demand to the branch office where WebRAO processes it. [0234] (12) An employee of the branch office (WebRAO) receives the demand for the certificate sent from the RA and compares it with the information in the paper form (which includes the client's identity and fingerprint). [0235] (13) The employee of the branch office (WebRAO) submits the processing of the demand for the certificate to the RA. [0236] (14) The RA signs the demand. [0237] (15) The RA sends the signed demand to the CA. [0238] (16) The CA issues a new certificate signed by a private CA key. [0239] (17) The CA publishes a new certificate in the LDAP directory. [0240] (18) The CA sends the newly issued certificate to the RA. [0241] (19) The registration operator picks up the newly issued certificate and its distribution by e-mail is automatically provided. [0242] (20) The client installs the newly issued certificate to keys storage. [0243] 1.6 Personal Offline Registration Process [0244] Possible alternatives with this process, wherein the keys are generated by the bank, include: a) the registration operator generates software keys in the bank; and b) the registration operator generates SC keys in the bank. [0245] A special application for the process at an offline OM may be installed in the registration operator's PC. The client fills in a paper form at the OM. A registration operator fills in the demand for the certificate based on the information from the form. First, the operator verifies the information in the form, then generates keys on a floppy disk or BCC. The demand for the certificate is entered to a file in PKCS#10 format. The registration application provides these activities for the offline OM. It is also possible to modify the registration process so that the client only presents his e-mail address and an ID (passport). The demand for the certificate filled in by the registration operator is printed and signed by the client. [0246] Files with the demands for the certificates and paper forms will be regularly sent to the relevant OM that is connected to the BCC network. The registration operator of the branch office imports the demands for the certificate in PKCS#10 format, checks them and verifies their contents with the information in the relevant paper form. If the content of a paper form does not collide with the electronic form, the certificate is shifted to further processing. Further steps for processing of the certificate demand and distribution of a new certificate are similar to those in the other registration processes. FIG. 9 is a flow chart 52 illustrating the offline registration process wherein the keys are generated by the bank. The procedural steps, numbered (1) through (13) in the figure, are as follows: [0247] (1) The client 53 personally visits the bank's working place (working in offline mode) and fills in a paper form with the demand for a certificate. [0248] (2) The employee of the OM 54 verifies the client's identity and compares it with the information in the demand. [0249] (3) The OM employee ensures the filling in of the certificate demand and generating of keys (Software or SC). The certificate demand is formatted to a file in PKCS#10 format and saved in the OM. [0250] (4) The employee of the OM shifts the processing of the demand to a branch office where WebRAO 55 processes it. [0251] (5) The employee of the branch office (WebRAO) receives the demand for the certificate sent by the RA 56 and compares it with the information in the paper form. [0252] (6) The employee of the branch office (WebRAO) submits the processing of the demand to the RA 56. [0253] (7) The RA 56 signs the demand. [0254] (8) The RA 56 sends the signed demand to the CA 57. [0255] (9) The CA 57 issues a new certificate. [0256] (10) The CA 56 publishes a new certificate in the LDAP 58 directory. [0257] (11) The CA sends the newly issued certificate to the RA. [0258] (12) The registration operator picks up the newly issued certificate and its distribution by e-mail is automatically provided. [0259] (13) The client 53 installs the newly issued certificate to keys storage (software or SC). [0260] Steps 1 and 3 of this procedure can be modified wherein the registration operator fills in the electronic demand for the certificate based on an ID (e.g. passport) and an e-mail address (offered to clients in a paper form, for exactness). This demand will be printed and consequently signed by the client. [0261] 2. Validation Process [0262] The last step of each registration process is validation of the issued client certificate. In this step the accuracy of the certificate is checked, by checking whether the private key generated for the specific certificate fits the public key in the certificate. Validation of the certificate has functional significance (if the certificate is not exact, it is not applicable), not safety significance (in case of underplayed false certificate, the verification process marks it as failed or unreliable and as such it cannot be applicable either). [0263] The validation process is a revision of certificate's utility. If the certificate validation is not executed, there is a threat that it will not be applicable. There is no safety risk that the certificate will be misused (falsified) unless the private key has been stolen or disclosed. Therefore it is advisable not to reduce the system's security in reliance on the validation process (e.g. by saving revocational passwords to special database). Based on the listed procedures providing solutions, it is advisable that the certificate not be suspended and the validity date rescheduled a few days earlier. During these days (which may be termed the �validity period�) the certificate will not be valid nor will it be on the revocational list of certificates. During the validity period the client runs the validation process to check the issued certificate. In case problems are found, the client may take action or otherwise inform the bank (e.g. through a call center or by canceling the certificate via Web) and the bank may ensure the revocation of the certificate. If during the validation period, the client does not report any problems with the issued certificate, the certificate automatically becomes valid after expiration of the period. Electronic signature of data is preferably utilized in the validation process. Using the applet, the client may download and sign the relevant data with his new private key. The data, digital signature, and newly issued certificate may be applet packed into a structured message and sent via a verification application (relying party). The verification application checks the electronic signature of data using the public key of the connected certificate, and 10 checks the contents and validity of the connected certificate (revision towards CRL or OCSP, depending on the final solution) [0264]FIG. 10 is a flow chart 58 illustrating the steps for a validation process. The steps for a) revision of certificate validity towards CRL (LDAP) are indicated in the figure as follows: [0265] (0a) Verification application 59 downloads CRL from the LDAP 63. [0266] (1) Applet 60 receives the client's data for signature. [0267] (2) Applet ensures the signing of the data and prepares a structured message to be sent. [0268] (3) The message is sent to the verification application 59. [0269] (4a) The verification application 59 revises the signature and verifies the validity of the connected certificate towards the CRL. [0270] (7) The verification application 59 sends the response to the client 61. [0271] Additionally, the steps for b) the revision of a certificate's validity via a Validity authority (OCSP responder) are indicated in the figure as follows: [0272] (0b) The certificate's state is published. [0273] (1) Applet 60 receives the client's data for signature. [0274] (2) Applet ensures the signing of the data and prepares a structured message to be sent. [0275] (3) The message is sent to the verification application 59. [0276] (4b) The verification application 59 sends a demand for validation of the certificate. [0277] (5b) The validation authority 62 (OCSP responder) processes the demand for validation. [0278] (6b) The validation authority sends the response to the verification application 59. [0279] (7) The verification application resends the response to the client. [0280] 3. Certificate and Keys' Renewal [0281] Renewal of the certificate's validity by generating a new pair of keys basically means cancellation of the validity of the old certificate and issuance of a new certificate with new keys. Issuing the new certificate must be verified directly during a visit to the bank's registration place or by using the system's technology (with electronic signature for the demand of the certificate's renewal). [0282] Various processes may provide for the renewal of keys for software and certificate utilizing the original certificate and keys. The security level of the newly issued certificate will be identical with the security level of the original certificate (i.e. it is not possible to renew keys on the BCC using a software certificate). [0283] To renew certificates and keys, it is necessary to perform the following: [0284] 1. To generate new keys and make a request for a new certificate, the request being made by the client. [0285] 2. To find the connection between the old certificate and the request for the new certificate, verify the contents of the new request for the certificate, and further ensure the arrangement and pre-preparation of data (Registration BackEnd Server). [0286] 3. Issue a new certificate with immediate validity and suspend the old certificate. [0287] 4. Verify the newly issued certificate (see validation process). [0288] To ensure these steps, the client will use a special application that will generate a pair of keys and will prepare the demand for a certificate and keys' renewal. The application will pack the demand into a structured message that will contain the request for issuing a certificate. The structured message will be signed by the old private key (the �old� certificate will be a part of the message). The RBE Server will be instrumental in the initial revision of the request for a certificate's renewal as well as in dispersing data and will pre-prepare data for the ARM module. The ARM module makes the request for the new certificate (to the RA) and suspends the old certificate's validity. After the processing is complete, the newly issued certificate will be distributed to the client via e-mail. The client is also informed about suspension of the old certificate's validity by an e-mail. The client installs a new certificate (this certificate is immediately valid). In the next step, the client verifies the functionality of the newly issued certificate (see Validation process). In case the new certificate is not functional, the client initiates the unsuspending of the old certificate and the new certificate will be suspended. If the new certificate is functional, the client can utilize it immediately. FIG. 11 is a flow diagram 64 illustrating the procedure for the renewal of keys and certificate, without the validation process. The procedural steps, numbered (1) through (18) in the figure are as follows: [0289] (1) The bank's client 65 uses a special application to demand keys and certificate renewal. [0290] (2) The application ensures generation of a new set of keys (Software or SC), and �packs� the demand for the certificate together with the old certificate to to a structured message signed by an old private key. [0291] (3) The application sends the request for renewal to the RFE server 66. [0292] (4) The RFE Server re-sends the request to the RBE Server 67. [0293] (5) The RBE unpacks the structured message, verifies the, validity of the old certificate towards CRL (RBE can download CRL individually during later steps of the process). [0294] (6) The RFE 66 pre-prepared data is sent for processing through the ARM and saves it in the ARM database 68. [0295] (7) The ARM 69 takes over the pre-prepared data from the ARM database 68. [0296] (8) The ARM processes the data, including the request for suspending the certificate's validity and demand for issuing a new certificate, and sends the data to the RA (or RA database 70). [0297] (9) The RA signs the demand. [0298] (10) The demands are sent from the RA to the CA 71. [0299] (11) The CA processes the demands. [0300] (12) The new certificates are published in the LDAP, and the old certificate is revoked in the CRL. [0301] (13) The CA sends the newly issued certificate to the RA. [0302] (14) The RA sends the output from demands processing to the ARM. [0303] (15) The ARM prepares an e-mail for distribution of the new certificate and a notice about suspension of the old certificate and sends the messages to a MailGateway 73. [0304] (16) The MailGateway re-sends the mail to the client [0305] (17) The client downloads the newly issued certificate from the web address. [0306] (18) The client installs the newly issued certificate to the keys storage (software or SC). [0307] 4. Extending Certificate's Validity/Change of Data in the Certificate [0308] The process for extending a certificate's validity is similar to the process for effectuating a change of data in the certificate in terms of utilizing architecture. The client indicates in the client application that apart from extending certificate's validity, he request a change of data in the certificate. The process is almost identical to the process of keys' renewal. The only difference is that no new keys are generated and in the PKCS#10 demand, the old private key signs the old public key. [0309] 5. Suspending a Certificate's Validity [0310] Different types of clients can request the suspension of a certificate's validity via a) web-pages of the bank by entering a pass phrase to suspend the certificate; b) a telephonic call to a call center whereby the client recites a pass phrase to an operator who will have the ability to suspend the certificate; and c) by a personal visit to the bank's branch office. A Pass phrase to suspend the certificate's validity will exist for each issued certificate. The same pass phrase may be used for suspending the certificate, revoking its validity, and unsuspending or reinstating the certificate. [0311] 5.1 Suspending of Validity through Web-Pages [0312] The steps for suspending a certificate via a banks web page are as follows: [0313] (1) The Client logs into the bank's web page and runs the applet for suspending a certificate. [0314] (2) He fills in the necessary data (e.g. first name, surname, special client number and revocational pass phrase). [0315] (3) The application prepares a PKCS#7 message for client, coded by a public key of the RBE Server containing a request for suspending and sends it to the RFE Server. [0316] (4) The RFE Server resends the demand to the RBE Server. [0317] (5) The RBE Server pre-prepares the demand to an acceptable format for the ARM (strong arm processor). [0318] (6) The ARM takes over the demand, processes it and shifts it to further processing in the RA. [0319] (7) The RA automatically signs the demand. [0320] (8) The RA sends the signed demand to the CA. [0321] (9) The CA suspends the certificate and issues a new CRL and writes it to the LDAP directory. [0322] (10) The CA informs the RA about this. [0323] (11) The ARM receives the message from the RA regarding successful suspending, and resends an e-mail to the user (via mail-gateway). [0324] 5.2 Suspending of Validity Telephonically or by Personal Visit of the Bank [0325] In this case a registration operator (WebRAO operator in the branch office or RAO or CAO operator in the main office in case of fault) effectuates the suspension. The client provides the necessary data (first name, surname and special client number). [0326] While the present invention has been described with regards to particular embodiments, it is recognized that additional variations of the present invention may be devised without departing from the inventive concept. BRIEF DESCRIPTION OF THE DRAWINGS [0053]FIG. 1 is a diagram of the system of the present invention, in accordance with a preferred embodiment. [0054]FIG. 2 is a diagram of the communication information center (CIC) and its internal databases and execution modules, in accordance with a preferred embodiment of the present invention. [0055]FIG. 3 is a diagram of the customer's computer and money tag. [0056]FIGS. 4A and B show a flow diagram illustrating a transaction process, in accordance with a preferred embodiment of the present invention.
Referenced byCiting PatentFiling datePublication dateApplicantTitleUS6983882 *Mar 31, 2003Jan 10, 2006Kepler, Ltd.Personal biometric authentication and authorization deviceUS7314164 *Jul 1, 2004Jan 1, 2008American Express Travel Related Services Company, Inc.System for biometric security using a smartcardUS7325724 *Jul 1, 2004Feb 5, 2008American Express Travel Related Services Company, Inc.Method for registering a biometric for use with a smartcardUS7341181 *Jul 1, 2004Mar 11, 2008American Express Travel Related Services Company, Inc.Method for biometric security using a smartcardUS7765163 *Dec 11, 2001Jul 27, 2010Sony CorporationSystem and method for conducting secure transactions over a networkUS7765398Jul 7, 2005Jul 27, 2010At&T Intellectual Property I, L.P.Method of promulgating a transaction tool to a recipientUS7780091 *Feb 18, 2009Aug 24, 2010Beenau Blayn WRegistering a biometric for radio frequency transactionsUS7954715Nov 8, 2010Jun 7, 2011Tyfone, Inc.Mobile device with transaction card in add-on slotUS7954716Dec 8, 2010Jun 7, 2011Tyfone, Inc.Electronic transaction card powered by mobile deviceUS7954717Dec 8, 2010Jun 7, 2011Tyfone, Inc.Provisioning electronic transaction card in mobile deviceUS7961101Aug 8, 2008Jun 14, 2011Tyfone, Inc.Small RFID card with integrated inductive elementUS7979740 *Feb 17, 2010Jul 12, 2011Mudalla Technology, Inc.Gaming machine having game play suspension and resumption features using biometrically-based authentication and method of operating sameUS7991158Aug 24, 2007Aug 2, 2011Tyfone, Inc.Secure messagingUS8061593 *Oct 1, 2010Nov 22, 2011Diebold Self-Service Systems Division Of Diebold, IncorporatedBanking system that operates during different transaction sessions to provide a particular individual the next predetermined presentation in a marketing campaign preassigned to the particular and individual prior to the sessionsUS8108917 *Dec 21, 2006Jan 31, 2012Brother Kogyo Kabushiki KaishaManagement apparatusUS20100332391 *Jun 30, 2009Dec 30, 2010Khan KhurramSecure authentication between multiple partiesUS20110099112 *Aug 29, 2008Apr 28, 2011Mages Kenneth GApparatus and method for conducting securing financial transactionsUS20110126002 *Nov 24, 2009May 26, 2011Christina FuToken renewalEP1662442A1 *Nov 24, 2004May 31, 2006Topseed Technology Corp.Activation mechanism of personal financial accountWO2007089439A1 *Jan 18, 2007Aug 9, 2007Microsoft CorpIdentity theft mitigation* Cited by examinerClassifications U.S. Classification705/44, 705/39International ClassificationG07C9/00, G06Q20/00, G06Q30/00Cooperative ClassificationG06Q20/40, G06Q30/06, G06Q20/04, G06Q20/10, G07C9/00071, G06Q20/385European ClassificationG06Q20/04, G06Q30/06, G06Q20/40, G06Q20/10, G06Q20/385Legal EventsDateCodeEventDescriptionMar 21, 2003ASAssignmentOwner name: FUSION TECHNOLOGY, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BARILLOVA, KATRINA;MICHALKO, ROBERT;REEL/FRAME:013900/0175;SIGNING DATES FROM 20030308 TO 20030310RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google