Abstract:
Methods and systems are provided for a secured electronic communication in a network that includes a verification station, a registration station, and a authentication station. At the registration station, a request for a digital certificate is received from a user. The registration station instructs the verification station to forward to the user a message associated with the request. The message is compared against the user at the authentication station to determine whether the message properly identifies the user. A first signal indicating the result of the comparison is sent to the verification station. If the first signal indicates that the message properly identifies the user, a second signal is sent to the registration station. Based on the second signal, the registration system then generates a digital certificate.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     The present application is a continuation of, and claims the benefit of, U.S. patent application Ser. No. 12/073,208 filed Mar. 3, 2008 now abandoned, which is a continuation of U.S. patent application Ser. No. 11/810,275 filed Feb. 22, 2005 (now abandoned), which is a continuation of U.S. patent application Ser. No. 10/485,857 filed Feb. 5, 2004 (now abandoned), which is a continuation of PCT International Application No. PCT/US02/25075, filed Aug. 7, 2002, which is related to and claims the benefit and priority of U.S. Provisional Application No. 60/310,233 filed Aug. 7, 2001, in the name of James C. Bullard, Jr., and titled APPARATUS AND METHODS FOR PROVIDING A DIGITAL CERTIFICATE, all of which are fully incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     This invention relates generally to a system and method for providing secured electronic communication between parties, and more particularly, to a system and method for providing a digital certificate that may be used in electronic communications to ensure the integrity of an electronic transaction. 
     BACKGROUND 
     Presently, consumers and businesses exchange vast amounts of information in order to engage in a business transaction or sale. In traditional business transactions, consumers use accepted means of payment to purchase items at a store or another place of business. In exchange, businesses offer goods or services in consideration of the payment by the consumers. In many instances, businesses use security methods to verify the method of payment, for example verifying through a driver&#39;s license that a consumer is the same as the individual identified on a credit card. 
     As electronic communication becomes more popular as a means for transacting business, through for example the Internet, consumers and businesses desire a more secured form of electronic communication. For example, it is desired that a credit card number electronically sent to a business is not intercepted or used improperly. For e-business transactions to become more widely accepted, consumers must use the electronic services provided by businesses, and businesses must be able to ensure the security of such electronic transactions. Otherwise, the advantages of an electronic commerce environment will not be realized, due to a lack of participation or demand by consumers and businesses. Therefore, businesses and consumers who communicate electronically need to know that their respective messages are private and need to verify the identity of a sender. 
     To ensure that transactions take place smoothly between parties, it is essential that the parties not only trust the communication path but also have assurances regarding the integrity of the information transmitted and the identity of the party transmitting the information. Without this assurance, the possibility of fraud, either unintentional or purposeful, could undermine the ability of parties to effectively engage in electronic commerce. 
     In modern electronic commerce environments, digital certificates are used to prevent interception of transactions and to allow authentication and verification of the transactions. For example, a digital certificate makes it possible to verify someone&#39;s claim that they have the right to use a given key in a key-based security scheme, which helps prevent unauthorized users from impersonating a rightful user. Digital certificates, used in conjunction with encryption, provide a more complete security solution by assuring the identity of all parties involved in an electronic transaction. 
     It is therefore desirable to provide systems and methods to allow for the secure and reliable exchange of information between parties utilizing electronic communication. 
     SUMMARY 
     Methods and systems are provided for a secured electronic communication in a network that includes a verification station, a registration station, and a authentication station. At the registration station, a request for a digital certificate is received from a user. The registration station instructs the verification station to forward to the user a message associated with the request. The message is compared against the user at the authentication station to determine whether the message properly identifies the user. A first signal indicating the result of the comparison is sent to the verification station. If the first signal indicates that the message properly identifies the user, a second signal is sent to the registration station. A digital certificate is generated at the registration station upon receipt of the second signal. 
     A system for a secured electronic communication comprises a verification station, a registration station, and an authentication station. The registration station is configured to communicate with the verification station, receive a request for a digital certificate from a user, and to instruct the verification station to forward to the user a message associated with the request. The authentication station is configured to communicate with the verification station, compare the message against information about the user, and to send a first signal to the verification station indicating the result of the comparison. If the first signal indicates the message properly identifies the user, the verification station sends a second signal to the registration station such that the digital certificate is generated based on the second signal. 
     Additional features and advantages will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the claims. The advantages will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the appended claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the figures, 
         FIG. 1  is a block diagram of a system for providing secured electronic communication; 
         FIG. 2  is a block diagram illustrating a digital certificate module in a system for providing secured electronic communication in greater detail; 
         FIG. 3  is a block diagram showing a registration station in a system for providing secured electronic communication in greater detail; 
         FIG. 4  is a flowchart of tasks performed by a digital certificate request module in a system for providing secured electronic communication; 
         FIG. 5  is a block diagram showing a verification station in a system for providing secured electronic communication in greater detail; 
         FIG. 6  is diagram showing a message flow within a system for providing secured electronic communication. 
     
    
    
     DETAILED DESCRIPTION 
     Referring now to the drawings, in which the same reference numbers will be used throughout the drawings to refer to the same or like parts,  FIG. 1  is a block diagram of a system  100  providing secured electronic communication to a customer  102 . System  100  may include a registration station  104 , a verification station  106 , and an authentication station  108 . Registration station  104 , which communicates with customer  102  and verification station  106 , may include a digital certificate module  110 . Verification station  106  communicates with customer  102  and authentication station  108 , in addition to registration station  104 . Customer  102  also communicates with authentication station  108 . 
     Registration station  104  may receive a request for a digital certificate from customer  102 . The request may include account information to identify customer  102  with the digital certificate. The account information may include information, such as first name, last name, and social security number. When registration station  104  receives the request from customer  102  along with the account information, registration station  104  may instruct verification station  106  to send a message to customer  102 . The contents of the message may include the account information that customer  102  sends to registration station  104 . Customer  102  may take the message to authentication station  108 , where an operator checks the message and compares the accuracy of the information provided in the message against identification supplied by customer  102 . 
     Authentication station  108  may communicate the result of the comparison to verification station  106 . If authentication station  108  determines that the message properly identifies customer  102 , then verification station  106  communicates to registration station  104  that a digital certificate should be generated for customer  102 . Registration station  104  may determine if the digital certificate can be issued (e.g., if there is another individual with the same information as customer  102 , then a digital certificate cannot be issued) and if so, generates a digital certificate in favor of customer  102  through digital certificate module  110 . 
       FIG. 2  is a block diagram of digital certificate module  110  in greater detail. Digital certificate system  110  may include a digital certificate request module  202  and certification authority module  204 . Once verification station  106  receives a communication from authentication station  108  that customer  102  is properly identified with the account information, request module  202  may send a request to certification authority module  204 . Certification authority module  204  may determine if the request for the digital certificate can be processed. For example, certification authority module  204  could return one of two responses to the request for a digital certificate from request module  202 —either the digital certificate or an error message. Error messages may be separated into two different kinds, a lesser error or a greater error. A lesser error may occur when an event, such as a technical difficulty that can be resolved by retransmission is detected. However, a greater error may occur when it is impossible for certification authority module  204  to issue a digital certificate (e.g., a digital certificate already exists for customer  102 ). 
       FIG. 3  is a block diagram showing registration station  104  in further detail. Registration station  104  may include a processor  302 , a memory  304 , and a secondary storage  306 . Memory  304  may further include digital certificate module  110 , and secondary storage  306  may include a database  308 . As shown in  FIG. 3 , digital certification module  110  may be a program stored in memory  304  and executed by processor  302 . 
       FIG. 4  is a flowchart  400  of tasks performed by digital certificate request module  202 . Flowchart  400  begins at stage  402  where a parent program accesses database  308 . Control flags may exist as part of the parent program to ensure quality of the retrieved accounts. The three control flags may be used to determine which account in database  308  is ready to be processed and which account may be ignored. The first flag may ensure that the account has been activated. For example, the first flag may ensure that customer  102  entered information into registration station  104 , took the message to authentication station  108 , authentication station  108  verified the message and notified verification station  106 , and the account is active within database  308 . 
     The second flag may ensure that customer  102  has registered for an account that uses a digital certificate (i.e., customer  102  is registered for a product that uses a digital certificate). The third flag ensures that the account is pending processing. In other words, the third flag ensures that the account has either been newly generated and waiting for certification authority module  204  to assign a digital certificate, or the account is waiting in database  308  due to previous responses that generated and that resulted in error. Responses to digital certificate requests are explained below. 
     If the three flags are met, then the account record for customer  102  may be submitted for processing and pulled from database  308 . At stage  404 , the parent program may generate a clone program, also called a child program, and give the account information for customer  102  to the child program. The child program may format the information of customer  102  into a digital certificate request, at stage  406 , and then transmit the digital certification request to certificate authority module  204  at stage  408 . 
     Next, at stage  410 , certification authority module  204  may generate and return one of two responses to the digital certification request module  202 —either an error message or a digital certificate. 
     If the response is an error message, error processing may occur at stage  412 . The error may be categorized into one of two categories: a lesser error or a fatal error. A lesser error may occur when, for example, there is noise on the transmission line between digital service request module  202  and certification authority module  204 . The result is that database  308  would be flagged to try that record again later. However, if a fatal error occurs, at stage  414 , the request for a digital certificate will be aborted and the record is skipped by subsequent searches on database  308 . For example, if customer  102  is named “John Smith” and submits information on an application indicating first name “John” and last name “Smith,” customer  102  is assigned a digital certificate. If another individual named “John Q. Smith” also fills out an application indicating first name “John” and last name “Smith” with no middle initial, this would generate an error message because customer  102  named “John Smith” is already in database  308 . Notably, other implementations are possible, providing for any number of error conditions. 
     If no error exists, certification authority module  204  may return a digital certificate at stage  416 . The digital certificate may be bundled with one or more root certificates by digital certification request module  202  and the digital certificate bundle may be stored in database  308 . A root certificate may allow verification that digital certificates from certification authority module  204  are the most current and valid. The digital certificate, together with the digital certificate bundle, is transmitted to the Internet web browser belonging to customer  102 , and the root certificate is stored in the browser&#39;s certificate storage. Typically, Internet web browser&#39;s have access to a storage containing trusted certificates. 
     At stage  416 , the root certificate referenced may not be included in the browser certificate store of customer  102 . Thus, in order to make the digital certificate that is issued to customer  102  useful, the root certificate may be bundled with the digital certificate and transmitted to the Internet web browser of customer  102 . If the certificate generation is successful, the information may be stored in database  308  at stage  418 . In addition, at stage  420 , a confirmation e-mail may be sent to customer  102  indicating that the digital certificate has been issued by certification authority module  204 . 
     The digital certificate module  110  may also support a set of command line parameters in order to allow more versatility in operation and control over digital certificate request module  202 . These parameters are listed in Table 1. 
     
       
         
               
             
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 Command-line parameters: 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 -a 
                 Specify account number of individual account to be processed 
               
               
                 -b 
                 Set the base path 
               
               
                 -c 
                 Specify the location of the “Mail Command” script file 
               
               
                 -d 
                 Specify name of database to be used 
               
               
                 -e 
                 Specify Email address to which Conformation Message will be sent 
               
               
                 -f 
                 Specify the location of the text file containing the Failure Message 
               
               
                 -h 
                 Help. Generate usage statement. 
               
               
                 -i 
                 Specify Input File/Configuration File 
               
               
                 -l 
                 Unlock all records (crash recovery) 
               
               
                 -m 
                 Specify location of text file containing Confirmation Message 
               
               
                 -n 
                 Normal processing with default values 
               
               
                 -o 
                 Specify Email address for Operator/Administrator 
               
               
                 -p 
                 Specify database password 
               
               
                 -r 
                 Indicate the certificate files should be removed from hard drive upon 
               
               
                   
                 successful completion 
               
               
                 -t 
                 Specify number of times parent process should run 
               
               
                 -u 
                 Specify username for database login 
               
               
                 -v 
                 Indicate that only the record with this “vanity name” (username/ 
               
               
                   
                 logon id) is to be processed 
               
               
                 -x 
                 Specify Debug mode (verbose logging output) 
               
               
                 -z 
                 Indicate the number of seconds the parent process should sleep in 
               
               
                   
                 between database checks 
               
               
                   
               
             
          
         
       
     
     The following are a description of the parameters listed in Table 1. 
     -a: This command followed by an account number and instructs digital certificate request module  202  to process records associated with that account number. 
     -b: This command sets the base path for the operation of digital certificate request module  202  and allows an administrator to store and run digital certificate request module  202  at different locations. The base path is the highest level system directory of digital certificate request module  202 . 
     -c: This command specifies the location of the script file that sends the confirmation e-mail message at stage  420 . 
     -d: This command allows the administrator to specify the name of databases, including database  308 , that digital certificate request module  202  will search in its operation, for example at stage  402 . The administrator may have multiple databases or multiple projects being run from registration station  104 . 
     -e: This command allows the administrator to specify an e-mail address to which the e-mail confirmation message will be sent at stage  420 . 
     -f: This commands lets the administrator give the file name for the text file containing a failure message which may be sent to the administrator indicating that a problem occurred with digital certificate request module  202 . 
     -h: This command specifies that a help message will be generated by digital certificate request module  202 . 
     -l: This command allows the administrator to specify an input or configuration file with information that will be needed for generating the digital certificate request, for example an IP address, a proxy, or a port necessary for contacting certification authority module  204  or the directory where the digital certificates will be stored. 
     -l: This command may be used in the event of crash recovery to reset all of the records that may have been in progress at the time of the crash. This command notifies database  308  to go to an unlocked state ready to be read by the next process. 
     -m: This command specifies the file name of the text file containing the e-mail confirmation message which gets sent to customer  102  at stage  420 . 
     -n: This command sets a default flag, which may run digital certificate request module  202  under default values. 
     -o: This command specifies the e-mail address for the administrator. This is where any failure messages will be sent notifying the administrator of a problem. 
     -p: This command specifies the password for signing into a database to be searched, for example database  308 . 
     -r: This command is a clean-up indicator indicating that once the digital certificates have been generated and bundled, they are to be removed from a hard drive and stored in database  308 . 
     -t: This command is used primarily during a debug mode and specifies a number of times the process should check database  308 , for example stage  402 . 
     -u: This command specifies the user name necessary for logging into a database to be checked, for example database  308 . 
     -v: This command allows a record with a particular name, which can be similar to individual&#39;s name or a log-on identification name, to be processed. 
     -x: This command indicates that the administrator is in a debug mode. 
     -z: This command specifies the number of seconds to wait between checks to database  308 , for example, at stage  402   
       FIG. 5  is a block diagram showing verification station  106  in greater detail. Verification station  106  may include a customer service mainframe  502  and a delivery confirmation mainframe  504 . Mainframes  502  may communicate with mainframe  504  to provide secured electronic communication. Mainframe  502  may be a national customer service center (NCSC) mainframe, which handles the request for messages from registration station  104  and generates messages to go out to customer  102 . Mainframe  504  may be a delivery confirmation mainframe, which handles the verified messages back from authentication station  108 . 
       FIG. 6  is diagram showing a message flow  600  within system  100 . Message flow  600  begins at step  602  where customer  102  may provide registration information to registration station  104 . At step  604 , registration station  104  may request a public key from the internet web browser of customer  102 . At step  606 , the browser of customer  102  may send the public key to registration station  104  may, and registration station  104  may store the public key in database  308 . 
     Registration station  104  may request the public key from the browser of customer  102 . For example, registration station  104  may pass a command to the browser of customer  102  telling it to generate a complex mathematical data set called a public key and a private key. Customer  102  may retain the private key while the public key is sent to registration station  104 . This function may happen automatically in the browser of customer  102  without any required interaction from the customer  102 . 
     At step  608 , registration station  104  may request a message to be sent to customer  102 . The message may be processed by verification station  106 . 
     At step  610 , mainframe  502  may send the message to customer  102  and send a notice to mainframe  504  at step  612 . The notice to mainframe  504  may indicate that the message to customer  102  has been sent. From the notification, mainframe  504  may recognize information received from authentication station  108  regarding the results of the comparison between the message and customer  102 , as described below. 
     At step  614 , customer  102  may take the message to authentication station  108 . Customer  102  may also take several forms of identification to authentication station  108 , if specified in the message. An example of authentication station  108  may be a post office. 
     At step  616 , an operator for authentication station  108  may review the information on the message and compare it against information on the forms of identification offered by customer  102 . If the operator is satisfied that customer  102  is properly identified, authentication station  108  may notify mainframe  504  of the verified message. For example, authentication station  108  may process the message as if it were a package and mail the letter to verification station  106 . 
     At step  618 , mainframe  504  may receive the verified message from authentication station  108 . For example, mainframe  504  may not treat the verified message as a “package,” but may forward the verified message to mainframe  502  as a registration request. 
     At step  620 , mainframe  502  may send the verified message to mainframe  502  to registration station  104  to activate the account of customer  102  and start the process of requesting and generating a digital certificate within registration station  104 , as illustrated in flowchart  400  of  FIG. 4 . 
     At step  622 , registration station  104  may generate a digital certificate request and send a confirmation e-mail to customer  102  indicating that a digital certificate is ready. At step  624 , customer  102  may access registration station  104  to obtain the digital certificate. At step  626 , a digital certificate may be downloaded into the browser of customer  102 . 
     Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the appended claims disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit being indicated by the following claims.