HK1069655B - Tokenless identification system for authorization of electronic transactions and electronic transmissions - Google Patents

Description

Non-cost ticket identification system for electronic transaction and electronic transmission authorization

no marking

The present application is a divisional application No. 96195641.0 entitled "non-token identification system for electronic transaction and electronic transmission authorization" filed on 1996, 5/17.

Today's financial world populates tokens and credit cards. A token is any inanimate object that is awarded to an individual. The object gives the individual who presents the object an ability. Each financial account is accessed remotely by using a token or plastic piece. Whether the use of a debit card to purchase groceries or a credit card to purchase consumer goods, the heart of the transaction is the exchange of funds permitted by a token that identifies an individual and the financial account accessed by the individual.

The reason for going from the metal coin to the use of plastic cards is simple and straightforward: access to currency in a money exchange system is far more secure for both merchants and consumers than using large amounts of coins and banknotes.

Unfortunately, the techniques associated with such convenient token-based money exchange systems have resulted in systems that are vulnerable to theft and cheating.

The verification of the user's identity is based solely on the data put into the token, which is easily copied and transferred between different individuals. Such security must rely on authorized users and merchants in keeping information private and effort and luck. However, due to the inherent nature, there is not a strong association between the token and the individual. Identifying the legitimate owner of the token through the token is also, to the greatest extent, vulnerable. This can be seen from the fact that: individuals other than the legitimate owner of the token have used such tokens to deceive merchants and other consumer goods providers.

The great development of the credit industry of the consumers in the eighties brings great profits to the card issuers and brings new convenience to the consumers. However, since consumer credit is readily available to consumers, it is a target of criminals. Just as car mobility in the early 20 s and 30 s led to a large number of bank robberies, the popularity of consumer credit led to an increase in crime opportunities.

Initially, the banking industry accepted the partial losses due to fraud and passed the cost to the consumer. However, as crimes become more and more organized. The technology is becoming higher and the credit retail outlets are beginning to be operated by people who are becoming less and less trained in the security aspects of credit cards, and the rate of increase in losses caused by fraud is proliferating. The cost of the alarming statistics and precautionary steps of fraud compels credit card companies to specifically look for other solutions.

Fraud losses in the credit card industry originate from many different aspects of the highly vulnerable nature of credit card systems, but the main causes are lost, stolen, and counterfeit cards. The operation of credit cards does not require the use of a Personal Identification Code (PIC), so a lost card can become money once it falls into one's hands. The theft of tokens accounts for the majority of fraud in the system, and the use of counterfeit credit cards is rising. Counterfeit cards are made by more technically sophisticated criminals by obtaining and using a valid account number for the cardholder. The counterfeiter encodes the magnetic strip and applies (emboss) the account number film to the counterfeit plastic card. The card is then presented to the merchant and credited to the rightful cardholder's account. Another form of loss is due to a criminal merchant who happens to get the cardholder's account. Yet another type of fraud is by authorized cardholders, in which a good is purchased with a token and the token is declared lost or stolen. It is estimated that every year all types of fraud incur losses in excess of nine hundred million dollars.

Typically, debit cards are used in conjunction with Personal Identification Codes (PICs). Counterfeiting of debit cards is more difficult because criminals must not only obtain the account number, but also obtain the PIC and then make the card as a credit card is made. However, there are many ways to obtain the PIC from the cardholder, such as a trojan horse automated teller machine or ATM in a shopping center that does not receive cash but records the PIC, a merchant point of sale device that also records the PIC, and a person that telescopes to view the cardholder's input of the PIC at the ATM. The subsequently manufactured counterfeit debit card is used on various ATM machines until the account is depleted.

The financial industry knows the trend of fraudulent costs and takes steps to enhance the security of the card. Fraud and theft of the token have an indirect impact on the cost of the system.

Blank cards are manufactured under very strict security conditions. These cards are then marked with an account number and expiration date and sent to the cardholder. Light costs 10 billion dollars per year for manufacturing and distributing cards. The financial industry costs standard cards $ 2 per card, but only $ 0.3 of these $ 2 is associated with the actual manufacturing cost.

Over the past 10 years, the financial industry has changed the tokens due to counterfeiting and fraud, but has not made fundamental changes to the use of credit transaction systems. The remedy is an administrative change such as having the user call an issuer to validate their card. Other variations include adding holographic security, photo ID or improved signature area. These types of changes indicate that the system is sensitive to fraud in that there is a lack of genuine identification of individuals. This is estimated to double the manufacturing cost to 20 billion dollars per year.

In the near future, the banking industry is expected to move to more expensive cards, i.e. "smart cards". The smart card contains the same computing power as some of the first home computers. The current cost plan for the first generation smart cards is estimated at approximately $ 3.5 per card and does not include a distribution cost, which would be significantly higher than $ 0.3 for a plastic blank card.

The significant increase in cost has forced the financial industry to find new ways of using the capabilities of smart cards in addition to simple transaction authorization. It can be seen that in addition to storing credit and debit account numbers, the smart card may also store telephone numbers, frequent flyer miles, coupons from stores, history of transactions, e-coins available at toll booths and public transportation systems, and the user's name, key data and even medical history. Clearly, the trend in the financial industry is to further establish the use of tokens.

A side effect of the increase in the capabilities of smart cards is the concentration of functionality. The secondary side effect of increased function is increased vulnerability. With these features of smart cards, the loss or damage of such high-end cards can cause significant inconvenience to the cardholder. The absence of such a card would render the cardholder financially ineffective until the card was replaced. In addition, losing a card full of electronic money will also result in a real financial loss. In addition, the ability to counterfeit a smart card that can be copied one smart card per day has not been mentioned.

Unfortunately, due to the centralized functionality that appears on smart cards, cardholders are more susceptible to loss or damage to the card itself. Thus, after spending a lot of money, the finished system is safer, but damage or loss of such cards on the consumer is likely to be subject to increasingly heavy penalties.

The financial industry recognizes security issues associated with smart cards and makes efforts to make each molded card difficult to counterfeit. Billions of dollars are used to make plastic cards more secure in the next five years. To date, the consumer financial transaction industry has a balanced simple formula: to reduce fraud, the cost of the card must be increased.

In connection with and beyond the popularity of electronic financial transactions, electronic faxes, electronic mail messages and similar electronic communications are widely used. The problem of lack of proper identification of individuals in financial transactions is similar to the lack of proper identification of individuals in electronic transmissions. The convenience and rapidity of electronic communication and the low price compared to ordinary postal delivery are one of the options for ways of communication between individuals and in the business community. This type of communication has grown enormously and is expected to continue to grow. However, millions of electronic messages, such as faxes and electronic mail ("E-mail") are delivered without knowing whether they have reached their true destination or whether someone has actually sent or received the electronic message. In addition, the identity of the individual sending or receiving the electronic message cannot be verified.

Recently, many efforts have been made to overcome the problems inherent in token and code security systems. One major aspect is that the PIC is encrypted, altered or decorated to make it more difficult for unauthorized users to make more than one transaction, and it is largely the processing of the PIC to make such code more resistant to fraud. Many methods have been proposed, such as introducing an algorithm that changes the PIC in a manner known only to the user, so that a different PIC code is required for each next access to the account. For example, the PIC code may be changed and tailored specifically to the calendar day or date of the access attempt. In another approach, a time variable factor is introduced to produce a predictable personal identification code that is displayed only to authorized users at the time of access. While less vulnerable to fraud, the system incorporates an invariant code, such an approach is not substantially fraud-free as it still relies on data that is not unique and non-reproducible to the individual of the authorized user. In addition, such systems are inconvenient for consumers who do not easily remember invariant codes and those who rarely change codes. Examples of such methods are described in U.S. patent 4,837,422 to Dethloff et al, U.S. patent 4,998,279 to Weiss; U.S. patent 5,168,520 to Weiss; U.S. patent 5,251,259 to Mosley; U.S. patent 5,239,538 to Parrillo; U.S. patent 5,276,314 to Martino et al and U.S. patent 5,343,529 to Goldfine et al, all of which are incorporated herein by reference.

In more recent times, one has turned his attention away from using personal identification codes to using unique biometric data as the basis for authentication and eventual computer access. In this way, the actual biometric data is recorded from a user with a known identity and presented on a token for future verification. In each subsequent access attempt, the user is required to physically enter the required biometric data, which is compared to the authenticating biometric data on the token to determine if the two match to verify the user's identity. Because biometric data is unique to the user's individual and physically entering biometric data is essentially non-reproducible, a match can infer actual identity, thus reducing the risk of fraud. Many biometric data are suggested, such as fingerprints, hand-prints, voice-prints, retinal images, handwriting samples, etc. However, since biometric data is typically stored electronically (and thus can be recreated) on a token and the comparison and verification process does not depart from the hardware and software used directly by the individual attempting access, a significant risk of fraudulent access still exists. Examples of such ways of system security are described in the following patents: U.S. Pat. No. 4,821,118 to Lafreniere, U.S. Pat. No. 4,993,068 to Piosenka et al; U.S. patent 4,995,086 to Lilley et al; U.S. patent 5,054,089 to Uchida et al; us 5,095,194 to Barbanell; united states 5,109,427 to Yang; U.S. patent 5,109,428 to lgaki et al; U.S. patent 5,144,680 to Kobayashi et al; U.S. patent 5,146,102 to Higuchi et al; U.S. patent 5,180,901 to Hiramatsu; U.S. patent 5,210,588 to Lee; U.S. patent 5,210,797 to Usui et al; U.S. patent 5,222,152 to Fishbine et al, U.S. patent 5,230,025 to Fishbine et al; U.S. patent 5,241,606 to Horie; U.S. patent 5,265,162 to Bush et al; U.S. Pat. No. 5,321,242 to Heath, Jr et al; U.S. patent 5,325,442 to Knapp; U.S. patent 5,315,303 to Willmore, all of which are incorporated herein by reference.

As can be appreciated from the above discussion, there is a tremendous and unavoidable need to try to design a highly fraud resistant security system, but which is easy and convenient for consumers to use. Disadvantageously, the proposed improvements to the token and code system as disclosed above do not address, nor attempt to balance, this need. Such systems typically store the authenticated biometric data in electronic form directly on a token that can be considered to be reproducible. In addition, such systems do not properly isolate the authentication process from the intervention of a person attempting to gain unauthorized access.

An example of a token-based security system that relies on biometric data of a user can be found in U.S. patent 5,280,527 to Gullman et al. In the system of Gullman, the user must carry and present a credit card sized token (known as a biometric data security device) containing a microchip on which the characteristics of the authorized user's voice are recorded. To initiate the access procedure, the user must place the token into a terminal, such as an ATM, and then speak into the terminal to provide a biometric data input to be compared with the authenticated input on the microchip of the presented token. The process of authentication is generally not isolated from the intervention of a person attempting unauthorized access. If there is a match, the remote terminal may inform the host computer that access should be allowed, or may prompt the user to enter an additional code, such as a PIN (also stored on the token), before sending the necessary authentication signal to the host computer.

While the stored and entered biometric data comparison in the Gullman system reduces the risk of unauthorized access compared to digital codes, the use of a token as a repository of authentication data by Gullman and the inability of Gullman to isolate the identity verification process from the possibility of intervention reduces any improvement in the resistance to fraud after the digital codes are replaced by biometric data. In addition, the system is somewhat awkward and inconvenient because of the need to also present a token to initiate the access request.

Almost consistently, patents disclosing token-based systems do not disclose the identification of biometric data without the use of a token. The reasons for this approach relate to the storage requirements of biometric data recognition systems, and the significant time duration of identifying large numbers of individuals, even for the largest computers.

In view of the foregoing, there is a long felt need for a computer access system that is highly resistant to fraud, practical and efficient to facilitate user operations and to conduct electronic transactions and transmissions quickly.

There is also a need for a computer system that is completely cost-free and that can verify the personal identity of a user. This authentication is based solely on a personal identification code and biometric data that is physically unique to the authorized user, as opposed to verifying whether an individual has an object that can be freely transferred between different individuals. Such biometric data must be readily available without damage, must be easily and inexpensively stored and analyzed, and must not infringe on the privacy of the individual.

A further need for computer access system design is convenience for the user. It is highly desirable that consumers have spontaneous access to the system, particularly when unexpected needs arise, with minimal effort. In particular, there is a need for a system that greatly reduces or eliminates the need to remember large or cumbersome codes, and makes it unnecessary to carry and present unique objects to initiate an access request.

Such a system must be simple, accurate and reliable to operate. There is a need for a computer access system that allows a user to access multiple accounts and obtain all services authorized for the user, conduct transactions within and between all financial accounts, pay for purchases and receive various services, and the like.

There is also a greater need for a computer access system that gives authorized users the ability to: alerting an authorized party to: a third party is forcing the user to request access without letting the third party know that an alarm has been generated. There is also a need for a system that can temporarily limit the types and number of transactions that can be made once access is granted without the knowledge of the forcing third party.

In addition, the computer system must be affordable and flexible enough to operate compatibly with existing networks having a variety of electronic transaction and transmission devices and system architectures.

Finally, there is a need for secure transmission and reception of electronic mail messages and electronic faxes, where the contents of the electronic message are protected from disclosure to unauthorized individuals, and where the identity of the sender and receiver can be obtained with a high degree of certainty.

The present invention fills these needs by providing an improved identification system for determining the identity of an individual by comparing a biometric data sample and personal identification code of the individual collected in an attempt step with a biometric data sample and personal identification code collected for the individual in an enrollment step and stored at a remote site at a data processing center. The present invention includes a computer network host system having means for comparing an input biometric data sample with a personal identification code and is equipped with various databases and memory modules. In addition, the invention is provided with biometric data and personal identification code input means and means for inputting data to provide the requested transaction and transmitted information to be performed by the host when the identity of the individual is determined. The invention is also provided with means for connecting the host computer with the terminal and the biometric data input device.

The computer is also provided with means for performing various transactions and transmissions in addition to conventional stored data and modifications. In addition, the computer can output an evaluation of the biometric data-PIC ("personal identification code") comparison, as well as a determination of the identification evaluation, or the status of any execution of the transaction or transmission. In addition, the computer system notifies and authenticates the verified individual that the computer system is accessed by sending back to the individual a unique code that the individual previously selected in the enrollment step.

The computer system is preferably protected from electronic eavesdropping and electronic intrusions and viruses. Additionally, these means for collecting biometric data samples and personal identification codes for use by a computer include: a) at least one biometric data input device for collecting biometric data samples, having a software component and a hardware component; b) at least one terminal device functionally partially or fully integrated with the biometric data input means for inputting any additional auxiliary information; c) a data input device for inputting a personal identification code, the data input device being integrated with one of the biometric data input device or the terminal device, and d) a means for interconnecting the biometric data input device, the data input device and the terminal. The terminal device also has at least one display for displaying data and information. For greater security, the computer system uniquely identifies the biometric data input device and uniquely identifies the counter party or merchant via a counter party or merchant identification code associated with the terminal to which the biometric data input device is connected. The biometric data input device is preferably protected from physical or electronic intervention, and when the device is physically compromised, measures are preferably taken to physically and/or electronically damage the relevant components of the apparatus and/or to remove critical data from the memory module of the device.

In addition, the biometric data input device includes a hardware section including: a) at least one computing module for data processing; b) an erasable or non-erasable memory module for storing data and software; c) a biometric data scanning device for inputting biometric data; d) a data input device for inputting data; e) a digital communication port; f) apparatus for preventing electronic eavesdropping.

In order to protect the integrity and concealment of electronic data between the biometric data input device, the terminal and the computer network, the data is preferably encrypted and sealed.

The host computer network is connected to and can communicate with other independent computer systems, databases, fax machines, and other computing networks in a conventional manner.

The method of the present invention includes automatically identifying an individual without the use of any token by examining at least one biometric data sample provided by the individual and a personal identification code also provided by the individual. In an enrollment step, the individual enrolls an authenticated biometric sample, an individual identification code and a unique code into the system. Thereafter, a biometric data sample and a personal identification code of the individual are collected in a try (bid) step and compared with those registered in the registration step. A match of the personal identification code and the biometric data sample results in a positive identification of the individual. In order to authorize the identified individual that the genuine computer system is accessed, the unique code collected during the enrollment step is returned to the individual.

The method of the present invention preferably includes a method of examining the biometric data samples at enrollment time and comparing such biometric data to a collection of biometric data samples of persons deemed to be attempting crime or actually being fraudulent on the system.

In a preferred embodiment, the present invention preferably includes a method of notifying an authorized party of an emergency and that the authorized party is in a duress state.

Preferably, the data is protected by encrypting and sealing the data, including digitized biometric data samples, from accidental leakage or leakage during transmission due to criminal factors.

The method preferably includes the step of enabling the individual to select different financial accounts and to select different electronic transmission modes.

The method preferably includes a method of implementing data and electronic transmission and retrieving data using tracking codes.

Preferably, any document such as a fax or email message is uniquely evaluated for a checksum by using an algorithm for future identification of the document.

Furthermore, another method of the present invention is to be able to quickly identify a different individual by checking its biometric data samples and the individual identification code by storing several dissimilar biometric data samples of the individual in an electronic basket (basket) identified by an individual identification code.

In one embodiment of the invention, a computer system allows an individual to select his personal identification code from a set of Personal Identification Codes (PICs) selected by a remote data processing center. This is done as follows; once the biometric data of an individual is collected, the data processing center randomly selects a number of PICs for easy recall. The data processing center then compares the collected biometric data to those already in the PIC basket or group. When the biometric data of the new enrollee is similar to any previously enrolled biometric data that has been assigned to any of those optional PIC groups, the database denies the PIC to be used by the new individual and another PIC is selected for another such biometric data comparison. Once the data processing center has collected several alternative sets of PICs without ambiguous similar biometric data, the PICs are presented to new registrants from which individuals may select a PIC.

In one embodiment of the present invention, there is a method of rapidly searching at least one first previously stored biometric data sample from a first individual using a personal identification code basket that can include at least one algorithmically unique second biometric data sample from at least one second individual, and the second biometric data sample is identified by the personal identification code basket, the method comprising: first, a storing step, the storing step further comprising: a) selecting a unique code by a first person; b) selecting a personal identification code by said first individual; c) inputting a biometric data sample of the first individual; d) determining a location of a basket of personal identification codes identified by the personal identification code selected by the first individual; e) comparing the biometric data sample obtained from the first individual with any previously stored biometric data samples in the selected personal identification code basket to determine that the biometric data sample entered by the first individual is algorithmically unique and different from at least one previously stored biometric data sample provided by at least one second individual, and; f) storing the input biometric data sample in a selected personal identification code basket if the sample is algorithmically unique and different from at least one previously stored biometric data sample from the at least one second individual. There is a try (bid) step, the try step further comprising: a) entering said selected personal identification code by a first individual, and; b) inputting a biometric data sample by the first person. There is also a comparison step comprising: a) finding a personal identification code-basket identified by the personal identification code entered by the first person; b) comparing the biometric data samples entered by said first individual with said at least one stored biometric data samples from said at least one second individual stored in said entered personal identification code-basket to produce a successful or failed identification. There may also be: a) an execution step in which a command is processed and executed to produce a determination; b) an output step in which the recognition result or the determination is externalized and displayed, and; c) a presenting step, wherein a unique code is presented to said first person when the identification of said first person is successful.

According to one embodiment of the invention, the host system is serially interposed between the identified individual and the other computer network to be accessed, and thus acts as an interface. It should be appreciated that in this embodiment, the user directly makes an access request to the host computer system of the present invention, which interacts with other independent secure computer systems (e.g., VISANET-visa). The computer system thus maintains authenticated biometric data samples for all authorized users of each secure computer system it serves. These data are consulted by each authorized user interaction. Thus, after identification is complete, the security system provides the user with a list of systems that the individual is authorized to access and prompts the user to select the desired network. The requested execution steps and information relating to the transaction are then sent to the selected independent computer network, similar to the type of communication sent between the merchant and the credit card company today.

In a second embodiment, the host system may perform other independent computer system functions, such as debiting or crediting a financial account. In such a system, the computer system of the present invention performs the functions requested by the individual without the need for an external, independent computer network.

According to yet another embodiment of the present invention, a means is provided for alerting a pre-designated authorized party in an access attempt when a user is forced by a third party to request access to the host computer system. In this embodiment, the authorized user has several codes, most of which are recognized by the computer system as standard access codes, and others of which are recognized as emergency codes. The comparing means of the computer system of the present invention may be configured to accept and identify at least one code for each authorized user and activate the emergency alert device whenever the code entered by the user matches the emergency code. At the same time, the determination of the authorized identity of the user results in the user having access to the requested secure computer system or results in misleading data (i.e., "false screens") at a restricted level of access that may be predetermined, thus preventing third parties of others from being forced to know that the user has entered an emergency notification. The entry of the emergency code may be as part of or simultaneously with the user personal identification code, or an emergency account index may be selected upon accessing the computer system. In each case, the security of the user requesting access is at risk if the enforcing party finds that the user is trying to notify the authorizing party. It is therefore critical that the access process continues uninterrupted and access is allowed to authorized users so that compelling parties believe everything is functioning properly. Although these features may be included in the host computer network of the present invention, a separate computer network may implement the same or modified features described above.

The present invention has several advantages over the prior art. First, it is convenient and highly efficient for users, especially when accessing financial accounts, because it does not require any tokens to be carried and presented to access someone's account. The present invention eliminates all of the inconvenience associated with carrying, securely holding and placing any required coupons, and, in addition, provides access to all assets by using only one personal identification code, significantly reducing the memory and effort required by the consumer, since coupons are often specific to a particular computer system and require the memory of the password assigned to that particular coupon. Thus, in a single, non-token transaction, the consumer can efficiently and securely conduct virtually any commercial exchange or electronic message exchange, such as cash withdrawal from a bank account, occasional authorization consent to the term, direct shopping from television, and local property tax payment. Consumers now have the unique ability to conveniently conduct electronic transmissions and transactions for individuals and/or professions at any time by virtue of the present invention rather than relying on a token that may be stolen, lost or damaged.

The invention has a significant advantage of convenience, making retailers and financial institutions less cumbersome and more convenient to trade and conduct additional financial transactions. Paper work in financial transactions can be significantly reduced compared to current systems, such as current credit card purchasing systems that require the generation of receipts for use by credit card companies, merchants, and customers, respectively. Such electronic transactions greatly reduce operating costs and save considerable time and expense for merchants and banks. Because the system of the present invention enables a consumer to access all of his financial accounts directly at the same time, transactions involving currency, checks, commercial instruments, etc. are significantly reduced, thereby reducing the equipment and manpower required to collect and process such transactions. In addition, the manufacturing and issuing expenses of issuing and reissuing cards such as credit cards, ATM cards, phone cards, etc. can be substantially eliminated, thereby further saving the economic costs of merchants, banks, and ultimately the money of consumers. Indeed, the system of the present invention is likely to promote economic growth since all consumers are able to obtain their electronic financial resources by simply entering their fingerprints or other biometric data.

The significant advantages of the present invention and the advantages over existing systems are a high resistance to fraud. As mentioned above, the unreliability of current computer systems is inherent in that they base the determination of the identity of a user on a uniquely manufactured physical form, and in some cases, information known to the user. Unfortunately, both the token and the information may be made known to others by loss, theft, or the initiative of the authorized user. Thus, unless an authorized user recognizes and reports the loss or inadvertent propagation of such items, anyone in possession of such items can be identified by the existing security system as an authorized user to whom the token and information is assigned.

In contrast, the present invention analyzes one or more unique biometric data characteristics of a user to determine the identity of the user, in effect, messaging the danger of granting access to unauthorized users. Even in extreme cases where an authorized user is forced by a forcing party to access his or her own account, the system can generate an emergency account index in advance so that the authorized user can inform the authorizing party of the violation without being perceived by the forcing party

The invention further improves the anti-fraud capability by maintaining the authentication data at a point in the system that is operationally unrelated to the user requesting access and performing an authentication operation, thereby preventing the user from obtaining a backup of the authentication data or tampering with the authentication process. Such a system is clearly superior to existing token-based systems where authentication information, such as a unique code, is stored in and recovered from the token, and where the actual identity determination is operationally accessible to the user during access.

It is therefore an object of the present invention to provide a computer access identification system which does not require the user to own or provide a physical object, such as a token, in order to initiate a system access request.

It is another object of the present invention to provide a computer access identification system that can verify the identity of a user as opposed to verifying possession of a proprietary object and information.

It is yet another object of the present invention to verify the identity of a user based on one or more unique characteristics that are physically dependent on the person of the user.

It is yet another object of the present invention to provide a practical, convenient, easy to use security access system.

It is yet another object of the present invention to provide a system for securing access to a computer system that is highly resistant to fraud for unauthorized user access attempts:

it is yet another object of the present invention to provide a computer access identification system that enables a user to notify an authorized party that a particular access request is being enforced by a third party that is not aware of the notification.

There is also a need for a computer access identification system that automatically limits the user's transaction capabilities on the computer system based on the user's own desired configuration.

These and other advantages of the present invention will become more apparent upon reading the following detailed description of the invention in conjunction with the accompanying drawings.

FIG. 1 is a schematic diagram of the system of the present invention;

FIG. 2 is a schematic diagram of a Data Processing Center (DPC) and its internal databases and execution modules;

fig. 3 is a schematic diagram of a retail point of sale terminal, biometric data input device and its components and interconnections.

FIG. 4 is a flow chart of the operation of the biometric data input device and the terminal generating the request packet;

FIG. 5 is a representative diagram of a request packet and the requisite and optional data it contains;

FIG. 6 is a representative schematic diagram of a reply packet and the requisite and optional data it contains;

fig. 7 is a flowchart showing a data encryption and sealing process performed by the biometric data input device;

FIG. 8 is a flow chart showing the data decryption and counter side identification process performed by the DPC;

FIG. 9 is a flow chart showing the data encryption and sealing process performed by the DPC;

FIG. 10 is a flowchart showing user enrollment performed during the enrollment process;

FIG. 11 is a flowchart illustrating a process of identifying a person and returning a unique code thereto;

FIG. 12 is a schematic flow chart of the processing and execution steps occurring in the DPC;

FIG. 13 is a flow chart of emergency request and response processing in the DPC;

