HK40035118A - System and method for automated online notarization meeting recovery - Google Patents

Description

System and method for automatic online notarization conference recovery

Cross Reference to Related Applications

This application claims priority from U.S. provisional application No. 62/575,772 entitled "AUTOMATED online characterization measurement RECOVERY" filed on 2017, month 10, 23, the entire contents of which are incorporated herein by reference.

Technical Field

The present disclosure relates to verification systems and, more particularly, to verifying authorship of electronic signature sessions when an interruption occurs.

Background

Electronic or e-signatures have long been implemented in contracts and, like more traditional forms of executable files, have the same legal effect in many jurisdictions. With the widespread adoption of mobile devices, user-centric mobile electronic signature services have increased significantly in terms of usage. Although mobile electronic signature services are becoming more and more popular, it is still difficult to conclusively determine the identity of a signer to prevent fraud.

Disclosure of Invention

In one or more embodiments of the present disclosure, a computer-implemented method for electronic signature verification is provided. The method may include initiating, using a computing device, an online notarization conference between a signer and an agent and displaying, at a graphical user interface, a first electronic file associated with the online notarization conference. The method may further include allowing, at the graphical user interface, one or more edits to be made to the first electronic file to produce a partially completed first electronic file and displaying, at the graphical user interface, a user selectable option to lock the partially completed first electronic file. In response to receiving a selection of the user selectable option, the method may further include storing the partially completed first electronic file. The method may also include determining that the online notary conference has been interrupted and, after the interruption, restoring the partially completed first electronic file.

One or more of the following features may be included. In some embodiments, the first electronic file may be one of a plurality of electronic files associated with an online notary conference. The user selectable options may include an option to reject the partially completed first electronic file. Upon selection of the option to reject, the method may display one or more user-selectable rejection reasons at the graphical user interface. Restoring the partially completed first electronic file may include restoring a video recording associated with the online notary conference. The method may also include displaying, at the graphical user interface, a list of the plurality of electronic files, wherein the list includes the partially completed first electronic file and at least one fully completed electronic file. The method may further comprise automatically processing the partially completed first electronic file after the determining step.

In another embodiment of the present disclosure, a computer-readable storage medium is provided having one or more instructions stored thereon, which when executed by a computer, cause one or more operations associated with an electronic signature verification method. The operations may include initiating, using a computing device, an online notarization conference between a signer and an agent and displaying, at a graphical user interface, a first electronic file associated with the online notarization conference. The operations may also include allowing, at the graphical user interface, one or more edits to be made to the first electronic file to produce a partially completed first electronic file and displaying, at the graphical user interface, a user selectable option to lock the partially completed first electronic file. In response to receiving a selection of the user selectable option, the operations may further include storing the partially completed first electronic file. The operations may also include determining that the online notary conference has been interrupted and, after the interruption, restoring the partially completed first electronic file.

One or more of the following features may be included. In some embodiments, the first electronic file may be one of a plurality of electronic files associated with an online notary conference. The user selectable options may include an option to reject the partially completed first electronic file. Upon selection of the option to reject, the operation may display one or more user-selectable rejection reasons at the graphical user interface. Restoring the partially completed first electronic file may include restoring a video recording associated with the online notary conference. The operations may also include displaying, at the graphical user interface, a list of the plurality of electronic files, wherein the list includes the partially completed first electronic file and at least one fully completed electronic file. The operations may also include automatically processing the partially completed first electronic file after the determining step.

In another embodiment of the present disclosure, an electronic signature verification system is provided. The system may include at least one processor configured to initiate an online notary conference between a signer and an agent. The at least one processor may be further configured to display, at a graphical user interface, a first electronic file associated with the online notarization conference. The at least one processor may be further configured to allow, at the graphical user interface, one or more edits to the first electronic file to produce a partially completed first electronic file. The at least one processor may be further configured to display a user-selectable option at the graphical user interface to lock the partially completed first electronic file. The at least one processor may be further configured to enable storage of the partially completed first electronic file in response to receiving a selection of the user selectable option. The at least one processor may also be configured to determine that the online notary conference has been interrupted. The at least one processor may be further configured to restore the partially completed first electronic file after the interruption.

One or more of the following features may be included. In some embodiments, the first electronic file may be one of a plurality of electronic files associated with an online notary conference. The user selectable options may include an option to reject the partially completed first electronic file. Upon selection of the option to reject, the at least one processor may be configured to display one or more user-selectable rejection reasons at the graphical user interface. Restoring the partially completed first electronic file may include restoring a video recording associated with the online notary conference. The at least one processor may be further configured to display, at the graphical user interface, a list of the plurality of electronic files, wherein the list includes the partially completed first electronic file and the at least one fully completed electronic file. The at least one processor may be further configured to automatically process the partially completed first electronic file after the determining step.

The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features and advantages will become apparent from the description, the drawings, and the claims.

Drawings

Embodiments of various techniques for systems and methods for verifying authorship of an electronic signature session (session) will be described below with reference to the accompanying drawings. It should be understood, however, that the drawings merely describe various embodiments herein and are not intended to limit the scope of various techniques described herein.

FIG. 1 is an illustrative schematic diagram of an electronic signature verification program connected to a distributed computing network in accordance with one or more embodiments of the present disclosure;

FIG. 2 is an illustrative flow diagram of the electronic signature verification process of FIG. 1 in accordance with one or more embodiments of the present disclosure;

FIG. 3 is an illustrative diagram of a client-side electronic signature verification application scanning interface in accordance with one or more embodiments of the disclosure;

FIG. 4 is an illustrative diagram of a client electronic signature application file display interface in accordance with one or more embodiments of the disclosure;

FIG. 5 is an illustrative diagram of a client-side electronic signature application verification interface in accordance with one or more embodiments of the disclosure;

