Abstract:
The method and system of the present invention function perform signature verification using third party authenticator via paperless electronic transaction platform. The invention is particularly suited to electronic commerce transactions that require a legally binding, traditional notarization by a live notary public, albeit in a format that is compatible to and electronic commerce. A customer downloads an appropriate electronic document from an electronic document repository and inputs the required information into the electronic document. After inputting all of the required information, the customer uploads the electronic document to an electronic document repository. An electronic transaction manager determines when all of the required information from each of the parties is present and amalgamates all of the information into a single final electronic document. The parties required to execute the electronic document are notified that the electronic document is ready to be electronically signed and electronically notarized. The signatories go to a notary public or a mobile notary public may travel to a location designated by the requesting signatory. The signatory inputs a manual, hand-written signature to the electronic document, using a electronic signature capture input device. The notary public inputs a manual, hand-written signature to the electronic document, using the electronic signature capture input device. The notary public next affixes an electronic notary seal by way of the electronic notary seal input device. After affixing the notary public&#39;s signature and seal, a desktop manager automatically executes an electronic notary journal. The electronic notary journal consists of all of the information required by law to legally enforce the notarization of the electronic commerce transaction.

Description:
COPYRIGHT NOTICE  
         [0001]    A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office, patent file or records, but otherwise reserves all copyright rights whatsoever.  
         Prior Applications  
         [0002]    This application claims the benefit of pending patent application entitled, “Method Of And System For Providing And Performing Notary Services and Verifying A Digital Signature Via A Global Computer Network” by Inventor Nicholas N. Nassiri, and referenced as docket number 32,870.001, with respect to the application&#39;s a method of signature verification using a notary public, electronic documents and the internet.  
         BACKGROUND OF THE INVENTION  
         [0003]    1. Field of the Invention  
           [0004]    The present invention generally relates to the field of signature verification with respect to on-line electronic commerce transactions. More particularly, the present invention relates to a method and system for providing signature verification using a paperless electronic document transaction platform.  
           [0005]    2. Description of the Prior Art  
           [0006]    Processing and closing certain paper based transactions such as a mortgage or a loan application is a well-known but complex process that involves many separate entities, diverse parties and involves multiple documents to consummate the transaction. Likewise, preparing, transferring and delivering the paper documents for signature on such document-laden transactions remains an expensive, slow, paper-based, offline process. The problems of excess documents and lapses in time time are compounded by the fact that the parties to such type transactions are typically numerous and geographically dispersed. Therefore, such type transactions incur considerable amounts of time and money to transport the necessary documents between the geographically dispersed parties. Sometimes, the diverse locations can be as far as cross-country or international. If changes are made to the documents at hand, more time and money are lost while the documents are shipped back and forth for review by the signatories. Upon completion of the documents, the signatories must then sign the documents to such type transactions in front of a notary public to ensure legal enforceability of the transaction.  
           [0007]    Additionally, such type transactions have been largely unable to take advantage of on-line electronic commerce because of the preemptive legal/ business practice requirement that a notary public authenticate the signature to bind the transaction. To date, there exists no integrated solution whereby these types of transactions can be conducted on-line using a paperless document platform that encompasses the necessary component of signature verification to conclude the transaction. Although an increasing number of such type transactions may be initiated online, they are invariably consummated off-line due to the inability to integrate the parties. Further, there exists no method of on-line notarization that meets the expectations or standards of a duly notarized signature done by a licensed notary public. Moreover, there exist no integrated process or method that integrates the parties and entities to such transactions on-line using a paperless transaction device that is accessible by all of the parties to the transaction. including a notary public.  
           [0008]    Nonetheless, there exists a real need to redress the problems addressing such type transactions. Although there exist solutions that claim to provide on-line “notarized” signature verification, such solutions do not comply with the standards and processes of a duly notarized signature. Notarization, legally and traditionally, requires an independent, in-person verification of the identity and signature using a live commissioned notary public who affixes a notary seal and jurat as a means of authentication. Existing products and solutions that state to be electronic “notaries” are not notarizations in the traditional sense of the word. Existing products and solutions typically use code-based digital certificates issued by a licensed certification authority as a means to verify a signature. Digital certificates are a function public key cryptography whereby a person&#39;s signature is converted to a digital code. Such processes operate so that a person&#39;s identity is verified a single time when the digital certificate is issued by the issuing authority. The applicant subsequently uses the code associated with the digital certificate each time his or her signature is required. The end result being that a signatory may use the digital certificate to unilaterally affix a “notarized” signature to an electronic document, when in fact a notary is not present, nor has a notary verified the identity of the signatory. The problem associated with public key cryptography methods is that while the certification authority is capable of issuing a certificate that correspond to an applicant, it is unable to verify the identity of the person who is signing the electronic document at the time the digital certificate is used. The inability of public key cryptography to guarantee a person&#39;s identity, has precluded such type transactions from effectively electronic based commerce to conclude such transactions.  
           [0009]    The prior art reveals the following six (6) prior art patents are found to be related to the field of signature verification although none of them provide an integrated approach to signature verification using a paperless electronic document platform.  
           [0010]    1. U.S. Pat. No. 5,742,685 issued to Berson et al. on Apr. 21, 1998 for “Method For Verifying An Identification Card And Recording Verification Of Same” (hereafter the “Berson Patent”). The Berson Patent discloses a method for verifying an identification card and recording verification of the same. The identification card includes information on a first portion of the card, the information including personal information relating to the person to be identified, and an encrypted representation of at least part of the information on a second portion of the card, the part including the personal information. The encrypted information can be read from the card and then decrypted to obtain a decrypted representation. The card is then verified by comparing the decrypted representation of the information with the information on the first portion of the card and the personal information is stored as at least part of a record of the verification transaction. The Berson Patent further discloses a record system which includes a source identification such as a machine number and a secure tamper proof clock.  
           [0011]    2. U.S. Pat. No. 5,912,974 issued to Holloway et al. on Jun. 15, 1999 for “Apparatus And Method For Authentication Of Printed Documents” (hereafter the “Holloway Patent”). The Holloway Patent discloses an apparatus and method for authentication of printed documents. The printed documents are scanned and digitized using a conventional scanner. The scanned and digitized document contents are edited before being used to generate a digital signature. This allows reading errors which could invalidate a subsequent verification process to be corrected. Using the editor and an input device, the signing authority identifies on the screen different segments of the document. Each segment contains data of a single type and selects a set of rules, among a group proposed by the system, for authenticating the document. Then, for each segment, an edited digital form of the data contents is derived using the method defined in the rules. A hash value of the rules used and the edited digital form of the segment contents is calculated using a public hashing algorithm. Then the apparatus generates a digital signature of the edited digitized segment contents using the secret key of the authenticator. Finally, an authentication code comprising the edited digital form of each segment and the digital signature is printed on the document. To verify the authenticity, the printed document is scanned and digitized again and the digital signature is checked by using the associated public key. If the check fails, the verifier identifies which segment has been scanned differently, comparing it with the related edited digital form in the authentication code printed on the document to evaluate its validity.  
           [0012]    3. U.S. Pat. No. 5,872,848 issued to Romney, et al. on Feb. 16, 1999 entitled, “Method and apparatus for witnessed authentication of electronic documents.” The Romney patent consists of a method and apparatus for authenticating an electronic document using an electronic document authenticator. An electronic document authenticator is an individual or enterprise that has been authorized by the inventor witness a digital signature. The Romney patent does not use a licensed notary public nor does the Romney patent perform a method of notarization. Rather, the Romney patent is a form of public key encryption verification whereby the customer enters a digital code, presumed to be the equivalent of his or her written signature, in the presence of the authenticator. The authenticator verifies the digital certificate belongs to the customer that used it by using a corresponding public key provided by the same customer. The Romney patent essentially ascertains that the public key supplied to the authenticator by the customer matches the private key used by the customer to produce the digital signature. The Romney patent fundamentally is a solution to deal with one of the most common problems associated with public key cryptography: identity theft. It is not a form of a method of traditional notarization. The Romney patent is premised on the issuance of digital certificates to be used by all parties, including the authenticator, to attest to the veracity of a document, as opposed to the authenticity of an identity and corresponding signature, per the method of a traditional notarization performed by a licensed notary public.  
           [0013]    4. U.S. Pat. No. 5,926,551 issued to Dwork et al. on Jul. 20, 1999 for “System And Method For Certifying Content Of Hard-Copy Documents” (hereafter the “Dwork Patent”). The Dwork Patent discloses a system and method for certifying content of hard-copy documents. A digital representation of the data object is produced, typically, for hard-copy documents to produce a two dimensional bit map. Then, a signature for the digital representation is obtained from a certifying agent. The signature is produced as a function of the digital representation of the data object, so as to reflect the content of the data object. This will commonly be performed by a certifying agent, such as a post office clerk or a notary public. As a result, a representation of the signature, along with the data object is provided. Accordingly, it is established that the signature authenticates the content of the data object.  
           [0014]    5. U.S. Pat. No. 5,940,187 issued to Berke on Aug. 17, 1999 for “Method For Certifying Facsimile Communication Over A Telephone Network” (hereafter the “Berke Patent”). The Berke Patent discloses a method for certifying facsimile communication over a telephone network. The method includes a registration sequence during which an originator of facsimile messages establishes an account with the certifying system by providing a handwritten signature and identifying data. The handwritten signature is linked to the identifying data, and the identifying data is utilized through the method in an effort to insure the authenticity of facsimile messages certified by the certifying system.  
           [0015]    6. U.S. Pat. No. 5,973,731 issued to Schwab on Oct. 26, 1999 for “Secure Identification System” (hereafter the “Schwab Patent”). The Schwab Patent discloses a secure identification system for providing a secure interactive communication of text and image information between a central server computer and one or more client computers, located at remote sites for the purpose of storing and retrieving files describing and identifying unique products, services or individuals.  
           [0016]    A major problem to conducting electronic commerce that requires signature verification is that to date there exists no method whereby electronic documents can be electronically notarized using the traditional and legally binding method by a live, licensed notary public.  
           [0017]    A major problem to conducting electronic commerce, is that to date there exists no method whereby electronic documents are integrated and managed using a paperless document platform that eliminates the need to physically transport documents to be signed and notarized.  
           [0018]    It is desirable to provide a new method and system for providing signature verification with the capability of signing and notarizing electronic documents at remote locations without the need to physically transport the hard copies of such documents to the remote locations to be signed by the signatories and notarized by a notary public. While the devices created by the prior art may be suitable for the particular purpose to which they address, they are not as suitable for signature verification for electronic commerce transactions that typically require the traditional form and security of an in-person notarization.  
           [0019]    In view of the foregoing disadvantages inherent in the known prior art, the present invention provides a new method for providing and performing notary services on-line with the capability of electronically transporting, signing and notarizing the electronic documents. In this respect, the method of signature verification with the capability of electronically transporting signing and notarizing the electronic document according to the present invention, substantially departs from the conventional concepts and designs of the prior art, and in so doing provides an apparatus primarily developed for the purpose of performing notary services via the Internet with the capability of electronically signing and notarizing the electronic document at a remote location. Further novel features and other objects of the present invention will become apparent from the following detailed description, discussion and the appended claims, taken in conjunction with the drawings.  
         SUMMARY OF THE INVENTION  
         [0020]    The general purpose of the present invention, which will be described subsequently in greater detail, is to provide a new method of electronic notarization by a notary public using a paperless document platform that is not anticipated, rendered obvious, suggested, or even implied by any of the prior art, either alone or in any combination thereof.  
           [0021]    Described briefly, the method and system of the present invention function to provide and perform signature verification using a live notary public and a paperless electronic transaction platform. The invention is particularly suited to electronic commerce transactions that require a traditional notarization by a live notary public, albeit in a format that is compatible to electronic documents. A customer wishing signature verification for an electronic document runs a desktop manager on the browser of a local computer system to interface with the functions and features of the present invention. To initiate a transaction, the customer first must register with an electronic transaction manager which structures the transaction request and manages the transaction cycle. Upon registering with the electronic transaction manager, a customer may download an appropriate electronic document or set of electronic documents (referred to as the “electronic document”) from an electronic document repository. After downloading an electronic document, the electronic transaction manager assigns a password and a name to the electronic document. The customer inputs the required information into the electronic document using a local computer system. After inputting all of the required information, the customer uploads the electronic document to the electronic document repository. The electronic transaction manager records the transaction in the electronic transaction manager database, and posts the electronic document for retrieval by a subsequent authorized party. A subsequent authorized party downloads the electronic document using an access password and the document name. Several subsequent authorized parties may access a single electronic document, singularly or simultaneously.  
           [0022]    The parties to the transaction communicate with one another via the electronic transaction status board. The electronic transaction status board allows the parties to have constant and instant information and communication that is readily accessible. The electronic transaction status board functions as a virtual message center where the parties may inform one another of the respective status of the electronic documents. Likewise, the electronic transaction status board functions to post information from the electronic transaction manger regarding the status of the electronic document and to post other information regarding the transaction cycle.  
           [0023]    The electronic transaction manager determines when all of the required information from each of the parties is present and amalgamates all of the information into a single final electronic document. The electronic document is encrypted and assigned a corresponding temporary signing password. The temporary signing password is distinct from the initial password and the access password assigned to the electronic document. Upon assigning a temporary signing password, no information may be added, deleted or modified to the electronic document prior to signature. The parties required to execute the electronic document are notified that the electronic document is ready to be electronically signed and electronically notarized. Each signatory is given the electronic document&#39;s name and the corresponding temporary signing password. The signatories go to a notary public or a mobile notary public may travel to a location designated by the requesting signatory. The signatory reveals the electronic document&#39;s name and corresponding temporary signing password to the notary public, who downloads the electronic document. The desktop manager highlights or otherwise indicates each and every place where signature or the initials of the signatory are required in the electronic document. The signatory inputs a manual, hand-written signature to the electronic document, using a electronic signature capture input device. The notary public inputs a manual, hand-written signature to the electronic document, using the electronic signature capture input device. The notary public next affixes an electronic notary seal to the electronic document where indicated by the desktop manager. The notary public affixes the notary seal by way of the electronic notary seal input device. After affixing the notary public&#39;s signature and seal, the desktop manager automatically executes the electronic notary journal. The electronic notary journal creates an independent electronic record of the notarization that remains in the sole possession of the notary public. The electronic notary journal consists of all of the information required by law to legally enforce the notarization of the transaction. After recording the transaction in the notary journal, the signed, notarized electronic document is encrypted and a time/date stamp is applied. Any changes made to the electronic document after this point in time invalidate the electronic document.  
           [0024]    It has been discovered, according to the present invention, that if transactions requiring traditional notarization can be electronically notarized using an in-person method of notarization and a paperless transaction platform, such type of transactions can be conducted on-line thereby saving substantial amounts of time and money.  
           [0025]    It has been discovered, according to the present invention, that if the access and transport of electronic documents and notary public services can be accomplished online, that the executed electronic documents can be rapidly verified and validated without waiting for paper document to be physically shipped to a remote location or without having the parties travel to a remote location, thereby saving substantial amounts of time and money.  
           [0026]    It has been discovered, according to the present invention, that if notary services using a paperless transaction platform can be accomplished online, then sensitive agreements, or high-value transactions and the like, which traditionally and legally require a notary seal, do not sit on hold and can be executed more rapidly and efficiently.  
           [0027]    It has additionally been discovered, according to the present invention, that if notary services paperless transaction platform can be accomplished online, it reduces courier costs and possible delay by the couriers who transport the documents to remote locations to be signed.  
           [0028]    It is therefore an object of the present invention to provide a method for performing signature verification using a notary public and a paperless transaction platform, with the capability of rapidly signing and notarizing electronic documents at remote locations without physically transporting the documents to the remote location to be signed by signatories and notarized by a participating notary public at the remote location.  
           [0029]    It is a further object of the present invention to provide a method and system for providing and performing electronic notary services using a paperless document platform, where notarizations can take place at the notary&#39;s place of business having internet access or wherever there is internet access.  
           [0030]    It is a further object of the present invention to utilize the most trusted and secure form of identity and signature verification, a licensed notary public, to execute binding legal electronic documents.  
           [0031]    It is a further object of the present invention to enable high value or sensitive electronic document transactions requiring an in-person notarization to be conducted on-line using a paperless electronic document platform.  
           [0032]    It is a further object of the present invention to integrate all of the parties to high value or sensitive transactions on-line by providing a standardized set of electronic documents that are accessible on-line and interchangeable among the parties on-line, including the notary public.  
           [0033]    It is still a further object of the present invention to provide a method and system for verifying and identifying an electronic signature of a signatory by providing a key, code or pin number to the signatory so that the signatory can use the pin number at a later time to verify and identify his or her digital signature to a requesting party, vendor etc.  
           [0034]    There has thus been outlined, rather broadly, the more important features of the invention in order that the detailed description thereof may be better understood, and in order that the present contribution to the art may be better appreciated. There are additional features of the invention that will be described hereinafter. In this respect, before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of the description and should not be regarded as limiting.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0035]    Referring particularly to the drawings for the purpose of illustration only and not limitation, there is illustrated:  
         [0036]    [0036]FIG. 1 is a flow chart diagram that illustrates the exemplary embodiment of the present invention;  
         [0037]    [0037]FIG. 2 is a flow chart diagram that illustrates the customer and notary public registering to use the present invention;  
         [0038]    FIGS.  3 A- 3 D are a series flow chart diagrams that illustrate the exemplary method for using the electronic transaction manager to manage the paperless document transaction according to the method of the present invention. FIG. 3A depicts the electronic transaction manager assigning an internal reference number/code that is distinct from the electronic document name and password code, FIG. 3B depicts the electronic transaction manager assigning the electronic document a name and password code , FIG. 3C depicts the customer assigning the electronic document a name and password code, FIG. 3D depicts the electronic transaction manager using the foregoing internal reference number/code, and the electronic document a name, and the password code assigned to the electronic document to manage the transaction cycle;  
         [0039]    FIGS.  4 A- 4 C are flow chart diagrams that illustrate the customer and other authorized parties accessing the electronic document according to the method of the present invention;  
         [0040]    FIGS.  5 A- 5 B are flow chart diagrams that illustrate changes made to previously entered information and the processing of such changes according to the method of the present invention;  
         [0041]    FIGS.  6  A- 6 B are flow chart diagrams that illustrate the process of accessing and displaying an electronic document for signature verification according to the method of the present invention;  
         [0042]    FIGS.  7 A- 7 B are flow chart diagrams that illustrate the customer and notary public electronically signing the electronic document according to the method of the present invention;  
         [0043]    [0043]FIG. 8 is a flow chart diagram that illustrates the notary public notarizing the electronic document according to the method of the present invention;  
         [0044]    [0044]FIG. 9 is a flow chart diagram that illustrates verifying the notary public according to the method of the present invention; and  
         [0045]    [0045]FIG. 10 is a flow chart diagram that illustrates the execution of the notary public journal according to the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0046]    I. Description of Present Invention  
         [0047]    Although specific embodiments of the present invention will now be described in detail and with reference to the drawings, it should be understood that such embodiments are by way of example only and merely illustrative of but a small number of the many possible specific embodiments which can represent applications of the principles of the present invention. Various changes and modifications obvious to one skilled in the art to which the present invention pertains are deemed to be within the spirit, scope and contemplation of the present invention as further defined in the appended claims.  
         [0048]    With reference to FIG. 1, the method and system of the present invention comprises a customer  5 , the internet or other TCP/IP based networks  10 , a customer local computer system  20 , a desktop manager  30 , a host computer server  40 , an electronic transaction manager  50 , an electronic transaction management database  60 , electronic document repository  70 , an electronic document  80 , an electronic transaction  90 , a rules-based integrity check  100 , an electronic transaction status board  110 , other authorized parties  120 , a signatory  130 , an electronic signature input device  135 , a notary public  140 , notarization processes and methods  150 , an electronic notary seal input device  160 , and an electronic notary journal device  170 .  
         [0049]    Any party to an electronic transaction that requires signature verification, the “customer”  5 , may initiate a notarization request to electronic transaction manager  50  using a customer local computer system  20 . The customer  5  may be, but need not be, the signatory  130 , whose signature is to be notarized by a notary public  140 . For example, a loan officer, an escrow officer, or a regulatory agency may be the customer  5  that inputs information  190  into an electronic document  80  that eventually will be signed by a different signatory  130 , for example, a loan applicant. The customer  5  accesses the present invention using a local computer system  20  from a remote location (i.e. the home, office, or a laptop) that establishes internet or TCP/IP connectivity  10  with the host computer server  40  using the desktop manager  30 . The desktop manager  30  runs on the browser  21  of the local computer system  20  and provides the interface that allows the customer  5  to operate the present invention by the processes and methods described herein. Likewise, the desktop manager  30  runs on the browser  21  of the customer local computer system  20  of the notary public  140  and provides the interface that allows the notary public  140  to operate the present invention by the processes and methods described herein. With respect to the customer  5 , the desktop manager  30  is the interface that allows the customer  5  to access the present invention, establish a registration account  55  with the electronic transaction manager  50 , navigate the electronic document repository  70 , to download and upload  180  an electronic document  80  from the electronic document repository  70 , to access the electronic transaction status board  110 , and to input an electronic signature  245  onto the electronic document  80  using the electronic signature input device  135 .  
         [0050]    With respect to the notary public  140 , the desktop manager  30 , is the interface that allows the notary public  140  to establish a registration account  55  with the electronic transaction manager  50 , to download and upload  180  an electronic document  80  from the electronic document repository  70 , to access the electronic transaction status board  110 , to input an electronic signature  245  onto the electronic document  80  using the electronic signature input device  135 , to input an electronic seal  164  using the electronic notary seal input device  160 , to execute notarization processes and methods  150 , to execute the electronic notary journal  170  and to authenticate the notary public  140  as being authentic  144 .  
         [0051]    The electronic transaction manager  50  is an application that manages the paperless document transaction from the point of initiation by the customer  5  to the end point of notarization  150  by a notary public  140  . Initially, the customer  5  registers with the electronic transaction manager  50  which in turn establishes a customer registration account  55  in the electronic transaction manager database  60 . The customer registration account  55  is the basic upon which the electronic transaction manager  50  correlates electronic documents  80  and keep a record of the parties to a transaction. The electronic transaction manager  50  is a function of the host computer server  40 . The electronic transaction manager  50  tracks and manages each electronic document  80  registered within the electronic transaction management database  60  using the registration information described fully below as a tracking mechanism and associating the information of the electronic transaction  90  with a particular customer registration account  55 . The electronic transaction manager  50  also serves to authorize access by the other authorize parties  120  and the notary public  140  to a single electronic document  80 , even though the other authorized parties  120  may be geographically remote, whether it be another city, another state, of another country.  
         [0052]    The electronic document repository  70  consists of various electronic documents  80  that are specific to certain transactions and certain sectors or industries. For example, the electronic document repository  70  may consist of electronic documents  80  for the financial and banking sector, the real estate sector, or government/ regulatory agencies and the like. The electronic documents  80  may be listed by type; i.e. deeds of trust, or by category; i.e. banking documents. A customer  5  may opt to post a “restricted access group” within the electronic document repository  70 . A restricted access group consists of confidential electronic documents  80  that are proprietary to a specific customer  5  and may only be accessed or utilized by the registered customer  5 . The restricted access group is password protected. In any category, the electronic document  80  may be represented singularly, or as a grouped set of electronic documents  80  (collectively referred to as the “electronic document”). The electronic document repository  70  may be used in conjunction with a request for signature verification or independently. In either scenario, the transaction must be initiated via the desktop manager  30  and managed by the electronic transaction manager  50  as described herein.  
         [0053]    The electronic transaction manager  50  further consists of an electronic transaction status board  110 . The electronic transaction status board  110  functions as an on-line virtual message communication center. The electronic transaction status board  110  automatically received electronic transaction information  90  from the electronic transaction manager  50 . That is, upon successful upload of the electronic document  80  to the electronic document repository  70 , the electronic transaction manager  50  automatically posts the time, date, and the party that posted the electronic document  80  to the electronic transaction status board  110 . Likewise, the electronic transaction manager  50  posts when a transaction cycle is complete, including the time and date of notarization on the electronic transaction status board  110 . The electronic transaction status board  110  further functions as a virtual message center where the various parties to the transaction may inform one another of the respective status of the electronic document  80 , i.e. a lender may be waiting on an appraisal, or the signatory  130  may be ill and unable to conclude the transaction at this point in time. Likewise, the parties may post questions or requests for other parties on the electronic transaction status board  110 .  
         [0054]    The electronic signature input device  135  is a device that is remote  125  to the customer local computer system  20  or is a function embedded within the customer local computer system  20 . The electronic signature input device  135  captures the manual, hand-written signatures of the signatory  130  and the notary public  140 . The desktop manager  30  indicates on the browser  21  of the customer local computer system  20  where the electronic signature  245  of the signatory  130  and the notary public  140  are to be input into the electronic document  80 . The desktop manager  30  affixes the captured electronic signature  245  of the signatory  130  and the notary public  140  to the electronic document  80 . The electronic notary seal input device  160  is a device that is remote to the customer local computer system  20  that operates in conjunction with a function embedded within the desktop manager  30 . Alternatively, electronic notary seal input device  160  is a device that is embedded in the customer local computer system  20  that operates in conjunction with a function embedded within the desktop manager  30 . The electronic notary seal input device  160  executes an electronic notary seal  244  or an electronic notary jurat (collectively referred to as the “notary seal”) of the notary public  140  to the electronic document  80 . The desktop manager  30  indicates on the browser  21  of the customer local computer system  20  where the electronic notary seal  164  is to be input into the electronic document  80 , and the desktop manager  30  affixes the captured electronic notary seal  164  to the electronic document  80 . The electronic notary journal  170  is a function of the desktop manager  30 . The electronic notary journal  170  executes upon a notary signature  245  and seal  164  being affixed to the electronic document  80 . The electronic notary journal  170  contains all of the verification information of the transaction required by law. The electronic notary journal  170  is a record that remains in the sole possession of the notary public  140  to whom it belongs.  
         [0055]    II. Operation of the Present Invention  
         [0056]    The method and system of the present invention function to provide and perform signature verification services by a live notary public  140  via the internet or other TCP/IP based network  10  using a paperless document platform which consists of a customer local computer system  20 , a desktop manager  30 , a host computer server  40 , an electronic transaction manager  50 , an electronic transaction management database  60 , electronic document repository  70 , an electronic document  80 , an electronic transaction  90 , a rules-based integrity check  100 , an electronic transaction status board  110 , other authorized parties  120 , a signatory  130 , an electronic signature input device  135 , a notary public  140 , notarization processes and methods  150 , an electronic notary seal input device  160 , and an electronic notary journal device  170 .  
         [0057]    With reference to FIG. 1, a customer  5  with internet or TCP/IP connectivity  10  may either a website, a local access network (LAN) or a wide access network (WAN) using a client-server infrastructure, to provide the point of access to the present invention. In the preferred embodiment of the present invention, the request for signature verification using a paperless document platform is initiated by the customer  5  accessing a website on the world-wide-web using the customer local computer system  20 . The website provides the customer  5  with information about the services available and information in the form of a tutorial on how to register with, and use the present invention. Alternatively, the invention may be configured for use an a restricted LAN or a restricted WAN.  
         [0058]    With reference to FIG. 2, registration with the electronic transaction manager  50  is a prerequisite to using the present invention by the customer  5  and the notary public  140 . The customer  5  and the notary public  140  establish a registration account  55  in the same manner but for different reasons. The customer  5  and the notary public  140  establish a registration account  55  with the electronic transaction manager database  60  by inputting registration information from the customer local computer system  20 . With respect to the customer  5 , registration enable the electronic transaction manager  50  to correlate electronic documents  80  selected by the customer  5  with that particular customer  5  and with all other authorized parties  120  as identified by the customer  5 , during the registration process. Registration further allows the electronic transaction manager  50  to associate all electronic document transactions  90  with that particular registration account  31  which is integral to the function of the present invention for the purpose of managing the electronic document transaction cycle, (as more fully described below with reference to FIGS. 3A through 3D). With respect to the notary public  140 , registration entails the notary public  140  providing verification information to register with the present invention as a duly licensed notary public  140 . The notary public registration account  55  is recorded in the electronic transaction manager database  60 , and is subject to verification by the rules-based integrity check  100  prior to the desktop manager  30  executing the notarization processes and methods  150 .  
         [0059]    With reference to FIGS. 3A through 3D, after establishing a registration account  55  with the electronic transaction manager database  60 , the customer  5  selects the electronic document  80  required to be managed by the electronic transaction manager and to be notarized by the notary public  140 . With reference to  3 A, each electronic document  80  is assigned  51  a code or a form of internal identification  52  by the electronic transaction manager  50  as a priori, this code or reference number  52  is separate and distinct from the registration account  55 . Upon a customer  5  selecting an electronic document  80  from the electronic document repository  70 , the electronic transaction manager  50  automatically correlates the electronic document  80  to the customer registration account  55  by way of the code or reference number  52 . With reference to FIGS. 3B the electronic transaction manager  50  further assigns a password  54  and a document name  53  to each electronic document  80  selected by the customer  5 . Alternatively, with reference to FIG. 3C, the customer  5  may input a document name  53  and corresponding password  54  to the electronic document  80 . Otherwise, the customer  5  may opt to use the default document name  53  and corresponding password  54  provided by the electronic transaction manager  50 . With reference to FIGS.  3 D, upon assigning a document name  53  and a corresponding password  54 , the electronic transaction manager  50  automatically registers  56  each electronic document  80 , its corresponding code  52 , document name  53 , password  54  and correlating customer registration account  55  in the electronic transaction manager database  60 .  
         [0060]    With reference to FIG. 4A, upon the download of a particular electronic document  80  from the electronic document repository  70 , the desktop manager  30  displays the selected electronic document  80  on the browser  21  of the customer local computer system  20 . The desktop manager  30  directs the customer  5  to each place in the electronic document  80  where information  190  is required to be input into the electronic document  80  by the customer  5 . In the preferred embodiment, the electronic document  80  appears as a graphical representation on the browser  21  of the local computer system  20 , and areas in the electronic document  80  requiring information to be input  190  shall be highlighted or otherwise indicated by the desktop manager  30 . Alternatively, the electronic document  80  appears as a graphical representation on the browser  21  of the local computer system  20  alongside fields; information being input into these fields that appear in the graphical representation of the electronic document  80 . Information may be comprised of varied sorts, including personal information such as a driver&#39;s license, numerical information such as a purchase price, expert opinion, and the like. The desktop manager  30  further determines which fields where information is to be input are restricted and which fields are permissive. That is, certain parties may be prohibited from inputting information  190  into restricted fields in the electronic document  80 . The determination of which fields are restrictive is made by the customer  5  during the registration process, or in some instances, after downloading the electronic document  80 , but always prior to posting the electronic document  80  for retrieval by a subsequent authorized party  120 .  
         [0061]    With reference to FIG. 4A, upon inputting the required information  190  into the electronic document  80  using the customer local computer system  20 , the customer  5  uploads the electronic document  80  to the electronic document repository  70  for retrieval by a subsequent authorized party  120 . Subsequent authorized parties  120  are identified by the customer  5  in the customer registration account  55 . The desktop manager  30  executes the rules-based integrity check  100  to ensure that all of the required information is present before permitting the electronic document  80  to upload to the electronic document repository  70 . The rules-based integrity check  100  entails that the following criteria are met: (i) all of the required information is present; and (ii) the electronic document  80  has not been altered in any way, with the exception of the permissive information input. If the electronic document  80  fails the rules-based integrity check  100 , in the first instance (i) the desktop manager  30  alerts the customer  5  with instruction to complete the missing information and reload the electronic document  80  to the electronic document repository  70 . If the electronic document  80  fails the rules-based integrity check  100  in the second instance (ii), the desktop manager  30  alerts the customer  5  that the electronic document  80  may not be uploaded to the electronic document repository  70 . Once the electronic document  80  is uploaded to the electronic document repository  70  for retrieval by a subsequent authorized party  120 , no subsequent authorized party  120  may alter information entered by a previous authorized party  120  or by the customer  5 .  
         [0062]    Upon a customer  5  uploading an electronic document  80  to the electronic document repository  70 , the electronic transaction manager  50  automatically runs a rules-based integrity check  100 . The rules-based integrity check  100  entails confirming that the following criteria are met: (i) all of the required information is present in the electronic document  80 ; (ii) that the electronic document  80  corresponds to a registration account  55 ; and (iii) that the electronic document  80  has not been altered in any way, with the exception of permissive information being added to the electronic document  80 . Should these criteria fail, the electronic transaction manager  50  will not accept the electronic document  80  to be posted in the electronic document repository  70 . After passing the rules-based integrity check  100 , the electronic transaction manager  50  records the transaction status  90  in the electronic transaction manager database  60  and posts the electronic document  80  for retrieval by a subsequent authorized party  120 .  
         [0063]    With reference to FIG. 4B, an authorized party  120  is an individual or entity identified by the initial customer  5  in the registration account  55  as being allowed to access the electronic document  80 . The electronic transaction manager  50  assigns and disseminates  210  an access password  200  to the other authorized party  120  per the instructions of the initial customer  5 . The access password  200  permits the authorized party  120  to download  180  the electronic document  80  from the electronic document repository  70 . In the preferred embodiment of the present invention, a subsequent authorized party  120  downloads  180  the electronic document  80  using an access password  200  supplied by the electronic transaction manager  50 . In another embodiment, an authorized party  120  downloads the electronic document  80  using an access password  200  supplied by the customer  5 . In either embodiment, the access password  200  is additional and different from the initial password  54  assigned to the electronic document  80 . No subsequent authorized party  120  shall have the same access password  200  as another authorized party  120  nor shall they have access to any access password  200  other than their own.  
         [0064]    With reference to FIG. 4C, a subsequent authorized party  120  utilizes the present invention per the same method as did the customer  5 . That is, an authorized party  120  runs the desktop manager  30  on a customer local computer system  20  and downloads the electronic document  80  using the document name  53  and the access password  200 . The desktop manager  30  displays the electronic document  80  on the browser  21  of the customer local computer system  20 , and indicates where information is to be input  190  into the electronic document  80  per the methods described above. The other authorized party  120  inputs the required information  190  where indicated by the desktop manager  30  and uploads the electronic document  80  to the electronic document repository  70  to be managed by the electronic transaction manager  50 . The electronic transaction manager  50  may post several copies of the electronic document  80  so that several other authorized parties  120  may access the electronic document  80  singularly or simultaneously in time, each using their own unique access password  200 . Upon a determination by the electronic transaction manager  50  that all of the required information is input  190  into the electronic document  80  by the customer  5  and each of the authorized parties  120  identified in the registration account  55 , the electronic transaction manager  50  amalgamates the information from every party into a single finalized electronic document  80 .  
         [0065]    With reference to FIGS. 5A and 5B, only the originator  224  of the information input  190  into the electronic document  80  (whether it be a customer  5  or other authorized party  120  may alter or otherwise change such information after the originator  224  has successfully uploaded the electronic document  80  to the electronic document repository  70 . Should the originator  224  of the information, wish to add, delete or otherwise modify information after posting the electronic document  80  for retrieval by a subsequent authorized party  120 , the electronic transaction manager  50  automatically executes a rules-based integrity check  100  to the changed information. The rules-based integrity check  100  executes upon the originator  224  of information re-posting the electronic document  80  to the electronic document repository  70 . The rules-based integrity check  100  compares the modified information in the electronic document  80  with the original information in the electronic document  80 . The rules-based integrity check  100  compares the modified information with the original information and extracts the specific modifications that have been made to the electronic document  80 . The electronic transaction manager  50  notifies  226  each party to the transaction via the electronic transaction status board  110  that the electronic document  80  has been modified, and the time and date of the modification. The electronic transaction manager  50  further identifies the party  224  that made the modification and specifies what modifications have been made to the electronic document  80 . Each party to the transaction must respond to the electronic transaction manager  50  by way of an affirmative action  227 , such as activating an “I Accept” icon, or some variation thereof, prior to the electronic transaction manager  50  accepting the modified electronic document  80  to be posted in the electronic document repository  70 .  
         [0066]    The electronic transaction manager  50  further consists of an electronic transaction status board  110 . The electronic transaction status board  110  functions as an on-line virtual message communication center. The electronic transaction status board  110  automatically receives tracking information from the electronic transaction manager  50  that consists of the electronic document transaction  90 . That is, upon a successful upload of the electronic document  80  to the electronic document repository  70 , irrespective of the point in the transaction cycle, the electronic transaction manager  50  automatically posts the time, date, and the party that posted the electronic document  80  to the electronic transaction status board  110 . Likewise, the electronic transaction manager  50  posts when a transaction cycle is complete, including the time and date of notarization  164  on the electronic transaction status board  110 . The electronic transaction status board  110  further functions as a virtual message center where the various parties to the transaction may inform one another of the respective status of the electronic document  80 , i.e. a lender may be waiting on an appraisal, or the signatory  130  may be ill and unable to conclude the transaction at this point in time. Likewise, the parties may post questions or requests for other parties on the electronic transaction status board  110 . The electronic transaction status board  110  allows the parties to the transaction to have constant and instant information and communication that is readily accessible. However, access to the electronic transaction status board  110  is password protected and only the customer  5  and subsequent authorized parties  120  may access the electronic transaction status board  110 . Each party to the transaction is assigned an individual electronic message board that resides in electronic transaction status board  110 . Each individual electronic message board is unique to the corresponding party, and access to input information into an individual electronic message board is restricted to the corresponding party to whom it is registered. Nonetheless, each party may view the contents of any one of the individual electronic message boards.  
         [0067]    With reference to FIG. 6, the electronic transaction manager  50  determines when the electronic document  80  is ready to be electronically signed by the signatory  130 . The electronic document  80  is ready for signature when all of the required electronic documents  80  needed to complete the transaction are uploaded into the electronic document repository  70 , and the rules-based integrity check  100  ensures that all of the required information  190  is completed in each of the electronic documents  80 . Upon a determination that the electronic document  80  is ready for signature, the electronic transaction manager  50  encrypts the electronic document  80  and applies a time and a date stamp. Too, at this time, the electronic transaction manager  50  assigns a temporary signing password  230  to each signatory  130 . Each signatory  130  is given a temporary signing password  230  that is unique to the signatory  130 . No two signatories  130  shall have a common temporary signing password  230 . The electronic transaction manager  50  registers each temporary signing password  230  with the correlating electronic document  80  to be signed in the electronic transaction manager database  60 . The temporary signing password  230  is a function of the electronic transaction manager  50  and is distinct from the initial password  53  assigned to the electronic document  80 , and from the access password  200  assigned to the subsequent authorized party  120 .  
         [0068]    The electronic transaction manager  50  alerts the signatory  130  that the electronic document  80  is ready to be electronically signed  135  and electronically notarized  150 . Likewise, the electronic transaction manager  50  disseminates the temporary signing password  230  to the signatory  130  along with a list of locations for a notary public  140  with the means to electronically notarize  150  the electronic document  80  according to the present invention. The signatories  130  may be geographically remote, as in different states or countries, each utilizing a different notary public  140  who shall access the same electronic document  80  from the electronic repository  70  for notarization  150 . The signatory  130  discloses the name of the electronic document  80  and the corresponding temporary signing password  230  to the notary public  140 . Using the temporary signing password  230 , the notary public  140  downloads the electronic document  80  from the electronic document repository  70  using a customer local computer system  20  that runs the desktop manager  30 .  
         [0069]    With reference to FIG. 6B, after reviewing the electronic document  80  in the presence of the notary public  140 , the signatory  130  affixes an actual hand-written signature to the electronic document  80  using the electronic signature input device  135 . The desktop manager  30  highlight or otherwise indicates  241  each and every place where a signature or initials is required in the electronic document  80  that appears on the browser  21  of the customer local computer system  20  as a graphical representation  240 . Indication will typically appear as an icon such as an arrow or some other pointing device that physically demonstrates on the browser  21  of the customer local computer system  20  which part of the electronic document  80  the signatory  130  is initializing or signing. To ensure the signor&#39;s intent, each place indicated by the desktop manager  30  requiring a signature or initials must be physically input using the electronic signature input device  135 . That is, the desktop manager  30  will not replicate signatures if multiple signatures are required in the electronic document  80 , but mandate that the signatory  130  sign each place in the electronic document  80  where indicated by the desktop manager  30 ,  241 .  
         [0070]    With reference to FIG. 7A, the signatory&#39;s  130  actual hand-written signature  245  is captured by way of an electronic signature input device  135 , and affixed to the electronic document  80  by the desktop manager  30 . The electronic signature input device  135  may be a part of the customer local computer system  20  or a device external to it  125 . The electronic signature input device  135  utilizes the traditional pen and ink method of physically signing one&#39;s own signature. The desktop manager  30  electronically affixes  242  the signature to the electronic document  80  as a graphical representation  246 . Alternatively, the electronic signature  245  captured by the electronic signature input device  135  may be encrypted as a code  247  that is unique to the signatory  130  and linked with the corresponding electronic document  80 .  
         [0071]    With reference to FIG. 7B, upon witnessing the signatory  130  physically sign the electronic document  80 , the notary public  140  affixes an actual hand-written signature  245  to the electronic document  80  where indicated by the desktop manager  30 , using the electronic signature input device  135 . Per the method referenced above, the desktop manager  30  will not replicate the notary public&#39;s  140  signature  245  if multiple signatures are required, but mandate that the notary public  140  sign each place where indicated by the desktop manager  30 . Per the method above, the electronic signature input device  135  utilizes the traditional pen and ink method whereby the notary public  140  physically signs the electronic document  80  that appears as a graphical representation  240  of the hard copy document it replaces. The electronic signature of the notary public  140  appears on the electronic document  80  as a graphical representation  246 . Alternatively, the electronic signature  245  captured by the electronic signature input device  135  may be encrypted as a code  247  that is unique to the notary public  140  and linked with the corresponding electronic document  80 .  
         [0072]    With reference to FIG. 8, after affixing a signature  245  to the electronic document  80 , the notary public  140  affixes an electronic notary seal  150  to the electronic document  80 . The notary public  140  electronically affixes the seal to the electronic document  80  using the electronic notary seal input device  160 . The electronic notary seal input device  160  is independent of the desktop manager  30  but operates only in conjunction with the desktop manager&#39;s  30  notarization function. The desktop manager&#39;s  30  notarization function only operates when activated by the electronic notary seal input device  160 . The electronic notary seal input device  160  may be function embedded in the customer local computer system  20  or a portable device that attached to the customer local computer system  20 . In the preferred embodiment pf the present invention, the electronic notary seal input device  160  is a remote device that remains in the sole possession of the notary public  140 . The notarization function of the desktop manager  30  will only run when the electronic notary seal input device  160  is attached to the customer local computer system  20 . The remote electronic notary seal input device  160  is a hardware-based security portable device that attaches to the serial or parallel printer port of the customer local computer system  20 , including a laptop. The remote electronic notary seal input device  160  utilizes a hardware key that uses codes and passwords embedded inside the key to control access to the desktop manager&#39;s  30  notarization function. While activated, the electronic notary seal input device  160  receives encoded data from the desktop manager  30  and decodes it in a way that cannot be imitated. The decoded data that is returned from the remote electronic notary seal input device  160  is deployed in the desktop manager  30  so that it affects the mode in which the manager  30  executes the notarization function. The remote electronic notary seal input device  160  is programmed to execute a notarization  164  upon a verified match  162  with the desktop manager  30 . After decoding, a verified match  162  will execute the notarization function of the desktop manager  30  that in turn activates the execution of the electronic notary seal which is embedded in the remote electronic notary seal input device  160 . The desktop manager  30  indicates by way of an arrow or an icon that appears on the browser  21  of the customer local computer system  20  where the electronic seal shall be input and appear on the electronic document  80 . In the preferred embodiment of the present invention, the notary seal appears as a graphical representation  165  of a traditional notary seal on the electronic document  80 . The graphical representation  165  may include an encrypted code that is affixed to the electronic document  80  that contains the date and time the notary public&#39;s  140  seal was affixed and the verification information of the notary public  140  provided in the notary public&#39;s registration account  55 . As stated, verification information consists of that information required by law to license and register the notary public.  
         [0073]    Alternatively, the remote electronic notary seal input device  160  may input an electronic notary seal in the form of an encrypted barcode  166  that appears on the electronic document  80 . The notary barcode seal  166  of the remote electronic notary seal input device  160  is verified by the desktop manager  30  that utilizes a secure server database specifically configured to authenticate the notary barcode seal  166 . The notarization function of the desktop manager will only execute upon a verification from the secure server of a positive code match with the notary barcode seal  166  embedded in the remote electronic notary seal device  160 . A standard barcode reader uses light to convert the notary barcode into an electrical signal. The barcode reader measures the relative widths of the bars and spaces of the notary barcode, translates the code into regular characters, and transports the translation to the host computer server  40 . Each notary barcode seal  166  begins with a special start character and ends with a special stop character. The notary barcode seal  166  may include a checksum character just before the stop character. The checksum is calculated using the characters in the notary barcode seal  166  before the notary barcode seal  166  may be affixed to the electronic document  80 . The barcode reader performs the same calculation and compares its answer to the checksum it read at the end of the notary barcode seal. If the two calculations do not match, the barcode reader shall invalidate the notary barcode seal  166 . The barcode of the present invention is not a standard bar code scheme that is typically obtained from an independent party, rather the barcode is a proprietary-based, secure software application embedded in the remote electronic notary seal input device  160 . The data in a bar code denotes a reference number that the secure server utilizes to look up the associated computer record that contains descriptive verification data of the notary public  140  to whom the corresponding barcode seal is registered to. The barcode may further contain the date and time the notary public&#39;s  140  seal was affixed and the verification information for the notary public  140 .  
         [0074]    With reference to FIG. 9, the remote electronic notary seal input device  160  is pre-configured uniquely for each notary public  140  and is registered to the notary public  140 . Each electronic notary seal input device  160  contains a particular serial number assigned and registered to the notary public  140  by the electronic transaction manager  50 . The desktop manager  30  verifies that the serial number associated with the remote electronic notary seal input device  160  is an authorized, registered device. The notarization function of the desktop manager  30  will run with only upon verification of registration. The notary public  140  may choose to add extra coding to the remote electronic notary seal input device  160  in the form of a password or code for additional security. The portable hardware device allows the notary public  140  to have sole control and possession of the electronic notary seal input device  160 , thereby securing compliance with prevailing governmental regulations. The portable hardware device further allows the notary public  140  to electronically notarize electronic documents  80  wherever the customer local computer system  20  has access to the internet or TCP/IP connectivity  10 , including a laptop. The portable hardware device is easily transportable and can be used at diverse locations to another without a cumbersome uninstall/install process.  
         [0075]    With reference to FIG. 10, upon affixing the notary signature and seal, the desktop manager  30  automatically executes the electronic notary journal  170 . The electronic notary journal  170  creates an independent electronic record  171  of the notarization transaction. The electronic notary journal  170  contains all of the information required by law to legally enforce the notarization of the electronic document  80 . Upon recording the notarization transaction in the electronic notary journal  170 , the desktop manager  30  encrypts the signed, notarized, electronic document  80  and applies a time and date stamp. Any changes made to the electronic document  80  after this point in time invalidate the notary public&#39;s seal. The signed, notarized, electronic document  80  is uploaded by the notary public  140  onto the host computer server  40 . Upon uploading the electronic document  80  to the host computer server  40 , the temporary signing password  230  terminates. A signatory  130  to the electronic document  80  may have the notary public  140  print a hard copy of the electronic document  80  out, if so desired. The host computer server  40  archives the electronic document  80  for future use and retrieval by approved parties.