figure 14 is a flow diagram of the overall operation of the retail transaction authorization process conducted in the DPC;

figure 15 is a flow diagram of the overall operation of the remote transaction authorization process performed in the DPC;

FIG. 16 is a flow chart of the overall operation of the ATM account access process performed in the DPC;

figure 17 is a flow diagram of the overall operation of the distributor batch modification process performed in the DPC;

FIG. 18 is a flowchart of the overall operation of the secure fax submission and electronic document submission process performed in the DPC;

FIG. 19 is a flowchart showing the overall operation of the secure fax data and electronic document data processing performed in the DPC;

FIG. 20A is a representative schematic diagram of an electronic signature request package;

FIG. 20B is a representative schematic diagram of an electronic signature response package;

FIG. 20C is a representative schematic diagram of an electronic signature verification request package;

FIG. 20D is a representative schematic diagram of an electronic signature verification response package;

fig. 21 is a flowchart of the overall operation of the electronic signature processing performed in the DPC;

fig. 22 is a flowchart of the overall operation of the electronic signature verification process performed in the DPC.

As described above, the primary object of the present invention is a non-rewriteable, secure, reliable, secure, and harmonizable apparatus and method for identifying individuals for conducting commercial or non-financial transactions that can accommodate a large number of users. The essence of the invention is that the customer has the ability to conduct these transactions without the use of any tokens, credit cards, badges or identification cards (including driver's licenses). To be practical, it is important that the system operate at the speed required to complete financial transactions, such as credit card purchases from multiple banks and multiple credit card accounts and ATM services. The system must also be secure, both within the computer system that performs the personal identification and authorization transaction and during data transfer between the computer system in communication with the computer system and the remote station, the customer's personal records and their biometric data must be kept secret and secure. In addition, the system must be reliable and errors in identification and authorization must not prevent the system from operating or make the system cumbersome to use. Since biometric data is intended only to be used to identify individuals, the system must also have security measures to either reduce the level of access (even by authorized users) or notify authorized parties in an emergency. In addition, the system must be able to handle a large number of users, be suitable for storing and transferring large amounts of data (e.g., biometric information), and accommodate the processing speeds of financial transactions in today's society.

Turning now to the drawings. Fig. 1 shows the general structure and the individual components of the invention. Essentially, a Data Processing Center (DPC)1 is connected to a variety of terminals 2 via a variety of communication means 3, which may be one of several types. The DPC is also connected to and communicates with a separate computer network 4. The DPC has a plurality of databases and software execution modules as shown in fig. 2. In the preferred embodiment of the present invention, the database is backed up or "mirrored" for security reasons. The firewall computer 5 is responsible for preventing electronic intrusion into the system and the gateway machine 6 is responsible for executing all requests from the user, including adding, deleting or modifying all databases. The gateway machine is also responsible for decrypting and unpacking data from the terminal by using the MACM module 7, the MDM module 8 and the SNM module 9. The PGL module 10 and the IML module 11 are used to find the correct personal identification code and biometric data sample basket (basket). Fig. 3 shows a terminal and biometric data input device 12. The input device 12 has a biometric data scanner 13, a data input device (such as a numeric keypad or PIN pad) 14 and a display panel 15. Although a fingerprint scanner will be used as an example below, the biometric data scanner may be any of a fingerprint scanner, a voice recognition device, a palm print scanner, a retina scanner, or the like. The biometric data input device is further provided with a calculation module 16, a device driver and an erasable or non-erasable storage module. The biometric data input device preferably communicates with the terminal via a serial port 17. Terminal 2 communicates with the DPC via a conventional modem 18 by means of request packets 19 and response packets 20 using an interconnection means shown in figure 1, such as a cable network, cellular telephone network, internet, ATM network or x.25. Fig. 4 shows a representative schematic of the request package 19 and its generation by the biometric data input device software. Fig. 5 and 6 show representative schematic diagrams of request and reply packets with optional and mandatory data segments, and further show which portions of these packets are encrypted and which packets are sealed. Figure 7 is a block diagram of the overall process of encrypting and sealing data, showing the use of DUKPT key data 20 to encrypt data before adding additional data, before sealing the request packet with a message authentication code key (MAC) 21. Fig. 8 and 9 illustrate decryption and encryption processes performed in the DPC. The block diagrams in figures 12 to 19, and 21 to 22 show some examples selected from the execution steps of the DPC.

The drawings, schematic diagrams, flowcharts and specific contents of the invention, such as hardware parts, software parts, execution modules, databases, connection devices and data transmitted therebetween, are described in detail below.

1.1. Biological characteristic data input device (BIA)

1.1.1. Introduction to the design reside in

The BIA is a combination of hardware and software that functions to collect biometric data input, encode it and encrypt it for personal identification. All operations of the BIA are instructed by an external control mechanism, called a terminal, which sends commands over the serial line of the BIA and receives the results.

There are 4 standard forms of BIA hardware: standard type, wireless type, integrated telephone/cable television (CATV)/fax type, and ATM type. Each variant of BIA hardware addresses a particular need in the market, and the privacy level of each variant is different due to the different structure.

The BIA software has 7 standard forms: personal computer (or PC) type, retailer type, ATM type, registry type, in house type, distributor type, and integrated remote type. Each software load provides a different, dedicated set of commands. For example, the registration software may be loaded without accepting a request to form a retail transaction message. Likewise, the retail software command set cannot send out a personal registration message. To provide another layer of protection, the DPC knows what software packages are loaded in each BIA. A BIA, when attempting to send a message that normally cannot be sent, is rejected and is considered a major security violation.

The ability of the present invention to authenticate and resist commercial fraud is based on the following facts: i.e., the external interface of the BIA is strictly restricted, the structure of the BIA also makes it exceptionally difficult to tamper with its content, each BIA having a unique encryption code known only to the DPC, each BIA being allowed to perform only operations limited within its specified functions. Each biometric data input device has a hardware identification code pre-stored in the DPC, which enables the biometric data input device to be uniquely identified by the DPC each subsequent transmission of biometric information to the input device.

The BIA in the present invention is constructed on the assumption that: i.e. the control terminal is the source of fraud and fraud. Terminals can range from software applications running on personal computers to specialized hardware/software systems developed for each specialized purpose, such as a commercial retail outlet. Regardless of its specific type, none of the BIAs is capable of displaying unencrypted biometric data. Those BIAs that do not have a display device (e.g. LCD, LED or quartz screen) must reveal some selected information (e.g. a personal specific code) to the terminal for display, and therefore this particular terminal-BIA combination is considered to be not secure enough.

Depending on the kind of work to be done, various types of BIAs are either partly or wholly integrated with the terminal. The partially integrated devices are physically separated from the terminal and they include a wireless type BIA and a standard BIA for commercial retail outlets. The fully integrated device is housed in a mechanical housing that is self-contained by the terminal (e.g., ATM or telephone).

None of the BIAs reveals any confidential encryption code to any external source.

1.1.2.BIA type

The specific BIA hardware type has a number of different structures. They will be briefly described below.

BIA

The standard version has a computing module (i.e., a multi-chip module), a biometric data scanner (i.e., a single fingerprint scanner), a display device (i.e., an LCD screen), a communication port (i.e., a serial port), a data entry device (i.e., a manual data entry keyboard or PIC keyboard) housed in the crash resistant housing, and an electronic detection device (i.e., an RF shield).

BIA/wireless type

Standard type, but a broad spectrum wireless communication module using an external antenna replaces the serial line. For use in restaurants and the like.

BIA/ATM type

A heavy duty scanner, a serial port and a multi-chip module are provided. But since the LCD is part of the terminal and not the BIA, it must provide the terminal with a dedicated code, thus degrading security. Used in ATMs.

BIA/cable TV type

A light duty scanner is provided, and the others are similar to ATM type. For use in telephones, CATV remote and facsimile machines. The worst safety. The reason is that the LCD and PIC keypads are part of the terminal and not part of the BIA, and the low price feature present in this market.

1.1.3.BIA Command set message

Each BIA software command set provides a different set of operations. They will be briefly described below.

BIA/ATM

Account access

BIA/cable TV

Remote transaction authorization

BIA/fax

Secure facsimile submission

Secure facsimile data

Secure facsimile tracking

Secure fax retrieval

Secure fax rejection

Secure facsimile document

Secure facsimile contract acceptance

Secure facsimile contract denial

Electronic document retrieval

BIA/interior

User identification

BIA/publisher

Publisher batch processing

BIA/personal computer

Electronic document submission

Electronic document data

Electronic file tracking

Electronic document retrieval

Electronic document rejection

Electronic document file

Electronic document retrieval

Electronic signature submission

Electronic signature verification

Remote transaction authorization

Network credentials

Secure connection

BIA/registration

Personal identification

Biometric data enrollment

BIA/retail

Transaction authorization

1.1.4.BIA hardware: standard type

The standard BIA hardware is a multi-chip module combined with a single line scanner, LCD screen, serial port and PIC keypad encased in a hard bump-proof housing. The housing provides crash avoidance and radio frequency shielding for the components therein.

These components are combined into a multi-chip module called a "BIA multi-chip module" (a process known in the computing arts that wraps multiple processors within a physical core) that is constructed to protect the communication path between devices from easy eavesdropping.

Serial processor

PIC keyboard processor

LCD screen processor

CCD scanner A/D processor

High speed DSP processor with flash ROM and mask ROM

General purpose microprocessor

Standard RAM

·EEPROM

The following software packages and data are stored in the mask ROM. Mask ROMs are less expensive than other types of read-only memories, but are more easily reverse engineered and do not allow for electrical erasability. For this purpose, we store here only the unimportant, commonly available codes (mask ROM is well known in the art of computing).

MAC calculation library

DUKPT Key management library

DES encryption library (with CBC)

Base-64 (8-bit to printable ASCII) conversion library

Public key encryption vault

Embedded operating System

Serial line device driver

LCD device driver

PIC keyboard device driver

Scanner device driver

Unique hardware identification code

Multiple language program profiles

The following standard data and software packets are stored in flash ROM. Flash ROM is expensive but difficult to reverse engineer and most importantly electrically erasable. All the more important data is stored here. Flash ROM is used in an attempt to increase the difficulty of copying a BIA (flash ROM is a well known technique in the computing arts).

Unique DUKPT future Key Table

Unique 112 bit MAC Key

DSP biological characteristic data quality determination algorithm

DSP biological characteristic data coding algorithm

Random number generator algorithm

Command function Table

The information serial number, which increases with each time the BIA transmits information, is transmitted from the BIA and stored in the EEPROM. EEPROMs can be erased many times and are also non-volatile, the contents of which remain valid during power interruptions (EEPROMs are well known in the art).

The following data is stored in RAM, which is temporary in nature and whose contents are lost upon power loss.

Encoded biometric data register

PIC register

Account index code register

Job category index code register

Magnitude registers

File name register

PIC block key

Message key

The response key

Sharing session keys

Private session keys

8 general purpose registers

Stack and heap space

Each multichip module contains a "write-once" memory location that is irreversibly set after flash ROM initialization. When attempting to download software into the flash ROM, the memory location is first checked. If the location is already set, the BIA rejects the load. Thus, important software and data keys can only be downloaded to the device once (at the time of manufacture).

When a transaction is cancelled, all registers and keys are obviously cleared. The register will also be cleared once the transaction is completed. Upon execution of the "form message" command, the biometric data register, PIC register, account index register, and any encryption keys not needed in subsequent processing are cleared.

It is important that software does not preserve a backup of registers or keys in stack variables (as is well known in the art).

The following associated hardware components constitute standard BIA hardware modules:

BIA Multi-chip Module

CCD single-line scanner

Capacitance detection plate (known in the art)

Luminous PIC keyboard

2 rows and 40 columns LCD Screen

RF shielding

Anti-collision case

Serial ligation (Up to 57.6kb)

Breech detection hardware (known in the art)

Optional thermal charging device attached to the multichip module (known in the art)

All temporary storage, internal hardware and software used to calculate these values are kept secret, which means that they will block any attempt to determine their current values or their functional meaning. This is very important for the security of the invention, since it is so important that "eavesdropping" on the BIA, more specifically collecting the biometric data-PIC block used in the spoofing device, becomes very difficult and almost impossible.

In a practical device, the multi-chip module and the components are physically connected to each other without exposing the bonding wires.

The cabinet protecting the electronic components of the BIA is welded to the end of manufacture and in any case cannot be opened without major damage to the casing. When a shell open (or damage) is detected, the BIA performs an emergency electrical clear of any or all keys and subsequently all software libraries residing in the flash ROM. The specific method of cross-tube (breech) detection is confidential and patented.

To protect its contents, the enclosure also shields the internal operations from detection by the rf signal detector.

The BIA is also of an ultra-secure type in which the fork detection method is associated with a mechanism that can physically destroy the multi-chip module and the detection method itself.

1.1.5.BIA type: wireless type

The wireless type BIA hardware is structurally identical to the standard type except that an external antenna is used instead of an external serial port to send out a broad-spectrum wireless communication module.

This type is designed for use in restaurants to authorize transactions for the convenience of customers.

In the following description, items to be added to the standard type are marked with a "+" sign, and items to be subtracted from the standard type are marked with a "-" sign.

Multi-chip module:

-a file name register

-sharing a session key

-a private session key

-message key

The components:

-serial port

+ external antenna

+ broad spectrum wireless serial module (known in the art)

1.1.6.BIA hardware: ATM type

The ATM type BIA hardware is a multi-chip module combined with a heavy duty single grain scanner and a serial port. The components are enclosed in a crash-proof enclosure that provides crash-proof and radio-frequency shielding functions for the various components.

This type is designed as a retrofit to ATM machines. The scanner board is thus a heavy duty sensor board, the overall structure of which uses the screen and keyboard of the ATM itself.

In the following description, items to be added to the standard type are marked with a "+" sign, and items to be subtracted from the standard type are marked with a "-" sign.

Multi-chip module:

-a magnitude register

-a file name register

-sharing a session key

-a private session key

-message key

The components:

-luminous PIC keyboard

-2 rows and 40 columns of LCD screen

Notably, since ATMs do not have LCD screens or PIC keyboards, drivers for these devices need not be provided in the mask ROM.

1.1.7.BIA hardware: telephone/cable television type

The phone/cable type BIA hardware is a multi-chip module combined with a single line scanner and serial port. The module is physically attached to the scanner and is integrally encapsulated in plastic, making it more difficult to bump against it. A certain amount of radio frequency shielding can also be provided for the components therein.

This type is designed to be integrated with telephones, television remote controls and fax machines. In this way, the existing keyboard, LCD screen or television screen can be used to input or display numerical values. It may also utilize the communication device of the master terminal. For example, fax machines may use a built-in fax modem, and the television remote may use a CATV cable network.

Such hardware is not sufficiently secure (as compared to other types) because it is desirable that these devices be as low cost as possible, lightweight, and easily integrated with existing low cost devices.

Of course, the type of security feature that has a more complete chassis is also possible and should be encouraged.

In the following description, items to be added to the standard type are marked with a "+" sign, and items to be subtracted from the standard type are marked with a "-" sign.

Multi-chip module:

-a file name register

-sharing a session key

-a private session key

-message key

The components:

-luminous PIC keyboard

-2 rows and 40 columns of LCD screen

BIA software

1.2.1.BIA software Command interface

The external interface of the BIA is similar to a standard modem, and commands are sent from a control terminal using an external serial line. When a command is completed, a response code is sent from the BIA to the terminal.

Each BIA software supports a different set of operations after loading. For example, a retail software may only support transaction authorization after loading, while an enrollment software may support personal identification and biometric data enrollment after loading.

All BIA data fields are in printable ASCII code, and the fields are separated by field separator (or fs) controller, and the records are separated by new lines. The encrypted field is a binary code that has been converted to 64-bit ASCII code using a base-64 translation table (well known in the art).

Some commands are not available in some configurations. For example, the ATM BIA cannot execute the "Get PIC command because no PIC keyboard is connected to it. In contrast, ATM BIA supports "Set PIC commands.

Response code:

and (4) timeout:

the time allocated to the command has expired. A message indicating this will be displayed on the LCD screen (if any). When the time for a given command expires, the BIA operates as if the cancel button were pressed.

And (3) cancelling:

the "cancel" button has been pressed and the entire operation is cancelled. This also has the side effect of clearing all the collected information. A message indicating this will be displayed on the LCD screen (if any).

And (3) normal:

the command is successfully executed.

And others:

each command may have a specific other response code that is valid only for it. These response codes typically have text accompanying the code and are displayed on the LCD screen (if any).

Message:

it indicates that the command is in progress, but the BIA wishes to send the message to the terminal in the form of a temporary result message. This result is also displayed on the LCD (if any). This function is used for prompt or status messages.

Command:

in the argument tables of the following commands, < > are enclosed independent arguments, [ ] are enclosed optional arguments, | indicate that a given argument may be one of a number of choices given.

Setting language < language-name >

The command is selected from a plurality of different languages encoded into the BIA for prompting the user for input.

Obtaining biometric data < time > [ major/minor ]

The command requests the BIA to activate its scanner, take a biometric message input from the individual, and store in the encoded biometric data register.

First, a message "please press a finger on the light emitting panel" will be displayed on the LCD screen and returned to the terminal. The scanner board is illuminated prompting the user to enter his biometric data.

A value of < time > of zero means that there is no limit to the scan input time of the biometric information.

In scan mode, a fingerprint scan is performed and an initial analysis is performed using a fingerprint quality algorithm. If the scan is not good enough, the BIA will also perform a new scan until the number of seconds in < time > has expired. When the fingerprint snapshot is analyzed over time, a message about the problem detected by the fingerprint quality software is also posted on the LCD screen and sent to the terminal. If no fingerprint of suitable quality is present, the BIA returns a time-out error code and displays a message on the LCD indicating this.

Once the fingerprint quality algorithm has determined the quality of the fingerprint scan, the fingerprint encoding algorithm takes the minutiae of the fingerprint. Only a subset of the details is randomly selected but enough information is guaranteed to be identified. These details are then randomly ordered and placed in a register encoding the biometric data. The BIA then responds with a successful result code.

If [ major/minor ] is specified (only possible in the biometric data enrollment command set), then the full details will be selected, not just the smaller subset. Likewise, the primary/secondary biometric data selection command ends with placing the encoded biometric data into the appropriate register.

The light indicating the progress of the scan will go off once the scan is over, whether the operation is successful or not.

It is important to note that the same biometric data input will produce different codes, which makes any attempt to find the encrypted code in the captured BIA more difficult. This is achieved by selecting a random subset and randomly ordering the encoded biometric data.

PIC < time >

The command requests the BIA to fill the PIC register by reading the keyboard.

First, on the LCD screen, the user will display "please enter your PIC, then press the < enter > key" and send it to the terminal, the appropriate keypad lights will be lit and keypad scanning will begin.

The scan ends when the number of seconds specified in the < time > item is exhausted, or when the individual taps the "enter" key.

It should be noted that the digits of the PIC are not displayed on the LCD screen, but rather an asterisk "is displayed for each particular type of digit, giving the user feedback. When the "amend" key is pressed, the last digit entered is deleted, allowing the user to modify the entry error.

When the PIC input is finished, the keyboard lamp is turned off.

If successful, the command will return a normal code.

Get Account index code < time >

First, a message "please enter your account index code now" will be displayed on the LCD display screen, and then press < enter > "and sent to the terminal. This will prompt the individual to enter his account index code. When each key is pressed, its value appears on the LCD panel. Pressing the correction button clears these values. When the "enter" key is pressed, the account index code register will be set.

The appropriate keyboard keys are illuminated during the input and the keyboard light is turned off when the input is complete.

If successful, the command will return an acknowledgement code.

Time of job index code >

First, a message "please input your job title index code now", then press < enter > "is displayed on the LCD display screen and sent to the terminal. This will prompt the user to enter his job title index code. When each key is pressed, its value appears on the LCD panel. Pressing the correction button clears one of the values. When the "enter" key is pressed, the job title index code register will be set.

The appropriate keyboard keys are illuminated during the input and the keyboard light is turned off when the input is complete.

If successful, the command will return a normal code.

Confirm magnitude < magnitude > < time >

The confirm authentication magnitude command sends a message "magnitude < magnitude > correct? ", and displays it on the LCD screen. If the person confirms the magnitude by hitting the "yes (or enter)" key, the magnitude register is set to the < magnitude >. The < magnitude > must be a valid number, should not carry a control symbol or space, etc. When prompted, the "yes", "no" and "clear" keys will light up. Once the prompt is over, all lights will go out.

If the user enters "no," the transaction is cancelled.

Input magnitude < time >

The input magnitude command issues a message of "input magnitude" to the terminal and displays it on the LCD screen. The individual must then enter the amount of money himself. Each character entered will be displayed on the LCD screen. All appropriate buttons will be illuminated. If the enter key is struck, the magnitude register is set on the value input from the keyboard. Once the input is complete, all lights will go out.

Confirm File < name > < time >

The confirm file command issues to the terminal "file < name > correct? "and displays it on the LCD screen. If the individual confirms the file by hitting the "yes (or enter)" key, the file name register will be set to < name >. The < name > must be printable ASCII code, no control symbols, and no space before and after. When prompted, the "yes", "no" and "clear" keys will light up. Once the prompt is over, all lights will go out.

If the user enters "no," the transaction is cancelled.

Assignment register < register > < text >

The assign register command sets the specified general register < register > to have the value of < text >. The command is used to set a merchant code, product information, etc.

Retrieving a message key

The get message key command causes the BIA to generate a 56-bit random key which the control hardware will use to encrypt any message body that the control device wishes to add to the message. The BIA will return the generated key in hexadecimal format (well known in the art). The message key is then added to the biometric data-PIC block.

Format message < type ═ identify | transaction | account access … >

The format message command instructs the BIA to output a message containing all the information it collects. It also checks to ensure that all registers appropriate for that particular message < type > have been set. If not all required registers are set, the BIA returns an error. The particular command set software will determine which messages can be formed by the BIA mode and others will be rejected.

Each message includes a transmission code consisting of a unique hardware identification code of the BIA and an incremental sequence number. The transport code causes the DPC to identify the BIA in transit and detect resubmit attacks.

The BIA uses the BUKPT key management system to select biometric data from a future key table-the PIC block encrypts a 56 bit DES key. This key is then used to encrypt the biometric data-PIC block using a Cipher Block Chaining (CBC). In addition, a response DES key is also randomly generated and used by the DPC to encrypt the portion of the response to be encrypted.

Note that: it is very important to separate the response key from the biometric data-PIC block key, since each encryption key must only be used within its own responsibility. In this way, if one wants to decipher the key encoding the private code, the biometric data-PIC is not made public.

The biometric data-PIC block consists of the following fields:

300 byte authorized biometric data

4-12 bit digital PIC

56 bit response key

[ optional 56-bit message Key ]

Note that the message key only appears if the control terminal has requested it for a message. Until the control terminal encrypts any message body attached to the transaction authorization request with the message key.

Once all encryption is complete, the BIA outputs the appropriate request message body (e.g., transaction authorization request message), terminated and protected with a Message Authentication Code (MAC).

The MAC field is computed using the secure 112-bit DES MAC key of BIA and covers all message fields from the first to the last. The MAC ensures that the DPC, which has no change in the message, effectively seals the message while still having the control terminal check the plaintext field.

When the format message command is issued, the BIA issues a message to the terminal that i am talking to the DPC center and displays it on the LCD screen, indicating that work is being performed according to the request.

After the command is completed, the command returns to normal, except for returning the entire formed message.

Indicating response < encrypted response > < time >

Indicating that the response command instructs the BIA to decrypt the private code from the system using its current response key.

After decryption, a chime occurs and the unique code is displayed on the LCD screen for < time > seconds. Soon, the command transmits the decrypted special code to the control terminal.

Confirmation-dedicated < encryption confirmation > < time >

This command is employed by the terminal during the secure network communication session, requesting the person to acknowledge the message from the external source. The message is encrypted and divided into two parts: request (challenge) and response.

Upon receiving the confirmation dedicated command, the BIA displays on the LCD screen the request message text as "normal < request >? ", but not to the terminal. When the individual has confirmed the request, the BIA encrypts the response using the private session key and then returns it to the terminal together with the normal response code. If the individual does not confirm the request, the BIA returns an "invalid" response code and "transaction cancelled by your request," which is also displayed on the LCD screen.

Note that the terminal is never made to see the plaintext of the request or response.

Reduction of position

The reset command instructs the BIA to remove all temporary registers, the LCD screen, all temporary key registers, and to turn off all keyboard lights that may be on.

Set PIC < value >

This command assigns the PIC register of the BIA to the value < value >

Note that having an unsecure device provide PIC is a potential security problem because unsecure devices are more susceptible to eavesdropping or replacement.

Setting Account index code < value >

This command assigns the account index code register of the BIA to < value >.

Note that having an unsecure device provide the account index code is a potential security problem because unsecure devices are more susceptible to eavesdropping or replacement.

Setting job index code M < value >

This command assigns a < value > to the job index code register of the BIA.

Note that having an unsecure device provide job index codes is a potential security problem because unsecure devices are more susceptible to eavesdropping or replacement.

Set magnitude < value >

The command specifies a value < to the magnitude register of the BIA >

Encryption response < encryption response message >

The encrypted response command instructs the BIA to decrypt the encrypted portion of the response message with its current response key. Once decrypted the response is returned to the control means, for example for display on an LED screen of the ATM terminal.

Note that the ability to provide this encryption is a security issue, as soon as the plaintext leaves the BIA, the terminal has the ability to handle it at will.

1.2.2.BIA software: support library

The BIA software is supported by several different software libraries. Some of these are standard, commonly available libraries, but some have special requirements in terms of the content of the BIA.

1.2.2.1. Random number generator

Since BIA often selects a random DES key for message body and message response encryption, it is important that the selected key be unpredictable. If the random number generator is based on time of day, or on some other externally predictable mechanism, the encryption key will be easily guessed by an adversary who happens to know the algorithm. To ensure the security of the encryption technique used by the BIA, it is assumed that both the random number generator algorithm and the encryption algorithm are well known.

A standard random number algorithm for generating DES keys is defined in ANSI X9.17, appendix C (well known in the art).

1.2.2.2.DSP biological characteristic data coding algorithm

The biometric data encoding algorithm is a unique algorithm for determining details formed by the ends of textures and bifurcations on a human fingertip. A complete detail table is stored in the DPC as a reference, and the algorithm requires only a part of the table when comparing the identification object with the registered person.

During the biometric data enrollment and identification, the encoding algorithm ensures that sufficient details are found before the biometric input step is finished.

1.2.2.3 operating System and device drivers

The BIA is a real-time computing environment that requires real-time embedded operating systems to run. The operating system is responsible for handling interrupts from the device and scheduling tasks.

Each device driver is responsible for interfacing between the operating system and specific hardware, such as a PIC keyboard device driver or a CCD scanner device driver. The hardware is the source of events such as "key of PIC keyboard pressed" or "CCD scanner scan completed". The device driver handles these interrupts, interrupt events, and then takes action on the events.

DES encryption library

There are a number of DES tools available publicly. The DES tool provides secret key-based encryption from plaintext to ciphertext and decryption from ciphertext to plaintext using a 56-bit secret key.

1.2.2.5 public Key encryption Bank

Public Key cryptography support libraries are available from Public Key Partners, which are the holders of RSA Public Key patents known in the art. Public key cryptosystems are asymmetric encryption systems that communicate without the need for extensive exchange of secret keys. To use a public key encryption system, a DES key is encrypted with a public key, and then the DES key is used to encrypt a message. The BIA provides secure exchange of secret keys using a public key cryptosystem.

Unfortunately, public key systems are not well tested compared to secret key systems, and therefore overall privacy is low in such algorithms. Thus, the present invention utilizes public key cryptography for communication security and short-lived credential exchange, rather than for long-term storage of secrets. Both the end-user person and the bank are identified with the DPC to establish the network credentials. The network credentials include an identification of the individual end user and the contents of the connection (i.e., the TCP/IP source and destination ports).

1.2.2.6.DUKPT Key management library

If an initial key and a message sequence number are given, a management library of unique keys (DUKPT) derived for each transaction is used to establish future DES keys. The future key is stored in a future key table. Once employed, a given key is removed from the table. The initial key is used only to generate an initial future key table. The BIA does not store the initial key.

DUKPT is used to establish a key authority that provides a different DES key for each transaction without leaving traces of the initial key behind. This means that even if a given future key table is successfully captured and resolved, the previously sent message cannot be compromised, which is an important goal when the useful life of the transmitted message is several decades. DUKPT is specified in detail in ANSI X9.24 (known in the art).

DUKPTs were originally developed to support PIC encryption mechanisms for debit card transactions. In this environment, it is important to protect all transactions. Assume that the criminal records the encrypted transaction over a 6 month period and then captures and successfully extracts the encryption code from the PIC keyboard. The criminal can then make a new counterfeit debit card for each message delivered during that 6 months. However, in the case of DUKPT, theft and resolution of the criminal will not cause him to decrypt the previous message (although the new message can still be decrypted if the criminal were to replace the PIC keyboard after resolution).

In the biometric-PIC case, even a hard time period for criminals, even if the message is decrypted, it is much more difficult to convert the digital biometric-PIC to an actual fingerprint than to convert the account-PIC to a plastic card, which is one of the great advantages of a non-coupon system.

In addition, if the criminal is able to decrypt, he can decrypt, which causes him to electronically submit the biometric-PIC to the system to authorize a fraudulent transaction. Although this is very difficult, it is desirable to limit the means available to criminals as much as possible, thus making use of DUKPT.

BIA software Command set

1.3.1.BIA software: retail command set

The BIA/retail software interface outputs an interface that enables the specific retail point-of-sale terminal to interact with the system.

The BIA/retail interface is used to cause the terminal to operate as follows.

Transaction authorization

To do this, the BIA/retail provides the following command set:

setting language < language-name >

Obtaining biometric data < time >

PIC < time >

Assign register < value >

Get Account index code < time >

Confirmation of magnitude < amount > < time >

Input magnitude < time >

Form message < type >

Shows response < encrypted response > < time >

Reduction of position

1.3.2.BIA software: CATV (Integrated remote terminal) command set

The BIA/CATV software interface outputs a command set to integrate the terminal with the telephone/CATV BIA for interaction with the system. The following operations are supported.

Remote transaction authorization

To do this, the BIA/CATV provides the following command set:

obtaining biometric data < time >

Set PIC < text >

Assignment register < register > < text >

Setting Account index code < text >

Form message < type >

Decryption response < encrypted response message >

Reduction of position

1.3.3.BIA software: centralized FAX command set

The BIA/Fax software interface outputs a command set to integrate the terminal with the Fax BIA to interact with the system. The following operations are supported:

Secure facsimile submission

Secure fax data

Secure facsimile tracking

Secure fax retrieval

Secure fax rejection

Secure facsimile document

Secure fax contract acceptance

Secure fax contract denial

Electronic document file retrieval

To do these operations, BIA/Fax provides the following command set:

obtaining biometric data < time >

Set PIC < text >

Set job index code < text >

Assign register < register > < value >

Retrieving a message key

Form message < type >

Decryption response < encrypted response message >

Reduction of position

1.3.4.BIA software: registration command set

The BIA/Reg software interface outputs an interface that allows a general purpose computer to interact with the system to identify and enroll individuals. The following operations are supported:

personal identification

Biometric data enrollment

To support these operations, BIA/Reg provides the following set of instructions:

setting language < language-name >

Obtaining biometric data < time > [ primary/secondary ]

PIC < time >

Assignment register < register > < text >

Retrieving a message key

Form message < type >

Shows response < encrypted response > < time >

Reduction of position

1.3.5.BIA software: PC Command set

The BIA/PC software interface outputs a set of commands that cause the general purpose computer to send, receive or sign electronic documents, conduct transactions over the network, and provide biometric data derived credentials to sites on the network. The following operations are supported:

Electronic document submission

Electronic document data

Electronic file tracking

Electronic document retrieval

Electronic document rejection

Electronic document file

Electronic document file retrieval

Electronic signature submission

Electronic signature checking

Remote transaction authorization

Network credentials

Secure connection

To support these operations, the BIA/PC provides the following command sets:

setting language < language-name >

Obtaining biometric data < time >

PIC < time >

Get Account index code < time >

Confirmation of magnitude < amount > < time >

Input magnitude < time >

Confirm File < name > < time >

Assignment register < register > < text >

Retrieving a message key

Form message < type >

Shows response < encrypted response > < time >

Confirmation dedicated < confirmation of encryption > < time >

Reduction of position

1.3.6.BIA software: set of publisher commands

The BIA/Iss command interface outputs an interface that enables a general purpose computer to interact with the system to authenticate and submit batch modification requests. The following operations are supported.

Publisher batch processing

To do this, the BIA/Iss provides the following command set:

setting language < language-name >

Obtaining biometric data < time > [ primary/secondary ]

PIC < time >

Assign register < register > < value >

Retrieving a message key

Form message < type >

Shows response < encrypted response > < time >

Reduction of position

1.3.7.BIA software: internal command set

BIA/Int outputs a set of commands that enable a general purpose computer to interact with the system to identify individuals. The following operations are supported:

personal identification

To do this, BIA/Int provides the following command set:

setting language < language-name >

Obtaining biometric data < time >

PIC < time >

Assign register < register > < value >

Retrieving a message key

Form message < type >

Shows response < encrypted response > < time >

Reduction of position

1.3.8.BIA software: ATM command set

The BIA/ATM software interface outputs a set of commands that cause the ATM to identify the individual. The following operations are supported:

account access

To do this, the BIA/ATM proposes the following command set:

obtaining biometric data < time >

Set PIC < text >

Setting Account index code < text >

Assign register < register > < value >

Form message < type >

Decryption response < encrypted response message >

Reduction of position

1.4. Terminal device

1.4.1. Introduction to

A terminal is a device that controls the BIA and is connected to the DPC via a modem, an x.25 connection or an internet connection (methods well known in the art). Terminals come in different shapes and sizes and require different versions of the BIA for their work. Any electronic device that issues commands to the biometric input device and receives results therefrom may be a terminal.

Some terminals are application programs running on a general-purpose microcomputer, while others are a combination of dedicated hardware and software.

Although the terminal is crucial for the functionality of the whole system, the system itself cannot trust the terminal anyway. Whatever information the terminal provides to the system, the system will always authenticate it in some way, either by being presented to the individual for confirmation, or by cross-checking with other previously registered information.

Although the terminal can read out some parts of the BIA message in order to verify that the data has been properly processed by the BIA, the terminal cannot read out biometric identification information including biometric data, PIC, encryption key or account index code.

The specific BIA outputs certain security functions to the terminal, such as PIC input and dedicated code display. Thus, such devices are less secure than fully self-contained devices and therefore have a lower degree of security.

There are many different terminal types, each connected to a specific form of BIA. Each terminal will be briefly described below:

ATM (automatic teller machine)

The BIA/ATM integrated with the ATM software payload provides biometric-PIC access to ATM cash dispensers.

BRT (biological characteristic register terminal)

A standard BIA loaded with registration software connected to a microcomputer provides the bank with the ability to register new individuals into the system, along with their financial asset accounts and other personal information.

CET (verified Email terminal)

A standard BIA with PC software connected to a microcomputer provides the individual with the ability to send, receive, store, reject and track verified Email messages.

CPT (Cable TV POS terminal)

The BIA/CATV, which is equipped with CATV software, connected to CATV broadband provides individuals with biometric-Television (TV) remote ends with the ability to authorize TV mall shopping.

CST (customer service terminal)

A standard BIA with internal software connected to a microcomputer system authorizes employees to create database requests for customer service purposes.

EST (electronic signature terminal)

A standard BIA, with personal computer software, connected to a microcomputer, provides the individual with the ability to create and verify an electronic signature on a document.

IPT (Internet point of sale terminal)

A standard BIA, with personal computer software, connected to a microcomputer, provides an individual the ability to purchase products from a merchant connected to the internet via the internet.

IT (publisher terminal)

A standard BIA, equipped with issuer software, connected to a microcomputer provides the bank with the ability to batch modify the asset accounts of the DPC.

ITT (Internet cashier terminal)

A standard BIA with personal computer software connected to a microcomputer connected to the internet provides individuals with the ability to conduct transactions with their favorite internet bank.

PPT (telephone point of sale terminal)

The BIA/CATV, which is integrated with the phone, and which is loaded with CATV software, provides the ability for individuals to authorize transactions in the phone.

RPT (retail sales terminal)

A standard BIA equipped with retail software, connected to the X25 network or using a modem, allows an individual to shop at a store with transaction authorization.

SFT (safety fax terminal)

The BIA/catv, which is integrated with the fax machine and is loaded with fax software, provides the individual with the ability to send, receive, reject, archive, and track secure fax messages.

1.4.2. A terminal: retail point of sale terminal

1.4.2.1. Purpose(s) to

The purpose of the RPT is to eliminate the need for a person to use cash, checks, debit cards, or credit cards while shopping at a store.

The RPT uses BIA/retail to authorize financial transactions from individuals to merchants. In addition to being used to receive biometric data-PIC authorization, the RPT provides standard debit and credit card scanning functionality.

Note that only transactions related to biometric data are detailed here. It is assumed that the RPT also consists of a standard credit and debit magnetic stripe card reader and optionally a smart card reader.

1.4.2.2. Structure of the device

Each RPT is connected to the DPC via a modem, an x.25 network connection, an ISDN connection, or similar mechanism. The RPT may also be connected to other devices, such as an electronic cash register, from which the transaction amount and merchant code may be obtained.

The RPT includes:

BIA/retail

Cheap microprocessor

9.6kb Modem/X.25 network interface hardware

Merchant identification code number in non-volatile RAM

DTC serial port for connection of BIA

Magnetic stripe card reader (known in the art)

ECR (electronic cash register) interface

An optional smart card reader (known in the art)

1.4.2.3. Identification

Two entities need to be identified in order for the DPC to actively respond to the BIA transaction authorization request: individuals and merchants

The individual is identified with biometric data-PIC and the customer is identified with DPC, which cross-checks the merchant code contained in the VAD record of the BIA and the merchant code added to the transaction request by the RPT.

1.4.2.4 operation

First, the merchant enters the transaction value into their electronic cash register. The individual then enters his biometric data-PIC, his account index code, and then confirms his magnitude. The RPT then adds the product information and merchant code to the BIA, instructs the BIA to construct a transaction, and then sends the transaction to the DPC via its network connection (modem, x.25, etc.).

When the DPC receives this message, it validates the biometric data-PIC, takes the account number with the index code, and cross checks the merchant code in the message with the registered owner of the BIA. If everything has been checked, the DPC forms and sends out credit/debit transactions to exchange. The response from the credit/debit network is added to the private code to form a transaction response message, which the DPC then sends back to the RPT. The RPT checks the response to see if authorization was successful and then sends a response to the BIA which then displays the individual's unique code, terminating the transaction.

1.4.2.5 security

The encryption by BIA and MAC computation guarantees the security of messages between RPT and DPC. The MAC allows the RPT to see the unencrypted portion of the message, but the RPT cannot change it. Encryption prevents the encrypted portion of the message from being disclosed to the RPT.

Each retail BIA must register with the merchant. This helps to deter BIA theft. In addition, since the RPT adds the merchant code to each message, the replacement of the merchant's BIA with a different BIA is detected by a repeated check at the DPC.

1.4.3. A terminal: internet point-of-sale terminal

1.4.3.1. Purpose(s) to

The purpose of an internet point of sale (IPT) is to authorize a lending financial transaction from an individual at a computer to a merchant, both on the internet.

Note that the internet simply represents a general purpose network in which merchants, DPCs, and IPTs can all be interconnected in real time. Thus, this mechanism can work as any other general purpose network:

1.4.3.2 constitution

The IPT comprises the following steps:

·BIA/PC

micro-computer

Internet shopper software application

Internet (or other network) connectivity

1.4.3.3 identification

In addition to identifying an individual, IPTs must also identify a remote merchant as the counterparty of the transaction. The merchant must also identify DPC and IPT.

The internet shopper program stores the host name (or other form of internet name) of the merchant from which the purchase is made in order to verify the identity of the merchant. Since the merchant registers all its legitimate internet hostnames in the DPC, the DPC cross-checks the merchant code with which one of the hostnames the stored merchant code is under.

1.4.3.4 operations

First, the IPT is connected to a merchant using the internet. Once the connection is established, the IPT secures this connection by generating and then issuing a session key to the merchant. To ensure that the session key is protected from disclosure, it is encrypted using the merchant's public key using public key cryptography. When the merchant receives this encrypted session key, it decrypts it with its private key. This process is called secret key exchange via public key encryption to secure the connection.

Once connected, the IPT downloads the merchant code from the merchant along with price and product information. Once the individual is ready to purchase, he selects the goods he wishes to purchase. The individual then enters biometric data-PIC using the BIA/PC and IPT sends the merchant code, product identification information and quantity to the BIA instructing it to set up a remote transaction authorization request. The IPT then sends the request to the merchant over the secure channel.

The commercial tenant is connected with DPC through the same kind of security connection with IPT and commercial tenant, namely, a security dialogue key is sent by using public key encryption method. However, unlike IPT-merchant connections, the merchant-DPC session key is beneficial for the entire day, not just one connection.

The merchant connects to the DPC, secures the connection with the session key, and sends the transaction to the DPC for confirmation. The DPC validates the biometric data-PIC, cross-checks the merchant code contained in the request and the merchant code sent in the request as being under the host name, and then sends a transaction to the credit/debit network. Upon the credit/debit network response, the DPC builds a response message including the credit/debit authorization, the encrypted unique code, and the personal address and sends the message back to the merchant.

Once the merchant receives the response, it copies the individual's email address from the response, records the authorization code, and sends the response message to the IPT.

The IPT passes the response to the BIA, which decrypts the private code and displays it on the LCD screen, indicating that the DPC identified the person. IPT also shows that the transaction result is successful or failed.

1.4.3.5 security

Since the system generally assumes that an adversary on the network can break the network connection at any point, the parties must have secure communications in their real-time interaction. Not the disclosure of information, but the insertion or redirection of messages, is of major concern.

The entire public key encryption system relies on having a trusted source for the public key. These trusted sources are called certifying authorities, and we assume that such sources are available on the internet in the near future.

1.4.4. A terminal: terminal of international internet teller machine

1.4.4.1. Purpose(s) to

Internet Teller Terminals (ITT) are used to identify individuals for internet banking sessions. The DPC, bank computer systems, and individuals are all connected to the internet.

There are two main tasks. The first is to provide a secure communication channel from the ITT to internet banking. The second is to provide internet banking with a losslessly assayable identity document. Once both are completed, the ITT can provide a secure internet banking session. In addition, the requirement-response verification capability of the BIA is used to provide additional security for all high value and/or irregular transactions.

1.4.4.2. Form a

The ITT comprises:

BIA (Standard type PC)

Micro-computer

Internet cashier software application

Internet connection

The IIT receives the biometric identifier using a BIA/PC connected to a microcomputer as a personal Internet terminal.

1.4.4.3. Identification

Both the person and the bank are identified by the DPC to establish the network credentials. The network credentials include the personal identification and the scope of the connection (i.e., the TCP/IP source and destination ports).

The DPC identifies the bank by cross-checking the code that the bank sent to the ITT and the bank hostname that the ITT sent to the DPC.

1.4.4.4. Operation of

First, the ITT connects to the internet bank, ensuring that the bank has the computing resources needed to handle the individual's new conversation. If the bank has sufficient resources, it sends the bank identification code back to the ITT.

Once connected, the ITT instructs the BIA to obtain biometric data-the PIC and account index code-from the individual. Then the ITT adds the host name and the bank code of the bank. Using all this information, the requesting BIA forms a network credential request message, which the ITT sends to the DPC via the internet.

When the DPC receives this message, it validates the biometric data-PIC, takes the account number with the index code, and ensures that the bank code from the message matches the bank code stored under the bank's host name in the remote merchant database. The DPC also checks to ensure that the account number returned with the index code also belongs to the bank. If all checks are complete, the DPC establishes a network credential using the personal account identification, time of day, and bank code. The DPC signs this credential using public key encryption and the DPC's private key. The DPC retrieves the bank's public key, the individual's private key, and forms a network credential response message with the credential. The response message is encrypted with the BIA response key and then sent back to the ITT.

When the ITT receives a response, it gives the response message to the BIA. The BIA decrypts and then displays the personal unique code on the LCD screen. The bank's public key is stored in a public key register. Two random session keys are generated by the BIA. The first key, called the shared session key, is disclosed in plaintext to the ITT. The ITT uses this shared session key to secure the connection with the bank.

Other session keys, called private session keys, are not shared with the ITT. It is used for the BIA's demand-response mechanism, which lets the bank get specific confirmation of an irregular transaction directly from the individual, without involving (untrustworthy) ITT.

Upon receipt of the shared session key, the ITT request BIA forms a secure connection request message that includes the session key and the network credentials, all encrypted with the bank's public key. The IIT then sends a secure connection request message back to the bank.

When the bank receives the request message, it decrypts the message using its own private key. It then decrypts the actual network credentials with the DPC's public key. If the network credentials are valid and not expired (after a few minutes, the credential time expires), the individual is authorized, the session continues, and the session key is used to ensure security.

Whenever an individual conducts any irregular or high value transactions, the bank may wish to request that the individual confirm that those transactions are exceptionally secure. To this end, the bank sends a demand-response message encrypted with a private session key to the ITT, which sends the demand-response message to the BIA. The BIA decrypts the message, displays the requirements (usually in the form of $ 2031.23 to Rick Adams, can.

1.4.4.5. Safety feature

The system uses public key cryptography to provide credentials and secure communications between the ITT and the bank.

For this mechanism to function properly, the bank must know the public key of the DPC and the DPC must know the bank's public key. The two parties ensure the safety of the respective public key and avoid unauthorized modification, which is important for the safety of the system. Note that the public key is readable by anyone but cannot be modified. Of course, any session or secret key must be kept secret from discovery. After the session is over, those secret keys must be destroyed.

An additional confirmation step for non-regular transactions is necessary because it is relatively difficult to secure personal computer applications due to viruses, hackers and personal negligence. Banks should potentially limit conventional funds transfers available for IIT to only include funds transfers to well-understood institutions (e.g., public welfare companies, major credit card issuers, etc.).

1.4.5. A terminal: electronic signature

1.4.5.1. Purpose(s) to

An Electronic Signature Terminal (EST) is utilized by an individual to generate an electronic signature for an electronic document that cannot be forged. EST allows an individual to sign an electronic document or to verify an electronic signature already present on such a document.

1.4.5.2. Form a

The EST comprises:

a BIA/PC;

a microcomputer;

a message classification coding algorithm;

a modem, an X.25 connection, or an Internet connection;

an electronically signed software application.

The EST uses a BIA/PC connected to a microcomputer controlled by an electronic signature software application.

1.4.5.3. Identification

Three things need to be done in order to create a token that does not require the use of public/private keys. First, the document to be signed needs to be uniquely identified, the time of day needs to be recorded, and the person performing the signature needs to be identified. This links the document, person and time, creating a unique time stamped electronic signature.

1.4.5.4. Operation of

First, the document to be signed is processed by a message classification encoding algorithm that generates a message classification encoding. Such an algorithm is the MD5 algorithm known in the art as RSA. By its nature, the message classification algorithm is specifically designed so that it is not possible to access another file that produces the same message classification encoding.

Using the BIA, the individual then enters his biometric data-PIC, transmits a message digest code to the BIA, adds the name of the document, and the resulting digital signature request message is sent to the DPC for authorization and storage.

When the DPC receives the request, it performs a biometric data identity check, and once the individual is verified, it collects the message digest code, the individual's biometric data account number, time of day, file name, and the identity of the collected signed BIA and stores them in an Electronic Signature Database (ESD). The DPC then forms a signed code text string consisting of the ESD record number, date, time, and name of the signatory. And sends the signed code back to the EST together with the individual's unique code.

To check an electronic signature, the document is sent through the MD5 algorithm (well known in the art) and the resulting value and electronic signature code are sent to the BIA along with the requesting individual's biometric data-PIC, which is sent to the DPC. The DPC examines each signature for verification and responds as appropriate.

1.4.5.5. Security

The BIA does not encrypt any data relating to the electronic signature and thus sends the file title in clear text together with the specific MD5 value. This case applies to signature verification.

Thus, although the signature cannot be forged, some details (including the file name) are easily intercepted.

1.4.6. A terminal: authenticated email terminal

1.4.6.1. Purpose(s) to

The purpose of authenticated electronic mail terminals (CETs) is to provide individuals with a way to deliver electronic messages to other individuals in the system, while at the same time serving to identify the sender and authenticate the recipient and receiver and to ensure the confidentiality of the message delivery.

CET uses a BIA/PC to identify the sender and receiver. Security is established by encrypting the message. The message key is then encrypted using the sender's BIA during upload and decrypted using the receiver's BIA during download.

1.4.6.2. Form a

Both sender and receiver CETs include:

a BIA;

a microcomputer;

a modem, an X.25 connection, or an Internet connection;

ability to receive e-mail

A verified email application.

The CET is typically a microcomputer with an email application and network connection that causes the BIA to generate a biometric data-PIC authorization to send and receive verified emails.

1.4.6.3. Identification

To guarantee delivery of the message, the sender and the receiver must be identified.

When the sender uploads the message to the DPC, he identifies himself using his biometric data-PIC. Each recipient to whom a sender wishes to send a document is identified either by a biometric data account identification number or by a fax number and extension. In order for a recipient to download the message, he identifies himself using his biometric data-PIC. The process is similar to a person-to-person telephone call.

1.4.6.4. Operation of

The individual uploads a file or message and identifies himself using his biometric data-PIC to initiate the transfer of the message. The individual then verifies the name of the file and encrypts the email message and uploads.

Upon uploading a message, the sender receives a message identification code requesting the current delivery status of the file to each recipient.

The DPC sends each recipient an email message informing them when an authentication message has arrived.

Once the recipient receives the notification, the recipient may choose to accept or reject the message or group of messages at his will by submitting his biometric data-PIC and acknowledging it through the DPC.

Once successfully transmitted to all recipients, the file is deleted after a predetermined period of time, typically 24 hours. An individual who wishes to archive the file, along with an indication of all individuals who have delivered the message, may submit a message archive request before deleting the message.

1.4.6.5. Safety feature

To ensure the security of the transmission, the file is protected from disclosure in the route. CET accomplishes this by using a 56-bit message key generated by BIA. As part of the biometric data-PIC, the encryption key is securely sent to the DPC since the BIA is responsible for encrypting the message key.

When the individual downloads the message, the encrypted message key is sent along with the private code to allow the recipient to decrypt the message. Note that since the recipients all receive the same message, it is preferable that all recipients have this message key.

For ITT, individuals must take care to protect their CET application software from being implicitly modified, since a modified CET can send any file it wishes once the individual has confirmed the file name.

1.4.7. A terminal: secure fax terminal

1.4.7.1. Purpose(s) to

The purpose of a Secure Fax Terminal (SFT) is to provide an individual with a way to deliver a fax message to other individuals in a system while providing identification of the sender, authentication of the recipient and recipient, and to ensure confidentiality of the message delivery.

Each SFT uses an integrated BIA/catv to identify the sender and receiver, and security of communication is accomplished through encryption.

1.4.7.2. Form a

The sender and receiver SFTs each comprise:

a BIA/CATV

A facsimile machine

Optional ISDN modem

The SFT is a fax machine connected to the DPC via a modem. The system handles the fax as it does for another type of authenticated email.

1.4.7.3. Identification

For secure faxes, there are several different levels of security, but in most security versions, the identity of the sender and all recipients are verified.

When the sender sends his message to the DPC, he identifies himself using his biometric data-PIC and job title index code. To collect the fax, each listed recipient again identifies itself using the biometric data-PIC and job title index code.

In addition, the receiving station is identified by a telephone number. The telephone number is registered in the DPC. For secure and confidential faxes, each recipient is identified by a telephone number and its extension.

1.4.7.4. Operation of

There are five basic types of faxes that can be sent by SFT

I. Non-secure facsimile

The non-secure fax corresponds to a standard fax. The sender inputs the telephone number of the receiving station and sends the fax. In this case, the sender is not identified and a fax is sent to a given telephone number in hopes of the fax being delivered to the correct recipient. The SFT marks the top row of all such insecure faxes as "insecure". All faxes received from non-SFT fax machines are always marked as unsecure.

Secure sender fax

In a secure sender fax, the sender selects the "secure sender" mode on the fax machine and enters his biometric data-PIC and their job title index code. The fax machine then connects to the DPC and sends the biometric data-PIC information. Once the DPC verifies the identity of the individual, the individual sends the facsimile by sending the document to a facsimile scanner. In this case, the fax is actually transmitted to the DPC that digitally stores the fax. Once all the faxes arrive at the DPC, the DPC begins sending the faxes to each destination, marking each page with "sender safe", name, job title, and sender company at the top of each page.

Secure fax

In secure fax, the sender selects the "secure" mode on the fax machine, enters their biometric data-PIC and their job index code, and enters the receiver's telephone number. Once the system verifies the identity of the sender and the telephone number of each recipient, the individual then sends the fax by sending the document to a fax scanner. The fax is then sent to the DPC, which digitally stores the fax. Once the entire fax arrives at the DPC, the DPC sends a small home page to the destination indicating the pending secure fax, the sender's job title and identity, and the number of pages waiting and tracking the code. The tracking code is automatically entered into the memory of the recipient's fax machine.

To retrieve the fax, the employee of the recipient company may select a "retrieve fax" button on his fax machine. The pending fax to be retrieved is selected by using the tracking code and then the biometric data-PIC is entered. If it is not the desired fax, the user can press a "decline fax" button. Although in order to do so he must identify himself to the system. Once a valid company member, the fax is downloaded to the recipient's fax machine. Along with the sender's identity and job title information, at the top of each page is marked "safe".

IV. secure fax

In secure fax, the sender selects "secure" mode on the fax machine, enters their biometric data-PIC and their job title and index code, and enters the phone number and system extension of each recipient. Once the DPC verifies the identity of the sender and the telephone number and extension of each recipient, the individual then sends the fax by sending the document to a fax scanner. The fax is sent to the DPC, which digitally stores the fax. Once the entire fax arrives at the DPC, the DPC sends a small home page to each destination indicating the pending secure fax, the sender's job title and identity, the receiver's job title and identity, and the number of pages waiting and tracking code. The tracking code is automatically entered into the memory of the recipient's fax machine. However, the only person who can retrieve the facsimile is the person whose extension code is indicated.

The individual selects the "retrieve fax" button, selects the pending fax to retrieve, and then enters his biometric data, PIC. Once a valid recipient, the fax is downloaded to the recipient's fax machine. Along with the title and identity information of the sender, a "security secret" is marked at the top of each page.

V. Security contract fax

The fax is handled the same as a secure-private fax, except that the fax is marked as "contract" rather than secure-private, in terms of actually transmitting the fax to the receiving party. In addition, the DPC automatically documents the contract facsimile. After receiving the contract facsimile through the SFT, any recipient can receive or reject the contract. The DPC performs the role of the electronic notary according to the selection.

Any fax sent to the system and then delivered to the recipient can be sent to any number of recipients without having to stop the sending fax machine. In addition, the tracking number of any sent fax is entered into the memory of the fax machine, and a status report can be generated on the sender for any sent fax by selecting the "status" button and selecting a particular fax pending tracking code. The DPC issues a report detailing the status of transmissions for each recipient which are immediately sent to the sending fax machine.

Using any secure or privacy fax, there is an option for either the sender or for one of the receivers to archive the fax (and the sender and receiver of the fax) for future reference. For which any secure fax is retained for a certain time (e.g. 24 hours) after a successful transmission. Whenever an archive is requested, the archive tracking code is returned to the individual. The archiving code is used to retrieve the facsimile and the facsimile status report archived with the system.

After a certain time (e.g., 24 hours), the archived facsimile is placed in the read-only secondary memory. Retrieving an archived facsimile requires manual intervention and may take up to 24 hours.

1.4.7.5. Safety feature

The SFT system works hard to guarantee the receipt of the sender identity, which also ensures to the sender that the recipient actually acknowledges the receipt of the file.

In order to protect the communication between the sender and the receiver from interception, the fax terminal encrypts the fax using a message key device provided by the BIA. Since the BIA encrypts the message key as part of the biometric data-PIC, the encryption key is sent securely to the DPC.

When the individual receives a secure facsimile of any type, the encrypted message key is sent along with the private code to allow the recipient to decrypt the message. Note that since they all receive the same message, it is preferable that all recipients have the message key.

1.4.7.6. Attention is paid to

Sending a secure fax is very similar to sending an email and uses much of the same software.

It is possible to construct a fax terminal without an integrated BIA/fax device but with a portion adapted to be connected with an external BIA/pc and software adapted to use the BIA.

1.4.8. A terminal: biometric data registration terminal

1.4.8.1. Purpose(s) to

The purpose of the biometric data registration terminal (BRT) is to register new individuals, including their biometric data-PIC, email address, proprietary code, email address, job listings and job index codes for sending and receiving electronic messages and faxes, financial asset accounts listings and accessible account index codes, all using their biometric data-PIC.

The goal of the registration process is to obtain personal information from an individual at the location of the reliable agency, where the information can be confirmed. This includes, but is not limited to, retail banking branches and business personnel departments. Each participating responsible organization has a BRT for use by a group of employees. The employees are authorized to perform the check-in, and each employee is responsible for each person registered.

1.4.8.2. Form a

A microcomputer, a screen, a keyboard and a mouse

A BIA/registration

9.6kb Modem/X.25 network connection (well known in the industry)

Biometric data enrollment software application

The BRT uses an attached BIA/registry for biometric data entry and is connected to the system via a 9.6kb modem or an x.25 network connection (well known in the art). The biometric data registration terminal is located at a location where they are physically secured, such as a retail banking branch.

1.4.8.3. Identification

In order to respond to the registration request of BIA/registration, 3 entities need to be identified for DPC; enrolling employees, institutions and BIA/enrolment. The employee must have been authorized to register individuals for that institution.

The organization code retrieved with the BRT identifies the organization and the BIA by cross-checking the owner of the BIA. By entering his biometric data-PIC at the start of the enrolment application, the employee identifies himself to the system.

Before registering an individual on the system, the institution uses his standard customer identification procedure (signature card, employee record, personal information, etc.). Verifying the identity of individuals as seriously as possible is important to institutions as registered individuals are allowed to transfer funds from those accounts at their discretion and/or to send electronic messages using the names of companies.

1.4.8.4. Operation of

During enrollment, the individual enters primary and secondary biometric data. The individual must use the index finger. If the individual loses the index finger, the next innermost finger can be used. Requiring the use of a specific finger allows existing fraud checking work.

The individual is encouraged to select one primary and secondary finger, preferably the primary finger is given during the DPC identity check so that the individual should take the most commonly used finger as primary. Of course, the DPC may be selected according to the operation to alter the design of the primary and secondary biometric data, if necessary.

As part of the biometric data encoding process, the BIA/R determines whether the individual has entered "a good fingerprint". Note that there are people whose work causes their fingerprints to be accidentally deleted, such as those working with abrasives or acids. Unfortunately, these individuals cannot use the system. At this stage, they are monitored and notified that they are unable to participate.

In a series of PICs provided by the system central database, the individual selects one PIC with 4 to 12 digits. However, the PIC must be acknowledged by the system. This involves two checks: first, the number of other individuals using the same PIC cannot be too large (since the PIC is used to reduce the number of individuals checked by the biometric data comparison algorithm), and second, the registered individual cannot be too close to other individuals in the same PIC group in terms of biometric data. If this occurs, registration is denied and an error message is returned to the BRT, informing the individual to request a different PIC. The system optionally returns an error condition with an "identical match" indicating that under that PIC the person has a record in the system.

A PIC of zero (0) allows the system to assign one PIC to an individual.

The individual constructs a secret unique code that includes a word or phrase. If the individual does not wish to construct a unique code, the terminal will randomly construct a unique code.

Individuals may also arrange for their financial asset code lists. The list describes which account index code points to which account (e.g., 1 for debit, 2 for credit, 3 for emergency debit, etc.). Note that this will only occur if the registration institution is a bank and the account is owned by a particular bank institution.

Even after each check-in, individuals using the system cannot perform operations that utilize the system until the time of the previous fraud check. This usually takes several minutes, but during high loads it takes several hours. The personal account is only activated when the system has not found prior fraud.

1.4.8.5. Safety feature

If an individual is found to be even fraudulent once in the system, the DPC performs an extensive casual biometric database search within the database for the criminal. A portion of these are performed overnight, allowing the particular individual the system is looking for to be isolated from the database by performing a time consuming process during light load activity conditions.

The employees performing the enrolment operation identify themselves by using the biometric data-PIC only when the enrolment system is initially started. This is convenient for employees, but may be a security issue for the system since an absent or "temporarily loaned" BRT may be the source of fraud.

1.4.9. A terminal: customer service

1.4.9.1. Purpose(s) to

The purpose of the Customer Service Terminal (CST) is to provide internal DPC supported personal access to various aspects of the system database. Support personnel need to answer the consultations made by individuals, issuers, merchants of the organization who have made the current questions when using the system.

1.4.9.2. Form a

The CST comprises:

a microcomputer

A BIA/Int

Ethernet/token Ring/FDDI network interface

Database checking and modification applications

Each CST is connected to the system through a high speed local area network connection such as token ring, ethernet, fiber optic (FDDI), etc. Each CST can query each database and display the results of those queries. However, the CST only displays fields and records that are based on the privileges of a single end user. For example, a standard customer service employee cannot see the encrypted code of a VDB record for a given BIA, although they can see which merchant or individual currently owns that BIA.

1.4.9.3. Identification

For CST to allow access to the database, the system must identify the individual and the BIA. In addition, the privilege level of the individual must be determined so that access can be appropriately restricted.

1.4.9.4. Operation of

Individuals using a CST initiate a conversation by entering their biometric data-PIC to provide identification. The BIA constructs an identification request message and sends it to the DPC for verification. Once the system authenticates the individual, the CST application operates normally, albeit limited by the DPC privilege level previously assigned by the individual.

1.4.9.5. Safety feature

For security purposes, the DPC terminates the connection to the CST application after a predetermined idle time.

It is important that the database application cannot be modified in any way, whether intentionally or by introduction of a virus. For this reason, the personal CST does not own any floppy disk drive or other removable media. Also, read access of the executable database application is strictly limited to those who need to know.

To protect the communication between the CST and the database from being surreptitiously modified or disclosed, the CST encrypts all communication between the CST and the database. To do so, the CST generates a session key that is sent to the server during the login session to the system. This session key is used to encrypt and decrypt all communications related to the DPC that occur during this period.

Although secure communication and non-modified database applications are assumed, the DPC ensures that DPC data fields that cannot be accessed by individuals operating the CST are not sent to the database application of the CST. Also, any individual may not have access to or be allowed to modify the individual's biometric data information at any time.

The DPC and support center may be co-located or the support center itself may be separated due to its inherent high security around the CST.

1.4.10. A terminal: publisher terminal

1.4.10.1. Purpose(s) to

The purpose of the issuer terminal is to allow employees at the issuing bank to provide bulk asset account modification operations to the DPC in a secure and identifiable manner.

1.4.10.2. Form a

The IT comprises:

a microcomputer

A modem, an X.25 network or an Internet connection to the system.

A BIA/Iss

Network connection to the bank intranet

The publisher terminal uses the sponsor BIA to authorize the addition and deletion of a large amount of financial asset information.

1.4.10.3. Identification

In such an operation, the bank must be identified, the bank employee correctly authorized must be identified, and all individuals whose asset accounts have been added or deleted must also be identified.

The bank is used to identify individuals who wish to add their accounts at the bank to their asset account list. As in biometric data registration, banks do this by using signature cards and personal information. The DPC identifies the bank by cross-checking the issuer code submitted by IT and the issuer code registered in the VAD record of BIA/Iss. Biometric data-PIC is used to identify the bank employee who actually submitted the batch.

1.4.10.4. Operation of

To join a financial asset account, the individual provides his biometric identification number to the bank along with the more joined account (the identification number is provided to the individual in an initial biometric registration step). After the person is correctly identified, the identification code and account list is transmitted to the IT for later batch submission to the system.

An authorized individual in the bank notifies IT to upload batches of account additions/deletions to the DPC whenever the bank deems appropriate. To do so, the authorized person enters his biometric data-PIC, IT adds the session key, adds the bank's issuer code, and constructs a sender batch request message with this BIA/Iss, whereupon the IT passes the message to the DPC. IT encrypts the batches using the message code and then sends them.

When the system receives the issuer batch request, it confirms that the BIA is a BIA/Iss that is registered with the bank that the issuer code requires, and that the person identified within the biometric data-PIC is allowed to submit batch requests to the DPC for that bank. If so, the DPC processes all requests, tracking errors as required. Once completed, the DPC returns the personal unique code along with the encrypted batch process including any errors that occurred during the process.

1.4.10.5. Safety feature

The security of the transaction is important to the security of the system. A criminal who intends to cheat need only discover a method to add another person's account to his biometric data identification code and can then do the cheat at will. Eventually the criminal is caught and removed from the database, but then the account of others is attacked by the criminal.

Encryption ensures that the transmission between the bank and the DPC is not intercepted and thus the account number is protected at the time of transmission.

Cross-checking the bank and BIA/Iss means that IT and BIA must commit spurious add/delete messages to the DPC in a compromise. In this way, the bank ensures that IT is physically secure and that only authorized individuals are allowed to use IT.

Requiring an individual to submit a batch ensures that the responsible person "runs the chores" and the job of the responsible person is to ensure that appropriate bank security measures are followed in the construction and transmission of the batch.

1.4.11. A terminal: automatic teller machine

1.4.11.1. Purpose(s) to

The purpose of biometric data ATMs is to allow individuals to access cash and conduct other ATM transactions without the use of an interbank card. This is done by providing a biometric data-PIC and an account index code and retrieving a bank account number. This replaces the interbank card (known in the art) + PIC mechanism for users of the system as a way to identify accounts and authorize individuals. Assume that the ATM will continue to accept inter-bank cards.

1.4.11.2. Form a

The IT comprises:

a standard ATM

An integrated BIA/ATM (scanner only)

One to DPC connection

The biometric data ATM uses an integrated BIA/ATM to identify individuals and allow them to access financial assets using the biometric data-PIC and an account index. A BIA/ATM is installed in the ATM, using the ATM's current PIC keypad to enter the PIC and account index code. The ATM is connected to the system using x.25 or a modem.

The BIA/ATM is constructed so that it integrates with existing ATM networks in the simplest manner. Making a compromise between security and ease of integration.

1.4.11.3. Identification

In order to properly respond to a BIA/ATM account request, three entities need to be identified for the DPC: personal, bank, and BIA/ATM.

The bank is identified by cross-checking the bank code stored by the ATM and the bank code of the BIA/ATM. The BIA/ATM was successfully located in the VAD to identify the BIA/ATM and the person was identified by standard biometric data-PIC.

1.4.11.4. Operation of

To use the ATM, the individual enters their biometric data-PIC and account index code into the BIA. The BIA forms an account access request message that is then sent to the DPC via the ATM. The DPC validates the biometric data-PIC and the emergency account index code and sends the resulting asset account number back to the ATM along with the unique code.

The ATM requests the BIA to decrypt the response and display the unique code on the display screen of the ATM. The ATM also checks the response to see if the individual performs a standard account access, or "enforces" account access. If a mandatory account access is indicated, the ATM may provide a false or misleading message regarding the amount of personal availability, and the specifics of such activity will vary from ATM to ATM. However, when conducting a forced transaction, the ATM will not provide any indication to the individual.

1.4.11.5. Safety feature

Messages between the ATM and DPC are protected by encryption of the BIA and MAC calculation. MAC means that ATM cannot change the content of a message without detection and encryption prevents disclosure of the encrypted portion of the message.

Since the BIA/ATM does not have an LCD or PIC keyboard, it requires the ATM to provide all text prompts and collect all the input of the individual. This case is less secure than the case where the BIA performs the operation, but since ATM is generally very robust, it may be referred to as wash.

1.4.11.6. Attention is paid to

The behavior of the ATM is determined between the bank and the individual when the individual indicates that he is performing a transaction under force. A particular bank may choose to restrict access, or change balance information, or display a fake screen. The false screen is a display of data that is predetermined to be incorrect such that a party cannot illegally obtain accurate data about a personal financial asset. It is beyond the scope of the present invention to define the exact behavior of the ATM in such a case.

1.4.12. A terminal: telephone point-of-sale terminal

1.4.12.1. Purpose(s) to

The purpose of a telephone point-of-sale terminal (PPT) is to authorize debit and credit financial transactions made from individuals purchasing goods from merchants using a specially made telephone.

1.4.12.2. Form a

The PPT comprises:

a BIA/catv

Fast connected digital modems (see Voice View patent (well known in the industry))

One telephone (keyboard, earphone, microphone)

A microcomputer

A DSP (digital signal processor)

A standard telephone line

The PPT accepts biometric data identification using a BIA/catv connected to and integrated with a cordless telephone, cellular telephone or standard telephone.

1.4.12.3. Identification

In order for the DPC to authorize a transaction, the individual and merchant must be identified.

For identifying the person, biometric data-PIC identification is used.

To identify the phone ordering merchant, all phone numbers of the merchant and the merchant to be personally called are registered to the DPC. Thus, when an individual submits an authorization, he also submits the telephone number he wants to call, which is cross checked with the merchant's listed telephone number.

1.4.12.4. Operation of

Individuals call merchants who sell their goods through paper catalogs, newspapers, magazines, or other basic print media mechanisms. The PPT exchanges digital information with the merchant using a specific modem sharing a telephone voice line.

In the case where an individual decides to purchase, the PPT tracks the telephone number entered by the user each time the individual makes a telephone call. The DSP is used to detect dial tones, ringing, connections, etc., to tell the actual telephone number entered, to distinguish from extended information (extension) or navigation of the telephone messaging system, etc.

Upon calling a merchant, the merchant's sales person digitally downloads all relevant information (including product, price, and merchant code) to the PPT. Note that in operation, the modem interrupts the speaker.

When the product information is downloaded, the PPT prompts the individual for biometric data-PIC, account index code and requests that the individual confirm the purchase amount. The phone number and merchant code are then added and the message is encrypted. The authorization information is sent to the merchant using a quick connect modem.

When the merchant receives the authorization information, the merchant verifies the price and product information and communicates the transaction to the DPC via a secure communication channel using the Internet or some other common network. The connection to the DPC is guaranteed using public key encryption and a secret key exchange.

Upon receiving and decrypting the telephone authorization, the DPC checks the telephone number and merchant code, validates the biometric data-PIC and sends the transaction to the debit/credit network for authorization. If authorization is successful, the DPC adds the address of the shopper to the response message and sends the response to the merchant.

The merchant receives the response from the DPC, copies the mail address and retransmits the message to the individual using a quick connect modem via a simple session. Upon completion of the transfer to IPT, a harmonious musical sound is sounded, the modem is disconnected and the individual's unique code (decrypted by the BIA) is displayed on the LCD screen. The merchant sales representative confirms that the personal email address is valid. If so, the call is interrupted and the transaction is completed.

1.4.12.5. Safety feature

One aspect relating to the security of telephone transactions is the security of the telephone system itself. In addition to biometric data identification, a major problem is ensuring that the number called by an individual does indeed reach the desired merchant.

Note that the communication line between the PPT and the merchant is not secure, so that shopping authorization from the individual to the merchant may be intercepted. However, no financial benefit is thereby generated, and this is therefore not considered important.

Because of inherent problems in clearing the responsibility for PIC entry and private code decryption and presentation, the security required for PPT due to price and weight is relatively low.

1.4.13. A terminal: cable television point of sale

1.4.13.1 purpose:

the purpose of a cable television (CATV) point-of-sale terminal (CPT) is to authorize financial transactions from an individual in front of a television (or "TV") set to a merchant who presents the objects of sale on the television.

1.4.13.2 Structure

The CPT includes:

one BIA/catv

One television remote control with integrated BIA/catv

A cable television digital signal decoder

A remote controller reader for cable TV

An on-screen display mechanism

Access to a cable television broadband bidirectional communication channel

The CPT accepts biometric data identification using BIA/catv integrated with the remote control device of the television. The remote control device communicates with a television set-top box, which itself communicates with the broadband cable television network. The terminal includes: a television remote control logic device in communication with the BIA, and a television set-top box in communication with the cable broadband network.

1.4.13.3 recognition

In this transaction, the merchant and the individual must both be identified to conduct the transaction.

The individual is identified by biometric data-PIC.

The merchant is identified by a merchant voucher created by the CATV broadcaster when the product is displayed on television. Each product broadcast has a merchant-product voucher including a merchant code, a time, a term and a price, which is marked with public key encryption and the private key of the CATV network broadcaster. This merchant-product voucher can only be generated by the webcast.

1.4.13.4 operation

When a product is displayed on a television broadcast, commercial information (infomercial), or home shopping channel, the cable network also broadcasts digital information describing the short description, price, and merchant-product credentials. The digital information is processed and temporarily stored by the CPT and is readily accessible to the user when making a purchase decision.

To purchase something that is currently being displayed, the individual selects an on-screen display function of the dedicated television remote that instructs the CPT to display on the screen textual information about the currently viewed product.

The individual is first prompted by an on-screen display of the number of products he wishes to purchase. He is then prompted to enter his biometric data-PIC, and his account index code. Once he verifies that the final purchase price is possible, the product, price, merchant, code, merchant-product credentials, and channel number along with the biometric data-PIC are used to compose a remote transaction authorization request message. The request is transmitted over a cable television broadband bi-directional communication channel to the merchant for authorization.

Note that each merchant wishing to sell products in this manner must have the ability to receive ordering information using a broadband cable television network.

Upon receiving the authorization request, the merchant submits the request to the DPC using an encrypted Internet connection or an X.25 connection.

If the DPC authorizes the transaction, it may constitute an authorization response that includes the person's current email address in addition to the authorization code and the encrypted unique code. Once the merchant receives the authorization, he copies the authorization and the email address, and then sends the authorization back to the CPT, which displays the unique code to the individual, ending the transaction.

1.4.13.5 safety

This system architecture does not allow criminals to replay messages intercepted from the cable broadband network, but they are able to read some of the messages. If this is not desired, the message may be encrypted by using an optional cable center public key, or "link level" encryption between the cable set-top box (known in the industry) and the cable local office.

To secure the connection between the merchant and the DPC, the connection employs a session key that changes every day, which has been previously replaced using a public key encryption key replacement system.

1.5 description of the system: data processing center

1.5.1 introduction

The Data Processing Center (DPC) has as its primary responsibility the processing of financial transaction authorizations and personal registrations. In addition, DPC provides storage and retrieval for secure faxes, electronic documents, and electronic signatures.

Each DPC site consists of several calculations and several databases connected together by LANs (known in the industry) as shown in the DPC overview (numerals). Multiple identical DPC sites guarantee reliable service in the face of a failure occurring at any single DPC site or a severe hardware failure. Furthermore, each DPC site has a backup power source and multiple redundancies in all of its critical hardware and database systems.

DPC components are divided into three categories: hardware, software, and databases. The following is a short description of each component class by class. A more detailed description appears in the following sections.

1.5.1.1. Hardware

FW firewall machine: entry point to the DPC site.

GM gateway machine: a system coordinator and a message processor.

DPCLAN DPC local area network: connecting the DPC sites.

1.5.1.2. Database with a plurality of databases

IBD personal biometric database: the person is identified from the person's biometric data and the PIC code.

PFD previous fraud database: individuals who have been fraudulent of the system are listed and a biometric data is checked for a match with any of these individuals.

VAD valid device database: information needed to validate and decrypt the BIA message is stored.

AOD device owner database: information about the BIA owner is stored.

ID issuer database: the issuing bank participating in the system is identified.

AID authorized personal database: a list of individuals who are allowed to use the individual or distributor BIA device is stored.

RMD remote merchant database: information needed to process transactions with telephone and cable merchants is stored.

EDD electronic file database: electronic documents, such as faxes and e-mails, are stored for retrieval by authorized individuals.

ESD electronic signature database: storing the electronic signature for recognition by a third party user.

1.5.1.3 software

MPM message processing module: the processing of each message is performed by coordinating with other software modules and databases that are needed to perform the task of the message.

SNM serial number module: DUKPT sequence number processing is performed.

MACM message authorization code Module: verification and generation of the MAC is performed.

MDM message decryption module: encryption and decryption of BIA requests and responses are performed.

PGL PIC group list: the lookup for the PIC group is managed using the PIC and a database element structure that depends on the list of PIC groups.

IML IBD machine list: a lookup is made for the main and backup database machines that are dedicated to maintaining IBD records for each given PIC group.

1.5.1.4 terminology

When defining a database schema, the following terms are used to describe field types:

int < x > integer using < x > byte memory

character array of char < x > < x > bytes

text variable length character array

< type > < x > specified type array with length < x >

time is used to store the type of time and date

binary data type for storing biometric data

fax binary data type for storing facsimile image

The term "expected" when describing database storage requirements means the expected condition of a fully loaded system.

1.5.2 protocol description

The terminals complete their tasks by sending request packets to the DPC site. The DPC station sends back a reply packet containing the status of success or failure with respect to the request.

Communication is through a logical or physical connection-oriented messaging mechanism such as an x.25 connection, TCP/IP connection, or telephone call to a modem pool. Each session remains open to the terminal connection before the DPC sends a response back to the terminal.

The request packet contains a BIA message part and a terminal message part:

BIA message part

Protocol version number

Message type

4-byte BIA identification

4 byte sequence number

< message specific data >

Message Authentication Code (MAC)

Terminal message part

< terminal-specific data >

The BIA message part is built by a BIA device. It includes one or two biometric data, a PIC, an authorization number, and the contents of a general register set by the terminal. Note that: the MAC in the BIA message part is applicable only to the BIA part and not to the terminal part.

A terminal may place additional data for the request message in the terminal message part. The BIA provides a message key to allow the terminal to secure the terminal portion data. The BIA automatically adds the message key to the encrypted biometric data-PIC block of the packet when needed. However, the terminal itself performs encryption of the message key.

The response packet contains a standard header and two optional free-form message parts: one with one MAC and the other without.

Standard header

Protocol version number

Message type

Optional free-form message part with MAC

< message specific data >

MAC

Optional free-format message part without MAC

< additional message-specific data >

The message part with the MAC is transferred to the BIA so that it can confirm that this part of the reply has not been tampered with and then reveal the private code of the person. The message part without the MAC is used to send a large amount of data, such as fax images, which is not transmitted to the BIA for MAC confirmation, since the BIA to terminal connection may be bandwidth limited.

1.5.3. Treatment bag

In an embodiment of the invention having multiple DPC sites, a terminal need only transmit its request to one of the DPC sites, typically the nearest one, because the site automatically updates the other sites by running distributed transactions whenever needed.

When one of the DPC's firewall machines receives a packet, it sends the packet to one of the GM machines for actual processing. Each GM has a message handling module that coordinates between DPC components for handling requests and returns responses to the sender.

1.5.4. Validating and decrypting packets

All packets received by the DPC, except those not constructed by the BIA, contain a BIA hardware identification (BIA identification of the packet), a sequence number, and a Message Authentication Code (MAC). The GM asks the MAC module to acknowledge the MAC of the packet and then checks the sequence number by the sequence number module. If both checks pass, the GM passes the packet to the message decryption module for decryption. If any of the checks fail, the GM records an alert, terminates processing of the packet, and returns an error message to the BIA device.

Currently, the only message types not created by the BIA are secure fax data requests and electronic document data requests.

1.5.5. Response bag

Each packet received by the DPC may contain an optional response key stored in the encrypted biometric data-PIC block of the packet. Before the DPC responds to a request containing a response key, it encrypts the response packet with the response key. It also generates a message authentication code and appends it to the packet.

The only exception to the encrypted response packet applies to the error message. The error is never encrypted and never contains confidential information. However, most replies contain a status code or reply code indicating the success or failure of the request. For example, when the DPC denies a lender authorization, it does not return an error packet, but returns a standard transaction response packet with a response code set to "fail".

DPC Process

The DPC has two processes that are used in common when processing requests.

1.5.6.1. Personal identification process

For requests that require the DPC to identify individuals, the DPC performs the following process: using the PIC code, the DPC retrieves the IBD machine list look-up master and backup IBD machines, which are responsible for handling the identification of a given PIC code. The DPC then sends an identification request to the primary or backup machine depending on who is loaded the least. The IBD machine responds with either the person's IBD record or a "person not found" error.

The IBD machine retrieves all IBD records for a given PIC. Using a proprietary biometric data hardware device, the IBD machine compares the primary biometric data of each record to the biometric data of the individual to obtain a comparison score that indicates the similarity between the two biometric data. If none of the biometric data has a sufficiently close comparison score, the comparison is repeated using the secondary biometric data. If any of the secondary biometric data does not have a sufficiently close comparison score, the IBD machine returns a "person not found" error. Otherwise, the IBD machine returns a full IBD record for the individual from which fields such as a unique code, account number, job title, etc. may be obtained.

1.5.6.2. And (3) emergency response process:

for requests containing an account index, the DPC handles the case where an individual selects his or her emergency account index. The GM handling the request immediately notifies the DPC customer support personnel, records an alert, and sets the code to "urgent" if the response packet has a response code. It is the responsibility of the owner of the requesting BIA device to wait for the "urgent" response code and provide further assistance, such as the false screen mechanism described in the ATM terminal section. Whenever the emergency account index is accessed, the DPC also increments the emergency usage count of the person's IBD records.

1.5.7. Protocol request

The following sections describe each protocol request/reply and the actions taken by the DPC to implement them.

The list of protocol packets is:

personal identification

Authorization of the transaction

Registration

Account access

Publisher batch processing

Secure facsimile transmission

Securing facsimile data

Secure fax tracking

Secure fax retrieval

Secure fax rejection

Secure facsimile documentation

Confidential fax contract acceptance

Secure fax contract denial

Secure facsimile agency changes

Electronic document delivery

Electronic document data

Electronic file tracking

Electronic document retrieval

Rejection of electronic documents

Electronic document archive

Electronic document archive retrieval

Electronic signature

Verification of electronic signature

Network credentials

1.5.7.1. Personal identification

Personal identification request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric data-PIC block:

300 byte authorized biometric data

4-12 bit digital PIC

56 bit response key

MAC

Terminal portion: (not used)

Personal identification response

Encrypted (response key):

special code text

Personal name

Biometric data identification code

MAC

The person identification request contains a block of biometric data-PIC, which the DPC uses to identify the person through a person identification process. If the individual is identified, the DPC responds with the individual's name, biometric data identification, and unique code. Otherwise, the DPC responds with an "unknown individual" error.

1.5.7.2. Transaction authorization

Transaction authorization request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (BUKPT key) biometric data PIC block:

300 byte authorized biometric data

4-12 bit digital PIC

56-bit response key

[ optional 56-bit message key ]

Account indexing

Price

Identification

[ optional free form product information ]

[ optional Merchant code (telephone number, channel number + time, main name) ]

[ optional Send Address request ]

MAC

Terminal portion: (not used)

Transaction authorization response

Encrypted (response key):

private code content

Authorization response

Authorization particulars (authorization code, transaction identification, etc.)

[ optional personal Address information ]

Response code (failure, Normal, Emergency)

MAC

There are two basic transaction authorization subtypes: retail and remote sales:

for retail authorization, the DPC identifies the purchasing individual using the requested biometric data PIC block. If the person cannot be identified, the DPC responds with an "unknown person" error.

The DPC then accounts for the asset involved (e.g., Visa)^TM，or AmericanExpress^TM) An external authorization request (crediting the asset account of the BIA device owner and debiting the individual's asset account) is sent to one of several financial authorization services already present. If the external financial authorization service approves the transaction, the DPC sends the external authorization code and a "normal" response code back to the BIA device. Otherwise, the DPC sends back the reason for denying the authorization and sets the answer code to "failed". In either case, the DPC includes the individual's unique code in the response.

When the DPC looks up the individual's asset account with the requested account index, the selected account may be an "urgent" account. If this happens, the DPC performs an emergency response procedure. However, external authorization may still occur.

The remote authorization may be generated by a telephone, mail order, or cable merchant. The DPC handles remote authorization in the same way as retail authorization but with the following exceptions:

i) the remote authorization contains a remote merchant code which the DPC checks against the remote merchant database to verify that the merchant identification of the package matches the identification stored in the database. In addition, the asset account being credited is an account of the remote merchant, not an account of the BIA device owner.

ii) additionally, the BIA device generating the remote authorization is intended to be a personal BIA device. The DPC checks the biometric data identification of the identified person against a list of authorized personal databases of persons allowed to use the BIA device. If the individual is not authorized to use the device, the DPC rejects the authorization request.