FIG. 6 is an illustrative diagram of an automated online notary conference recovery program connected to a distributed computing network in accordance with one or more embodiments of the present disclosure;

FIG. 7 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery procedure of the present disclosure;

FIG. 8 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery procedure of the present disclosure;

FIG. 9 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery procedure of the present disclosure;

FIG. 10 is a graphical user interface illustrating an exemplary embodiment consistent with an automated online notary conference recovery procedure of the present disclosure;

FIG. 11 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery program of the present disclosure;

FIG. 12 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery procedure of the present disclosure;

FIG. 13 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery procedure of the present disclosure;

FIG. 14 is a graphical user interface illustrating an exemplary embodiment consistent with the automated online notary conference recovery procedure of the present disclosure; and

fig. 15 is an illustrative flow diagram of the automated online notary conference recovery program of fig. 6 in accordance with one or more embodiments of the disclosure.

Like reference symbols in the various drawings may indicate like elements.

Detailed Description

System overview:

reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in fig. 1-15. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will convey the concept of the disclosure to those skilled in the art.

Referring now to fig. 1, an Electronic Signature Verification (ESV) program is shown that may reside on and/or be executed by a microprocessor (not shown), which may be executed by one or more client electronic devices, such as client electronic devices 28, 30, 32, and/or 34, respectively. Examples of client electronic devices 28, 30, 32, and 34 may include, but are not limited to, personal computers 28, notebook computers 30, smart phones 32, laptop computers 34, and application-specific devices (not shown). One or more client electronic devices 28, 30, 32, and/or 34 may be connected to the network 22, where the network 22 may be the internet or a regional network. Further, server ESV program 10 may reside, in whole or in part, on a server computer 20 that may be connected to a network 22.

Embodiments of client ESV program 16 may be configured to utilize smartphone 32 technology (e.g., smartphone audio recording/video recording, Global Positioning System (GPS), etc.) and may include one or more downloadable applications, application-specific devices, cellular connections, and network-based monitoring systems. Thus, client ESV program 16 may verify the authorship of the electronic signature of the user (e.g., user 48) of the digital copy of file 410.

Referring now to fig. 1-15, while shown in fig. 1 as a client ESV program 16, and the disclosure is depicted throughout as residing, in whole or in part, on a smartphone 32, this is intended to be described for illustrative purposes only. Smartphone 32 may be any mobile computing device, some of which may include, but are not limited to, a tablet computer, a tablet, a smart watch, or an application-specific device, wherein the mobile device is capable of executing, in whole or in part, client ESV program 16.

Referring again to FIG. 2, a flow diagram of a method 200 for transferring a document signing transaction session from a client ESV application 76 to an ESV application 72, wherein the document signing transaction session may be associated with a user 48, is shown. In some examples, the file signing transaction session may include personally identifiable information, wherein the personally identifiable information may enable user 48 to be uniquely identified. ESV program 10 may include (210) analyzing at least one government identification document, wherein the analyzing includes authenticating the at least one government identification document. Embodiments may further include (215) extracting personally identifiable information about the user from the at least one government identification document. Embodiments may also include (220) displaying a digital copy of the file to be signed to the user, and (225) obtaining an electronic signature of the file of the user. Embodiments may further include (230) receiving personally identifiable information, wherein the personally identifiable information is related to the user and the user can be uniquely identified. Embodiments may also include (235) transmitting a file signing transaction session. Many other operations are also within the scope of the present disclosure, which will be discussed in further detail below.

In some embodiments, the client ESV application 76 may be executed by the client ESV program 16, and the client ESV program 16 may reside on the client device 32 and may be executed by the client device 32, where the client device 32 is a smartphone 32. The client ESV application 76 may be a stand-alone client ESV application 76. ESV application 72 may be executed by server ESV program 10, and server ESV program 10 may reside on server computer 20 and may be executed by server computer 20. The server computer 20 may be one or more network servers, wherein the ESV application 72 may be a network-based application.

It should be appreciated that although the method 200 indicates a particular order of execution of the operations, in some examples, certain portions of the operations may be performed in a different order and may be performed on different systems. Moreover, in other examples, additional operations or steps may be added to method 200. Similarly, the method 200 may omit some operations or steps.

In some embodiments, ESV program 10 may include monitoring one or more sensors, wherein the one or more sensors are configured to collect personally identifiable information about user 48. For example, smartphone 32 may include a camera, wherein the camera may be configured to acquire live imagery 510 of the user. The real-time imagery 510 of the user 48 may be used to uniquely identify the user 48 and/or verify that the user is performing a desired action, where the desired action may be signing a digital copy of the file 410 with an electronic signature, performing a sworn, writing a sworn book, and the like.

In some embodiments, the personally identifiable information may include biometric data and/or location data. For example, the biometric data may include at least some of DNA analysis, ear lobe geometry analysis, eye diagram analysis, face recognition analysis, fingerprint analysis, hand geometry analysis, signature analysis, and voice waveform analysis. For example, the location data may include one or more of Global Positioning System (GPS) data, Wi-Fi access point identification information, cell tower identification information, wherein the location data is assisted global positioning system (a-GPS) data. Personally identifiable information about the user 48 may enable the user 48 and its location to be uniquely identified, thereby verifying the authorship of the electronic signature session.

In some embodiments, ESV program 10 may include scanning one or more forms of government identification documents associated with user 48, wherein the one or more forms of government identification documents include personally identifiable information. For example, client ESV program 16 may utilize one or more cameras of smartphone 32 to scan one or more forms of government identification files, wherein such one or more forms of government identification files may include at least one of: social security cards, driving licenses, government issued identification cards, military identification cards, passports, passport cards, birth certificates, department of defense identification cards, U.S. citizenship cards, admission cards, green cards, NEXUS cards, SENTIS cards, and the like. In some examples, ESV program 16 may utilize one or more cameras of smartphone 32 to capture images of one or more forms of government identification files provided by user 48. For example, the user 48 may take a picture of his driver's license 310 using his smartphone 32 and may upload the image to the client ESV application 76 and/or ESV application 72 for processing, where the ESV application 72 is a web-based ESV application.

