Abstract:
A process is disclosed for notarizing document, by a client in the presence of a notary, comprising the steps of registering the notary, the client and the document, from a local workstation coupled to a central office, to provide for assigning at least one respective encryption key for identifying each of the notary, the client and the document to be notarized; associating in the central office, the respective encryption keys of the client with the notary and with the document; generating a transaction code, based on the step of associating the respective encryption keys, for authorizing execution of the document to provide the notarizing; executing the document; and embedding selected ones of the respective encryption keys together with a notary seal in the document.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a Continuation of U.S. Pat. No. 7,660,988, issued Feb. 9, 2010, and entitled “ELECTRONIC NOTARY,” which is incorporated herein by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The present disclosure pertains generally to executing document signatures electronically during transactions and, more particularly, to notarizing document signing using internet based services. 
       BACKGROUND 
       [0003]    Parties executing documents as part of a transaction between them must do so in the physical presence of a notary who verifies the identity of the party who will affix its signature to the document, witness the acts of signing the documents and affix his or her own signature and notary seal to the signed document. This is often an inconvenient process requiring special arrangements to assemble the parties and the documents at a given time and place, sometimes requiring travel etc. This process, besides being inconvenient, is often wasteful of time and resources. Moreover, security of the documents, the signatures and the information exchanged during the verification of identities, etc., may be inadequate when subject to the difficulties of arranging and accommodating time and place requirements. What is needed therefore, in a business world increasingly characterized by transactions performed electronically, is a way to utilize the electronic facilities available to the parties to perform the steps in the notary process enumerated above and to do so while maintaining or improving the security of the transaction of the documents involved. 
       SUMMARY 
       [0004]    A process is disclosed for notarizing at least one document, by a client in the presence of a notary, comprising the steps of registering the notary, the client and the at least one document, from a local workstation coupled to a central office via a global communication network, to provide for assigning at least one respective encryption key for identifying each of the notary, the client and the at least one document to be notarized; associating in a first database in the central office, the respective encryption keys of the client with the notary and with the at least one document; generating a transaction code, based on the step of associating the respective encryption keys, for authorizing execution of the at least one document to provide the notarizing; executing the at least one document; and embedding selected ones of the respective encryption keys together with a notary seal in the at least one document. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying Drawings in which: 
           [0006]      FIG. 1  illustrates an overall block diagram of an electronic notary system according to the present disclosure; 
           [0007]      FIG. 2  illustrates a simplified flowchart for registering a notary in the embodiment of the electronic notary system of  FIG. 1 ; 
           [0008]      FIG. 3A  illustrates a first portion of a simplified flowchart for electronically notarizing a document in the electronic notary system of  FIG. 1 ; 
           [0009]      FIG. 3B  illustrates a second portion of the simplified flowchart for electronically notarizing a document in the electronic notary system of  FIG. 1 ; 
           [0010]      FIG. 3C  illustrates a third portion of the simplified flowchart for electronically notarizing a document in the electronic notary system of  FIG. 1 ; and 
           [0011]      FIG. 3D  illustrates a fourth portion of a simplified flowchart for electronically notarizing a document in the electronic notary system of  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    Referring now to  FIG. 1 , there is illustrated an overall block diagram of an electronic notary system  10  according to the present disclosure. A local workstation  12  is coupled through an internet service provider  14  to a global communication network (CCN)  16  which may also be known as the Internet  16 . Similarly a Cognomina central office  18  is coupled through an internet service provider  20  to the global communication network  16 . Feeding into the local workstation  12  are inputs from a client  22 , from a notary  24  and a from a block representing input devices  26  for entering a document  27 , which input device  26  includes, for example, a scanner, keyboard, a disc drive for retrieving a file from memory media or other memory device, etc. Local workstation  12 , sometimes also called workstation  12 , may also be coupled to a printer  28 , to a display  30  and to a local database  32 . The Cognomina central office  18  is also coupled with an encryption key database  34  and an archive database  36 . 
         [0013]    As will become clear in the description which follows, the Cognomina central office  18  plays a central role in the control of the notarizing process as well as the issuance of encryption keys associated with the client  22 , the notary  24  and the document  27  entered through the input device  26  during the electronic notary process. The encryption key database  34  provides a storage facility for the various encryption keys which are issued according to a public key-private key or asymmetric encryption system. The encryption keys are issued to protect the identities of the parties or documents as contrasted with a frequent use of such encryption to encrypt the text of a document. The archive database  36  provides for storage of the document  27  following the completion of the electronic notary process disclosed herein. Associated with the Cognomina central office  18  is its relationship with a certification authority  38  which provides for registering the electronic notary system provider of the present disclosure as well as a directory of the public keys assigned during the transactions processed using the electronic notary system of the present disclosure. 
         [0014]    In operation, an electronic notary program installed at the local workstation  12  controls the operation of the notarization process including the registration of the notary  24 , the client  22  and the document  27  as well as the communication via the GCN  16 . Similarly, the central office  18  operates according to a programmed process to interact with the local workstation  12 , the databases  34 ,  36  coupled to the central office  18  as well as the communication via the GCN  16 . 
         [0015]    Referring further to  FIG. 1 , it will be observed that the parties interacting with the local workstation  12  and the Cognomina central office  18  via the global communication network  16  are further interconnected by dashed lines representing the communication of information or documents between the entities shown. These dashed lines are identified by bold face capital letters which correspond with steps in the process to be described hereinbelow in conjunction with  FIGS. 2 and 3 . For example lines  40  and  42 , also identified with the letters E, F, J, H and I, couple the client  22  with the Cognomina central office  18  through the local workstation  12  and the global communication network  16 . Similarly, lines  44  and  46 , also identified with the letters A, B, C, D, J and K, couple the interaction of the notary  24  through the local workstation  12  and via the global communication network  16  to the Cognomina central office  18 . Likewise, the input devices are coupled through dashed line  48 , also identified with the letter G, to the Cognomina central office  18  via the global communication network  16  and dashed line  50 , also identified with the letter L, which couples the Cognomina central office  18  through the global communication network  16  back to the local workstation  12 . The capital letters assigned to the dashed lines identify certain steps, described in  FIGS. 2 and 3 , of the electronic notary process in the sequence in which they occur illustrated in  FIG. 1 . 
         [0016]    Referring now to  FIG. 2 , there is illustrated a simplified flowchart for registering a notary in the electronic notary system of the embodiment of  FIG. 1 . The process beings at a Start block  60  and proceeds to block  62  where the notary  24  logs in to the central office  18  at the local workstation  12 . Following login the process inquires whether the notary  24  is registered with the central office  18  in decision block  64 . If the result is negative then the process proceeds to block  66  where the notary  24  enters his or her profile information and a signature graphic to become registered in the central office  18 . If the registration is completed successfully, the central office  18  issues a notary seal and the public and private keys associated with the notary  24 . The process proceeds to block  68  where the central office  18  stores the public and private keys in the encryption key database  34  coupled with the central office  18  and the flow returns to the input of decision block  64  to again inquire whether the notary  24  is registered. If the answer is affirmative, then the flow proceeds to decision block  70  wherein the central office  18  checks whether the local workstation  12  is registered in the central office  18 . If the response is negative, then the flow returns to the input to block  66  to perform the registration process for the local workstation  12  using similar steps to the registration of a notary, the difference being that the local workstation  12  does not supply a signature and it does not receive a notary seal. However it does supply information that identifies the workstation  12 . Once the workstation  12  is properly registered, then the flow proceeds from decision block  70  along the path labeled Y to block  72  wherein the workstation  12  fetches a public key authority from the central office  18 ; if the authority is approved in decision block  74 , the flow proceeds to block  78  whereupon the central office  18  acknowledges its approval for the use of the public key by sending a key certificate for the public key to the notary  24  at the local workstation  12 . If, however, in decision block  74 , the authority was not approved, then the flow proceeds along the N path to block  76  to repeat the registration process. Once the approval of the public key authority is given by sending the key certificate in block  78 , the flow proceeds to block  80  where it ends the process of registering a notary. 
         [0017]    Referring now to  FIG. 3A , there is illustrated a first portion of a simplified flowchart for electronically notarizing a document in the electronic notary system of  FIG. 1 . The process begins at a Start block  100  and proceeds to block  102 . Therein the notary  24  operating at the local workstation  12  logs in and enters his or her public key that was previously assigned during the registration of the notary  24  as described hereinabove. The flow of the process after the notary  24  logs in at block  102  proceeds to block  104  where the notary enters a request to perform a notary transaction. The next step, decision block  106 , determines whether the request to perform a notary transaction has been received at the central office  18 . If the result is negative, then the flow follows the N path to block  108  to retry the request to perform a notary transaction and the flow returns to the input to block  104 . If the result of the determination in block  106  is affirmative, then the flow proceeds along the Y path to block  110  wherein the central office  18  looks up the notary public key record in the encryption key database  34  at the central office  18 . If the notary  24  is authorized in decision block  112 , the flow proceeds along the Y path to block  114  to acknowledge the notary  24  by sending a public key certification to the notary  24  at the local workstation  12 . If, in decision block  112  the notary  24  was not authorized, then the flow proceeds along the path labeled N to another decision block  116  in which the central office  18  inquires of the notary  24  at local workstation  12  whether the notary  24  wishes to re-register with the central office  18 . If the notary  24  enters a negative response, then the flow proceeds along an exit path at block  122 . If, however the notary  24  enters an affirmative response in decision block  116 , the flow proceeds to block  118  to perform the registration of the notary  24  in the procedure described hereinabove with respect to  FIG. 2 . Then, the flow proceeds to another decision block  120 , wherein the notary  24  is asked whether he or she wishes to proceed with a request to perform a notary transaction. If the notary  24  responds in the negative, the flow follows the N path to the exit block  122 . If the notary  24  responds affirmatively, then the flow follows the Y path back to the input to block  104  wherein the notary  24  is again provided the opportunity to request a transaction. After the notary  24  has received the public key certification at the workstation in block  114 , the flow proceeds along the path identified with the letter X to  FIG. 3B . 
         [0018]    Referring now to  FIG. 3B , there is illustrated a second portion of the flow chart begun in  FIG. 3A . The process flow from block  114  in  FIG. 3A , identified with the letter X, enters block  124  to prompt the workstation  12  to set up the client who wishes to notarize one or more document  27 . Following the prompt to the workstation  12  to set up a client  22  at block  124 , the flow proceeds to a decision block  126  wherein the system inquires whether the client  22  is registered. If the response is negative, the flow follows the N path to block  128  whereupon the notary  24  enters the client  22  profile and signature graphic in to a credentials manager portion (not shown) of the program operating on the local workstation  12 . The client profile and signature information is then utilized in block  130  by the central office  18  to register the client  22  into the system and flow again enters decision block  126  to determine whether or not the client  22  is in fact registered. If the response is affirmative, the flow proceeds along the Y path to block  132  whereupon the central office  18  verifies the association of the client  22  with the notary  24  and issues an ID and password for the notary transaction requested previously. In the next step at decision block  134 , the central office  18  inquires whether the client  22  wishes to proceed with the transaction; if the response is negative the flow proceeds along the N path to the exit block at  136 . If, however, the result of the determination in decision block  134  is affirmative, the flow proceeds to block  138  whereupon the central office  18  assigns a first private key to the client  22  for the present transaction and stores the public key portion of the first public key-private key pair assigned to the client in the encryption key database  34 . In the next step, at block  140 , the credential manager then reviews the profile information for the notary  24  and the client  22  and the request for the transaction to verify whether state law requirements for notarizing documents are being satisfied. Upon a successful review of this information, the central office  18  in step  142  acknowledges to the client  22  that the private key portion of the first public key-private key pair has been properly assigned to it and the flow follows the Y path to the next step in  FIG. 3C . 
         [0019]    Referring now to  FIG. 3C , there is illustrated a third portion of the flow chart of  FIGS. 3A and 3B . The process enters the  FIG. 3C  at the path labeled Y to block  144  whereupon a prompt is issued to a client  22  to enter the document  27  for which a notary transaction has been requested. Following the prompt, the flow proceeds to a decision block  146  to determine whether the document  27  entered by the client  22  at the local workstation  12  has been received at the central office  18 . If the result is negative, the flow returns to the beginning of block  144  to again request the entry of the document  27 . If however, in block  146 , it is determined that the document  27  has been received at the central office  18 , then the flow proceeds to block  148  to display the document  27  upon the display  30  at the local workstation  12  so that the client  22  and the notary  24  may verify the document  27  that has been entered previously. When the document  27  has been verified on the display  30  at the local workstation  12 , the flow proceeds to block  150  whereupon the system fetches the assigned first private key from the client  22  and proceeds to step  152  whereupon the central office  18  assigns the private key portion of a second private key-public key pair to the document  27  associated with the present transaction and stores the second private key in the encryption key database  34  at the central office  18 . 
         [0020]    In the next step at block  154  in  FIG. 3C , the central office  18  tests the associative relationship of the respective public and private key pairs that have been assigned to the notary  24 , the client  22  and the document  27 . In particular, the associative relationship of the client  22  with the notary  24 , and of the client  22  with the document  27  entered by the client  22  at the local workstation  12  are tested. If the association of the respective encryption keys in the encryption key database  34  of the central office  18  tests OK in decision block  156 , then the flow proceeds to block  158  to generate a transaction code corresponding to the successful test of the associative relationship and issue a transaction ID representing the present transaction involving the notary  24 , the client  22  and the document  27 , and transmits it together with the transaction code to the local workstation  12  in block  160 . If however, in decision block  156 , the test for an associative relationship of the respective encryption keys was not successful, then the flow proceeds along the N path to block  162  whereupon the central office  18  transmits an error message to the local workstation  12  from which in the following step, decision block  164 , the local workstation  12  requests of the notary  24  whether he or she wishes to cancel the transaction. If the notary responds affirmatively, then the flow exits along a Y path to the exit block  166 . If, however, the notary  24  responds negatively, then the flow proceeds from decision block  164  to block  168  where the central office  18  may perform an encryption key check to determine the reason for the unsuccessful test of the associative relationship of the respective encryption keys. Such a key check routine may include steps to correct an error or perform a new registration as determined by a trouble shooting portion of the key check routine in block  168 . Following the key check routine in block  168 , the flow then proceeds to block  170  to restart the transaction in which case the flow would exit the transaction routine and return to the Start block  100  shown in  FIG. 3A . Returning to block  160  and the transmission of the transaction code along with the transaction ID to the local workstation  12  the flow thereupon proceeds along the path labeled with a letter Z to the entry point of  FIG. 3D . 
         [0021]    Referring now to  FIG. 3D , there is illustrated a fourth portion of the flow chart of  FIGS. 3A ,  3 B and  3 C. The process follows the Z path from block  160  in  FIG. 3C  to block  180  in  FIG. 3D  wherein the local workstation  12  prompts the client  22  to execute the transaction code at the local workstation  12  by entering a command to affix the signature of the client  22  previously entered in a graphic routine to the document  27 . In the next step at block  182 , the system embeds the first and second public key private key pairs into the document  27  and then, in step  184 , confirms the link of the client  22  and the notary  24  in the central office database. Next, in step  186 , the graphic seal and the signature of the notary  24  is embedded in or affixed to the document  27  at the local workstation  12 . From block  186 , the flow proceeds to block  188  whereupon the central office  18  acknowledges the completion of the notary transaction and in the following step  190  archives the executed documents in the central office archive database  36 . In the next step  182 , the system inquires of the notary  24  or the client  22  whether to download a copy of the document  27  to the local workstation  12 . If the response is negative, the flow follows the N path to exit at block  196 . If, however, the client  22  wishes to have a copy of the document  27  that has been notarized, then the client  22  enters an affirmative response to the query in  192  and the workstation  12  queries the central office  18  in block  194  to download a copy of the file containing the executed document  27  to the local workstation  12 . The routine exits at block  196 . 
         [0022]    It will be appreciated by those skilled in the art having the benefit of this disclosure that this electronic notary provides the ability for a remote notary and client to electronically sign and verify documents. It should be understood that the drawings and detailed description herein are to be regarded in an illustrative rather than a restrictive manner, and are not intended to be limiting to the particular forms and examples disclosed. On the contrary, included are any further modifications, changes, rearrangements, substitutions, alternatives, design choices, and embodiments apparent to those of ordinary skill in the art, without departing from the spirit and scope hereof, as defined by the following claims. Thus, it is intended that the following claims be interpreted to embrace all such further modifications, changes, rearrangements, substitutions, alternatives, design choices, and embodiments.