iii) finally, the authorization packet may contain a "send address" indicator. The indicator informs the DPC of the individual address included in the response packet and is instead used for mail order shopping.

1.5.7.3 registration

Registration request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric data-PIC block:

1000 bytes of main biometric data

1000 byte ancillary biometric data

4-12 bit digital PIC

56 bit response key

56 bit message key

MAC

Terminal portion:

encrypted (message key):

name (I)

Address

Postal code

Special code

Asset account list (Account number, index code)

Emergency account (Account number, index code)

Job list (Job index code, job alias)

Registration response

Status code

Encrypted (response key):

private code content

PIC

Biometric data identification code

List of PICs that DPC is selected from (if the original PIC is rejected)

Selected words)

Status code (Normal, reject)

MAC

The individual registers with the DPC through a biometric data registration terminal (BRT). The BRT sends to the DPC an enrollment package containing primary and secondary biometric data and personal identification codes, as well as secondary data such as personal name, address, financial asset account list, unique code, and emergency account. Alternatively, the individual may have an email address, a job listing including job title and job title index code, and a social security number (i.e., "SSN"). The individual may select her or his own PIC code or allow the system to select it. Any previously entered number may be modified or deleted at the modifying step.

At any one time, only one DPC station serves as a registration station for implementation convenience. Registration request packets received by the non-registering DPC stations are sent to the current registering station. The registering DPC station completes all registration checks, gives IBD records to IBD machines, and completes the assigned transaction needed to update all other DPC stations.