In some embodiments, ESV program 10 may include authenticating one or more forms of government identification documents, wherein the authenticity of the one or more forms of government identification documents may be verified. In some examples, the authentication may be accomplished by one or more supervisors 66, and/or the authentication may be accomplished by one or more software analysis programs. The one or more software analysis programs may be part of the client ESV application 16 and/or part of the ESV application 72.

In some embodiments, ESV program 10 may include extracting personally identifiable information about the user from one or more forms of government identification. In some examples, the extraction of personal identifying information may be accomplished by one or more software analysis programs. The one or more software analysis programs may be part of the client ESV application 16 and/or part of the ESV application 72. For example, user 48 may use their smartphone 32 camera to take a picture of their government identification file, and one or more software analysis programs may digitize the photograph 320 and/or signature 330 of user 48, which may be incorporated into the government identification file. In some examples, the digitized personal identification information of user 48 may be used as a reference. For example, the photograph 320 of the user 48 may be extracted from an authenticated form of government identification and used as the reference image 520 for the user 48. In another embodiment, ESV program 10 may include extracting at least one of: the user's date of birth 340, driver's license number 390, eye color 380, hair color 360, height 370, social security number, residence address 350, gender 355, weight 350, etc., where the extracted information may be recorded, which may also be used for identification purposes. In some examples, the user's extracted information may be used to automatically fill in the required fill fields 420 within the digital copy of the document 410.

In some embodiments, ESV program 10 may include a digital copy of display file 410. A digital copy of file 410 may be displayed on the screen of smartphone 32. The user may scroll through the file 410 and may select one or more fields 420 within the file 410 that require the user's electronic signature. The user may select a field 420 within the file 410 using a pointing device, which may be the user's finger and/or a stylus. To manage the signature session, the display of the smartphone 32 may be configured as an input field where the user may draw his signature using his finger or a stylus, just as a handwritten signature using a pen and paper.

In some embodiments, ESV program 10 may include obtaining a signature of the user, wherein the signature of the user has been digitized. The ESV program 16 may further allow the user to place their electronic signature in one or more fields 420 within the document 410, wherein the electronic signature may be scaled to fit the document field 420. In some examples, the electronic signature may be automatically scaled by the ESV program 16 to fit the file field 420. The user and/or ESV program 16 may further verify that the electronic signature has been placed in all required fields 420 within the file 410 and the file 410 may then be considered as having been executed by the user. By executing file 410, the user may be considered to have adopted the contents of file 410.

In some embodiments, ESV program 10 may include comparing live image 510 of the user with reference image 520 of user 48. The live image 510 may be used to uniquely identify the user 48 and confirm that the user 48 is performing the desired task, which is an electronic signature of the digital file 410. In some cases, the comparison may be performed by one or more supervisors 66, and/or the comparison may be performed by one or more software analysis programs. The one or more software analysis programs may be part of the client ESV application 16 and/or part of the ESV application 72.

In some embodiments, ESV program 10 may include face recognition techniques. For example, storage 24 may include a database of stored images, which may be authenticated images, associated with each particular user of client ESV application 76. In some examples, each user may be authenticated by sending the captured photograph and/or video from their smartphone 32 over network 22 and/or network 26, and then may compare the photograph to images stored in the stored image database to authenticate the identity of user 48. Other biometric sensors and authentication techniques may also be used without departing from the scope of the present disclosure. Additionally and/or alternatively, the facial recognition, biometric identification, and localization methods described herein may be used in whole or in part with any other feature of ESV program 10.

In some embodiments, ESV program 10 may include determining a confidence score by software or manual analysis. For example, for the purpose of specifically identifying user 48, ESV program 16 may compare real-time image 510 of the user with reference image 520 of user 48, where reference image 520 may be extracted from one or more forms of government identification documents described herein. In some examples, the comparison may be performed by one or more software facial recognition programs, where the one or more software facial recognition programs specify a confidence score based on their analysis of whether the person identified in the reference image 520 corresponds to the person shown in the real-time image 510. Additionally, there may be a threshold for the confidence score, where the threshold may determine whether the comparison is to be verified by the supervisor 66. In another embodiment, this verification may be performed entirely by supervisor 66, and supervisor 66 may specify a confidence score based on its analysis. In this example, ESV program 16 may stream a file signing transaction session in real time, where the file signing transaction session may be streamed in part or in whole.

In some embodiments, ESV program 10 may include recording a file signing transaction session, wherein the file signing transaction session may be recorded in part or in whole. For example, ESV program 16 may record live image 510 of user 48 using one or more cameras of smartphone 32, where live image 510 may be used to authenticate the identity of user 48, and/or to obtain images of user 48 that sign digital copies of file 410. The record of the file signing transaction session may include at least one of, but is not limited to: one or more forms of government identification files, digital files 410 to be signed, users 48 who signed digital files 410, one or more forms of personally identifiable information as described herein, and the like. The records of the file signing transaction session may further comprise a unique file identification number, wherein a unique file identification number is associated with each record. In another embodiment, any witnesses signed by user 48 on digital document 410 may also be recorded and thus identified in the case of multiparty recording. The record may also include metadata, such as identification information of the user that witnessed the file signing transaction session, location information, and other information related to the file signing transaction session. The record may be transmitted to the ESV network 22 and/or 26 associated with the ESV application 72 in real time.