The registering DPC station selects PIC codes for those registration requests that do not specify a registration request, stores IBD records on the primary and backup IBD machines (as specified in the PIC group list), and checks the registration package for PIC and biometric data appropriateness before running the assigned transaction to update other DPC stations.

The DPC runs a personal identification code and biometric data sample replication checking step wherein the biometric data and personal identification code obtained in the enrollment step are checked against all previously enrolled biometric data currently associated with the same personal identification code. The DPC will reject the registration for the following reasons: the PIC code is too general or the biometric data is too similar to other biometric data stored under the selected PIC. To assist the individual in selecting an acceptable PIC, the DPC generates a short list of PIC codes for which the registration is guaranteed to remain for a period of time. The BRT then prompts the individual for a new PIC that can be selected from the list of good PICs.

1.5.7.4 Account Access

Account access request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (BUKPT key) biometric data PIC block:

300 byte authorized biometric data

4-12 bit data PIC

56 bit response key

[ optional 56-bit message key ]

Account indexing

MAC

Terminal portion: (not used)

Account access response

Encrypted (response key):

private code content

[ optional PIL ]

Asset account number

Response code (failure, normal, urgent)

MAC

Account access requests allow a BIA equipped teller machine to provide a more secure and convenient way for an individual to identify themselves to an ATM.

The GM identifies the individual using the package's biometric data-PIC and selects which asset account number to retrieve using the specified account index.

When the GM looks up the individual's asset account using the requested account index, the selected account may be an "urgent" account. If this occurs, the GM performs an emergency response procedure.

1.5.7.5 publisher batch processing

Publisher batch processing requests

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (BUKPT key) biometric data-PIC block:

300 byte authorized biometric data

4-12 bit digital PIC

56 bit response key

56 bit message key

Publisher code

MAC

Terminal portion:

batch list of encryption (information key):

add < biometric data Id > < Account index > < asset Account >

[ (Emergency flag > ]

Remove < biometric data Id > < Account index > < asset Account >

Publisher batch response:

encrypted (response key):

private code content

Answer code (failure, normal, urgent)

MAC

Failure list of encryption (message key):

failure < command > < code >

…

The issuer batch request allows the issuing bank or other authority to perform routine maintenance on the personal biometric database. If the DPC receives a publisher batch processing request from a non-publisher BIA device, the DPC will record a security violation alert and the DPC will also refuse to process the request.

The DPC identifies individuals submitting batch requests through the following individual identification process. The DPC then verifies that the individual is registered in an authorized individual database for use with the BIA device placed in the sending issuer terminal.

The DPC also uses the issuer code in the request to look up the equipment owner identification in the issuer database and compare it to the equipment owner identification stored in the valid equipment database to ensure that the issuer code is not counterfeit.

The DPC then executes add and delete commands in the encrypted batch list of message keys. The batch list is a new line-splitting command list.

The valid commands are:

plus < biometric data Id > < account index > < asset account > < emergency flag > ]

Remove < biometric data Id > < Account index > < asset Account >

The add command adds the asset account to the list of accounts in the specified account index. An optional emergency flag indicates whether the particular account index is to be treated as a personal emergency account. If the asset account existing in the account list does not belong to the issuer, the command fails. This feature prevents one bank from adding or removing asset accounts from customers of another bank without personal awareness or authorization.

The remove command clears the personal asset accounts in the account list stored in the prescribed account index. If the asset account stored in the current account list does not match the account the issuer intended to remove, the command fails.

For each command in the batch that cannot be executed correctly, the GM logs a warning of security violation and first appends an entry to the failed response list. The failed entry includes the contents of the command and an error code.

1.5.7.6 secure facsimile transmission

Secure fax delivery request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encryption (DUKPT key) human biometric data-PIC block:

300 byte authorized biometric data

4-12 bit digital PIC

56 bit response key

56 bit message key

Security code (insecure, sender secure, Security-privacy)

Sender job index code

Sender fax number

Sender fax extension information

Recipient list

[ optional filing fax indicator ]

[ optional contract/agreement indicator ]

Terminal portion: (not used)

Secure fax submission response

Encrypted (response key):

private code content

Facsimile tracking number

MAC

When the DPC receives a secure fax submission request, it identifies the individual from the requested biometric data-PIC by performing an individual identification process. This identification, along with the personal job title described by the job index code, is provided to the recipient so that the sender of the fax is always reliably identified.

The DPC generates a tracking number for tracking purposes and stores the number, sender biometric data identification, security mode, and message key in a newly created EDD file record. The DPC also creates a recipient record for each recipient in the recipient list. The DPC then waits for the sending fax machine to send fax data encrypted with the message key.

If the request contains an "archive fax" or "contract/agreement" indicator, the EDD places a copy of the file and recipient record in the archive database. Any subsequent updates to these records are also made to the version of the specification.

The fax data is sent in separate steps so that if the sender makes an error in entering his biometric data and PIC, the system will notify him before he wastes time feeding the document into the fax machine.

1.5.7.7. Secure fax data

Secure fax data request

The BIA part: (not used)

Terminal portion:

facsimile tracking number

Encrypted (message key):

facsimile image data

Secure fax data response

State (incomplete, normal)

The secure fax data request allows a secure fax machine to send fax images to the DPC for provision to a recipient that has been provisioned. This request does not involve any biometric data identification, but relies on a secret message key to securely transmit the image.

The facsimile image data is encrypted by a message key registered by the secure facsimile submission request. Once the DPC has received the complete fax, it sends a secure fax arrival notification message to each recipient fax number. The DPC retrieves the recipient list by querying the EDD for all recipient records containing fax tracking numbers. The recipient record contains the destination fax number and an optional extension. After issuing the arrival notification, the DPC updates each recipient record delivery status field to "notified". Note: if the destination fax number is busy, the DPC marks the delivery status field as "busy" and periodically retransmits the notification (i.e., once every 10 minutes) until successful and updates the status field to "notified" at this point.

The arrival notification is as follows:

secure fax arrival notification (fax information)

Sender's name, company, job title and fax number

Facsimile tracking number

Instructions for how to drop the fax.

The DPC sends only one status notification to the sender by fax after all recipients either receive the fax or reject the fax. The sender may interrogate the DPC using a secure fax tracking request (see below) to obtain the current status of all recipients.

The status notification is as follows:

secure fax status notification (fax information)

Sender's name, company, job title and fax number

Facsimile tracking number

The recipient list indicates:

name, company, job title and fax number

Date and status of transmission

Contract/agreement status

The DPC looks up the company and job title information for each individual in the EDD institutional form.

For those individuals who are not registered in the system and are therefore unable to receive secure faxes, or for those non-recipient secure modes, the DPC does not send them a secure fax arrival notification, but rather sends them a fax directly. If the fax line is busy, the DPC tries once every 10 minutes until the fax is successfully transmitted.

1.5.7.8 secure fax tracking

Secure fax tracking request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric data-PIC block:

300 byte authorized biometric data

4-12 bit digital PIC

56 bit response key

56 bit message key

Facsimile tracking number

MAC

Terminal portion: (not used)

Secure fax tracking response

Encrypted (response key):

private code content

Message digest for tracking response to facsimile images

Status code (Normal, failure)

MAC

Facsimile image for recipient status list

The DPC processes the secure fax tracking request by examining all EDD recipient records for a fax and generating a fax message that displays the records. If the individual making the tracking request is not the sender of the fax file, the DPC sets the status code to fail and places an empty fax in the response.

The tracking response fax includes information describing a status of the fax transmitted for each of the recipients. The facsimile includes the following status information: the line is busy, a fax arrival notification has been sent, a fax is rejected, a contract is accepted, etc.

The tracking notification is as follows:

secure fax tracking notification (fax message)

Sender name, company, job title and fax number

Facsimile tracking number

The receiving party displays the list:

name, company, job title and fax number

Date and status of transmission

Contract status

1.5.7.9. Secure fax retrieval

Secure fax retrieval request

The BIA part:

4 bytes of BIA identification;

4 byte sequence code

Encrypted (DUKPT key) biometric data-PIC block:

300 byte authorized biometric data

4-12 bit digital PIC

56 bit response key

Facsimile tracking code

MAC

Terminal portion: (not used)

Secure fax retrieval response

Encrypted (response key):

personal code

56 bit message key

State (incomplete, normal, invalid receiver)

Message digest for facsimile image

MAC

Encrypted (message key):

facsimile image

The DPC identifies the person making the retrieval request by executing a personal identification program using the biometric-PIC. If there is no EDD recipient record for the individual and the particular fax, the DPC responds with "invalid recipient" status information.

The DPC retrieves the encrypted fax image from the EDD file record based on the correct fax tracking number and biometric identifier that it returned to the requesting party.

The fax image includes a home page showing whether the fax is a contract/agreement, sender name, company, job title, fax number, and extension information.

When the last recipient receives or rejects the fax, the DPC sends a status notification to the sender of the fax via fax (see secure fax data above). Scheduling is then performed for a configurable period of time, with the documents and recipient records removed from the EDD. This time period allows the receiving party sufficient time to determine whether to archive the fax.

1.5.7.10. Secure fax rejection

Secure fax rejection request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometric

4-12 bit digital PIC

56 bit response key

Facsimile tracking code

MAC

Terminal portion: (not used)

Secure fax rejection response

Encrypted (response key):

personal code

Status code (Normal, invalid receiver)

MAC

The DPC utilizes biometric-PIC to identify the individual making the secure fax rejection request. The DPC finds the EDD recipient record keyed by the requested facsimile tracking number and the person's biometric identification. If no record can be found, the request is declared a failure in an "invalid recipient" state.

When the last recipient receives or rejects the fax, the DPC sends a status notification to the sender of the fax using the fax (see secure fax data above), and then schedules the fax and tracking records to be deleted from the EDD for a configurable period of time. This time period allows the receiving party sufficient time to determine whether to archive the fax.

1.5.7.11. Secure facsimile archiving

Secure facsimile archiving request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

Facsimile tracking number

MAC

Terminal portion: (not used)

Secure fax archiving response

Encrypted (response key):

personal code

Status code (Normal, invalid individual)

MAC

The DPC uses biometric-PIC to identify the individual making the request for secure facsimile archiving. The DPC finds the EDD recipient record keyed by the requested facsimile tracking number and the person's biometric identifier. If no record can be found and the person is not the sender or one of the recipients, the request is declared a failure in an "invalid person" state. Otherwise, the DPC copies the file and recipient record into the EDD document database. Any changes to these records will also be copied into the archived version thereafter.

1.5.7.12. Secure fax contract acceptance

Secure fax contract acceptance request

The BIA part:

4-byte BIA identifier

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

Facsimile tracking number

MAC

Terminal portion: (not used)

Secure fax contract acceptance response

Encrypted (response key):

personal code

Status code (Normal, invalid receiver)

MAC

The DPC uses the biometric-PIC to identify the individual making the contract acceptance request. The DPC finds the EDD recipient record keyed by the requested facsimile tracking number and the person's biometric identification. If no record can be found, the request is declared a failure in an "invalid person" state. Otherwise the DPC updates the contract status field of the receiver record to "received" and generates a status notification for the sender of the fax (see fax data above).

1.5.7.13. Secure fax contract denial

Secure fax contract denial request

The BIA part:

4-byte BIA identifier

4 byte sequence code

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

Facsimile tracking number

MAC

Terminal portion: (not used)

Secure fax contract rejection response

Encrypted (response key):

personal code

Status code (Normal, invalid individual)

MAC

The DPC uses the biometric-PIC to identify the individual making the contract denial request. The DPC finds the EDD recipient record keyed by the requested facsimile tracking number and the person's biometric identification. If no record can be found, the request is declared a failure in an "invalid recipient" state. Otherwise, the DPC updates the contract status field of the receiver record to "reject" and generates a status notification for the sender of the fax (see fax data above).

1.5.7.14. Secure facsimile mechanism change

Secure fax mechanism change (secure fax message)

Sender name, company, job title and fax number

An organization change list.

The institutional change is submitted to the DPC via a secure fax message. The requested change in the fax message is made by the customer's technical engineer and verifies that the individual submitting the request is allowed to register the individual for that particular company. Since the facsimile is a secure facsimile, the identity of the sender and its job are both confirmed.

1.5.7.15. Electronic document submission

Electronic document submission request

The BIA part:

4-byte BIA identifier

4 byte sequence code

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

56 bit message key

Recipient list

MAC

Terminal portion: (not used)

Electronic document submission response

Encrypted (response key):

personal code text

Tracking number:

status code (Normal, invalid receiver)

MAC

When the DPC receives an electronic file submission request, the individual is identified by performing an individual identification process.

The DPC then generates an EDD file record and assigns it a unique tracking number. The DPC initializes the recorded sender identification code to the biometric identification code of the identified individual and the message key to the message key in the request.

The DPC then looks up each recipient in the personal biometric database and generates an EDD recipient record for it. Each record is initialized with a tracking number, a recipient biometric identification code, and an "incomplete" transfer status. If a recipient is not found, the DPC replies to an "invalid recipient" state.

1.5.7.16. Electronic document data

Electronic document data request

The BIA part: (not used)

Terminal portion:

tracking numbers

Command (abort or data)

[ optional message offset ]

Completion indication

Encrypted (message key):

message text

Electronic document data response

State (incomplete, normal)

Electronic file data requests allow an individual to send the file body(s) to the EDD for delivery to a recipient. The request does not involve any biometric identification, but rather the text of the document is sent secretly based on a secret message key.

Assume that the request body is encrypted by a message key stored in the EDD file record and appended to the document body already stored in the record.

When the EDD receives a packet with a "file complete" indicator, it knows that the sender has completed sending the document. The EDD then sends an arrival notification to all recipients of the file via internet email, notifying them that a file is waiting.

The arrival notification is as follows:

electronic file arrival notification (Internet email message)

Sender name, company, job title, and email address

Tracking numbers

Instructions on how to receive the electronic file.

The EDD also updates the status of the EDD recipient record to "notified". When all recipients retrieve or reject the electronic file, the DPC sends a status notification to the file generation source via internet email.

The status notification is as follows:

electronic file status notification (Internet email message)

Sender name, company, job title, and email address

Tracking numbers

List of recipients, for each name, company, job title, email address

Date and status of transmission.

The DPC finds the company and job title information for each individual in the EDD authority table.

1.5.7.17. Electronic document retrieval

Electronic document retrieval request

The BIA part:

4-byte BIA identifier

4 byte sequence code

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

Tracking numbers

MAC

Terminal portion: (not used)

Electronic document retrieval response

Encrypted (response key):

personal code

56 bit message key

Status (incomplete, normal, invalid recipient);

MAC

encrypted (message key):

text of a document

The DPC uses the biometric-PIC to identify the individual making the electronic document retrieval request by performing a person identification process.

The DPC then finds EDD recipient records that are keyed to the tracking number and the personal biometric identification.

If no record can be found, the request is declared a failure with an "invalid recipient" status. Otherwise, the DPC sends the message key of the file and the file (still encrypted by the message key) to the requestor.

The EDD then updates the status of the EDD recipient record to "retrieved". When all recipients have retrieved or rejected the file, the DPC sends a status notification to the file generation source via internet email (see electronic file data above) and then schedules, deletes the file and recipient records (see secure fax retrieval).

1.5.7.18. Electronic document rejection

Electronic document rejection request

The BIA part:

4-byte BIA identifier

4 byte sequence code

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

Message tracking number

MAC

A terminal: (not used)

Electronic document rejection response

Encrypted (response key);

personal code

Status code (Normal, invalid receiver)

MAC

The DPC uses the biometric-PIC to identify the individual making the electronic file rejection request. The DPC then finds EDD recipient records that are keyed to the tracking number and the personal biometric identification. If no record can be found, the request is declared a failure with an "invalid recipient" status.

The EDD rewrites the status of the EDD recipient record to "rejected". The DPE then performs the same notification and deletion processes as described above in the electronic document retrieval.

1.5.7.19. Electronic document archiving

Electronic file archiving request

The BIA part:

4-byte BIA identifier

4 byte sequence code

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometrics

4-12 bit digital PIC

56 bit response key

Tracking numbers

MAC

Terminal portion: (not used)

Electronic file archive response

Encrypted (response key):

personal code

Status code (Normal, invalid individual)

MAC

The DPC uses biometric-PIC to identify the individual making the request for electronic file archiving. The DPC finds the EDD recipient record keyed by the requested facsimile tracking number and the person's biometric identification. If no record can be found and the person is not the sender or one of the recipients, the request is declared a failure in an "invalid person" state. Otherwise, the DPC copies the file and recipient record into the EDD archive database. Any changes to these records will also be copied into the archived version thereafter.

1.5.7.20. Electronic document file retrieval

Electronic document file retrieval request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometric

4-12 bit digital PIC

56 bit response key

Optional job index code, send fax number and extended tracking number

MAC

Terminal portion: (unused)

Electronic document archive retrieval response

Encrypted (response key):

personal code

Status code (Normal, invalid individual)

MAC

The PPC is capable of receiving electronic document file retrieval requests from a secure fax terminal or a qualified email terminal. The DPC uses a person identification process to determine the person sending the profile retrieval request. The individual must be one of the sender or the recipient, otherwise the DPC rejects the request and sets the status code to "invalid individual". However, if the archived file is a facsimile transmitted by a company post, DPC allows other individuals with higher post levels in the company level to retrieve the archived file.

The EDD maintains an archive database whose index is the initial tracking number of the file, stored on off-line media such as CD-ROMs and tapes that take considerable time to retrieve the archive. Thus, the DPC does not return the archive immediately, but rather notifies the requesting individual that the search has begun. Someday thereafter, after the DPC completes the search, it will notify the requesting party that the archived file has been retrieved by a standard file arrival notification mechanism, such as fax or email, depending on the different format of the original file.

The DPC creates an EDD profile request record to store information about the requestor so that after the search is completed, the DPC can remember to whom to send the retrieved document.

1.5.7.21. Electronic signature

Electronic signature request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometric

4-12 bit digital PIC

56 bit response key

File name

Document MDS computation

MAC

Terminal portion: (unused)

Electronic signature response

Encrypted (response key):