In some embodiments, ESV program 16 may include generating a unique identification number. The unique identification number may be associated with the file signing transaction session and may be an exclusive unique identification number. The unique identification number may be based at least in part on file signing transaction session metadata. In some examples, the unique identification number may be used to approve the validity of the file signing transaction session. For example, ESV program 16 may generate the unique identification number based at least in part on a confidence score greater than a threshold value and/or a file signing transaction session verified by supervisor 66. In some examples, the supervisor 66 may further record that he or she observed the file signing transaction session in its entirety, and may then append and/or add the unique identification number to the file signing transaction session. In another embodiment, an authentication mark and/or seal may be appended to and/or added to the document 410, wherein the authentication mark may be a proprietary mark. The unique identification number may be used to retrieve the file signing transaction session at a later date.

In some embodiments, ESV program 10 may include storing the file signing transaction session. In some examples, ESV program 16 may store the file signing transaction session locally on smartphone storage 32. The document signing transaction session may be retrieved at a later time and transmitted to ESV application 72, where it may be stored on network storage 24. The stored file signing transaction session may be stored for later retrieval and/or reference, wherein the unique identification number may be used to retrieve the file signing transaction session. The information relating to the file signing transaction session and the executed file will be stored in a manner that logically associates them together so that the session details can later be considered as supplementary verification details for the file itself.

In some embodiments, ESV program 10 may include enabling the wireless transmitter to transmit a file signing transaction session, wherein the file signing transaction session includes at least one of: digital file 410, one or more electronic signatures, one or more forms of evidence of government identification files or other means of authentication, a real-time record of a user, a real-time record of one or more witnesses, a unique file identification number, an audit trail of authentication methods, a record of a signing session, a confidence number, and the like. The document signing transaction session may be transmitted from smartphone 32 to ESV application 72. Further, the file signing transaction session may be transmitted in response to a prompt from monitoring networks 22 and/or 26, or upon initiation by user 48.

Referring now to fig. 3, a schematic diagram of a client ESV application 76 scanning interface 300 depicted on the display of mobile smartphone 32 is shown. Scanning interface 300 may permit a user to scan one or more forms of government identification documents associated with user 48. For example, a user may utilize one or more cameras of smartphone 32 to acquire images of the one or more forms of government identification documents. Such one or more forms of government identification documents may include at least one of: social security cards, driver's license 310, government issued identification cards, military identification cards, passports, passport cards, birth certificates, department of defense identification cards, U.S. citizenship cards, admission cards, green cards, NEXUS cards, SENTIS cards, and the like. For example, the user 48 may take a picture of his driver's license 310 using his smartphone 32 and may upload the picture to the customer ESV application 76 and/or ESV application 72. The uploaded picture may be further authenticated by one or more software analysis programs, which may be associated with the client ESV application 16. In some examples, personally identifiable information about the user may be extracted from the driver's license 310. For example, a photograph 320 of the user 48 may be taken from the driver's license 310 of the user and used as the reference image 520 of the user 48. Alternatively/additionally, the user's signature 330 may be extracted from the driver's license 310 of the user 48 and used as the reference signature 330 for the user 48.

Referring now also to FIG. 4, a schematic diagram of a client ESV application 76 file display interface 400 is shown. File display interface 400 may display a digital copy of file 410 on the screen of smartphone 32. The user may select the field 420 within the file 410 using a pointing device that may require their electronic signature. To manage the signature, the display of the smartphone 32 may be configured as an input field where the user may draw his signature using his finger or a stylus, just as a handwritten signature using a pen and paper.

Referring now also to FIG. 5, a schematic diagram of a client ESV application 76 user authentication interface 500 is shown. Visual and/or audio prompts may be presented to user 48 as part of ESV program 10, where the prompts may include instructions to perform one or more particular actions. The client monitoring application 76 may utilize at least some of the smartphone 32 sensors to collect personally identifiable information about the user 48, where the personally identifiable information may enable the user 48 to be uniquely identified. For example, smartphone 32 may include one or more cameras, and the one or more cameras may be configured by client ESV application 76 for obtaining live images 510 of user 48. Live image 510 may be a still image and/or a video image of user 48. The one or more real-time images 510 may be time and/or date stamped. The still image and the video image may have different resolutions and may be used for different purposes. For example, the still image may have a higher resolution than the video image and may be used to uniquely identify the user 48. The video image may have a lower resolution than the still image and may be used to confirm that the user 48 is performing the desired task. For example, the video image may be used to confirm that the user 48 is performing a desired task (such as signature file 410), and/or utter recognizable and distinguishable words (such as their name). In some examples, the video imagery may be used to uniquely identify the user 48.

Referring again to FIG. 5, a diagram comparing a live image 510 of the user 48 with a reference image 520 of the user 48 is shown. The reference image 520 may be stored locally (e.g., via storage device 40), and/or remotely (e.g., via storage device 24) at one or more storage locations. In another embodiment, the reference image 520 may be stored locally 40 and may be used to prompt the user 48 for the requirements of the live image 510 to be recorded. For example, the reference picture 520 may be a facial portrait and may be used to inform the user 48 of the relative size of the live picture 510 to be recorded. The reference image 520 may be at least one of: a generic profile image, a previously recorded and stored reference image 520 of the user 48, and a generic facial contour outline. The reference image 520 may be used to align and resize the live image 510. For example, the live image 510 may be superimposed on the reference image 520, and recording of the live image 510 may be automatically initiated when the live image 510 and the reference image 520 are substantially aligned. Alternatively, the reference image 520 may be displayed adjacent to the live image 510 and used as a visual reference for the supervisor 66.