personal code text

Sign string

MAC

To process the electronic signature request, the DPC first performs a biometric identification with the biometric-PIC. The DPC then creates an ESD record, assigns it a unique signature identification code, and sets the record's signature field to the electronic signature in the request. The DPC then returns a signature string that can be used in later verification:

“<Dr.Bunsen Honeydew><Explosions in the Laboratory>5/17/9513 PST 950517000102”

1.5.7.22. electronic signature verification

Electronic signature verification request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometric

4-12 bit digital PIC

56 bit response key

Sign string

MAC

Terminal portion: (unused)

Electronic signature verification response

Encrypted (response key):

personal code text

Sign string

State (pass, fail validation)

MAC

The DPC performs biometric identification, extracts the signature tracking code from the signature string, retrieves the indicated ESD record and verifies that it matches the signature string. The DPC returns the result of the personal code and signature comparison.

1.5.7.23. Network credentials

Network credential request

The BIA part:

4-byte BIA identification

4 byte sequence number

Encrypted (DUKPT key) biometric-PIC block:

300 byte authorization biometric

4-12 bit digital PIC

56 bit response key

Account indexing

Bank code

Bank host name (hostname)

Terminal port and bank port (TCP/IP address)

MAC

Network credential response

Encrypted (response key):

personal code

Signed (private key of DPC):

voucher (time, account, terminal port, bank port)

Public key of bank

Status code (Normal, failure)

MAC

The DPC identifies the individual using the biometric-PIC in the request and retrieves the individual asset account stored in the designated index. If the account index is an emergency account, the network credential response status code is set to "fail" and no credential is generated.

The DPC creates credentials using the current time, the retrieved asset account and TCP/IP addresses of the terminal and bank. The DPC then encrypts with the public key to sign the credential with its private key.

The response also includes the bank's public key, which the DPC retrieves from the remote merchant database.

1.5.8. Customer support and system management messages

The DPC also processes auxiliary message types classified as internal messages. DPCs generally do not accept such messages from non-DPC systems. Such messages vary from database provider to database provider. However, the internal network uses DES encrypted packets to provide an additional degree of security.

Customer service and system management tasks are performed using the query language and application development tools of the database provider.

1.5.8.1. Customer service tasks:

IBD: searching, activating, deactivating, deleting, updating records

AID: adding or deleting authorized persons

AOD: looking up, adding, deleting, updating records

VAD: searching, activating, deactivating, deleting, updating records

RMD: looking up, adding, deleting, updating records

PFD: adding, deleting, updating records

1.5.8.2. And (3) system management tasks:

fraud pre-check

Modify the list of valid sites

Summarize log information (Warning, error, etc.)

Modify the PIC group list

Performance monitoring

Make a backup

Accident recovery procedure

Time synchronization of DPC sites

Change the master enrollment station

Changing the secret DES encryption key

Clearing old file tracking numbers

Generate a list of BIA hardware identification codes, MAC encryption keys, and DUKPT base keys. Stored on the encrypted floppy disk of the key loading device.

1.5.9. Fire wall machine

1.5.9.1. Purpose(s) to

Firewall (FW) machines provide a first line of defense against network viruses and computer hackers. All communication links to and from the DPC site pass first through a secure FW machine.

1.5.9.2. Application method

The FW machine is an internet-lan router and handles only messages arriving at the GM machine.

The BIA equipped terminal sends packets to the individual DPC sites via modem, x.25 or another communication medium. The DPC relies on third parties to provide the required modem banks to handle the large number of calls and to route the data to the DPC backbone.

For DPC-to-DPC communications, primarily for distributed transactions and sequence number updates, the FW machine sends DES encrypted packets of twice length. DPC LAN component handles encryption and decryption: the FW has no ability to decrypt the packets.

1.5.9.3. Safety feature

A suitably configured network sniffer (sniffer) acts as a backup security for the FW to detect intruders. If an anonymous message is detected, the intrusion message is recorded as a whole and alerts the operator, and the sniffer physically turns off the FW machine.

The FW does not allow any transmission from the intranet to the rest of the internet.

1.5.9.4. Message bandwidth

The transaction authorization request requires about 400 bytes and the registration package requires about 2 KB. To be able to process 1000 transaction authorizations per second and one registration bundle per second, the FW can process about 400KB per second (as is well known in the art).

Each DPC site requires a centralized bandwidth of nearly 3T 1 connections to third party modem banks and other DPC sites.

1.5.10. Network shutdown device

1.5.10.1. Purpose(s) to

The GM Machine (GM) links the outside world (BIA equipped terminals and further DPCs) to the internal components of the DPC through the FM machine. DPC has multiple GMs, usually two.

1.5.10.2. Application method

The GM is responsible for the processing of each BIA request, communicates with the DPC components as necessary, and sends the encrypted request results back to the request sender. The software that accomplishes this task is called a message processing module.

The GM records all requests it receives and any alerts received from the components it communicates with. For example, the GM records any emergency account accesses, sequence number breaks, and invalid packets.

The GM may need to inform the GM among all the other DPCs when processing a request that the DPC database has changed. When this happens, the GM runs a distributed transaction to update those remote databases.

Distributed transactions fall into two categories: synchronous and asynchronous. Synchronizing a distributed transaction requires the GM to wait for the distributed transaction to commit before continuing to process packets. Asynchronous distributed transactions do not require the GM to wait for a commit, but allow the GM to complete the processing of the request regardless of whether the distributed transaction has committed. Asynchronous distributed transactions are only used to update data that is not absolutely required for database consistency: the recording of the serial number and the biometric checksum may be performed asynchronously, while creating a database record, such as a personal biometric record, may need to be performed synchronously.

When a synchronous distributed transaction is performed, the requesting GM considers the entire transaction successful only if all sites can successfully commit the transaction locally. Otherwise, these GMs all recover the change of local data and reject the request due to transaction error.

The list of active DPC sites typically includes all of the sites. However, in the event of a site catastrophic failure, the system administrator may manually remove the site from the list of valid sites. The most common cause of distributed transaction failures, however, is a temporary network failure unrelated to any DPC device. A request that requires a synchronized distributed transaction cannot be executed until the network connection is restored or the site is removed from the list of valid sites. The system administrator will update the site database to be consistent with the database of the currently active site before adding a site back to the table with a valid site.

1.5.10.3. Software component

To improve performance, each GM runs the following software components locally:

message processing module

Message authentication code module

Message decryption module

Personal biometric database machine listing

1.5.10.4. Message bandwidth

The message bandwidth required by the GM is similar to the bandwidth required by the FW machine. An FDDI network interface can provide 100Mb per second of bandwidth and can easily meet any bandwidth requirement.

1.5.11.DPC LAN

1.5.11.1. Purpose(s) to

DPC Local Area Networks (LANs) use fiber token ring to connect the DPC site machines. Fiber token ring can provide very high bandwidth and very good physical security.

1.5.11.2. Safety feature

The network interface used by the machines on the DPC LAN includes decryption hardware to render the intercepted or snooped packets useless without the encryption key. The encryption key is stored in the encryption hardware and is the same for all machines on the LAN.

A suitably configured network sniffer acts as a backup security for the FW to detect intruders. If an anonymous message is detected, the intrusion message is recorded in its entirety and alerts the operator, and the sniffer will also physically turn off the FW machine.

j1.5.12. Message processing module

1.5.12.1. Purpose(s) to

The Message Processing Module (MPM) is responsible for processing the request. It communicates with the other components of the DPC as necessary to accomplish its tasks. MPMs are labeled GM on the machine.

1.5.12.2. Application method

The MPM maintains a request context for each currently processing request. The request context includes necessary information for maintaining a network connection to the requesting terminal, BIA device information, a response key, and a response packet.

1.5.13. Message authentication code module

1.5.13.1. Purpose(s) to

The task of the Message Authentication Code Module (MACM) is to verify the message authentication code on the inbound packet and to add a message authentication code to the outbound packet.

1.5.13.2. Application method

The MACM maintains a memory-located hash table of 112-bit MAC encryption keys keyed by the BIA hardware id.

When the MACM receives a request from a GM to validate the MAC of a packet, it first looks up the hardware id of the packet in the hash table. If there is no entry, the MACM answers the GM in error with an "invalid hardware identification code".

Otherwise, the MAC m MAC checks the BIA message portion of the packet using the 112-bit MAC encryption key. If the MAC check fails, the MACM answers GM with an "invalid MAC" error. Otherwise, the MACM replies with a "valid MAC" message.

The MACM also checks the merchant code against the owner identification code in the hash table if the package contains the merchant code. If the codes do not match, then MACM answers incorrectly with an "invalid owner".

When the MACM receives a request from a GM to generate a MAC for a packet, it looks up the MAC encryption key with the hardware identifier of the packet. With the MAC encryption key, MACM generates a MAC and adds it to the packet. If the MACM cannot find the hardware identification code in its hash table, it replies incorrectly with an invalid hardware identification code.

1.5.13.3. Database schema

The MACM hash table entries include:

MACM table entry:

int4 hardware Id

Int4 owner Id

Int16 mac encryption key

The table is hashed from the hardware identification code.

1.5.13.4. Database size

Assuming that 5 million BIA-equipped devices are used, the hash table requires approximately 120MB of storage. This hash table is located entirely in a cache area in memory for performance reasons.

1.5.13.5. Dependence on

The MACM only contains records relating to valid BIA hardware identification codes and valid device owners. When a device or device owner has hung up or removed from the system, the MACM removes any entries relating to the identification code. When a device is started, the MACM adds an entry for it.

The MACM also caches the MAC encryption key from the valid device database. Since the system does not allow the keys of the BIA to be modified, there is no need to worry about the reception of key updates by the MACM.

1.5.14. Message decryption component

1.5.14.1. Purpose(s) to

The message decryption component (MDM) task is to reconstruct the DUKPT transaction key and use it to decrypt the biometric-PIC block in the package. It maintains a list of DUKPT basic keys, which are required to generate transaction keys.

1.5.14.2. Application method

The MDM uses the package's serial number as the DJKPT transaction count, the upper 22 bits of the BIA hardware identification code as the DUKPT tamper resistant security module (or "TRSM") identifier, and the lower 10 bits of the BIA hardware identification code as the DUKPT key setting identifier to establish the DUKPT transaction key.

The DUKPT standard specifies how transaction keys are generated. The key setting identifier is used for finding out a basic key from the basic key list. The base key is used to transform the TRSM identification into the initial key through an encryption/decryption/encryption cycle. The transaction counter is then applied to the initial key in a series of DES encryption/decryption/encryption cycles to generate the transaction key.

To increase security, two basic key tables are maintained, one for low security BIA devices and one for high security devices. The MDM selects which basic key table to use based on the security level of the device.

1.5.14.3. Database schema

The MDM base key table entry contains:

MDM table entry:

int16 as the basic key

The basic key table is indexed by a key set identification.

1.5.14.4. Database size

The MDM maintains a list of DUKPT base keys in memory. Each key requires 112 bits. The MDM maintains two sets of 1024 keys, requiring a total of 32 KB.

1.5.14.5. Dependence on

MDM does not rely directly on any other DPC components.

1.5.15.PIC group List

1.5.15.1. Purpose(s) to

The PIC Group List (PGL) together with the personal biometric database list defines the IBD machine structure. The PGL stores the PIC group list in the system for simplifying PIC management. The PIC group is a set of consecutive PIC codes. PGL is present in each GM Machine (GM).

1.5.15.2. Application method

When a PIC code is given, the PGL looks up the group containing the PIC code through its PIC group list. The PGL maintains a list of groups in order and uses binary search to quickly find the correct group.

The initial structure of the PGL is a macro-PIC group containing all possible PICs. After dispensing a critical amount of PIC, the macro-PIC component splits into two. This process is then applied to all subsequent PIC groups.

Upon PIC group splitting, the PGL assigns new host and standby IBD machines based on available memory according to a first come first principle. The PCL in cooperation with the IBD machine first copies the records involved from the old master and standby machines into the new machine, updates the IML records, and finally removes the copies in the old master and standby machines. Splitting the PIC group is a self-contained task. When the DPC is lightly loaded, such as at night, the PGL batches the pending split requests.

The system administrator may also change the host and standby IBD machines if the free storage area of the machine is below the level required to expect to handle the new registration for a given PIC set.

1.5.15.3. Database schema

The PIC group recording mode is

PICGroup：

Low Pin int8

High Pin int8

used＝int4

Each PIC group is identified by a unique identification. For convenience, the PIC group identification code is the low Pin code for the group, however the system need not be based on this.

PCL keys with a low Pin field.

1.5.15.4. Database size

It is desirable for the PGL to contain about 3000 groups (each PIC group contains about 1000 valid PICs, but may span millions of actual PICs). The entire PGL requires about 72KB of storage and is fully cached in memory.

1.5.15.5. Dependence on

When adding, merging, or splitting PIC lists, the PGL is responsible for informing the IBD list of changes and directing IBD records to move from one IBD machine to another.

1.5.16. Personal biometric database machine list

1.5.16.1. Purpose(s) to

IBD Machine List (IML), which together with the PIC group list encodes the IBD machine structure. The IML maps the PIC code into the primary and alternate IBD machines that store the IBD record of the PIC. The IML is actually keyed to a set of PICs (a set of consecutive PIC codes) rather than to individual PICs, as this can save significantly on the memory space required to store the list. IMCs are present on every GM Machine (GM).

1.5.16.2. Application method

When the GM processes a request for biometric identification, the GM finds the IML record keyed by the PIC group of the biometric. The GM then knows the host and alternate IBD machines for biometric identification.

1.5.16.3. Database schema

The mode of the IML table entry is:

a machine pair:

group pin int8

Main int2

Ready to use int2

IML keys a pin group.

1.5.16.4. Database size

It is desirable that the IML include about 3000 entries (number of PIC groups). Each machine pair record is 12 bytes, requires about 36KB of memory, and is completely cached in memory.

1.5.16.5. Dependence on

Any changes in the structure of the IBD machine are reflected in the IML. In addition, the IML uses the PIC group as a key, and is updated when there is a change in the PIC group list.

1.5.17. Serial number module

1.5.17.1. Purpose(s) to

The main function of the Sequence Number Module (SNM) is to determine the validity of the packet sequence number to prevent duplicate attacks. Its second task is to notify other SNM sequence number updates in the remote DPC site, minimize the impact of a resubmit attack, and periodically update the sequence number in the active device database.

The SNM maintains a hash table of sequence numbers in memory with BIA hardware id as key to quickly identify packet sequence numbers.

1.5.17.2. Application method

When the SNM receives a request from the GM to validate a given hardware identification code and sequence number, it looks up the hardware identification code in the hash table. The GM "invalid hardware identification code" error is answered if there is no SNM.

Otherwise, the SNM checks this given sequence number against the sequence numbers stored in the hash table entries. If the sequence number is less than or equal to the stored sequence number, the SNM answers an "invalid sequence number" error. Otherwise, SNM sets the sequence number in the hash table entry to the given sequence number and replies with a "valid sequence number" message.

Sometimes SNM can observe sequence number gaps. When SNM receives a sequence number which is more than one than the sequence number in the hash table entry, the sequence number is vacant. In other words, the sequence number is skipped. When the SNM finds that the sequence number is empty, it replies a "sequence number empty" message to the GM instead of a "valid sequence number" message. The GM treats the packet as valid but is marked with a "sequence number empty" warning.

Sequence number gaps typically occur when the network connection state is lost; i.e., dropping packets or failing to be sent out before the network returns to working order. However, sequence number gaps can also occur due to fraud: malicious parties may intercept packets so that they cannot reach the DPC or they attempt to forge a packet (with a large sequence number so that it is not immediately rejected).

The second function of the SNM is to inform other DPCs of the updated sequence number. When only the first site should receive a packet, rapidly updating the sequence number at all DPC sites resists resubmit attacks in which an offender monitors packets destined for one DPC site and immediately sends a duplicate packet to a different DPC site in an attempt to make it valid for both sites to accept the packet, with the delay of transmitting the sequence number from one DPC site to another.

The SNMs send update messages to each other whenever a valid sequence number is received. If a SNM receives an update message with a sequence number that is less than or equal to the sequence number currently stored in the hash table, the SNM records the sequence number and again submits an alert. All resubmission attacks are thus detected.

A simpler method of completely resisting resubmit attacks is to have only one SNM determine the validity of a packet. In this scheme, no update of the transmission delay window may be utilized to conduct a resubmission attack. Alternatively, many SNMs work simultaneously, except that they cannot validate serial numbers for the same BIA equipped device.

1.5.17.3. Serial number maintenance

When the SNM starts, it loads the sequence number hash table from the sequence numbers of valid BIAs stored in the VAD.

Once daily, the SNM downloads the current serial number into a local active equipment database (VAD).

The VAD is responsible for sending add and remove entry messages for the SNM of any working or inactive BIA-provisioned device to keep the SNM hash table up to date.

1.5.17.4. Database schema

The SNM hash table entries include:

SNM table entry:

int4 hardware Id

Int4 serial number

The hash table is keyed by the hardware Id.

1.5.17.5. Database size

If about 5 million devices with BIAs are in use, the hash table is about 40 MB.

1.5.17.6. Dependence on

SNM relies on a database of valid devices. When a device hangs or moves from the database, the SNM removes the corresponding entry. When a device is activated, the SNM creates an entry for it.

1.5.17.7. Message bandwidth

SNM requires approximately 8KB of transmission bandwidth per second to handle 1000 update sequence number messages per second. The update sequence number messages are buffered and sent once per second to minimize the number of actual messages sent.

1.5.18. Device owner database

1.5.18.1. Purpose(s) to

The device owner database (ADD) stores information about individuals or institutions owning 1 or more devices equipped with BIAs. This information is used to double check that the BIA device is used only by the rightful owner, to provide asset account information for financial debit transactions, and to identify all BIA devices owned by a particular individual or institution.

1.5.18.2. Application method

Each ADD record includes an asset account that is credited or debited to the owner when the DPC processes a financial transaction submitted by one of the owner's BIA-equipped devices. For example, a transaction proposed from a BIA at a retail point of sale terminal involves crediting an asset account, while a verified e-mail transmission results in posting the account to the asset account.

1.5.18.3. Database schema

The device owner record mode is:

the device owner:

int4 owner Id

Name char50

Address char50

Charr 9 post code

Asset account char16

Int1 status

The status field is one of:

0: hang up

1: movement of

The device owner database is keyed by the owner Id.

1.5.18.4. Database size

It is desirable for an AOD to store about 2 million device owner records. Each table entry 130 bytes, requiring about 260MB of storage. The AOD is stored as a hash file keyed by the owner identification code. A copy of the AOD exists on each GM.

1.5.18.5. Dependence on

When an entry is removed from the AOD or suspended, any active device database records that refer to those device owners are marked as suspended. In addition, the MAC module and the sequence number module remove the table entry of the suspended device.

1.5.19. Efficient device database

1.5.19.1. Purpose(s) to

The valid equipment database (VAD) is a collection of records representing all the BIAs manufactured so far. The VAD contains for each BIA record a message authentication code encryption key and an indication of whether the BIA is active, waiting for transport or corrupted. In order to decrypt messages from the BIA, the BIA must be present and there is an active record in the VAD

1.5.19.2. Application method

At manufacture, each BIA has a unique public identification code and a unique MAC encryption key. Both are fed into the VAD recording prior to BIA usage.

When a BIA is first constructed, it is given a unique hardware identification code. When the BIA is put into use, its hardware identification code is registered by the system. First, the owner or responsible party of the BIA is entered into the device owner database (AOD). The VAD record is then directed to the AOD record and the BIA is set to active. The request from that BIA is accepted by the DPC.

When the BIA leaves the service, it is marked as inactive and the link to the AOD record is broken. No communication is accepted from the BIA,

Each BIA type and model has a security level assigned to it, indicating its physical security level. When the DPC processes a request from that BIA, it uses the security level of the BIA to measure what behavior is allowed. The DPC also provides a level of security to external financial transaction authorization services.

For example, a financial transaction authorization service may be able to deny any requests over $300 from a low security level BIA, requiring an individual to use a higher security level BIA to authorize such lines. The authorization service can also use the security level as a guide for risk-based transaction payment amounts.

The level of security and the behavior they allow is actually determined. In fact, the cost of a rogue system must be higher than the potential revenue, so the level of security is linked to the cost to compromise with the equipment.

1.5.19.3. Database schema

The modes of active device recording are:

an effective device:

int4 hardware Id

Int16 mac encryption key

Int8 owner Id

Manufacturing date int8

Service date being time

Security level int2

Int1 status

Type int1

Using int1

The state field possible values are:

0: hang up

1: activation

2: destruction of

Type field possible values are (one for each type of terminal)

0：ATM

1：BRT

2：CET

3：CPT

4：CST

5：EST

6：IPT

7：IT

8：ITT

9：PPT

10：RPT

11：SFT

The possible values of the use field are:

0: retail sale

1: personal

2: distributor

3: remote control

The database of valid devices is keyed by a hardware identification code.

1.5.19.4. Database size

The VAD handles approximately 500 tens of thousands of retail, distributor and remote active equipment entries, each 51 bytes, requiring 255 MB. The VAD is stored as a hash file keyed by the hardware identification code. One copy of the VAD is stored on each GM.

The number of personally valid device entries in the range of 3 million requires another 1.5GB of storage.

1.5.19.5. Dependence on

When the VAD records a change of state, the MAC module and the serial number module are notified of the change of state. For example, when a device becomes active, MACP and SNM add an entry for the newly activated device. When a device becomes inactive, MACP and SNM remove their entries for the standby.

1.5.20. Personal biometric database

1.5.20.1. Purpose(s) to

Personal biometric database (IBD) records store personal information, including their primary and secondary biometric data, PIC codes, financial asset account lists, unique codes, emergency accounts, addresses, and phone numbers. Individuals may also selectively include their SSN and email addresses. This information is necessary to identify an individual by either biometric or personal information, access account information, or provide an address or telephone number for a remote merchant for additional verification.

1.5.20.2. Application method

In the individual enrollment process, an individual is added to the system at a biometric enrollment terminal that is enrolled by a retail banking institution or local system institution worldwide. During registration, the individual selects their personal identification number and adds the financial asset account to their biometric and PIC combined data.

The personal information can be removed from the database when fraud is reported by any issuing member. If this occurs, the individual's account information is moved from the IBD to a Previous Fraud Database (PFD) by an authorized internal system representative. Biometric identification recorded in PFD cannot be used for recording in IBD.

IBDs exist on multiple machines, each responsible for a subset of IBD records, with copies of each record stored on two different machines, both for redundancy and load sharing. The list of IBD machines stored on the GM, which machine holds which PIC, is maintained.

1.5.20.3. Database schema

The modes for personal biometric recording are:

personal biometrics:

principal biological characteristics (biometrical)

Biometric feature of the auxiliary

Biometric Id int4

PIC＝char10

Char12

Surname ═ char24

Named char24

The intermediate name is char2

SSN＝char9

Char40 as a special code

Address char50

Charr 9 post code

Char64 as a public key

Check sum int4[10]

Account Link char30[10]

Emergency index char1

Char1 for emergency links

Charr 10

Registrar int8

Int4 emergency usage count

Int1 status

One of the status fields is:

0: hang up

1: movement of

2: previous fraud

IBD is keyed by PIC.

1.5.20.4. Database indexing

Each IBD machine has additional indices of personal social security number, biometric identifier, last name, first name, and phone number to facilitate access to the IBD database.

1.5.20.5. Database size

Each IBD machine has a secondary storage of 40GB provided by one or more RAID devices. 2658 bytes per IBD record (assuming that the biometric data is 1K each), allowing up to 1500 ten thousand records per machine. IBD records are stored on the PIC using a (perhaps clustered) secondary index that is stored in memory and requires no more than 64MB of storage (a 64MB index manages approximately 1600 ten thousand entries). To store records for 3 billion individuals, DPC requires at least 40 IBD machines: 20 IBD machines are used for primary storage and 20 are used for backup. The number of IBD machines can easily be increased or decreased depending on the number of individuals enrolled.

1.5.20.6. Dependence on

The IBD machine, the PIC group list, and the IBD machine list utilize which PIC is up-to-date on which machine. When a PIC group reconfigures or the primary and backup machines for the PIC group change, the IBD machine updates its database and index appropriately.

1.5.21. Authorized personal database

1.5.21.1. Purpose(s) to

For each issuer or individual having a BIA device, an authorized personal database (AID) maintains a list of individuals authorized to use it by the device owner.

There are two reasons for the presence of AID. The first is that it provides a restricted access terminal. For example, the issuer terminal may only be used by authorized bank representatives. A second reason for AID is to prevent criminals from secretly replacing the BIA in the retail point of sale terminal with the personal BIA of the telephone terminal and then transferring all money to a remote merchant account established by the criminal.

1.5.21.2. Database schema

The authorized personal data schema is:

the authorized person:

int4 hardware Id

Biometric Id int4

The hardware Id refers to a record in the database of valid devices and the biometric Id refers to a record in the database of personal statistics. Whenever the DPC needs to verify that an individual is authorized to use an individual or issuer device, the DPC verifies the presence of the authorized individual's records with the correct hardware Id and biometric Id.

The personal BIA device is identified by a usage field with 1 (person) set in the valid device database. The issuer BIA device is identified by a usage field set to 2 (issuer) in the valid device database.

1.5.21.3. Database size

Assuming that each publisher terminal has 10 individuals authorized to use it and each person device has two additional authorized individuals, 1,000,000 individual devices in the server, the AID stores about:

10 × 100,000+2 × 1,000,000 ═ 3,000,000 items

The entire database requires about 24MB of storage.

1.5.21.4. Dependence on

When an authorized owner database record or a valid device database record is removed, all authorized personal records referencing them are removed.

1.5.22. Database of previous fraud

1.5.22.1. Purpose(s) to

The Previous Fraud Database (PFD) is a collection of records representing individuals who have at some point in the past fraudulent issuer members. The PFD also runs a background transaction during periods of low activation of the system to purge individuals in IBD who have matching records in the PFD.

The system does not automatically place individuals into the PFD unless it detects that they are attempting to re-register, which is a sensitive policy issue, beyond the scope of this document.

1.5.22.2. Application method