In some embodiments, the reference image 520 may enable the user 48 to be uniquely identified. For example, supervisor 66 may compare real-time image 510 to reference image 520 for the purpose of uniquely identifying user 48. Supervisor 66 may have the option of using an approval button 530 to approve live image 510, or a decline button 540 to decline live image 510, where the approval may or may not be in real-time. In some examples, the comparison may be accomplished by one or more software analysis programs. The one or more software analysis programs may be part of client ESV program 16 and/or ESV program 10, where ESV program 10 may be a network-based monitoring program.

In some embodiments, the current location and/or location data of user 48 may be determined by client monitoring application 76 and sent to monitoring application 72 as part of a document signing transaction session as described herein. The location data may be obtained from an integrated Global Positioning System (GPS) sensor within smartphone 32. The location data may also be assisted global positioning system (a-GPS) data, wherein the GPS data is supplemented by Wi-Fi access point identification information and/or cell tower identification information.

In some embodiments, the method may further include a knowledge-based authentication and/or proof-of-advance procedure whereby the user must successfully answer an identity challenge question to verify his identity. Thus, given information about a person, the present approach may create wallet or identity challenge issues. The client must answer correctly. This may be provided as an alternative to photo ID based authentication. If so, an audit trail of the transaction may be stored, just like an audit trail of a photo ID. The method may also include identity vetting, in which the user is asked to answer an identity challenge question.

In some embodiments, each file may be "locked" or stamped with a digital security credential. The credential may be associated with a "viewer" and may be associated with a graphic seal that it applies. The credential locks the file from editing and also binds the file to the "observer" so that the observer can verify the transaction after the fact.

In some embodiments, any and all information may be stored in a logically associated manner. As such, the file may be locked/encrypted and may be associated with a record of the transaction such that the file and the transaction may be independently verified via the record details of the transaction.

Referring also to fig. 6-15, embodiments consistent with an automated notary meeting recovery ("NMR") routine 610 are provided. In previous systems, if an online notary conference including multiple files was unsuccessful, all work done on the files by the signers and the agents was lost. An unsuccessful conference is defined as any conference in which any file in the data package (package) is not complete. There are many situations that can cause the conference to be unsuccessful. Some of these situations may include, but are not limited to, a situation where the agent terminates the meeting, a situation where the signer or agent leaves the meeting by exiting the application or closing the browser window, a situation where the meeting fails due to technical issues or network conditions, etc. In these types of cases, when the signer returns, both the signer and the agent must start at the beginning of the file package and repeat all previous work. Given that multi-file sessions can take a long time (e.g., typically over an hour), this wasteful effort results in a time-consuming, cost-consuming, and generally poor user experience.

Accordingly, embodiments of NMR program 610 are directed to a solution for recovering from an interrupted online notary conference, such as described in fig. 1-5. The coordination system of the software client and signature platform processing components allows the agent to lock the files within the multi-file data package so that if the conference is interrupted due to a problem that the participants cannot directly control, all progress in the conference can be resumed in the next conference. Embodiments may include a method for trained agents to alter the state of a signature file during a meeting ("meeting a") so that the signature platform can automatically process it correctly when the meeting fails. Embodiments may further include one or more graphical user interfaces or displays that may be configured to provide a series of visual cues to clearly indicate to signers, agents, and other authorized parties the status of each signature file during and between each meeting. Embodiments may also include a method for initiating a new meeting ("meeting B") based on a partially completed set of files, such that the signing system recognizes previously completed files and does not require a signer or agent to redo.

Referring again to FIG. 6, an automated notary meeting recovery ("NMR") program 610 may be connected to the computer or computer network. For example, the server NMR program 610 may reside on a server computer 620 and be executed by the server computer 620, and the server computer 620 may be connected to a network 622 (e.g., the internet or a regional network). Examples of server computer 620 may include, but are not limited to: a personal computer, a server computer, a series of server computers, a minicomputer, and/or a mainframe computer. The server computer 620 may be a network server (or series of servers) running a network operating system, examples of which may include, but are not limited to: for exampleWindowsOr Red(Microsoft and Windows are registered trademarks of Microsoft Corporation in the United states and/or other countries; Novell and NetWare are registered trademarks of Novell Corporation in the United states and/or other countries; Red Hat is a registered trademark of Red Hat Corporation in the United states and/or other countries; and Linux is a registered trademark of LinusTorvalds in the United states and/or other countries).

The instruction sets and subroutines of server NMR program 610 may be stored on storage 624 connected to server computer 620, and may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into server computer 620. Storage 624 may include, but is not limited to: a hard disk drive; flash drive, disk drive; driving an optical disc; a RAID array; random Access Memory (RAM); read Only Memory (ROM); erasable programmable read-only memory (EPROM); and a flash memory.

The server computer 620 may execute a web server application, examples of which may include, but are not limited to:IIS、Web Server^TMor isWhich allows access to server computer 620 (via network 622) using one or more protocols, examples of which may include, but are not limited to, HTTP (i.e., hypertext transfer protocol), SIP (i.e., session initiation protocol), andthe VP protocol. (Webserver is a trademark of Novell Corporation in the United states and/or other countries; Apache and Tomcat are registrations of Apache Software Foundation in the United states and/or other countriesA trademark; lotus and Sametime are registered trademarks of International Business Machine Corporation in the United states and/or other countries). Network 622 may be connected to one or more auxiliary networks (e.g., network 626), examples of which may include, but are not limited to: a local area network; a wide area network; or an internal network.

In addition to/in lieu of server NMR program 610, one or more client NMR programs (e.g., client NMR programs 612, 614, 616, 618) may reside on and be executed by one or more client electronic devices (e.g., client electronic devices 628, 630, 632, and/or 634, respectively). Thus, in some embodiments, the NMR program may be a server-side program (server-side process), where all functions may be performed on the server computer 620. Further, the NMR program may be a client-side program (client-side process) in which all functions may be performed on the client electronic device. In still further embodiments, the NMR program may comprise a hybrid server-client program, wherein at least one function may be performed by the server device and at least one function may be performed by the client device.