The primary and secondary biometric data of the individual are examined against each in the PFD using the same biometric comparison technique as used in the individual identification process before a new IBD record is activated. If a match is found for the new IBD record, the status of the IBD record is set to "previous fraud". If a previous fraud check is made as part of the registration request, the GM records an alert that a previously fraudulent person is registered.

It is assumed that the PFD will remain relatively small. The cost of running a PFD is expensive because it is an occasional biometric search, so only those individuals who add significant expense to the system are added to the PFD.

1.5.22.3. Database schema

The previous fraud recording mode is:

previous fraud:

principal biological characteristics (biometrical)

Biometric feature of the auxiliary

Biometric Id int4

PIC＝char10

Char12

Surname ═ char24

Named char24

The intermediate name is char2

SSN＝char9

Special signal char40

Address char50

Charr 9 post code

Char64 as a public key

Check sum int4[10]

Account Link char30[10]

Emergency index char1

Char1 for emergency links

Charr 10

Registrar int8

Int4 emergency usage count

Int1 status

One of the status fields is:

0: hang up

1: movement of

2: previous fraud

The PFD is keyed by a biometric.

1.5.22.4. Database size

PFD recordings are identical to IBD recordings. Fortunately, the DPC only needs to store a small portion of it, so only two database machines are needed to store the entire database, one of which is a backup.

1.5.22.5. Dependence on

PFD did not have any direct correlation to any other DPC component.

1.5.23. Publisher databases

1.5.23.1. Purpose(s) to

The Issuer Database (ID) stores information about banks and other financial institutions whose asset accounts allow access through the system. The issuing authority is the only authority that can add or remove its asset account number from the IBD record of a given individual.

1.5.23.2. Application method

The DPC uses the ID to confirm the request from the issuer terminal by searching for a record in the ID containing the issuer code of the issuer terminal. The owner identification stored in the record must match the owner stored in the BIA valid device database stored in the publisher terminal.

The distributor records are:

the issuer records:

distributor code int6

Int4 owner Id

Name char50

Char12

Address char50

Charr 9 post code

The publisher database is keyed by a publisher code.

1.5.23.3. Database size

The publisher database handles about 100,000 entries. Each entry is 127 bytes requiring less than 2 MB. A copy of the ID is present on each GM.

1.5.23.4. Dependence on

The publisher database does not have any direct dependency on any other DPC component.

1.5.24. Electronic file database

1.5.24.1. Purpose(s) to

Electronic Document Databases (EDDs) store and track electronic documents, such as facsimile images and electronic mail messages, to a particular individual. It also maintains a corporate architecture to provide an official job classification for both the sender and the recipient. The EDD also archives the file with the sender's or recipient's request and provides neutral third party verification of the contractual agreement submitted by the system.

1.5.24.2. Application method

When the DPC receives a fax or other electronic file from a person, it generates an EDD file record to store the file until the file is accessed by an authorized recipient.

For facsimile documents, the recipient is specified by a facsimile number and extension. For other electronic files, the recipient is specified by an email address. The DPC uses the fax number and extension or email address to look up the institution record for each recipient. If no records are found, the DPC looks up from the personal biometric database only if the recipient is specified by the email address. If found, for each recipient, the DPC generates a recipient record that relates the file and the recipient biometric data identification specified by the institution or IBD record. The PC allows a receiver who is not registered in the system, but confidentiality of transmission or reception cannot be guaranteed.

The EDD is flexible enough to ensure that fax documents are sent to someone's email address, as well as email messages to a fax machine.

When the system does not set an electronic signature on the document, the system can ensure, undoubtedly by encryption, that the message received (and decrypted) by the verification email or the secure fax terminal is sent by said person.

Authorized officers of the organization may submit secure fax or electronic messages to the DPC, assign job titles and fax extensions to new members, update member job titles or fax extensions, or remove terminated members.

When someone is removed from the fabric tree, the DPC discards the extension number for a period of one year. The retirement period allows the individual enough time to notify their friends that they will not be able to receive a confidential fax at the extension so that the organization does not mistakenly send a fax to others on the extension, but rather have others receive a fax that is not intended for him or her.

The EDD maintains an archive file database containing copies of files and recipient records at the request of one of the sender or recipient of the files. The archive file database is periodically moved to a CD-ROM.

1.5.24.3. Database schema

EDDs have three record types:

recording files:

file number int8

Sender Id int4

Fax for document

File text

Int8 message key

Int1 status

Receiver recording

File number int8

Int4 receiver Id

Receiver fax number char12

Receiver fax extension char8

Receiving e-mail address (text)

To int4

Time for the final modification

Int1 transfer status

Contract status int1

Filing request record:

biometric data Id int4

File number int8

Requester fax number char12

Requester fax extension char8

Requester e-mail address text

And (3) recording by a mechanism:

biometric data Id int4

Int4 enrolled person

Company as text

Job as text

Char12

Fax extension char8

E-mail address (text)

Effective date being time

privs＝int2

Int1 status

The file record status field is one of the following:

0: unfinished

1: is normal

The receiver records the delivery status field as one of the following:

0: unfinished

1: of notification

2: refused to

3: retrieved

4: insecure of retrieval

5: busy

The receiver records the contract status field as one of the following:

0: is free of

1: receiving

2: rejection of

The mechanism record status field is one of the following:

0: is effective

1: suspended

The mechanism record privileges field is used to indicate to the DPC those privileges that the individual is allowed:

0: registration

The file, the receiver and the archive retrieval record are keyed by a file number. The institution records are keyed by biometric data Id. The EDD maintains a secondary index on the sender Id field, the receiver Id field, the agency company name and job title field.

1.5.24.4. Database size

Since email messages are relatively small compared to fax pages, the need for EDD storage depends primarily on the number of fax pages that need to be stored. Each fax page requires more than 110KB of storage. Assuming 4 pages per fax, two per person per day, and 3000 ten thousand fax machines, the EDD requires 24GB of storage to store one day of fax.

1.5.24.5. Safety feature

Encrypted using the BIA encryption mechanism, files are sent to and from the system. However, the encryption key is stored in the same database as the file. The files are kept in an encrypted state to avoid accidental leakage, but people concerned about the security of the files deposited in the system should set additional encryption themselves.

1.5.24.6. Message bandwidth

Each fax requires about 110KB, meaning a T1 connection, with a throughput of 1.54 MB/sec, which can process about 1.75 fax pages per second.

1.5.25. Electronic signature database

1.5.25.1. Purpose(s) to

An Electronic Signature Database (ESD) identifies and tracks all electronic signatures generated by the system.

1.5.25.2. Application method

The person who is a member of the system, together with the biometric data PIC, submits a 16-byte "message digest" for the document and obtains a "digital signature", which is permanently kept in the document of the system. The digital signature encodes the individual's name, biometric data identification code, authorized signature record number, document title, and time stamp when the document was signed.

To verify the signature, the message digest of the document is first computed (e.g., MD5 using RSA) and sent along with the signature tag of the document. The ESD looks up the signature tag and verifies the message digest just computed against the message digest stored in the database.

1.5.25.3. Database schema

The schema for email recording is:

electronic signature:

sign number int8

Int4 signatory

File name is text

Check sum int16

Time is the date

A signatory is a biometric identification code of an individual who has signed a document. The electronic signature record is hashed with the signature number.

1.5.25.4. Database size

The electronic signature database stores two hundred and seventy thousand records (each of about 32 bytes) for each 1GB of secondary memory.

1.5.25.5. Dependence on

ESD relies on biometric identification of the signatory. Since these signatures remain permanently valid, the ESD records are not removed when the system deletes the personal biometric database record of the signatory. Note that IBD is never identified with biometric data.

1.5.26. Remote merchant database

1.5.26.1. Purpose(s) to

The Remote Merchant Database (RMD) stores information of merchants who provide goods and services through a phone, a cable television network, or the internet. Each order placed by an individual through a suitably equipped terminal is directed to the system through a merchant order terminal.

1.5.26.2. Application method

Upon receipt of a personal remote transaction authorization and MAC verified by the DPC, the merchant code is compared with the merchant code in the RMD. The merchant code, which may be a telephone number, a merchant-product voucher or an internet address, exists in the RMD in the form of a correct merchant identification code, otherwise the DPC interrupts the request and returns an invalid merchant code error to the sending BIA terminal device.

1.5.26.3. Database schema

The mode for remote merchant recording is:

remote merchant:

merchant Id int4

Commercial tenant code char16

Type of merchant int1

Int16 public key

The remote merchant type is one of:

0: telephone set

1：CATV

2: internet network

The merchant Id and the merchant code are both primary keys. There are no two RMD records with the same merchant Id and merchant code combination.

1.5.26.4. Database size

Assuming there are about 100,000 remote merchants, the RMD requires about 24 bytes per record, for a total of 2.4MB of storage.

1.5.26.5 dependence

RMD has no direct dependence on any other DPC moiety.

1.5.27. System performance

The primary performance indicator is how many financial authorization transactions per second the DPC can process.

In the GM:

MACM test MAC (local)

SNM check sequence number (network message)

MDM decrypts biometric data-PIC Block (local)

4. Finding IBD devices (local)

5. Sending an identification request (network message) to an IBD device

In an IBD device:

6. all IBD records are retrieved for the PIC (x seeks and x reads, where x is the number of pages needed to store the biometric data record).

7. For each record, its principal biometric data (y/2ms, where y is the number of records retrieved) is compared.

8. If there is no reasonable match, step 9 is repeated but the ancillary biometric data (z x y/2ms, where y is the number of records retrieved and z is the likelihood of finding no match) is compared.

9. The best matching IBD record checksum is updated and checked for possible replay attacks (1 seek, 1 read, and 1 write).

10. Return the best match IBD record or return an error message (network message) if the match is not close enough.

In the GM:

11. authorization request (network message) with external processor

GM encryption and MAC response (local).

13. A response packet (network message) is sent back.

Total disk demand

x*(s+r)+y/2*(1+z)+s+r+w+5*n

＝(x+1)*(s+r)+y/2*(1+z)+w+5*n

[ assuming that x is 20, y is 30, and z is 5%; s is 10ms, r is 0ms, w is 0ms, and n is 0ms

＝21*10ms+15*1.05ms

＝226ms

＝4.4TPS

[ assuming that x is 10, y is 15, and z is 5%; s is 10ms, r is 0ms, w is 0ms, and n is 0ms

＝11*10ms+7.5*1.05ms

＝118ms

＝8.4TPS

[ assuming that x is 1, y is 1, and z is 5%; s is 10ms, r is 0ms, w is 0ms, and n is 0ms

＝2*10ms+1/1.05ms

＝21ms

＝47TPS

The backup IBD device also handles requests for double active TPS.

Worst case (both devices are in use):

number of people per PIC TPS

30 8

15 16

1 94

Average case (20 machines in use):

number of people per PIC TPS

30 88

15 168

1 940

Best case (40 machines in use):

number of people per PIC TPS

30 176

15 336

1 1880

The above is merely an example of one configuration of a system that may be implemented in a commercially viable manner. However, it is contemplated that the invention can be configured in a number of ways, such as with faster computers, more computers, and other changes.

1.6. Terminal protocol flow

The following set of protocol flows describe the interaction between a particular terminal, DPC, additional BIA and other parties such as credit/debit processors and the like.

1.6.1 retail Point-of-sale terminal

In this example, the RPT communicates with the retail BIA and DPC to authorize the transaction. The transaction amount is 452.33, the personal account is 4024-.

RPT → BIA setting language < English >

BIA → RPT may

RPT → BIA biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → RPT may

RPT → BIA derived Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

Personal entry into PIC, then < carriage Return >

BIA → RPT may

RPT → BIA Account <40>

BIA/LCD: < now enter your account index code and then press < enter >

Personal enter code, then < carriage return >

BIA → RPT may

RPT → BIA confirmation magnitude <452.33> <40>

BIA/LCD: < may magnitude 452.33? < CHEM > A

The personal input can

BIA → RPT may

RPT → BIA evaluation register <1> <123456>

BIA → RPT may

RPT form message < transaction >

BIA → RPT < transaction request message >

BIA → RPT may

BIA/LCD: < I am talking to DPC center >

RTP → DPC < transaction request message >

DPC confirms the biological characteristic data, retrieves account → 4024-

DPC → V ISA < authorization 4024-

V ISA → DPC < authorization code 4024-

DPC: obtaining a unique code

DPC → RPT < transaction response message >

RPT → BIA display response < transaction response message > <8>

BIA/LCD: < transaction completion: i are completely persuaded >

BIA → RPT < may < authorization code >)

RPT: printing receipts with authorization codes

1.6.2. Internet point-of-sale terminal

In this example, the IPT communicates with a standard BIA and the DPC authorizes a transaction. The transaction amount is 452.33, the personal account is 4024-.

Com < if the resource allows please give me merchant code >

m ergot.com → IPT < may be 123456m ergot.com-public Key >

IPT generates a session key, encrypts with m exchange

Com < session key >

All subsequent communications with the merchant are encrypted with the session key.

Com → IPT < price and product information >

IPT/Screen: displaying price and product information

An individual: the item "dried fruit cake, price 45.33" is selected "

IPT → BIA setting language < English >

BIA → IPT may

IPT → BIA for biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → IPT may

IPT → BIA for Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

The person enters the code and then presses < carriage return >

BIA → IPT may

RPT → BIA Account <40>

BIA/LCD: < now enter your account index code and then press < enter >

The person enters the code and then presses < carriage return >

BIA → IPT may

IPT → BIA confirmation of the magnitude <45.33> <40>

BIA/LCD: < magnitude 45.33 may be? < CHEM > A

The personal input can

BIA → IPT may

IPT → BIA evaluation register <1> <123456>

BIA → IPT may

IPT → BIA assignment register <1> < m erchant. com >

BIA → IPT may

IPT → BIA assignment register <1> < dried fruit cake >

BIA → IPT may

IPT → BIA forms message < remote transaction >

BIA → IPT < remote transaction request message >

BIA → IPT may

BIA/LCD: < I am talking to DPC center >

Com < remote transaction request message >

Com → security-connecting to DPC using DPC public key

m exchange. com → DPC < remote transaction request message >

DPC confirms the biological characteristic data, retrieves account → 4024-

Com.m. internet is confirmed by DPC using code 123456

DPC → V ISA < authorization 4024-

V ISA → DPC < optional 4024-

DPC: obtaining a unique code

DPC → m exchange. com < transaction response message >

Com stores authorization codes

Com → IPT < transaction response message >

IPT → BIA display response < transaction response message > <8>

BIA/LCD: < transaction completion: i are completely persuaded >

BIA → IPT < transaction completion >

1.6.3. Internet cashier terminal

In this example, the ITT communicates with the standard BIA, DPC and bank internet servers, performing routine and non-routine primary banking operations. Note that the DPC does not participate in the actual verification of any transaction, but is only responsible for generating a valid set of network credentials and securing the communication line to the bank.

Com < if resources are available, send me a bank code >

bank.com → ITT < may 1200>

ITT → BIA setting language < English >

BIA → ITT may

ITT → BIA biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → ITT may

ITT → BIA for Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

Personal enters PIC and then presses < carriage return >

BIA → ITT may

RPT → BIA Account <40>

BIA/LCD: < now enter your account index code and then press < enter >

The person enters the code and then presses < carriage return >

BIA → ITT may

ITT → BIA evaluation register <1> <1200> < Bank code >

BIA → ITT may

ITT → BIA evaluation register <2> < bank.com >

BIA → ITT may

ITT → BIA assignment register <3> < ITT port,

com port > (TCP/IP address)

BIA → ITT may

ITT → formation message < network credential >

BIA → ITT < network credential request >

BIA → ITT may

BIA/LCD: < I am talking to DPC center >

ITT → DPC < network credential request >

DPC: validating biometric data, generating vouchers (time, account, bank)

DPC: obtaining a unique code

DPC → ITT < network credential request >

ITT → BIA display response < network credential response >

BIA decrypts the response, checks the response

BIA/LCD: < the credential may: i are completely persuaded >

BIA uses the public key pair certificate of bank, session key,

Require a key to encrypt

BIA → ITT < secure connection request message >

BIA → ITT < session Key >

BIA → ITT may

BIA/LCD: com make a secure connection to bank >

ITT → bank.com < Security connection request message >

Com utilizes private key to decrypt, validate credentials, use shared key

Com → ITT < may >

Com connected further transactions are encrypted by ITT using ITT/bank session key.

Any transaction that the bank determines is non-routine must be confirmed by the individual using the BIA's demand-response mechanism.

The demand-response mechanism is only feasible if the BIA is in a "secure connection" state.

Com → ITT < confirm request >)

ITT → BIA confirmation private information < encrypted confirmation request >

BIA decrypts the requested part and displays it

BIA/LCD: < please grant: 12,420.00 is transferred to 1023-

The user input can

BIA re-encrypts response with Requirements Key

BIA/LCD: com make a secure connection to bank >

BIA → ITT < may < encrypted confirmation response >)

ITT → bank.com < encrypted confirmation response >

1.6.4. Electronic signature terminal

In this example, the EST communicates with a standard BIA and DPC to form a digital signature. Personal special code

The document that "i'm completely persuaded" and signed is called "commodity model certificate".

CET → BIA setting language < English >

BIA → CET

CET → BIA for biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → CET

CET → BIA for Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

User enters PIC and then presses < carriage return >

BIA → CET

CET → BIA confirmation document < product model number > <40>

BIA/LCD: < document "article model number certificate" ok? < CHEM > A

The user input can

BIA → CET

CET → BIA evaluation register <1> < File MD5 value >

BIA → CET

CET → formation of message < signature present >

BIA → CET < electronic signature request >

BIA → CET

BIA/LCD: < I am talking to DPC center >

CET → DPC < electronic signature request >

DPC: validating biometric data, generating a signature, returning a signed text code

DPC: obtaining a unique code

DPC → CET < electronic signature request >

CET → BIA display response < electronic signature response > <8>

BIA/LCD: < completion of the file: i are completely persuaded >

BIA → CET < may < sign-on-text code >)

1.6.5. Authenticated email terminal

In this example, the CET communicates with a standard BIA and DPC to transmit authenticated e-mail. The personal unique code is "i am completely persuaded" and the file name is "school captain".

CET → BIA setting language < English >

BIA → CET

CET → BIA for biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → CET

CET → BIA for Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

User enters PIC and then presses < carriage return >

BIA → CET

CET → BIA confirmation document < Ship Length of school > <40>

BIA/LCD: is the document "the school carrier length" ok? < CHEM > A

The user input can

CET/Screen: < list of recipients? < CHEM > A

User input < fred @ telerate. com joe @ reuters. com >

CET → BIA assignment register <1> < fred @ telerate

oe@reuters.com>

BIA → CET

CET → formation message < File commit >

BIA → CET < electronic File submission request >

BIA → CET

BIA/LCD: < I am talking to DPC center >

CET → DPC < electronic File submission request >

DPC: confirm biometric data, generate message, return message #001234

DPC: obtaining a unique code

DPC → CET < electronic File submission response >

CET → BIA display response < electronic File submission response > <8>

BIA/LCD: < completion of the file: i are completely persuaded >

BIA → CET < File can be <1234>

CET → DPC < electronic document data request, 1234, part 1, not completed >

DPC → CET < electronic document data response, not completed >

CET → DPC < electronic document data request, 1234, part 2, not completed >

DPC → CET < electronic document data response, not completed >

CET → DPC < electronic document data request, 1234, part 3, not completed >

DPC → CET < electronic document data response, not completed >

CET → DPC < electronic document data request, 1234, part 4, complete >

DPC → CET < electronic document data response, Trace 1234.11234.2 >

DPC → fred @ telerate. com < email 1234.1 message arrival >

DPC → joe @ reuters. com < email 1234.2 message arrival >

mail @ telerate. com → DPC < notification email received 1234.1>

DPC → sender @ com company.com < email 1234.1 recipient is notified >

mailer @ reuters. com → DPC < Notification of reception 1234.1E >

DPC → sender @ com company.com < email 1234.1 recipient is notified >

[ CET at Fred: fred stores the "message arrives" email message and decides to fetch the message ]

CET → BIA setting language < English >

BIA → CET

CET → BIA for biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → CET

CET → BIA for Pin <40>

BIA/LCD: < please enter your PIC >

Personal enters PIC and then presses < carriage return >

BIA → CET

CET → BIA evaluation register <1> <1234.1>

BIA → CET

CET → formation message < File retrieval >

BIA → CET < electronic document retrieval request >

BIA → CET

BIA/LCD: < I am talking to DPC center >

CET → DPC < request for electronic document retrieval >

DPC: validating biometric data, looking up 1234.1

DPC: obtaining a unique code

DPC → CET < electronic document retrieval response >

CET → BIA display response < electronic document retrieval response > <8>

BIA/LCD: < completion of the file: i are completely persuaded >

BIA → CET < File can be < message Key >)

CET/Screen: decrypt and then display the file

1.6.6. Secure fax terminal

In this example, the SFT communicates with the BIA/catv and DPC to transmit the secure fax.

SFT → BIA acquisition of biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → SFT may

BIA/LCD: < please enter your PIC, then press < carriage return >)

User PIC, then press < carriage return >

SFT → BIA acquisition of P in <40>

BIA/LCD: < please enter your job index, then press < carriage return >)

The user enters the job index and then presses < enter >

SFT → BIA sets job index code <40>

BIA → SFT may

SFT/Screen: < receiving party? (extension plus, end plus #) >)

User input < 1510944-

SFT/Screen: < receiving party? (extension plus, end plus #) >)

User input < 1415-

SFT/Screen: < receiving party? (extension plus, end plus #) >)

User input < # >

SFT → BIA evaluation register <1> <15109446300 × 52514158777770 >

BIA → SFT may

SFT → formation message < File commit >

BIA → SFT < secure fax submission request >

BIA → SFT may

BIA/LCD: < I am talking to DPC center >

SFT → DPC < secure fax submission request >

DPC: confirm biometric data, generate message, return message #001234

DPC: obtaining a unique code

DPC → SFT < secure fax submission response >

SFT → BIA display response < secure fax submission response > <10>

BIA/LCD: < completion of the file: i are completely persuaded >

BIA → SFT < File can <001234>

SFT → DPC < secure fax data request, 1234, part 1, not complete >

DPC → SFT < secure fax data response, not completed >

SFT → DPC < secure fax data request, 1234, part 2, not completed >

DPC → SFT < secure fax data response, not completed >

SFT → DPC < secure fax data request, 1234, part 3, not completed >

DPC → SFT < secure fax data response, not completed >

SFT → DPC < secure fax data request, 1234, part 4, complete >

DPC → SFT < secure fax data response >

DPC → connection fax 15109446300

DPC → SFT6300< fax first Page "Sam Spade" from "Fred Jones

1234.14 Page waiting >

DPC → disconnection

DPC → connection fax 14158777770

DPC → SFT7770< faxing first page "John Jett" from "Fred Jones

1234.24 Page waiting >

DPC → disconnection

[ SFT at Sam: sam sees the fax home page from Fred and retrieves the file from DPC using tracking code 1234.1. ]

SET → BIA acquisition of biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user (Sam) places a finger on the scanner

BIA → SFT may

SFT → BIA derived Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

User (Sam) enters job index and then presses < carriage return >

BIA → SFT may

SFT → BIA evaluation register <1> <1234.1>

BIA → SFT may

SFT → formation message < File retrieval >

BIA → SFT < secure fax retrieval request >

BIA → SFT may

BIA/LCD: < I am talking to DPC center >

SFT → DPC < secure fax retrieval request >

DPC: confirming biometric data, searching 1234.1, verifying biometric data

PIC＝Sam Spade

DPC: looking up specialized codes in a database

DPC → SFT < secure fax retrieval response >

SFT → BIA display response < secure fax retrieval response > <8>

BIA → SFT < file can: i are completely persuaded < message key >

SFT/Screen: the < file can: i are completely persuaded >

SFT/Screen: printing fax

1.6.7. Biometric data registration terminal

In this example, the BRT communicates with a registration BIA and DPC to register the user in the system.

BRT → BIA setting language < English >

BIA → BRT may

BRT → BIA biometric data <20> < Main >

BIA/LCD < please place the main finger on the illumination plate >

The user places the main finger on the scanner

BIA → BRT may

BRT → BIA to obtain the biometric data <20> < Assist >

BIA/LCD < please place the auxiliary finger on the illumination plate >

The user places an auxiliary finger on the scanner

BIA → BRT may

SFT → BIA derived Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

User input 123456, then press < enter >

BIA → BRT may

BRT → BIA gets message key

BIA → BRT < may < message key >

BIA → < registration request message >

BRT/screen: < name: < CHEM > A

Representing input < R red G.Shultz >

BRT/screen: < address: < CHEM > A

Representative input <1234 North Main >

BRT/screen: < postal code: < CHEM > A

Representative input <94042>

BRT/screen: < special code: < CHEM > A

Representative asks about the person and then enters < I am completely persuaded >

BRT/screen: < list of asset accounts: < CHEM > A

Representative input <2, 1001- > 2001- > 1020- > 2011 (credit card)

Representative input <3, 1001- > 1002- > 0039- > 2212 (checking account)

BRT/screen: < Emergency Account >

Representative input <1, 1001- > 1002- > 0039- > 2212 (urgent, checking account)

BRT → formation message < registration >

BIA → BR < registration request message >

BIA → BRT may

BIA/LCD: < I am talking to DPC center >

BRT appends message-key cut-encrypted personal information to request

BRT → DPC registration request message < encrypted personal information >

DPC: confirmation of PIC 123456

DPC → BRT < registration response message >

BRT → BIA display response < registration response message > <8>

BIA/LCD < registration complete: i were completely persuaded, 123456>

BIA → BRT < may >

1.6.8. Customer service terminal

In this example, the CST communicates with a standard BIA and DPC to verify the identity and credentials of the individual.

CST → BIA setting language < English >

BIA → CST may

CST → BIA acquisition of biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → CST may

CST → BIA to obtain Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

User enters PIC and then presses < carriage return >

BIA → CST may

CST → BIA gets the message key

BIA → CST < may < message Key >

CST → formation message < subscriber identity request >

BIA → CST < subscriber identity request >

BIA → CST may

BIA/LCD: < I am talking to DPC center >

CST → DPC < subscriber identity request >

DPC: obtaining special code, personal privileges

DPC → CST < subscriber identity response >

CST → BIA display response < user identification response > <8>

BIA/LCD < identification complete: i are completely persuaded >

BIA → CST < may be < personal name privilege >)

CST: checking privileges to see if it is sufficient for CST use

1.6.9 distributor terminal

In this example, IT communicates with a standard BIA and DPC to authorize and send a set of account add and delete requests to the DPC. The personal-specific code is "i have been completely persuaded," and the bank code is 1200.

IT → BIA setting language < English >

BIA → IT

IT → BIA to obtain biometric data <20>

BIA/LCD < please place finger on the illumination plate >

The user placing a finger on the scanner

BIA → IT

IT → BIA to obtain Pin <40>

BIA/LCD: < please enter your PIC, then press < carriage return >)

User enters PIC and then presses < carriage return >

BIA → IT

IT → BIA evaluation register <1> <1200>

BIA → IT

IT → BIA gets the message key

BIA → IT < message Key >)