Examples of client electronic devices may include, but are not limited to, a personal computer 628, a laptop computer 630, a smartphone 632, a notebook computer 634, a personal digital assistant (not shown), and application-specific devices, a tablet computer (not shown), a server (not shown), a television (not shown), a smart television (not shown), a media (e.g., video, photos, etc.) acquisition device (not shown), and a network-specific device (not shown). Client electronic devices 628, 630, 632, 634 may be connected to network 622 and/or network 626, respectively, and may each execute an operating system, examples of which may include, but are not limited to, Android^TM、OSMicrosoft Windows CEO、RedOr to customize the operating system. (Android is a registered trademark of Google Inc.; Microsoft and Windows are registered trademarks of Microsoft Corporation in the United states and/or other countries; Apple iOS, Mac, and OSX are registered trademarks of Apple Inc. in the United states and/or other countries; Red Hat is a registered trademark of Red Hat Corporation in the United states and/or other countries; and Linux is a registered trademark of Linus Torvalds in the United states and/or other countries).

The instruction sets and subroutines of client NMR programs 612, 614, 616, 618 may be stored on storage devices 636, 638, 640, and 642 (respectively) connected to client electronic devices 628, 630, 632, and 634 (respectively), and may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices 628, 630, 632, 634 (respectively). Storage devices 636, 638, 640, and 642 may include, but are not limited to: a hard disk drive; a Solid State Drive (SSD); flash drive, disk drive; driving an optical disc; a RAID array; random Access Memory (RAM); read Only Memory (ROM); erasable programmable memory (EPROM); and a flash memory.

Users 644, 646, 648, and 650 (also referred to as "users," "monitors" 666, "agents" 666, "observers" 666, or "supervisors" 666) can access NMR programs in a variety of ways. For example, at least some of these users may directly access the server NMR program 610 through the devices (i.e., client electronic devices 628, 630, 632, 634) on which the client programs (e.g., client NMR programs 612, 614, 616, 618) are executed. Users 644, 646, 648, 650 may access server NMR program 610 directly through network 622 and/or through auxiliary network 626. In addition, the server computer 620 (i.e., the computer executing the server NMR program 610) may be connected to the network 622 through an auxiliary network 626, shown connected by dashed line 652. Users 644, 646, 648, 650 may also access NMR applications in a similar manner. The NMR program 610 may include one or more user interfaces, such as a browser and a textual or graphical user interface, through which the user 644, 646, 648, 650 may access the NMR program 610.

Various client electronic devices may be connected to network 622 (or network 626) either directly or indirectly. For example, personal computer 628 is shown directly connected to network 622 via a hardwired network connection. Additionally, notebook computer 34 is shown directly connected to network 626 via a hardwired network connection. Laptop 630 is shown wirelessly connected to network 622 via a wireless communication channel 654 established between laptop 30 and wireless access point (i.e., WAP)56, wireless access point 56 being shown directly connected to network 622. WAP 656 may be, for example, IEEE 802.11a, 802.11b, 802.11g, 802.11n, Wi-Fi, and/or Bluetooth devices that enable a wireless communication channel 654 to be established between laptop 630 and WAP 656. The illustrated smartphone 632 is wirelessly connected to the network 622 via a wireless communication channel 658 established between the smartphone 632 and the cellular network/bridge 660, which is shown as being directly connected to the network 622.

Some or all of the IEEE 802.11x specifications may use ethernet protocols and carrier sense multiple access with collision avoidance (i.e., CSMA/CA) for path sharing. For example, various 802.11x specifications may use phase shift keying (i.e., PSK) modulation or complementary code keying (i.e., CCK) modulation. Bluetooth (R) protocol^TMIs a telecommunications industry specification that allows, for example, mobile phones, computers, smart phones, and other electronic devices to be interconnected using short-range wireless connections. The short-range wireless connection may include one or more proprietary wireless interfaces and/or protocols. Other forms of interconnection (e.g., Near Field Communication (NFC)) may also be used.

For the accompanying discussion, client NMR program 616 has been described for illustrative purposes. It will be appreciated that the client NMR program 616 may interact and/or communicate with the server NMR program 610, for example, and/or may execute within one or more applications that allow communication with other server and/or client NMR programs. This is not intended as a limitation of the present disclosure, as other configurations are possible (e.g., smartphone NMR program 616 may include a stand-alone client program and/or a stand-alone server program). For example, some embodiments may include one or more of the client NMR programs 612, 614, 618 or the server NMR program 610 in lieu of, or in addition to, the client NMR application 676.

The computer 620 can include a data store, such as a database (e.g., a relational database, an object-oriented database, a triple store database, etc.), and can be located within any suitable memory location, such as the storage 624 connected to the computer 620. The data storage area may store therein any of the data described throughout this disclosure. In some embodiments, computer 620 may utilize a database management system, such as, but not limited to, "structured query language"To provide multi-user access to one or more databases, such as the relational database described above. The data store may also be a custom database, such as a flat document database or an XML database. Any other form of data storage structure and/or organization may also be used. The NMR program 10 may be a component of the data store, a stand-alone application that interfaces with the data store, and/or a applet/application that is accessed via client applications 622, 624, 626 and 628. The data storage areas can be distributed into a cloud computing topological structure in whole or in part. In this manner, computer 620 and storage 624 may refer to a plurality of devices, which may also be distributed throughout the network.