BIA → IT

IT → BTA form message < publisher request >

BIA → IT < publisher batch request >

BIA → IT

BIA/LCD: < I am talking to DPC center >

IT → DPC < issuer batch request > < issuer encrypted by message key

Batch processing >

DPC: confirmation of biometric data, confirmation of bank code 1200 and BIA identification

DPC: obtaining a unique code

DPC: issuer batch processing using message key decryption

DPC → IT < publisher batch response >

IT → BIA display response < publisher batch response > <8>

BIA/LCD < batch complete: i are completely persuaded >

BIA → IT < may >

1.6.10. Automatic teller machine

In this example, the ATM communicates with an integrated ATM BIA and DPC to identify the user and obtain his bank account number. The user account is 2100-.

ATM → BIA biometric data <20>

ATM/LCD < please place finger on the Lighting Board >

The user placing a finger on the scanner

BIA → ATM

ATM/LCD: < please enter your PIC, then press < carriage return >)

The user enters 123456 on the ATM keypad and then presses < enter >

ATM → BIA setting Pin <123456>

BIA → ATM

ATM/LCD: < now enter your account index code and then press < carriage return >)

User input 2, then < carriage return >

ATM → BIA sets Account index code <2>

BIA → ATM

ATM → BIA evaluation register <1> <2100>

BIA → ATM

ATM → formation message < Account Access >

BIA → ATM < Account Access request message >

BIA → ATM

ATM/LCD: < I am talking to DPC center >

ATM → DPC < Account Access request message >

DPC: confirming the biometric data, retrieving account → 2100-

1201

DPC: obtaining a unique code

DPC → ATM < Account Access response message >

ATM → BIA decrypt response < Account Access response message >

BIA → ATM <2100- > 0245- > 3778- > 1201> < No Emergency > < I have been completely completed

Persuasion >

ATM/LCD < I have been completely persuaded >

At this point the ATM has the account number it needs to proceed with, so it then retrieves the information associated with that account number and interacts with the user.

1.6.11. Telephone point-of-sale terminal

In this example, the PPT communicates with an integrated phone BIA and phone merchant to securely download information and purchase items using the phone. The user PIC is 1234, the account index code is 1, the merchant phone number is 1800542-.

Note that the phone removes the area code (1-800) before placing the phone number into the system.

User places telephone 18005422231

PPT → connect merchant 18005422231

PPT → BIA assignment register 1<5422231>

The sales representative responds. The user selects the item "do cake".

Sales representative downloads information

Merchant → PPT <123456 dry fruit cake 43.54>

PPT → BIA acquisition of biometric data <20>

telephone/LCD: < please place finger on the light board >

The user placing a finger on the scanner

BIA → PPT may

telephone/LCD: < please enter your PIC, then press # >)

The user enters 1234 on the keyboard and then presses # or (enter)

PPT → BIA setting Pin <1234>

BIA → PPT may

telephone/LCD: < now enter your account index code >

User inputs 1, then < carriage return >

RPT → BIA sets the account index code <1>

BIA → PPT may

PPT → BIA evaluation register <2> <123456>

BIA → PPT may

telephone/LCD: < if 45.54 is possible, # by >

User input # (yes)

PPT → BIA setting quantity <45.54>

BIA → PPT may

PPT → formation message < remote transaction >

BIA → PPT < remote transaction request >

BIA → PPT may

telephone/LCD: < I am talking to DPC center >

PPT → Merchant < telephone transaction request >

Merchant → DPC: secure connection to DPC using DPC public key

Merchant → DPC < telephone transaction request >

DPC: confirming the biometric data, retrieving account → 4024-

1212

DPC: confirming that merchant 5422231 has code 123456

DPC → V ISA < authorization 4024-

V ISA → DPC < grant 4024-

Code >

DPC: obtaining a unique code

DPC → Merchant < transaction request message >

Merchant verification response code

Merchant → PPT < transaction response message >

PPT → BIA decrypt message < transaction response message >

BIA → PPT < may < i have been completely persuaded > < authorization code >)

telephone/LCD: < beep > transaction completion: i have been completely persuaded

1.6.12. Cable television point-of-sale terminal

In this example, the CPT communicates with the integrated cable BIA and cable merchant, securely downloading information and purchasing items using the cable broadcast network. The user PIC is 1234, the account index code is 1, the channel is 5, the merchant code is 123456, and the actual account number is 4024-.

The user tunes the television to channel 5.

Merchant → CPT < dry fruit cake 43.54123456 > (broadcast)

User hitting buy on TV remote controller "

CPT/TV: < Dry fruit cake with a purchase price of $43.54 >

CPT → BIA acquisition of biometric data <20>

CPY/TV: < please place finger on the light board >

The user placing a finger on the scanner

BIA → CPT may

CPT/TV: < please enter your PIC, then press # >)

The user enters 1234 on the keyboard and then presses "buy"

CPT → BIA setting Pin <1234>

BIA → CPT may

CPT/TV: < now enter your account index code >

User inputs 1, then < carriage return >

RPT → BIA sets the account index code <1>

BIA → CPT may

RPT → BIA evaluation register <1> < channel 5, 15:30:20 PST >

BIA → RPT may

CPT → BIA evaluation register <2> <123456>

BIA → CPT may

CPT/TV: < if 45.54 were available, press "buy" >

User input of "buy"

CPT → BIA set quantity <43.54>

BIA → CPT may

CPT → formation of message < Cable TV trade >

BIA → CPT < CATV trade request >

BIA → CPT may

CPT/TV: < I am talking to DPC center >

CPT → CTV center < Cable TV trade request >

Merchant → DPC: secure connection to DPC using DPC public key

Merchant → DPC < cable TV transaction request >

DPC: confirming the biometric data, retrieving account → 4024-

DPC: confirm merchant channel 5, current program code is 123456

DPC → V ISA < authorization 4024-

V ISA → DPC < grant 4024-

Code >

DPC: obtaining special codes, mail addresses

DPC → Merchant < transaction response message >

The merchant checks the response code and records the mail address

Merchant → CTV center < transaction response message >

CTV center → CPT < transaction response message >

CPT → BIA decrypt message < transaction response message >

BIA → CPT < may < I have been completely persuaded > authorization code >)

CPT/TV: < beep > transaction completion: i have been completely persuaded

From the foregoing it can be seen how the objects and features of the invention are achieved.

First, the present invention provides a computer identification system whereby the user no longer needs to own or present the actual item, such as a token, that can initiate the system to accept the request.

Second, the present invention provides a computer identification system that can verify the identity of a user without verifying that the user has certain specialized items and information.

Third, the present invention verifies the identity of the user based on one or more unique characteristics that are physically associated only with the user.

Fourth, the present invention provides a practical, convenient and easy to use identification system.

Fifth, the present invention provides a system that provides secure access to a computer system and that is highly resistant to fraudulent access attempts by unauthorized users.

Sixth, the present invention provides a computer identification system that allows a user to notify an authorized party that a particular access request is being enforced by a third party that is not known to the third party.

Seventh, the present invention provides an identification system that allows identification of a sender and a receiver of an electronic message and/or fax.

Although the present invention is directed to a particular system and method for non-token identification, it should be understood that various modifications and changes may be made without departing from the spirit and scope of the invention as defined in the appended claims.

5. Glossary

Account index code: a numeric or alphanumeric sequence corresponding to a particular financial asset account.

AID: authorized personal database: containing a list of individuals authorized to use the individual and the publisher BIA device.

AOD: device owner database: a central repository containing geographic and contact information related to the owner of each BIA.

ACSII: american standard code for information exchange.

ATM: an automated teller machine; access to a financial asset management system, including withdrawal and account management, is obtained using the encoded biometric identity information.

BIA: a biometric input device; biometric identity information is collected, encoded and encrypted so that it can be used for authorization. There are different hardware models and software versions.

Biological characteristics: the system measures certain aspects of an individual's natural person.

Biometric ID: an identifier used by the system to uniquely identify a biometric record of an individual (IR ID-individual record ID).

BIO-PIC group: a collection of algorithmically distinct biometric samples linked to the same personal identification code.

BRT: a biometric registration terminal; at a retail bank branch, the BRT combines the biometric enrollment information with the PIN selected by the individual and the selected personal information to enroll the individual into the system.

And (3) CBC: cipher block chaining: an encryption mode of DES.

CCD: a charge coupled device.

CET: verifying the Email terminal; and (4) verifying the sender by utilizing BIA, encrypting the file and transmitting the file to the system. The system saves and notifies the receiving party that the system received the message. The recipient identifies itself and then transmits the file to the recipient. Once the file is sent, the sender is notified. The file is encrypted by BIA to be verified, sent and kept secret. The transmitting party may request the transmission status. Both parties must be system members.

Command: programs or routines residing in the DPC, perform specific tasks, activated by request messages sent from terminals equipped with BIAs.

Contract acceptance/rejection: the process by which an individual enters his BIO-PIC and executes a DPC to register the individual's contract acceptance or rejection, using terms contained in a file electronically transmitted to the individual.

CPT: cable television point of sale terminal: a combination of on-screen display simulcast digital signals indicating product information to a television set-top box with product imagery and a BIA remote controller performing biometric-PIN verification using a CATV communications network. Order/authorization/email address/goods ID to merchant. The authorization result is displayed on the television.

CST: a customer service terminal; the system customer service personnel are provided with access capability of different degrees (according to access authority), and personal information is retrieved and modified so that the account problem can be solved by the personnel.

And (3) data sealing: in conjunction with a cryptographic checksum on a message, converting plaintext into ciphertext (referred to as "encryption"), the cryptographic checksum allows the information to be stored in plaintext form while providing a means of detecting any subsequent modifications to the message.

DES: digital encryption standard: standards for cryptographic protection of digital data. See standard ANSIX 3.92-1981.

Determining: the status of the command processed in the executing step.

DPC: the data processing center is the place and unit where the hardware, software and personnel supporting the multi-gigabyte biological characteristic identity database are located. The DPC processes electronic messages, most of which involve performing biometric identity checks as a precursor to performing certain actions, such as financial exchanges, or sending faxes, or sending emails, etc.

And (4) DSP: a digital signal processor: an integrated circuit dedicated to mathematical operations required by signal processing applications.

DUKPT: derived unique key for each transaction: see standard ANSI/ABA X9.24-1992.

EDD (electro-deposition): electronic file database: a central repository containing all the pending faxes and electronic messages waiting for personal collection.

Emergency account indexing: the alphanumeric digits or sequences selected by an individual, when accessed, will cause the system to designate a transaction as an emergency transaction, possibly causing a false screen to be displayed and/or notifying an authorized authority that the individual has been forced to perform a transmission or transaction.

ESD: electronic signature database: all MD5 containing all documents signed by anyone as specified by the authorization number and a central repository of electronic signatures.

EST: the electronic signature terminal: the person is identified with the BIA, the computer calculates a checksum of the file, sends the checksum to the system, the system verifies the checksum, time stamps, saves, and returns the sig code. The Internet (Internet) is used as a transmission means. EST is also calculated for a given signature verification sig code and MD 5.

FAR (false acceptance rate): the biometric data of one individual is falsely identified as a statistical likelihood of biometric data of another individual.

False screen: the display of information that has been intentionally predetermined to be somewhat inaccurate, such that a compelling party will not be able to illegally obtain accurate data relating to a personal financial asset, while not paying attention to the alteration of that information.

FDDI: fiber digital equipment interface: network devices utilizing fiber token ring.

FS: a field separator.

FW: firewall machine: an internet-local area network router that manages communications entering and leaving the DPC.

GM: a gateway machine: a main processing computer in the DPC; most of the software is run.

IBD: personal biometric database: a central repository of biometric data, financial assets, and other personal information. The transaction is authorized and the identity is verified for transmission using a query to the biometric database.

ID: a publisher database: a central repository containing institutions that are allowed to add and delete financial asset account numbers to the system.

IML: list of IBD machines: a software module in the DPC determines which IBD machine is responsible for which PIN code.

Internet commercial tenant: a retail account for selling services or goods to a consumer using an Internet (Internet) electronic network.

IPT: internet point of sale terminal: entries from the internet and merchant codes, BIA biometric for verification-PIN, are sent to the system using the internet to deliver authorization/order/PO numbers to the merchant. The system also responds with the internet and displays the results on the screen.

A distributor: the financial account issuer of the financial asset to be registered with the DPC.

And (3) batch processing of the distributor: the set of "add" and "delete" instructions are completed using the biometric ID, the financial asset account, and the verified account index code provided by the issuer to the DPC.

IT: a publisher terminal; a collection of connections is provided to the system for the issuer to add or remove financial asset account numbers (of their) from a particular individual IBD record.

ITT: an internet teller terminal; the network termination session is authorized using encrypted credentials obtained from the DPC using the biometric ID.

LCD: liquid crystal display (device): a technique for displaying text.

MAC: message authorization code: an encrypted checksum algorithm, the MAC provides a guarantee: the content of the message is not altered after the MAC computation. See standard ANSIX 9.9-1986.

MACM: a message authorization code module: a software module in the DPC processes the MAC authentication and generates inbound and outbound packets.

MDM: a message decryption module: a software module in the DPC that encrypts and decrypts packets from and to the BIA device.

MPM: a message processing module: a software module in the DPC that performs processing of the request packet.

Network credentials: both the individual and the bank are identified by the DPC to establish the network credentials. The credentials include the personal identification as well as the contents of the connection (i.e., the TCP/IP source and destination ports). The DPC establishes a network credential using the personal account id, time of day, and bank code. The DPC signs the credential using public key encryption and the DPC's private key.

PFD: previous fraud database: a central repository of IBD records that have been associated with previous fraud. All PFD records are checked for biometric data of each new customer in order to reduce re-fraud.

PGL: PIN group list: a software module in the DPC for maintaining the architecture of an IBD machine.

PIN: personal identification number, a method for securing access to a personal account using secret knowledge, is formed from at least one number.

PIC: a personal identification code; a PIN consisting of numbers, symbols or alphabetic symbols.

POS: a point of sale; the location where the goods are sold.

PPT: a telephone point-of-sale terminal: the telephone number is combined with the price of the item and product information to authorize the transaction on the telephone carrying the BIA. The order/authorization/mail address/PO is transmitted to the merchant. The resulting authorization is displayed on the phone LCD, or "spoken," along with the individual's unique code.

RAM: a random access memory.

RF: radio frequency: generally refers to the radio frequency energy emitted during normal operation of the electrical device.

Register: memory reserved for specific purposes, data set on the chip, and operands stored for the instruction.

Requesting: electronic instructions from the BIA to the DPC instruct the DPC to authenticate the individual and thereby process the individual's commands when the authentication is successful.

RMD: remote merchant database: contains all merchant identification codes for merchant telephones and cable television ordering stores; indexed with merchant ID. Also contains each merchant system encryption code.

RPT: a retail point of sale terminal; the encoded biometric identity information is combined with the retail transaction (information may be from an electronic cash register) and an authorization request is made to the system using an x.25 network, a modulation tuner, etc.

And (4) safe transaction: an electronic message or fax in which at least one party has been authenticated by the DPC.

SFT: a secure fax terminal; the BIA is used to authenticate the sender, sending either an unsecured, sender secure, or secure-confidential fax. The latter two require the recipient to authenticate itself using the biometric PIN. The outgoing fax is marked with a "job" designation (designated by the job index number). The sender may ask for the status of the transfer. Both participating parties must be system members. The sender or receiver can request that the fax be documented.

SNM: a sequence number module: software in the DPC manages DUKPT sequence numbers for inbound request packets. Sequence number processing prevents attacks again.

A terminal: an apparatus for collecting biometric samples using BIA and forming a request message which is then sent to a DPC for authorization and execution. The terminal almost always adds information to the request message, indicates the other party, etc. as an aid.

Job index code: an alphanumeric sequence that uniquely identifies the role or ability of an individual to be authorized in their work environment.

The cost ticket: an inanimate object of a given capacity.

Tracking code: an alphanumeric sequence is assigned to the data stored in or transmitted by the DPC so that the data can be retrieved using the sequence or reports relating to the status of the data transmission are obtained.

Trading: electronic financial exchange.

And (3) transmission: electronic messages other than electronic financial exchanges.

VAD: valid device database: a central repository in which each BIA is identified (associated with a unique encryption code) together with the owner of that BIA.

Claims (40)

1. A method of tokenless authorization of an electronic transaction between a payer and a payee using a computer identification system and at least one payer's biometric sample to be selected, the method comprising the steps of:

a) a payer registration step in which the payer registers with the computer identification system at least one registered biometric sample, and at least one payer financial account data;

b) a transaction formation step in which an electronic financial transaction is formed between a payer and a payee, including at least one candidate biometric sample of the payer, the candidate biometric sample being obtained from the payer person;

c) at least one transfer step in which the payer's biometric sample to be selected is electronically transferred to a computer identification system;

d) a payer identification step in which the computer identification system compares the payer's candidate biometric sample with at least one registered biometric sample for generating a successful or failed identification of the payer;

e) an account retrieval step in which financial account data previously registered by the payer is retrieved;

wherein, upon successful identification of the payer, the biometric-based authorized electronic transaction is authorized using financial account data previously registered by the payer, wherein the payer does not need to conduct the financial transaction using a smart card or a magnetic stripe card.

2. The method of claim 1, further comprising adding a transaction amount in the transaction forming step.

3. The method as recited in claim 1, further comprising a display step, wherein financial account data previously registered by the payer is electronically displayed to the payer.

4. The method of claim 1, further comprising the step of communicating, electronically, financial account data previously registered by the payer to the financial transaction processor.

5. The method of claim 1, wherein the computer identification system is run by a third party.

6. The method as recited in claim 1, wherein the payer registration step further comprises registering the payer personal identification number with the computer identification system.

7. The method of claim 1, further comprising a payer resource determination step, wherein it is determined whether a financial account of the payer has sufficient resources to reimburse the transaction amount.

8. The method of claim 1, further comprising a payer account selection step, wherein upon successful identification of the payer in the payer identification step, the non-coupon authorization system presents at least one of the financial accounts registered by the payer to the non-coupon authorization system, one of the financial accounts being selected for reimbursement by the payer.

9. The method of claim 1, further comprising a transaction payment step wherein the transaction amount is tendered from a financial account of the payer.

10. The method of claim 9, wherein the transaction amount is redeemed against a financial account of the payee.

11. The method of claim 1, the registering step further comprising registering with the computer identification system a payer's unique code, distinguished from the personal identification number and not used in the payer identification step, wherein the unique code is displayed to the payer to confirm that the trusted computer identification system has processed the transaction.

12. The method of claim 7, wherein the payer resource determining step further comprises the non-coupon authorization system communicating with at least one external computer.

13. The method of claim 9, wherein the transaction payment step further comprises the non-coupon authorization system communicating with at least one external computer.

14. The method of claim 2, wherein the transaction amount comprises price information, a list of goods and services, a payee name, a date or time, a location, or an invoice number.

15. The method of claim 1, further comprising a transaction acceptance step, wherein a payer validates the transaction.

16. The method of claim 15, wherein the transaction accepting step further comprises the payer entering a new transaction amount that is the sum of the amount of cash owed and the transaction amount for the financial transaction.

17. The method of claim 9, wherein the transaction payment step further comprises the payer designating a future date to deduct the transaction amount from the payer's financial account and reimburse to the payee's financial account.

18. The method of claim 1, further comprising a payer re-enrollment step, wherein the user's enrollment biometric sample is compared to a previously specified biometric sample, and if there is a match, the computer system is alerted to the fact that the payer is re-enrolled to the non-coupon authorization system.

19. The method of claim 1, wherein biometric sampling comprises one of: fingerprints, face scans, retinal images, iris scans, and sonograms.

20. The method of claim 6, further comprising a biometric theft resolution step, wherein the payer's personal identification number is changed upon determining that the payer's biometric sample is fraudulently copied.

21. The method of claim 9, further comprising a re-presenting step, wherein when an electronic check is returned, the electronic check is automatically re-presented for crediting a financial account of a payer.

22. The method as claimed in claim 1, wherein in the payer registration step, the payer registers at least one payer financial account and assigns an account index code to each payer financial account, and in the acceptance step, the user adds the account index code to the financial transaction, wherein the account index code further includes one or more alphanumeric characters.

23. A non-token electronic check authorization apparatus for transferring funds from a payer financial account to a payee financial account, the apparatus comprising:

a) a computer processing center including a database in which a payer registers a registered biometric sample;

b) a party identification device having a biometric sensor for inputting a biometric sample;

c) a communication line for transmitting the enrollment and the candidate biometric samples obtained by the party identification device from the payer's person to the data processing center;

d) a comparator engine for comparing the biometric sample to be selected with at least one registered biometric sample; and

e) an execution module to transfer the transaction amount from the payer financial account to the payee financial account upon successful identification of the payer, wherein the payer does not need to conduct a financial transaction using a smart card or a magnetic stripe card.

24. The authorization device according to claim 23, wherein the biometric sample registered by the payer is associated with a personal identification number.

25. The authorization device of claim 23, wherein the execution module determines whether a financial account of the payer has sufficient resources for reimbursing the transaction amount.

26. The authorization device of claim 23, further comprising an account selection module, wherein upon successful identification of the payer, the authorization device presents at least one of the financial accounts registered with the authorization device by the payer, one of the financial accounts being selected for reimbursement by the payer.

27. The authorization device of claim 23, wherein the execution module tenders the transaction amount from a financial account of the payer.

28. The authorization device of claim 23, wherein the execution module tenders the transaction amount to a financial account of the recipient.

29. An authorisation device according to claim 23 further comprising authorisation device identification means, wherein the payer registers with the authorisation device a unique code which is distinguished from the personal identification number and which is not used to identify the payer, wherein the unique code is displayed to the payer to confirm that the trusted authorisation device has processed the financial transaction.

30. The authorization device of claim 23, wherein a subset of the payer's registered biometric sample is stored in the payer re-registration database, and the comparator engine compares it to the payer's registered biometric sample, and if there is a match, alerts the authorization device of the fact that the payer is re-registered to the non-token authorization system.

31. The authorization device according to claim 23, further comprising a display means for displaying information to the payer.

32. The authorization device of claim 31, wherein the display device is a point-of-sale terminal.

33. An authorisation device as claimed in claim 31 in which the display means is party identification means.

34. The authorization device according to claim 23, wherein the execution module is not co-located with the computer identification system.

35. The authorization device according to claim 23, wherein the execution module is run by a third party and communicates with the computer identification system via a communication line.

36. The authorization device of claim 23, wherein the execution module is in communication with a financial transaction processor.

37. The authorization device according to claim 23, wherein the computer identification system is run by a third party.

38. A system for non-coupon authorization of a transaction between a buyer and a seller using a computer system, comprising:

a) means for purchaser enrollment, wherein a purchaser enrolls a PIN, at least one enrolled biometric sample, and at least one purchaser financial account with a computer system;

b) means for proposing a proposal, wherein the seller provides a proposed transaction to the buyer, the proposed transaction including price information;

c) means for accepting, wherein the buyer signals acceptance of the seller's proposed transaction by adding to the proposed transaction personal authentication information for the buyer including a PIN and at least one candidate biometric sample, wherein the candidate biometric sample is obtained from a person of the buyer;

d) means for transmitting, wherein the biometric sample to be selected and the PIN are transmitted to a computer system;

e) means for purchaser identification, wherein the computer system compares the biometric sample to be selected with the enrolled biometric samples to generate a successful or unsuccessful identification of the purchaser; and

f) apparatus for payment wherein a financial account of a buyer is debited and a financial account of a seller is credited without the need for a payer to conduct the financial transaction using a smart card or a magnetic stripe card.

39. A method of tokenless authorization of a financial transaction between a payer and an acquirer using a computer identification system and at least one payer's candidate biometric sample, the method comprising the steps of:

a) a payer registration step in which the payer registers with the computer identification system at least one registered biometric sample, and at least one payer account data;

b) a transaction formation step in which a financial transaction is formed between a payer and a payee, including at least one candidate biometric sample of the payer, the candidate biometric sample being obtained from the payer person;

c) at least one transfer step in which the payer's biometric sample to be selected is electronically transferred to a computer identification system;

d) an identification step in which the computer identification system compares the payer's candidate biometric sample with at least one registered biometric sample for accessing the payer's previously registered account number;

e) a transaction payment step, in which the payer does not need to use a smart card or a magnetic stripe card to conduct the financial transaction.

40. An automated, token-free computer identification system for determining the identity of an individual by examining at least one candidate biometric sample collected in an attempt step and comparing it to a previously recorded enrolled biometric sample collected in an enrollment step, the system comprising:

a) At least one computer;

b) first collecting means for automatically inputting at least one enrolled biometric sample from the individual in the enrolment step;

c) second collecting means for automatically inputting at least one candidate biometric sample from the individual in a trying step;

d) first connecting means for interconnecting said first and second collecting means to said computer for transferring collected biometric samples from said first and second collecting means to said computer;

e) means for storing a plurality of enrolled biometric samples;

f) comparing means for comparing the sample of the biometric characteristic to be selected with the sample of the biometric characteristic registered to produce an estimate;

g) execution means in said computer for storing data and processing and executing commands to produce a determination; and

h) means for outputting the estimate or determination from the computer.