The computer 620 may execute an NMR application (e.g., NMR application 672). The NMR process 610 and/or NMR application 672 may be accessed via client applications 670, 674, 676, and 678. The NMR process 610 may be a stand-alone application or may be a mini-application/instruction code/extension that may interact with and/or execute within: one or more of NMR application 672, components of NMR application 672, and/or client applications 670, 674, 676, and 678. The NMR application 672 may be a standalone application, or may be a applet/application/instruction code/extension that interacts with and/or executes within: one or more of the NMR program 610, components of the NMR program 610, and/or client applications 670, 674, 676, and 678. One or more of client applications 670, 674, 676, and 678 may be stand-alone applications, or may be an applet/application/code/extension that interacts with and/or executes within, and/or is: components of the NMR program 610 and/or NMR application 672. Instruction sets and subroutines of client applications 670, 674, 676, and 678, which may be stored on storage devices 636, 638, 640, and 642, are connected to client electronic devices 628, 630, 632, and 634, which may be executed by one or more processors (not shown) and one or more memory architectures (not shown) incorporated into client electronic devices 628, 620, 632, and 634.

One or more of client applications 670, 674, 676, and 678 may be configured to implement some or all of the functionality of NMR application 620 (and vice versa). Thus, the NMR application 672 may be a pure server-side application, a pure client-side application, or a hybrid server-side/client-side application that is cooperatively executed by one or more of the client applications 670, 674, 676, and 678 and/or the NMR application 20. Because one or more of client applications 670, 674, 676, and 678, NMR program 610, and NMR application 620 may perform some or all of the same functions, either individually or in any combination, any description of such functions being performed via one or more of client applications 670, 674, 666, and 678, NMR program 610, NMR application 672, or combinations thereof, and any such interactions between one or more of client applications 670, 674, 676, and 678, NMR program 610, NMR application 672, or combinations thereof, to perform such functions should be taken as an example only, and not limiting the scope of the disclosure.

Referring now to fig. 7, a graphical user interface 700 is provided consistent with an embodiment of NMR program 610. In this particular example, GUI 700 may allow an agent to control the state of one or more electronic files. More specifically, in some embodiments, GUI 700 describes examples of file state controls that may be displayed to an agent. Here, the agent may be shown the option to lock or reject the electronic file (e.g., immediately below the last page of each file in the multi-file package). This control enables the agent to designate the file as complete by selecting either lock 701 or deny 702. If lock state 701 is selected, the file may end up by the signature platform upon successful conference completion, terminate by the agent, and/or fail due to out of the technical conditions directly controlled by the participants. If the deny condition 702 is selected, the transaction may be completed by the signing platform even if the signing system determines that the file requires a signature or notarization. In either completion state, neither the agent nor the signer can modify the file in any way.

In some embodiments, a signature platform associated with the NMR program 610 may determine that all actions required by the various conference participants (e.g., signatures, notations, dates, notes, etc.) have been satisfied, and may automatically set the file state to locked without agent input.

Referring now to fig. 8, a graphical user interface 800 consistent with an embodiment of the NMR program 610 is provided. In this particular example, GUI 800 may provide a file rejection feedback dialog display. In some embodiments, if the file is subject to rejection for any reason (e.g., using the reject option 702), the agent may be prompted to provide the reason for the rejection 803, and a detailed explanation 804, so that the relevant parties can take appropriate diagnostic and corrective action.

Referring now to fig. 9-10, graphical user interfaces 900 and 1000 consistent with an embodiment of NMR program 610 are provided. In this particular example, GUI 900 depicts a notary agent's view of the completed file. The top of the screen appears with a bar indicating the completed state 905 of the file. The reply state control 906 allows the agent to restore the file to its previous incomplete state. Immediately below the last page of the file, the state control (see FIG. 7) may be replaced by a strong visual indicator representing the locked state 907 of the file. FIG. 10 depicts a signer's view of a completed file. A bar appears at the top of the screen indicating the completed status 1008 (e.g., locked or rejected) of the file.

Referring now to fig. 11, a graphical user interface 1100 consistent with an embodiment of the NMR program 610 is provided. In this particular example, GUI 1100 describes a document selection control of a notary agent. The agent may use the GUI 1100 to visually determine the completed status of any files in the multi-file transaction within the status bar 1109. This helps the agent to know the overall status of the meeting and enables it to navigate directly to the incomplete files.

Referring now to fig. 12, a graphical user interface 1200 consistent with an embodiment of the NMR program 610 is provided. In this particular example, GUI 1200 depicts a status indicator on a dashboard containing multiple transactions. The recovered transaction may be explicitly indicated with a "partially completed" state 1210. The user may hover over the status indicator 1211 to see how many files in the transaction have been set to a completed state (and then processed at the end of the meeting).

Referring now to fig. 13, a graphical user interface 1300 is provided consistent with an embodiment of the NMR program 610. In this particular example, GUI 1300 depicts a video recording manifest associated with the recovered transaction. Each meeting in the recovered transaction occurs in an ordered list 1312 associated with a start and end timestamp 1313. Each inventory entry may include a video recording 1314 from the corresponding conference. Together, these records constitute a complete video archive of the transaction.

Referring now to fig. 14, a graphical user interface 1400 is provided consistent with an embodiment of the NMR program 610. In this particular example, GUI 1400 depicts a file manifest associated with the recovered transaction. The sort control 1415 allows the user to reorder the manifest based on the meeting where the files are completed, or where the files are in the originally specified signature order. Each file in the manifest displays a status indicator (e.g., completed 1416 or rejected 1417).

Referring also to fig. 15, a flow chart 1500 is provided that describes operations consistent with an embodiment of the NMR program 610. Operations may include initiating (1510), using a computing device, an online notarization conference between a signer and an agent, and displaying (1515) at a graphical user interface a first electronic file associated with the online notarization conference. Operations may also include allowing (1520) one or more edits to be made to the first electronic file at the graphical user interface to produce a partially completed first electronic file, and displaying (1525) a user selectable option to lock the partially completed first electronic file at the graphical user interface. In response to receiving the selection of the user selectable option, operations may also include storing (1530) the partially completed first electronic file. Operations may further include determining (1535) that the online notary conference has been interrupted, and resuming (1540) the partially completed first electronic file after the interruption.

Although certain embodiments disclosed herein may be based on the american notary and may refer to and/or incorporate the laws and regulations upon which they are based, it should be noted that the teachings of the present disclosure may also extend to other jurisdictions. Accordingly, embodiments of ESV program 10 and/or NMR program 610 may be used at ° in any suitable country and/or geographic region

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or computer program product. Accordingly, aspects of the disclosure may take the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software aspects with hardware aspects that may all generally be referred to herein as a "circuit," module "or" system. Further, aspects of the disclosure may take the form of: a computer program product embodied in one or more computer-readable media having computer-readable program code embodied therein.

Any combination of one or more computer-readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical drive, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in a base frequency or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and known procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

Aspects of the present disclosure are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a non-transitory computer-readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible embodiments of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular forms "a", "an" and "the" as used herein are intended to include the plural forms as well, unless the content clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, calculations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, calculations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The embodiments were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.

From the disclosure of the present application and the reference to embodiments thereof as thus detailed, it will be apparent that modifications, variations, and any combination of the embodiments (including any modifications, variations, and combinations thereof) are possible without departing from the scope of the present disclosure as defined in the appended claims.

Claims (20)

1. A method of electronic signature verification, comprising:

initiating, using a computing device, an online notary conference between a signer and an agent;

displaying, at a graphical user interface, a first electronic file associated with the online notary conference;

at the graphical user interface, allowing one or more edits to be made to the first electronic file to produce a partially completed first electronic file;

displaying, at the graphical user interface, a user-selectable option to lock the partially completed first electronic file;

in response to receiving a selection of the user selectable option, storing the partially completed first electronic file;

determining that the online notary conference has been interrupted; and

after the interruption, the partially completed first electronic file is restored.

2. The electronic signature verification method of claim 1, wherein the first electronic file is one of a plurality of electronic files associated with the online notarization conference.

3. An electronic signature verification method as in claim 1 wherein said user selectable options include an option to reject said partially completed first electronic file.

4. An electronic signature verification method as claimed in claim 3, wherein upon selection of the option to reject, one or more user selectable rejection reasons are displayed at the graphical user interface.

5. The electronic signature verification method of claim 1, wherein recovering the partially completed first electronic file comprises recovering a video recording associated with the online notary conference.

6. The electronic signature verification method of claim 1, further comprising:

displaying, at the graphical user interface, a list of a plurality of electronic files, wherein the list includes the partially completed first electronic file and at least one fully completed electronic file.

7. The electronic signature verification method of claim 1, further comprising:

automatically processing the partially completed first electronic file after the determining step.

8. A computer-readable storage medium having stored thereon one or more instructions which, when executed by a computer, result in one or more operations associated with an electronic signature verification method, the operations comprising:

initiating, using a computing device, an online notary conference between a signer and an agent;

displaying, at a graphical user interface, a first electronic file associated with the online notary conference;

at the graphical user interface, allowing one or more edits to be made to the first electronic file to produce a partially completed first electronic file;

displaying, at the graphical user interface, a user-selectable option to lock the partially completed first electronic file;

in response to receiving a selection of the user selectable option, storing the partially completed first electronic file;

determining that the online notary conference has been interrupted; and

after the interruption, the partially completed first electronic file is restored.

9. The computer-readable storage medium of claim 8, wherein the first electronic file is one of a plurality of electronic files associated with the online notary conference.

10. The computer-readable storage medium of claim 8, wherein the user-selectable options include an option to reject the partially completed first electronic file.

11. The computer-readable storage medium of claim 10, wherein upon selection of the option to reject, one or more user-selectable rejection reasons are displayed at the graphical user interface.

12. The computer-readable storage medium of claim 8, wherein restoring the partially completed first electronic file comprises restoring a video recording associated with the online notary conference.

13. The computer-readable storage medium of claim 8, further comprising:

displaying, at the graphical user interface, a list of a plurality of electronic files, wherein the list includes the partially completed first electronic file and at least one fully completed electronic file.

14. The computer-readable storage medium of claim 8, further comprising:

automatically processing the partially completed first electronic file after the determining step.

15. An electronic signature verification system, comprising:

at least one processor configured to initiate an online notarization conference between a signer and an agent, the at least one processor further configured to display a first electronic file associated with the online notarization conference at a graphical user interface, the at least one processor further configured to allow one or more edits to be made to the first electronic file at the graphical user interface to produce a partially completed first electronic file, the at least one processor further configured to display a user selectable option at the graphical user interface to lock the partially completed first electronic file, and in response to receiving a selection of the user selectable option, the at least one processor further configured to enable storage of the partially completed first electronic file, the at least one processor further configured to determine that the online notarization conference has been interrupted, the at least one processor is further configured to, after the interruption, restore the partially completed first electronic file.

16. The electronic signature verification system of claim 15, wherein the first electronic file is one of a plurality of electronic files associated with the online notarization conference.

17. An electronic signature verification system as claimed in claim 15 wherein said user selectable options include an option to reject said partially completed first electronic file.

18. An electronic signature verification system as claimed in claim 17, wherein upon selection of said option to reject, one or more user selectable rejection reasons are displayed at said graphical user interface.

19. The electronic signature verification system of claim 15, wherein recovering the partially completed first electronic file includes recovering a video recording associated with the online notary conference.

20. The electronic signature verification system of claim 15, further comprising:

automatically processing the partially completed first electronic file after the determining step.