WO2010143001A1

WO2010143001A1 - Electronic document verification system and method

Info

Publication number: WO2010143001A1
Application number: PCT/GB2010/050985
Authority: WO
Inventors: Norris Ebbin; Andrew J.D. Whalley
Original assignee: Provenance Information Assurance Ltd; Cole, Douglas L.
Priority date: 2009-06-12
Filing date: 2010-06-11
Publication date: 2010-12-16
Also published as: GB2471072A; GB0910163D0

Abstract

A method of verifying documents using an electronic document verification system is disclosed. The method includes sending a verification request to a verification server from a first terminal. A verification transaction entry is created in a database associated with the verification server. At least one electronic document to be verified is received and transmitted to a verifying user at a second terminal. Verification confirmation is received from the verifying user at the second terminal, and an electronic verification confirmation document is then generated and output by the system.

Description

Electronic document verification system and method

The present invention relates to systems and methods for electronic verification of documents.

Various methods for verifying or certifying documents are known, which are used to verify the authenticity or veracity of certain aspects of documents. Examples in the legal field include legalisation, notarisation, and certification of documents, and the taking of oaths. These processes are typically manual, laborious and time-consuming, and require the physical transmission of paper documents between various concerned parties, such as a lawyer seeking notarisation of a document on behalf of a client, the client himself, and a notary who carries out the notarisation. The security of these procedures typically rests on relationships of trust between the parties and physical authentication devices such as signatures and seals.

Electronic documents are increasingly used in a variety of transactions. Although some electronic signing technologies are available to enable documents to be signed and authenticated electronically, it can be difficult to ensure interoperability and reliable authentication between multiple parties. Also, typical electronic transmission channels may not provide the security needed, especially when documents are to be transmitted between multiple parties, and interoperability between communications channels can also be problematic. For these reasons, such technologies have not been widely adopted in more formal document verification procedures such as those mentioned above, which typically have more stringent security and authentication requirements.

The present invention seeks to alleviate some of these problems.

Accordingly, in a first aspect of the invention, there is provided a method of verifying documents using an electronic document verification system, comprising: sending, from a first terminal client, a verification request to a verification server; creating a verification transaction entry in a database associated with the verification server; receiving at least one electronic document to be verified; transmitting the document to a verifying user at a second terminal client; receiving verification confirmation from - -

the verifying user at the second terminal client; generating an electronic verification confirmation document; and outputting the electronic verification confirmation document.

The term "verification confirmation document" refers to a document, data set, data structure or file serving as confirmation that the document has been successfully verified (for example certified, notarised or legalised) by the verifying user. Thus the verification confirmation document may be a certificate (e.g. a notarisation certificate or Apostille certificate) in electronic form. Verification confirmation documents are also referred to herein as opinions.

By providing an integrated electronic document verification system, security and efficiency of verification procedures can be improved. The document to be verified may be retrieved from an electronic document repository associated with the system, in which case the verification request may comprise information identifying the document to be retrieved. Alternatively or additionally, receiving at least one document may comprise uploading an electronic document from the first terminal client to the verification server or a document upload server associated with the verification server. Receiving may alternatively or additionally comprise digitally imaging a paper document. The received document may be stored in an electronic document repository associated with the verification server or document upload server.

Preferably, the method comprises associating information rights management information with the received document and/or with the electronic verification confirmation document. This can allow access and use of the documents to be controlled, thereby improving security. The information rights management (IRM) information is preferably usable to control access to and/or use of the document, preferably to restrict document actions to specified users or groups of users, the actions preferably including one or more of: viewing, editing, and printing the document. Copying may be another restricted action. Preferably, users who have not been given particular rights cannot perform the corresponding actions (or cannot use the document at all if no rights have been granted). The IRM information may comprise metadata embedded or associated with a document or file, which may be - -

encrypted to limit access. The IRM protection is preferably applied when a document is uploaded or otherwise added to the system, or when the verification confirmation document is created. Alternatively or additionally, IRM protection may be applied (or may be modified) when a document or file leaves the system, e.g. when it is electronically transmitted to a recipient. IRM information is also referred to herein as document usage rights information.

To further improve security, the method may comprise generating an electronic tamper-proof seal for the received document or for each of a plurality of received documents. This may be used to detect modifications made to a document after the seal was created. The seal may be created when a document is uploaded or otherwise added to the system, for example by a user requesting verification. The seal can enable the verifying user to determine that the document has not been changed since it was uploaded. Alternatively or additionally, the method may comprise generating an electronic tamper-proof seal for the verification confirmation document.

The method may comprise performing verification for a group of documents, and generating a group electronic tamper-proof seal for the group of documents. Thus, a single seal can be generated which can be used to confirm the authenticity of a group of documents or files (where the files can include the original received documents, verification confirmation documents generated for those documents, and optionally any individual seals generated for those documents).

Thus, the method may comprise further generating a respective individual electronic tamper-proof seal for each document in the group, preferably wherein the group seal is generated for a collection of files including one or more or each of: the documents in the group; one or more verification confirmation documents generated for one or more documents in the group; and individual tamper-proof seals for the documents and/or verification confirmation documents. As an example, multiple documents may be verified, and a verification confirmation document may be generated for each document or for the group as a whole. A single seal may then be generated for a package of files which includes the verified documents and verification confirmation document(s), and optionally also the individual seals for the verified documents and verification confirmation document(s). - -

Generating an electronic tamper-proof seal preferably comprises generating an electronic seal file to be associated with a document or group of documents, preferably comprising performing a hash operation on the document or file or group of documents or files to be sealed and storing the result of the hash operation in the electronic seal file. The seal file itself may be encrypted.

The method may comprise checking the electronic seal for the document to be verified to determine whether the document has been modified. The outcome of the check is preferably displayed to the verifying user (before the verification confirmation is received from the verifying user). The check may be performed in response to a command from the verifying user or automatically, for example when the document to be verified is displayed to the verifying user. Thus, the verifying user can confirm the document has not changed before completing the verification.

The verification confirmation document may be signed/sealed electronically or printed and signed/sealed manually. Preferably, the method comprises applying a digital signature and/or a digital seal of the verifying user to the electronic verification confirmation document (in response to the verification confirmation). This may be in the form of a graphical signature or seal image and/or may use a digital signature algorithm, for example based on encryption.

Verification may include one or more of: consularising or legalising the document or providing an Apostille certificate for the document; notarizing the document; certifying the document; and taking an oath in respect of the document. The term "verification" as used herein is intended to cover any such certification procedure, as well as other processes for validating, verifying or certifying documents. The terms validation, verification and certification and the like are used herein interchangeably unless the context requires otherwise. The term "document" may include any suitable type of computer file which may be the subject of a verification process.

Preferably, outputting the electronic verification confirmation document comprises printing the electronic verification confirmation document. Alternatively or additionally, outputting may comprise electronically transmitting the verification - -

confϊrmation document to at least one recipient. In this way, an end-to-end verification system can be provided which allows for the secure upload, verification and distribution of documents. Preferably, the method comprises receiving from the first terminal client a selection of at least one recipient, the selection preferably included in the verification request, and transmitting the verification confirmation document to each selected recipient.

Preferably, the method comprises providing a verification confirmation template to the verifying user and, in response to receiving verification confirmation from the verifying user, generating the verification confirmation document based on the template. The template may be selected from a plurality of stored templates, preferably wherein the template is populated with data, preferably data from the verification request or database or data stored locally at the verifying user's terminal client. The method may comprise receiving modifications to the template input by the verifying user at the second terminal client and generating the verification confirmation document using the received modifications. This can enable more efficient verification. The method may comprise receiving an indication of a verification type preferably from the first terminal client, and generating or selecting the template based on the indicated verification type. Templates may, for example, be Word or PDF files or may use any other suitable file formats.

In one example, verification may relate to verifying the signature of the document by one or more signatories. The method then preferably comprises: receiving, from the verifying user at the second terminal client, a message indicating that the document is ready for signature; transmitting a signature request to one or more terminal clients associated with the one or more signatories; and receiving confirmation of signature from the one or more terminal clients. In this way, the system can enable verification of documents electronically signed by multiple parties without the parties necessarily having to be present at the same location. The method may comprise applying electronic signatures for the one or more signatories to the document and/or the electronic verification confirmation document. Preferably, the method comprises displaying a log-in (and/or readiness) status of one or more signatories to the verifying user, the log-in (and/or readiness) status preferably indicating whether the signatories are currently logged-in to the system (and/or ready to sign the document). This can - -

assist the verifying user in coordinating the verification process. A notification may be displayed at a signatory terminal client indicating that a signature is required. The signatories may be prompted to sign one by one, with the verifying user proceeding to the next signatory after receiving confirmation of signature from the previous signatory. Alternatively, signing by multiple signatories may proceed in parallel.

In some cases, for example where the document to be verified is a previously verified (e.g. notarized) document, the method may comprise accessing, by the verifying user, information in a database relating to a verifier (e.g. notary or other party) identified in the document, the information preferably including a representation of a signature of the verifier. The information is preferably displayed to the verifying user to assist in verification of the document.

The method preferably comprises receiving a selection of one of a plurality of verifying users to perform the verification. The method may comprise assigning the verification transaction to a work queue associated with an administrative user; accessing the verification transaction by the administrative user in the administrative work queue, and receiving the selection of the verifying user from the administrative user. Selecting the verifying user preferably comprises assigning the verification transaction to a work queue associated with the verifying user; preferably wherein the verifying user selects the verification transaction in the work queue to access the verification transaction. This can enable efficient coordination of verification processes.

The method may comprise generating billing information relating to the verification transaction, and may comprise transmitting an invoice to and/or debiting an account associated with a user, preferably an end user requesting verification or a verifying user.

The method may comprise transmitting the verified document and/or the verification confirmation document to a further verifying user for performing a further verification. For example, a document may be certified, then forwarded to a notary for notarization, and may then also be legalised by Apostille. Preferably, the system allows a verification transaction to have multiple verification stages defined, and - -

allows a user to allocate the transaction to a subsequent verifying user after a previous verification stage has been completed.

Preferably, the method comprises authenticating the verifying user and/or a user associated with the first terminal client, preferably by reference to stored credentials for the verifying user and/or other user.

The terminal clients may comprise client software provided at the terminals. The first and second terminal clients (and other terminal clients mentioned above) are preferably located at separate terminals, but multiple clients may alternatively be provided at a single terminal.

In some embodiments, the step of creating a verification transaction entry in a database associated with the verification server may be omitted. In that case, for example, information concerning the verification request may be transmitted directly to the verifying user.

The electronic document to be verified may comprise a digital media file, for example an audio file, a video file or an image file.

In a further aspect of the invention, there is provided a method of verifying signing of documents by multiple signatories using an electronic document signing and verification system, comprising: receiving an electronic document; transmitting the document to a verifying user at a first terminal client; transmitting the document to one or more further terminal clients associated with respective signatories; in response to an indication from the verifying user at the first terminal client, transmitting a message to each of the further terminal clients requesting signing by each signatory; receiving a signature confirmation message from each further terminal client; receiving confirmation from the verifying user that the multiple signatures have been received; generating an electronic verification confirmation document; and outputting the electronic verification confirmation document.

In a further aspect of the invention, there is provided a method of verifying documents using an electronic document verification system, comprising: receiving an electronic - -

document as an input document to be verified; receiving verification confirmation from a verifying user in relation to the input document; generating a verification confirmation document; generating an electronic seal relating to one or both of the input document being verified and the verification confirmation document; and outputting the input document, the verification confirmation document and the electronic seal.

The outputting step may comprise generating an output document comprising the input document, the verification confirmation document and the seal. The method may comprise performing a further verification in relation to the output document, the further verification comprising: receiving a verification confirmation from a verifying user in relation to the output document; generating a second verification confirmation document; generating a second electronic seal relating to one or both of the output document being verified and the second verification confirmation document; and generating a second output document comprising the output document, the second verification confirmation document and the second electronic seal.

The input document may itself comprise a sealed verified document. Preferably, the output document and/or the second output document is in the form of a single file representing the sealed verified document. Alternatively, output documents may be in the form of multiple associated files.

The electronic seal is preferably arranged to enable detection of modifications made to the document(s) being sealed. For example, the electronic seal may include a message digest (e.g. an MD5 message digest or the like). The seal may be encrypted. The input document and/or verification confirmation document may also be encrypted. Additionally or alternatively, the whole output document (including the seal) may be encrypted.

In a further aspect of the invention, there is provided a method of verifying documents using an electronic document verification system, comprising some or all of the following steps: sending, from a first terminal client, a verification request to a verification server; creating a verification transaction entry in a database associated with the verification server; optionally transmitting a receipt to the first terminal and - -

printing the receipt by a user at the first terminal; transmitting a physical document to be verified by the user optionally together with the printed receipt via a physical transmission channel (e.g. mail/courier) to a verifying agent; acquiring and storing (e.g. by scanning) a digital representation of the document to be verified; transmitting the digital representation of the document to a verifying user at a second terminal client; receiving verification confirmation from the verifying user at the second terminal; generating an electronic verification confirmation document; and outputting the electronic verification confirmation document. Alternatively, the step of acquiring a digital representation of the document may be omitted and instead the verifying user may verify the paper copy received. The verifying agent may be the same as the verifying user or may be a different entity, e.g. an administrative user or a firm for whom the verifying user works. Instead of transmitting a verification request from a terminal client, a user may visit the verifying agent and pass a physical copy of the document to be verified to the verifying agent. The verifying agent may then set up the verification request on the system and optionally scan the document before proceeding with the verification.

In a further aspect of the invention, there is provided an electronic document verification system comprising: a document repository for storing electronic documents; a database for storing verification transaction data; an interface for interfacing with a plurality of user terminal clients; software for receiving a verification request from a user terminal client and storing verification transaction data for the request in the database; software for receiving a document upload from a user terminal client and storing the uploaded document in the document repository; software for transmitting or displaying information relating to a verification transaction to or at a user terminal client associated with a verifying user and receiving a verification response from the verifying user; software for generating a verification confirmation document preferably in response to a verification response; and software for transmitting the verification confirmation document to one or more recipients.

The system may further comprise one or more or optionally each of: an electronic sealing module for generating an electronic tamper-evident seal for a document; an information rights management module for associating document usage rights - -

information with a document; a user management and/or authentication system for managing system user information and/or authenticating users and/or processing user logins; software for providing a client user interface for requesting verification of a document; software for providing a client user interface for uploading a document; software for providing a client user interface for managing verification transactions and/or performing administrative tasks relating to verification transactions; software for providing a client user interface for performing verification of a document by a verifying user; and workflow management software for assigning verification transactions to users.

In a further aspect of the invention, there is provided an electronic document verification system comprising: means for sending, from a first terminal client, a verification request to a verification server; means for creating a verification transaction entry in a database associated with the verification server; means for receiving at least one electronic document to be verified; means for transmitting the document to a verifying user at a second terminal client; means for receiving verification confirmation from the verifying user at the second terminal client; means for generating an electronic verification confirmation document; and means for outputting the electronic verification confirmation document.

The system aspects set out above preferably comprise means or are configured for carrying out any of the methods described herein.

The invention also provides a computer program or computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any method as set out above.

More generally, the invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein. - -

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

Furthermore, features implemented in hardware may generally be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which:-

Figure 1 illustrates an electronic document verification system in overview;

Figure 2 illustrates a document verification process;

Figure 3 illustrates user classes and characteristics; Figure 4 illustrates system input methods;

Figures 5, 6 A and 6B illustrate IRM rights applied to documents;

Figure 7 illustrates integration with a revenue collection system;

Figures 8 A - 8F illustrate examples of opinion templates;

Figure 9 illustrates the system architecture of an embodiment; Figures 10 - 18 show sample user interface screens;

Figures 19 - 25 are user interface flow diagrams;

Figures 26A and 26B illustrate the system interface design;

Figures 27A - 27C show a class-relationship diagram for the system; and

Figure 28 illustrates a deployment architecture for the system. - -

A document verification system in accordance with an embodiment of the invention is illustrated in Figure 1. The verification system can be used to assist in various different forms of document verification/certification processes, including: • Legalizing of documents, e.g. by Apostille

• Notarizing of documents, for example by a notary public

• Taking of oaths relating to documents, for example to confirm the truthfulness of statements in a document

• Certification of documents, for example to certify authenticity by an issuing organisation

The verification system 100 includes a verification transaction server 120 for coordinating the completion of document verification transactions. The verification transaction server 120 is connected to various users 102, 104, 106 via a network 110. The network may be a private network or public network such as the Internet, and/or may comprise a collection of different networks.

End users 102 connect to the system to carry out document verification. Verifying users 106 perform the verification, and are typically trusted third parties authorised to perform the relevant type of verification, such as government officials or public notaries. Administrative users 104 assist in the carrying out of verification transactions. Though in this example, the various types of users are connected to the verification transaction server 120 through a network such as the Internet, in other examples certain users (for example an administrative user) may be connected directly to the verification transaction server.

The various users connect to the system from user terminals (for example Internet- connected PCs) using client software at the terminals. In preferred embodiments the system is implemented (at least in part) as a web application, and the client software at the user terminals in that case comprises a web browser through which a web application interface is displayed to the user. Alternatively, a standalone client application may be provided. - -

Different web client interfaces may be provided for the different types of user supporting the various required functions. Thus, the system may include an end-user web client interface (for initiating new verification transactions and uploading documents), an administrator web client interface (for performing administrative tasks such as preparing/checking documentation and scheduling face-to-face meetings) and a verifier web client interface (for performing the actual verification steps).

The verification transaction server 120 is connected to a user authentication server 122 to perform user authentication for each type of user of the system when users log in to the system. Authentication may use passwords, smartcards, or any other suitable techniques or combinations of techniques. The verification transaction server is also connected to a verification transaction database 124 which stores information on completed and pending verification transactions, and a document repository 126 for storing electronic documents relating to completed and pending verification transactions. The verification transaction database 124 and document repository 126 may be separate as shown or may be stored as a single database.

An electronic document sealing server (e-sealing server) 128 is also provided and is connected to network 110 and/or to verification transaction server 120. The e-sealing server 128 provides functionality for the creation of an electronic tamper-evident seal relating to an electronic document to thereby electronically "seal" the document. Additionally, the e-sealing server provides functionality for checking a sealed document to determine whether the document has been modified since being sealed.

The electronic seal includes information which enables tampering with a document after sealing to be detected. In a preferred embodiment, the seal includes a hash of the document, using any suitable hashing algorithm (for example MD5). The seal may additionally include information identifying the person who sealed the document, the time of sealing, and the like. In a preferred embodiment, the electronic seal is a separate file which may be stored with the document being sealed, and the document itself is not modified. However, alternatively, the seal may be incorporated into the electronic file of the document being sealed. Multiple documents and/or verification confirmation documents (optionally including individual document seals) may be sealed as a package, and sealed packages may include other sealed packages. Thus, - -

multiple layers of seals may be used, each layer effectively encapsulating an inner layer of sealed documents. Preferably, the Evident Seal technology provided by Evident Technologies is used to provide the e-sealing functionality.

A typical process for verification of a document is illustrated in Figure 2.

In step 200, an end user initiates a new verification transaction by entering relevant information into a form provided by the verification application's web front-end. At the same time or separately, the user uploads the document or documents which are to be verified (step 202).

On receipt of the new verification request, the verification transaction server creates a new transaction in the verification transaction database, storing the information entered by the user. The documents uploaded by the user are electronically sealed and protected using IRM (described below) and stored in the repository in step 206. The new transaction is then allocated to a work queue in step 208 for subsequent processing by an administrative user.

In step 210, the administrative user accesses the transaction data using the administration interface and generates an opinion template. The term "opinion" here refers to a formal document generated as part of the verification process confirming the successful verification of the document(s) submitted for verification. The verification confirmation document or opinion is preferably generated in electronic form but may also be printed. For example, the opinion may be an Apostille certificate or other certificate. The opinion typically carries the signature and/or seal of the verifier (e.g. government official or notary) who verified the document, along with other relevant information. The administrator selects the relevant opinion template based on the type of verification being carried out and the details of the case, and may insert relevant information (such as information identifying relevant parties) in the template. Alternatively the system may select the correct opinion template automatically and/or insert relevant information automatically.

In step 212, the administrative user selects a verifying user (e.g. notary) to perform verification (where multiple verifiers are available). For some forms of verification - -

(e.g. taking of oaths), it may be necessary for relevant parties to attend a face-to-face meeting, in which case the administrative user may schedule a time and place for such a meeting using an event calendar module provided by the verification transaction server (alternatively or additionally, the system may interface with external calendar software). The administrative user then allocates the verification transaction to a work queue associated with the selected verifying user (step 214).

The verifying user accesses the transaction details using the appropriate user interface of the system and reviews the documents to be verified in step 216. The document seal may be checked at this point (preferably automatically) to confirm that the document is unchanged. The verifier then also reviews (step 218) the opinion template created by the administrative user or the system and amends or adds details as necessary, and then applies the verifying user's electronic signature and/or seal. Digital signatures may be applied using any appropriate digital signature algorithms and protocols, for example using cryptography-based digital signatures. Alternatively or additionally, this step may include adding a graphical representation of a signature and/or seal to the opinion.

Once the verification is complete, the completed, signed and sealed opinion template is stored as the opinion, also referred to herein as the verification confirmation document. The verification confirmation document is transmitted, optionally together with the verified document, to one or more relevant recipients in step 220, preferably electronically (for example by email). Files are IRM-protected as set out below.

Alternatively, one or more links may be transmitted using which a recipient can access the (IRM-protected) document(s) in question, for example via a further web interface made available by the verification transaction server. The recipients may be specified by the end user when creating the verification request or may be specified later, for example after verification is complete. In some embodiments, the verification confirmation document (opinion) and verified document may be combined into a single (preferably IRM-protected) document.

The above is given as an example of a verification process. Depending on the type of verification performed (e.g. legalisation, notarization etc.) and other circumstances, the details of the process may differ from that described above. For example, in some - -

cases, documents to be verified may already be present in the repository. In that case the user may simply select the pre-existing document(s) to be used in the verification process. In another example, a user may create the new verification transaction using the web front-end as described above, but instead of uploading the documents to the verification transaction server, may send the documents to another party (e.g. an administrator or notary) by post or courier, where they are scanned and uploaded to the system. Various detailed verification procedures for different types of verification are set out below.

The system may be used to verify signing of documents by multiple signatories. In that case, in response to an indication from the verifying user, a notification may be displayed to each signing user at their respective terminals (either one-by-one or in parallel), who may then apply their signatures. Confirmation of signing is transmitted to the verifying user. Once all parties have signed, the verifying user may then complete the verification process as described above. This "multiple signing" feature is described in more detail below.

In preferred embodiments, documents handled by the system are further protected using information rights management (IRM) or digital rights management (DRM) technologies or the like. Preferably, the Oracle IRM system is used for this. Using this technology, rights to perform various actions on a document, such as viewing, editing, copying or printing the document can be assigned to individual users or groups of users. For documents protected in this way, users can only perform the actions for a given document for which they have been authorised. This may be achieved by encrypting the document and storing rights management metadata with the encrypted document.

Preferably, documents which are to be verified are IRM-sealed when (or before) they are uploaded by the user (or scanned in by an administrator). This ensures that only authorised users in the system (e.g. the administrators, notaries and the like) can view, edit or print the documents. An Evident seal as discussed above is preferably generated in addition to the IRM protection to enable tampering to be detected (i.e. so that the verifying user can confirm that the document has not changed). IRM protection is preferably also applied to the verification confirmation document (the - -

opinion or certificate) output after verification is complete. After verification, the verification confirmation document, optionally together with the document having been verified, are then sent in IRM-protected form to the selected recipient(s). This ensures that only the intended recipients can view, print, copy or otherwise use the documents.

Referring back to Figure 1, IRM server 130 may be provided to implement the IRM functions and manage IRM rights for documents/users. IRM client software is also provided at user terminals to enforce the IRM rights for copies of the documents held and/or accessed at those terminals (for example the completed opinion transmitted to a recipient after verification).

A tamper-evident electronic seal (e.g. Evident seal) as described above may optionally also be generated for the verification confirmation document (opinion).

The system may enable multi-stage verifications, where a document is provided to a first verifying user for verification, and the generated verification confirmation document and verified document are provided to another verifying user for further verification (for example to produce an Apostille certificate for a previously notarised document). In that case, different electronic seals may be produced for the document packages produced at each stage, and the seals can then provide a stage-by- stage audit trail of the verification process, allowing the integrity of documents, the identities of the verifying users and other relevant information (e.g. time of verification) to be determined at each stage.

In more detail, in a preferred embodiment, the sealing process takes an input document and a verification confirmation document (e.g. certificate/opinion) produced as a result of verifying the input document, and produces a seal relating to both documents. The seal includes information identifying when, where and by whom the verification and sealing was performed. In addition to basic identifying information, the seal may also include biometric data relating to the person performing the verification/sealing, e.g. fingerprint data, retinal scan data or the like. The document, certificate and seal may then be combined into a single sealed package (e.g. a single document or file). - -

The resulting package may then be used as input (i.e. as document to be verified) in a second verification stage. Thus, another verifying user receives the sealed first-stage package and can use the seal to determine whether the package has been tampered with. Furthermore, the second verifying user can use the identifying information in the seal of the first-stage package to check the identity of the first verifying user. Having checked that information, and also the document and certificate contained in the first-stage package, the second verifying user can then perform his own verification. In this, the first-stage package plays the role of the original input document in the first-stage verification. Thus, the second verifying user produces a second certificate (verification confirmation document) certifying the first-stage package. A second seal is generated for the first-stage package and the second certificate. This seal in turn may contain information identifying when, where and/or by whom the second stage verification and sealing was performed, and may include other identifying information such as biometric information relating to the second verifying user. The documents (first-stage package being verified, second certificate, and second seal) can again be combined to form a further package.

This second-stage package can again be checked by way of its seal, and can provide the input document to a yet further verification stage.

Furthermore, since the second-stage package includes the second certificate together with the sealed first-stage package, and the sealed first stage packet includes the first certificate together with the original document, the entire verification process is recorded in the resulting output package, and can be reconstructed and checked, by checking the seals at each level. Thus, if a further verification process is carried out, the verifier can check the entire verification history of the documents, and can identify the date/time, place, and verifier for each verification stage. This can significantly improve the overall security of the verification procedure.

As an example, the first stage may be notarisation of a document. A notary certificate is generated and packaged with the document, with a tamper-evident electronic seal identifying the notary, and the date/time and place notarisation took place. The resulting package may then be transmitted to an Apostille agent for legalisation. - -

Alternatively, the resulting sealed package may be stored in document repository 126 (see Figure 1), from where it is later retrieved by the Apostille agent, in accordance with the workflows described above. The Apostille agent can then check the seal and the notary certificate in the package as described above and generate an Apostille certificate. The original package being legalised and the Apostille certificate are then combined into a further package, with a seal identifying the Apostille agent, date, time and place etc. This further package then represents the notarised and legalised document and can be forwarded to the intended recipients and/or stored in the document repository.

Further examples of the procedure are described below.

The term "document" as used herein may preferably include any type of document or file. In many cases documents being verified will be text documents, such as legal documents (powers of attorney, contracts and the like). These may, for example, be in PDF format, or in word processor format, or in any other suitable computer file format.

However, in a preferred embodiment, the system can be used to verify (e.g. certify / notarise) any type of document or computer file. In particular, the system may be used to verify media files, such as audio files, image files or video files. Such files may be provided as input documents to the system and processes described elsewhere herein.

Verification confirmation documents and electronic tamper-proof seals may be generated for media files in the same way as already described. Thus, the system may output a package including a media file, a certificate relating to the media file, and a seal for the media file and certificate as described above, and that package may itself be the starting point for further verification procedures.

Detailed implementation

By way of example, a detailed implementation of the electronic document verification system will now be described. - -

The system provides a legal document certification system referred to in the following as the e-CANOC (Electronic Consularising, Apostilling, Notarizing, Oath and Certification) system. The system preferably provides a comprehensive real-time certification portal system that allows users to authorize, digitally sign and verify the authentication of electronic documents. The system will also offer the ability to consularise documents electronically.

The system is capable of supporting authorized agents in providing Apostille, Notarial, Oath Swearing and Certification services. The system can provide the fo Ho wing benefits :

• Eliminate manual paper-based documents o Improve efficiency o Increase throughput

• Increase security • Improve Compliance o Revenues o Audit trails/archives

• Comply with initiative of The Hague Conference on Private International Law (HccH) (1961 Convention) - facilitate local and inter-country trade • Supports "green" environment

Currently, the processes involved, namely Consularising, Apostilling, Notarizing, Swearing Oaths and Certification are majorly paper based. Hence, this system aims to replace these manual processes to create an efficient and productive automated system, providing a higher level of security at a low TCO (total cost of ownership).

The system provides the following features:

• Portal based system - remote access/retrieval

• Robust access and identity security • Smart card integration

• Workflow and work queues to control certification processes

• Electronic Signing and e-Sealing of underlying documents, thus providing a durable non-repudiable Trust Authority Seal - -

• Certifies documents in different digital formats

• Information Right Management (IRM) - control content access and distribution

• End user real-time certification authentication; at any stage • Archival of certifications and related documents

• Agent revenue model(s) and related billing.

User classes and characteristics are illustrated in Figure 3, which shows the hierarchy of users using the system according to which user(s) will/can create which set of users.

System operating environment

The Server Environment for Deployment is illustrated in the following table:

The Evident Sealing Solution is used as a service and hence no specific hardware/software is mentioned here.

The Client Environment for Deployment is illustrated in the following table:

Evident Seal Validation can be performed on Mozilla Firefox 2.0-3.0 by uploading the document to validate the seal. e-CANOC client support is also preferably provided on Macintosh using Mozilla Browser. - -

The Oracle IRM server may use Windows Server 2k3 as OS and MS-SQL or Oracle as Database. The IRM Unsealer may be used with Macintosh OS (10.4 & above) for PDF formats (Acrobat reader version 8.0 and 9.0). IRM Desktop may be used with Windows 2000, XP, 2003 Server and Vista.

The system preferably supports a variety of file formats, such as Microsoft Office file formats; PDF, HTML, XML, rich text and plain text; GIF, PNG, JPEG and other image formats.

The major system processes (implementing various forms of document verification or certification) are as follows:

1) Consularisation

2) Apostilling

3) Notarization 4) Oath

5) Certification Following are additional major sub-processes used by the above:

1) User Management

2) Payment These processes will be described in more detail below. The following features apply generally to each of the four main processes set out above:

Batch Submission Number

• Every time a user/company raises request for Consularisation / Apostilling / Notarization / Swearing of Oath / Certification, a "Batch Submission Number" is generated.

• A Batch can have one or a set of documents, which have to be Consularised / Apostilled / Notarized / Sworn for Oath / Certified.

• For each document to be Consularised / Apostilled / Notarized / Sworn for Oath / Certified, a separate Case Number (Consularisation / Apostille / Notarization /

Oath / Certification Number) is created.

• Unless all the Case Numbers are processed, batch remains open. - -

System Input Methods

Figure 4 illustrates main system input methods, which include manual and electronic processes. Sending of documents using e-Mail may be provided but due to security concerns is not a preferred option.

Input information while creating a Case Consular / Apostille / Notary / Oath Information:

Number of copies (Only case output is paper document)

Type of documents. • Client reference number (matter ID)

• (Time and date is automatically generated). Output Form related information:

• IRM preferences.

• Whether mail directly to end client or the company. • Mail IDs of end client.

Type of output can be specified as paper or electronic output for each Case Number in a batch.

In case of paper output, whether output opinion to be original wet signed & sealed or electronically signed & sealed. • In case of electronic output, whether link or final document should be sent to end client. Other Information: This is specific to the process and is listed as shown below:

• Consularising / Apostilling / Notary / Oath / Certification Information o Notary Name o Notary Capacity

• Notarization o Preferred law firm or lawyer name

• Swearing of Oath o Preferred Commissioner of Oath or Law Firm name, (in certain jurisdictions a Commissioner for Oaths is generally an individual and not a law firm, but this may be different in other jurisdictions) - -

IRM Preferences

User can allow/disallow following permissions on document using Oracle IRM: View, Edit, Copy, Paste, Print and Capture Screen. IRM Rights definition for a document in e-CANOC system is as follows: 1. IRM on documents that will go out of the system will be as follows: a. Document can never be opened for view by un-intended users. Only users who have been assigned rights can view the document. b. Only the End User can set these Rights, except in the case opinions/certifications, the rights of which are based on default values. c. The Consular / Apostille / Notary / Oath or Certification Agent preferably does not have any role in setting the rights even on the opinion being created by him/her. d. In case user wants to share a document with users who don't belong to e-CANOC system, he has two options: - Request for a new Consularisation / Apostille / Notarization /

Certification / Oath

Or request for print rights on document. Document can be printed and shared with intended users. e. No Rights other than View and Print can be set on any document. f. All Seal Files preferably remain Un-protected.

These IRM rights are summarised in Figure 5.

2. IRM on documents inside system before finalization will be as follows: These IRM rights are summarised in Figure 6A.

3. IRM on documents stored in the system will be as follows: These IRM rights are summarised in Figure 6B.

System Output Methods Print output - Manual:

• In case user has opted for original wet signatures and Seal, opinion document is printed with electronic revenue stamp only. Agent applies wet signatures, applies

Consular / Apostille / Notary / Oath / Certification seal. Agent scans and uploads the document in the same case number and seals it (for its records).

• In case user has opted for electronic signatures and Seal, System applies signatures, Consular / Apostille / Notary / Oath / Certification seal and electronic - -

revenue stamp images. Agent attaches saved opinion with the case and prints the document for user.

• Electronic revenue stamp is not applicable in case of Apostille for both the above scenarios. • For each Electronic revenue stamp being added to the document there will be a unique identifier associated with it comprising of: Country ID+ Process(CANOC) ID + Unique Number.

• Barcode may also be added to the printed opinion document.

Electronic output :

• Output template of opinion document is automatically generated for the agent.

• Electronic signatures of agent are applied and Consular / Apostille / Notary / Certification / Oath stamp and revenue stamp are attached to the opinion. Electronic revenue stamp may not be applicable in case of Apostille. • For each Electronic revenue stamp being added to the document there will be a unique identifier associated with it comprising of: Country ID+ Process(C ANOC) ID + Unique Number.

• Opinion and original document are sealed.

• IRM is applied to original document & opinion page so that it can only be used by required/authenticated users. This is done by system. These IRM attributes may be applicable only during storage in the system. Separate attributes may then be applied when the document leaves the system.

• These four documents: IRM protected Original document, IRM protected Opinion, Seal on original document and seal on Opinion are added as attachment to PDF using Evident SDK.

Seal is applied to the output PDF document.

• User makes the payment

• Agent reconfirms list of receiving users.

• Document is either mailed to user or a link is sent from where it can be downloaded. Information of the user (Name, email id & company name) who requested for Consularisation / Apostilling / Notary / Oath / Certification is also sent. - -

Case distribution Apostilling:

Document is added to generic work-queue.

• All Apostille agents can log in to system and look into the queue. • Agent can select a case and start working on it (i.e. it is moved to their work queue).

• Apostille administrator can assign/re-assign cases to different individuals.

• If cases are not being started on the same day, administrator is notified. Notarization/Oath/Certification Process: • Document is added to Administrative Agent's work-queue.

• All administrative agents can log in to system and look into the queue.

• Agent can select a case and start working on it (i.e. is moved to their work queue).

• Administrative agent checks calendar of each Notary/Oath/Certifying Agent and case is transferred to Notary/Oath/Certifying Agent.

• Administrator can assign/re-assign cases to different individuals.

• If cases are not being started on the same day, administrator is notified.

Consularisation / Apostille / Notarization / Oaths / Certification Log Following information is maintained for documents which are coming in for Consularisation / Apostilling / Notarization / Certification:

Official receipt number (generated pre-number)

Date and time received

Batch submission number (if details previously entered by client) - Company from where it came and Company, Name & Id person delivering

Courier/Shipping reference number (Air Bill No.)

Signature of person delivering (signature is preferably recorded using a scanner)

ID of Agent receiving documents Following information is maintained for Apostilled/Notarized/Certified documents:

Date and time on which certificate and related document were sent/picked up

Company, Name and ID of receiving person

Courier/Shipping reference number (Air Bill No.)

Signature of receiving person - -

Case number - which is unique across all requests (Apostilling/Notarizing/Certification)

Event Calendar • For each notary/oath agent/certification agent, an event calendar is available in the system

• Notary's/Oath Agent's/Certifying Agent's free time slot is booked by Administrative Agent after consulting him/her.

• Meeting place is also fixed: Notary office/User's office/other place. • Once time slot is fixed, a notification is sent to user, administrative agent and

Notary/Oath Agent/Certifying Agent.

Notifications

Mail notifications are generated in following cases: • Agent is notified if a case is added to work queue.

• If case is not processed within defined time, administrator is notified.

• Apostilling/Notarization/Swearing of Oath/Certification request is received by system.

• Administrative agent, user and Notary/Oath Agent/Certifying Agent are notified of date, time and venue of meeting by Notary/Oath Agent/Certifying Agent.

• Apostilling/Notarization/Swearing of Oath/Certification is complete.

• Batch is complete.

Entities involved in Apostille / Notarization / Oath / Certification Process • User: Person requesting Apostille/Notarization/Swearing of Oath/Certification

• Apostille Agent: Person who performs Apostille in PRO(Parliamentary Registrar Office)

• Notary/Notary Agent: Person who performs Notarization. He can be an individual or can belong to a company. • Oath Agent: Either Justice of the Peace or Commissioner of Oaths. He is the person in front of whom the oath is sworn or affirmed.

• Certification Agent: Person who performs certification. He can be a Doctor/Lawyer/Banker/ Accountant, etc. - -

• Administrative Agent: Maintains the documents coming in for Notarization/Swearing of Oath/Certification, fixes time between notary & clients for executing Notarization/Swearing of Oath/Certification.

• End client: Person for whom document is being Apostilled/Notarized/Sworn/Certified.

• Law firm: Company whose Notary/Lawyer/Officer of Company or Authorized Signatory is notarizing/swearing/certifying the document.

• Apostille Administrator: Assigns/approves Apostille Agents access to system.

• NOC (Notarisation / Oath / Certification) Administrator: Person who registers Notary/Oath/Certifying Agent's and manages the work being performed by them including re-assigning of work.

• Certification Agent (non-legal)

Multiple Signing Feature Process for signing a document by one or more executing parties in the presence of the Notary/Oath Agent/Certification Agent is as follows:

1. The Notary/Oath/Certification Agent logs into the system.

2. Notary/Oath/Certification Agent selects the case as per the Event Calendar for Notarization/Oath/Certification. 3. In case each executing party has their own machine: a. Executing parties also log into the system. b. The login status of each executing party is displayed to the Notary/Oath/Certification Agent. c. Notary/Oath/Certification agent asks first executing party to sign the document by clicking on a button. A quick notification is displayed at first executing party side which asks him to apply signature at designated place. d. First executing party applies the signature, and a notification is sent back to agent saying signature has been applied. e. Notary/Oath/Certification agent asks other parties to sign (If applicable)

4. In case notary & executing parties have single machine: a. Notary/Oath/Certification agent initiates document execution process, and logs off from the system. - -

b. First executing party logs into the system & sees the status as - Document Execution Pending. c. First executing party applies the signature, and a notification is sent back to agent saying signature has been applied. d. Notary/Oath/Certification agent asks other parties to sign (If applicable) e. Notary/Oath/Certification agent logs into the system

5. Once signatures are applied by all executing parties, Notary/Oath/Certification Agent Signs and clicks on a button to complete the Notarization/Swearing of Oath/Certification Process.

6. A notification is sent to all users about the completion of process.

Various document verification processes will now be described. Apostilling User walks-in (Manual Opinion):

1. If user doesn't exist in system, Apostille agent can register him/her as a client (see description of user registration below)

2. User supplies hard copy of document(s) to Apostille Agent.

3. From system, Apostille agent selects name of client and enters payee number. 4. Agent checks validity of notary in system by verifying following: a. Name of notary exists in the system. b. Validity of his capacity specified. c. Signature verification of Notary with the specimens available in system. d. Agent physically confirms that opinion/document is unaltered.

5. If all these match for any item presented, a batch number is created into the system.

6. For each document to be Apostilled, agent adds a case number, together with relevant details, and uploads corresponding document. 7. System generates estimated bill to client and determines if sufficient cash has been prepaid. If insufficient, client will have to purchase correct prepaid balance. Otherwise:

8. An output template of opinion document(s) is automatically generated for each case, which can be printed by agent. - -

9. Apostille is printed, (see description of manual print output above)

10. The system automatically logs details to the Apostille log. Client name, id & signature are also captured in the Apostille log as evidence of delivery, (see logging feature described above) 11. Apostille Case is marked as complete.

12. Once all the Apostille cases are processed, Batch is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that.

User couriers document (Manual Opinion):

1. User/Notary or Notary Agent logs into the system, raises a request for Apostilling, and a batch submission number is created.

2. User/Notary or Notary Agent inputs all fields required for creating each case (Apostille), including Matter ID. 3. System generates estimated bill to client and determines if sufficient cash has been prepaid. If insufficient, client is notified to purchase correct prepaid balance before further processing will occur. Otherwise:

4. A submission receipt is generated for the user indicating batch submission number, Case numbers and other details. Apostille Agent in notified of case for processing.

5. User prints submission receipt and couriers it along with documents which need to be Apostilled.

6. On receipt of items, Client name, id & signature of delivering person are captured for inclusion in the Apostille log as evidence of receipt. 7. Agent enters batch submission number into system to identify requested work and marks Apostille cases as received.

8. Agent notifies client where case (Apostille) documents are missing. Status of the batch/case is marked as partial documents received.

9. After receiving the courier, Agent checks validity of notary in system by verifying following: a. Notary selected matches with the one on paper b. Capacity specified matches with one on paper c. Signature verification of Notary with the specimens available in system. - -

d. Agent confirms that opinion/document is unaltered

10. If all is in order, notary opinion(s) are scanned and uploaded to the Apostille case.

11. An output template of the opinion document(s) is automatically generated for each case, which can be printed by agent.

12. User's account is debited for the Apostilled documents.

13. Apostille is printed, (see description of manual print output above)

14. The system automatically logs details to the Apostille log. Client name, id & signature are also captured in the Apostille log as evidence of delivery, (see logging feature described above)

15. Apostille Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that.

16. Once all the Apostille cases are processed, Batch is marked as complete.

User uploads document (Electronic Opinion)

1. User/Notary or Notary Agent logs into system and creates a batch submission number.

2. User/Notary or Notary Agent inputs all fields required for creating each case (Apostille), including Matter ID. Notary opinion(s) and related document are scanned and uploaded to the case(s).

3. System seals the documents, applies required IRM Protection and sends document's link to the user.

4. System generates estimated bill to client and determines if sufficient cash has been prepaid. If insufficient, client is notified to purchase correct prepaid balance before further processing will occur. Otherwise:

5. Apostille agent receives a case (Apostille) in his/her work queue. Apostille Agent in notified of case for processing.

6. Agent checks validity of notary in system by verifying following: a. Notary selected matches with the one on document. b. Capacity specified matches with one on document. c. Signature verification of Notary with the specimens available in system. d. Agent confirms that opinion/document is unaltered. This can be performed automatically by confirming the seal and is done by the system. - -

7. If all is in order, an output template of opinion document is automatically generated for each case, which can be printed by agent (see description of manual print output above).

8. Electronic output PDF containing Apostille which can be mailed to recipients is created by the system (see electronic output feature described above).

9. End user reconfirms list of receiving user & IRM preferences.

10. User's account is debited for the Apostilled documents.

11. Document is mailed or a link is sent from where it can be downloaded. An entry is automatically made to Apostille log. 12. Apostille Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 13. Once all the Apostille cases are processed, Batch is marked as complete.

System notarized document (Electronic Opinion): 1. Notary or user selects document(s) to be Apostilled. A batch and its case(s)

(Apostille) are created into the system (Matter ID previously assigned).

2. System generates estimated bill to client and determines if sufficient cash has been prepaid. If insufficient client is notified to purchase correct prepaid balance before further processing will occur. Otherwise: 3. Original document is automatically extracted by the system, if it is IRM protected.

4. Apostille agent receives a case in his work queue. Agent in notified of case for processing.

5. Apostille Agent checks validity of notary in system by verifying following: a. Name exists in the system b. Validity of capacity specified c. Signature verification of Notary with the specimens available in system. d. Agent confirms that opinion/document is unaltered. This is performed automatically by the system.

6. If all is in order, an output template of opinion document is automatically generated for the agent, which can be printed by agent.

7. Electronic output PDF containing Apostille which can be mailed to the recipients is created by the system. - -

8. End user reconfirms list of receiving user & IRM preferences.

9. User's account is debited for the Apostilled documents.

10. Document is mailed or a link is sent to recipients as to where it can be downloaded. An entry is automatically made to Apostille log. 11. Apostille Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 12. Once all the Apostille cases are processed, Batch is marked as complete.

Notarizing User walks-in (Manual Opinion):

1. If user doesn't exist in system, administrative agent can register him/her as a client.

2. User supplies hard copy of document(s) to administrative agent.

3. From system, administrative agent selects name of client, payee number and raises a request for Notarization. A batch is created into the system.

4. For each document to be notarized, agent adds a case, together with relevant details, including matter ID, and uploads corresponding document(s) (optional).

5. System checks if Notary/Lawyer/Law Firm has sufficient prepaid stamp duty or Notary fees balance (if prepaid). If insufficient, Notary/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise:

6. Administrative agent/lawyer selects the opinion depending on type of document and user's choice.

7. An output template of opinion document(s) is automatically generated for each case. 8. If client has to be present, administrative agent fixes a time between client and Notary (see Event Calendar feature described above)

9. Case is routed to Notary/Lawyer's work queue. Notary/Lawyer is also notified of case for processing.

10. Notary modifies opinion template if required, checks the documents and executes notarization (If required, the Multiple Signing process described above can be used).

11. Notary opinion is printed.

12. The system automatically logs details to the Notary log. Client name, id & signature are also captured in the Notary log as evidence of delivery. - -

13. Notary's account is debited for the Notarized documents or Notary invoice is generated by system which can be sent to Notary Agent.

14. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 15. Once all the cases are processed, Batch is marked as complete.

User couriers document (Manual Opinion):

I. User logs into the system, raises a request for notarization, and a batch submission number is created. 2. User inputs all fields required for creating each case.

3. A submission receipt is generated for the user indicating batch submission number, case numbers, and other details. Administrative agent is notified of case for processing.

4. User prints submission receipt and couriers it along with documents which need to be notarized.

5. System checks if Notary/Lawyer/Law Firm has sufficient prepaid stamp duty, or Notary fees balance (if prepaid). If insufficient, Notary/Lawyer/Law Firm will have to purchase correct prepaid balances.

6. On receipt of items, Client name, id & signature (Optional) are captured for inclusion in the Notarization log as evidence of receipt.

7. Agent enters batch submission number and Matter ID into system to identify requested work and marks notarization case(s) as received.

8. Agent notifies client where case documents are missing.

9. If all is in order, document(s) are scanned and uploaded to case (optional). 10. Administrative agent/lawyer selects the opinion depending on type of document and user's choice.

I 1. An output template of opinion document(s) is automatically generated for each case, which can be printed by agent.

12. If client has to be present, administrative agent fixes a time between client and Notary.

13. Case is routed to Notary/lawyer's work queue. Notary/lawyer is also notified of case for processing.

14. Notary modifies opinion template if required, checks the documents and executes notarization (If required, Multiple Signing process can be used). - -

15. Notary opinion is printed.

16. Notary's account is debited for the Notarized documents or Notary invoice is generated by system which can be sent to Notary Agent.

17. The system automatically logs details to the Notary log. Client name, id & signature are also captured in the Notary log as evidence of delivery.

18. Notary invoice is generated by system which can be sent to Notary Agent

19. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that.

20. Once all the cases are processed, Batch is marked as complete.

User uploads document (Electronic Opinion):

1. User logs into the system and creates a batch submission number.

2. User inputs all fields required for creating each case (notarization). Related document(s) are scanned and uploaded to the case. 3. System seals the documents, applies required IRM Protection and sends document's link to the user.

4. System checks if Notary/Lawyer/Law Firm has sufficient prepaid stamp duty or Notary fees balance (if prepaid). If insufficient, Notary/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise: 5. Administrative agent is notified of case for processing.

6. Administrative agent receives a case in his/her work queue and assigns Matter ID.

7. Administrative agent selects the opinion depending on type of document and user's choice. 8. An output template of opinion document is automatically generated for each case, which can be printed by agent.

9. If client has to be present, administrative agent fixes a time between client and Notary.

10. Case is routed to Notary/lawyer's work queue. Notary/lawyer is also notified of case for processing.

11. Notary modifies opinion template if required, checks the documents and executes notarization (If required, Multiple Signing process can be used).

12. Electronic output PDF containing notarized documents which can be mailed to the recipients is created by the system. - -

13. End user reconfirms list of receiving user & IRM preferences, (see IRM preferences discussed above)

14. Document is mailed or a link is sent from where it can be downloaded. An entry is automatically made to notary log. 15. Notary's account is debited for the Notarized documents or Notary invoice is generated by system which can be sent to Notary Agent.

16. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that.

17. Once all the cases are processed, Batch is marked as complete.

System certified document (Electronic certification):

1. User selects document to be notarized. A batch and its case (notarization) are created into the system (Matter ID previously assigned).

2. Original document is automatically extracted if it is IRM protected. 3. System checks if Notary/Lawyer/Law Firm has sufficient prepaid stamp duty or Notary fees balance (if prepaid). If insufficient, Notary/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise:

4. Agent in notified of case for processing

5. Administrative agent receives a case in his work queue 6. Administrative agent selects the opinion depending on type of document and user's choice.

7. An output template of opinion document is automatically generated for the agent, which can be printed by agent.

8. If client has to be present, administrative agent fixes a time between client and Notary.

10. Notary modifies opinion template if required, checks the documents and executes notarization (If required, Multiple Signing process can be used). 11. Electronic output PDF containing Apostille which can be mailed to the recipients is created by the system.

12. End user reconfirms list of receiving user & IRM preferences.

13. Document is mailed or a link is sent to recipients as to where it can be downloaded. An entry is automatically made to Notary log. - -

14. Notary's account is debited for the Notarized documents or Notary invoice is generated by system which can be sent to Notary Agent.

15. If document is also to be Apostilled, a new case for Apostilling is created automatically by the system and moved to Apostille Agents work queue. 16. Notarization case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 17. Once all the cases are processed, Batch is marked as complete.

Oath User walks-in (Manual Opinion):

2. User supplies hard copy of document(s) to administrative agent.

3. From system, administrative agent selects name of client, payee number and raises a request for Oath. A batch is created into the system.

4. For each document to be sworn, agent adds a case, together with relevant details, including Matter ID, and uploads corresponding document(s).

5. System checks if Oath Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Oath fees balance (if prepaid). If insufficient, Oath Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise:

6. An output template of document(s) to be sworn is automatically generated for each case, which can be printed by agent.

7. Administrative agent fixes a time between client and Oath agent.

8. Case is routed to Oath agent's work queue. Oath agent is also notified of case for processing.

9. Oath agent checks the documents and asks the affiant if they affirm/swear that contents of the document are true and correct to the best of their information, knowledge and belief.

10. If yes, Affiant also needs to sign document along with Commissioner for Oaths. Oath is printed (see manual print output option described above; if required, the Multiple Signing process described above can be used).

11. If no, cannot proceed further.

12. Oath Agent's account is debited for the sworn documents or Oath invoice is generated by system which can be sent to Oath Agent. - -

13. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that.

14. Once all the cases are processed, Batch is marked as complete.

User couriers document (Manual Opinion):

1. User logs into the system, raises a request for oath, and a batch submission number is created.

2. User inputs all fields required for creating each case.

3. A submission receipt is generated for the user indicating batch submission number, case numbers and other details. Administrative agent in notified of case for processing.

4. User prints submission receipt and couriers it along with documents which need to be sworn/ affirmed.

6. Administrative Agent enters batch submission number and Matter ID into system to identify requested work and marks case(s) as received.

7. In case a document is missing, agent notifies client where case documents are missing.

8. If all is in order, document(s) is scanned and uploaded to cases.

9. An output template of sworn document(s) to be sworn is automatically generated for each case, which can be printed by agent.

10. Administrative agent fixes a time between client and Oath agent. 11. Case is routed to Oath agent's work queue. Oath agent is also notified of case for processing.

12. Oath agent checks the documents and asks the affiant if they affirm/swear that contents of the document are true and correct to the best of their information, knowledge and belief. 13. If yes, Affiant also needs to sign document along with Commissioner for

Oaths. Oath is printed (If required, Multiple Signing process can be used).

14. If no, cannot proceed further.

15. Oath Agent's account is debited for the sworn documents or Oath invoice is generated by system which can be sent to Oath Agent. - -

17. Once all the cases are processed, Batch is marked as complete.

User uploads document (Electronic Opinion):

1. User logs into the system and creates a batch submission number.

2. User inputs all fields required for creating each case. Related documents are scanned and uploaded to cases.

4. System checks if Oath Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Oath fees balance (if prepaid). If insufficient, Oath Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise:

5. Administrative agent in notified of case for processing. 6. Administrative agent receives a case in his/her work queue and assigns Matter ID.

7. An output template of sworn document(s) to be sworn is automatically generated for each case, which can be printed by agent.

8. Administrative agent fixes a time between client and Oath agent. 9. Case is routed to Oath agent's work queue. Oath agent is also notified of case for processing.

10. Oath agent checks the documents and asks the affiant if they affirm/swear that contents of the document are true and correct to the best of their information, knowledge and belief. 11. If yes, Affiant also needs to sign document along with Commissioner for Oaths. Electronic output PDF containing sworn documents which can be mailed to the recipients is created by the system (If required, Multiple Signing process can be used).

12. If no, cannot proceed further.

13. End user reconfirms list of receiving user & IRM preferences. 14. Document is mailed or a link is sent from where it can be downloaded.

15. Oath's account is debited for the sworn documents or Oath invoice is generated by system which can be sent to Oath Agent.

16. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. - -

17. Once all the cases are processed, Batch is marked as complete.

System certified document (Electronic certification):

1. User selects document(s) to be sworn. A case is created into the system (Matter ID previously assigned).

2. Original document is automatically extracted if it is IRM protected.

3. System checks if Certification Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Certification fees balance (if prepaid). If insufficient, Oath Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise: 4. Administrative agent receives a case in his work queue. Administrative Agent is notified of case for processing.

5. An output template of opinion document is automatically generated for the agent, which can be printed by agent.

6. Administrative agent fixes a time between client and Oath Agent. 7. Case is routed to Oath agent's work queue. Oath agent is also notified of case for processing.

8. Oath agent checks the documents and asks the affiant if they affirm/swear that contents of the document are true and correct to the best of their information, knowledge and belief. 9. If yes, Affiant also needs to sign document along with Commissioner for Oaths. Electronic output PDF containing sworn documents which can be mailed to the recipients is created by the system (If required, Multiple Signing process can be used).

10. If no, cannot proceed further.

11. End user reconfirms list of receiving user & IRM preferences. 12. Document is mailed or a link is sent from where it can be downloaded.

13. Certification's account is debited for the certified documents or Certification invoice is generated by system which can be sent to Certification Agent.

14. If document is to be notarized, a new case for Notarization is created automatically by the system and moved to user's work queue. 15. Oath is marked as complete. Batch is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 16. Once all the cases are processed, Batch is marked as complete. - -

Certification

User walks-in (Manual Opinion):

1. If user doesn't exist in system, administrative agent can register him/her as a client. 2. User supplies hard copy of document(s) to administrative agent.

3. From system, administrative agent selects name of client, payee number and raises a request for Certification. A batch is created into the system.

4. For each document to be certified, agent adds a case, together with relevant details, including Matter ID, and uploads corresponding document (optional). 5. System checks if Certification Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Certification fees balance (if prepaid). If insufficient, Certification Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise: 6. Administrative agent selects opinion depending on type of document and user's choice. 7. An output template of opinion document(s) is automatically generated for each case, which can be printed by agent.

8. If client has to be present, administrative agent fixes a time between client and certifying authority.

9. Case is routed to Certification Agent's work queue. The Certification Agent is also notified of case for processing.

10. Certifying Agent modifies opinion template if required, checks the documents and certifies the document. During certification, depending on capacity of signatory, certifying authority may need to affix Company seal to document (If required, Multiple Signing process can be used). 11. Certification page is printed (see manual print output option described above).

12. The system automatically logs details to the Certification log. Client name, id & signature are also captured in the Certification log as evidence of delivery.

13. Certification Agent's account is debited for the certified documents or certified invoice is generated by system which can be sent to Certification Agent. 14. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 15. Once all the cases are processed, Batch is marked as complete. - -

User couriers document (Manual Opinion):

1. User logs into system, raises a request for certification, and a batch submission number is created.

2. User inputs all fields required for creating each case. 3. A submission receipt is generated for the user indicating batch submission number, case numbers and other details. Administrative agent is notified of case for processing.

4. User prints submission receipt and couriers it along with documents which need to be certified. 5. System checks if Certification Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Certification fees balance (if prepaid). If insufficient, Certification Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise: 6. On receipt of items, Client name, id & signature of delivering person (Optional) are captured for inclusion in the certification log as evidence of receipt. 7. Agent enters batch submission number and Matter ID into system to identify requested work and marks case(s) as received.

8. Agent notifies client where case documents are missing.

9. If all is in order document(s) are scanned and uploaded to cases (optional).

10. Administrative Agent/certifying authority selects the opinion depending on type of document and user's choice.

11. An output template of opinion document(s) is automatically generated for each case, which can be printed by agent.

12. If client has to be present, administrative agent fixes a time between client and certifying authority. 13. Case is routed to Certifying Agent's work queue. Authority is also notified of case for processing.

14. Certifying authority modifies opinion template if required, checks the documents and certifies the document. During certification, depending on capacity of signatory, certifying authority may need to affix Company seal to document (If required, Multiple Signing process can be used).

15. Certification page is printed.

16. The system automatically logs details to the Certification log. Client name, id & signature are also captured in the Certification log as evidence of delivery. - -

17. Certification Agent's account is debited for the certified documents or certified invoice is generated by system which can be sent to Certification Agent.

18. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that. 19. Once all the cases are processed, Batch is marked as complete.

User uploads document (Electronic Opinion):

1. User logs into the system and creates a batch submission number.

2. User inputs all fields required for creating each case. Related document(s) are scanned and uploaded to cases.

4. System checks if Certification Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Certification fees balance (if prepaid). If insufficient, Certification Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise:

5. Administrative agent is notified of case for processing.

7. Administrative agent selects the opinion depending on type of document and user's choice.

8. An output template of opinion document is automatically generated for each case, which can be printed by agent.

9. If client has to be present, administrative agent fixes a time between client and certifying authority. 10. Case is routed to authority's work queue. Authority is also notified of case for processing.

11. Certifying authority modifies opinion template if required, checks the documents and certifies the document. During certification, depending on capacity of signatory, certifying authority may need to affix Company seal to document (If required, Multiple Signing process can be used).

12. Electronic output PDF containing certified documents which can be mailed to the recipients is created by the system (see electronic output option described above).

13. End user reconfirms list of receiving user & IRM preferences. - -

14. Document is mailed or a link is sent from where it can be downloaded. An entry is automatically made to certification log.

15. Certification Agent's account is debited for the certified documents or certified invoice is generated by system which can be sent to Certification Agent. 16. Case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that 17. Once all the cases are processed, Batch is marked as complete.

System certified document (Electronic certification): 1. User selects document to be certified (i.e. were signed in system). A case is created into the system.

2. Original document is automatically extracted if it is IRM protected.

3. Agent in notified of case for processing.

4. Administrative agent receives a case in his work queue and assigned Matter ID.

5. System checks if Certification Agent/Lawyer/Law Firm has sufficient prepaid stamp duty or Certification fees balance (if prepaid). If insufficient, Certification Agent/Lawyer/Law Firm will have to purchase correct prepaid balances. Otherwise:

6. Administrative agent selects the opinion depending on type of document and user's choice.

8. If client has to be present, administrative agent fixes a time between client and certifying agent. 9. Case is routed to Certifying Agent's work queue. Certifying Agent is also notified of case for processing.

10. Certifying Agent modifies opinion template if required, checks the documents and certifies the document. During certification, depending on capacity of signatory, certifying authority may need to affix Company seal to document (If required, Multiple Signing process can be used).

11. Electronic output PDF containing certified document which can be mailed to the recipients is created by the system.

12. End user reconfirms list of receiving user & IRM preferences. - -

13. Document is mailed or a link is sent to recipients as to where it can be downloaded. An entry is automatically made to Certification log.

14. If document is to be notarized, a new case for Notarization is created automatically by the system and moved to user's work queue. 15. Certification Agent's account is debited for the certified documents or certified invoice is generated by system which can be sent to Certification Agent.

16. Certification case is marked as complete. It remains active for a specified period (Default 30 days), and is closed & archived after that.

17. Once all the cases are processed, Batch is marked as complete.

User Management

User classification - User management involves user creation, deletion, modification & suspension. These operations have been grouped in two categories, ones for which approval is required, and other which don't require external approvals. Third party approval required - workflow based:

• Managing notary and legal certifier agents

• Managing non- legal certifiers

• Managing client (End-user) - corporate & individual

No third party approval required - self registration (internal):

• Managing Apostille agents

• Managing agent assistant - NOC (no ability to approve)

• Assignment of agents to company for NOC, Government, etc.

User creation - Notary & legal certifier registration:

1. The entire registration process is preferably modelled in workflow and deployed as a 5 step process.

2. On application submission, case is created with form data and submitted documents and notary is returned a registration number.

3. Account is created with status as "Verification in progress".

4. Applicant performs an e-mail validation - -

5. Once e-mail validation is done, validation of other particulars and documents are done by authorized agency.

6. Documentation supporting validation/qualification are uploaded to system.

7. The person who records the signatures in the next step will have to check all the required items displayed in a confirmation checklist after which he can proceed to the next step. The checklist also includes signing of affidavit.

8. For registering signatures, notary will be invited to court, where he records his specimen signatures

9. Status is changed to active, and notary is notified for the same. 10. At any instant, notary could enquire status of his request using registration number.

11. The fields used for notary creation may include name, address, passport details, date notary commission expires and other relevant data.

User creation - Client registration

2. On application submission, case is created with form data and submitted documents and user is returned a registration number. 3. Account is created with status as "Verification in progress".

4. Applicant performs an e-mail validation

5. Once e-mail validation is done, validation of other particulars and documents are done by authorized agency

6. For document verification, user is invited by authorized agent with original documents to confirm if particulars submitted are correct or not.

7. Status is changed to active, and user is notified for the same

8. At any instant, user could enquire status of his request using registration number.

9. The information used for Client/End User creation may include name and address details and any other relevant personal information; declarations as to prior convictions, bankruptcies or the like; and any other relevant information

User Deletion - Notary deletion

1. Notary can be deleted in following cases: - -

a. Cease to be resident in relevant jurisdiction b. Expelled by Court. c. Terminated by service provider for non-payment (in case of law firm) d. Should track date deleted to ensure no opinions occur thereafter. 2. Notary Administrator is authorized to delete a Notary

End user deletion:

1. End user can be deleted in following cases: a. Cease to be resident in relevant jurisdiction b. Terminated by law firm c. Should track date deleted to ensure no activities occur thereafter.

Corporate account deletion:

1. Corporate account can be deleted in following cases: a. Cease to be resident in relevant jurisdiction b. Terminated by law firm c. Terminated by service provider for non-payment (in case of law firm) d. Should track date deleted to ensure no activities occur thereafter.

2. In case corporate is deleted, all user accounts which belong to the said corporate are also be removed.

User Modification - The following operations for different users require a re- verification process. Other attributes can be modified without approval.

• Notary: Change in email id; Change in qualification document; Change in signature; Change in billing details.

• End user: Change in primary email id; Change in billing details; Change in identity proof.

• Corporate: Change of administrator; Change in billing details.

Billing and Payments

Generally, billing occurs at two levels: a. On behalf of clients to End Users - -

b. To Client for use of e-CANOC system

In one embodiment of the system, the system only bills End Users for Apostille services. For all other Services, the Agents bill and collect from End Users. Billing for both End Users and Clients can be either satisfied on a Prepaid or Post paid basis, to allow for the mitigation of credit risk.

Apostille Billing and Payment methods - Individual:

• User prepays Government Revenue at Revenue Collection Department (using generic prepaid A/c No.) • A receipt is issued.

• Documents & payment receipt are submitted when applying for Apostille

• Apostille agent processes the request and keeps receipt number as payment record (enter receipt details in system).

Payment methods - Agents and Corporate:

• Corporate Agents or NOC Agents can pre-pay Government Revenue and Stamp Duty amount at Govt. Cashiers (Revenue Collection System).

• Collection records are updated daily in e-CANOC system at the end of each day (Account number and prepaid amount) • In e-CANOC system, Corporate Agents or NOC Agents account are debited

(decremented) for each Apostilles, Notarisation, Oaths and Certification processed.

• When Corporate or NOC Agent's account balance reaches a minimum threshold, notification is sent to replenish.

• Monthly statement is sent to corporate on their usage (by email or online).

Integration with a Revenue Collection System is illustrated in Figure 7.

Internal billing: Fees may be charged by the service provider (i.e. the entity providing the document verification system for use by the various types of user) for using the e- CANOC system, which is referred to herein as "internal billing". The service provider may charge customers of e-CANOC system on pay as you go basis. Internal Fees are preferably not charged to End User requesting Apostille/ Notarization/ Oath/ Certification, unless they are one in the same. Fees may be charged from individual - -

agents/ designated corporate authorities for the Apostille, Notarization, Oath, and Certification services. Features of internal billing include:

• Billing can occur at the transaction level of fixed or flat fee.

• Each country may have its own rates for different process. This rate can be set by e-CANOC administration.

• System may have ability to bill items in group or individually.

• System may also be able to consolidate billing clients that represent different segments. For example, a corporate client (law firm).

• Individual agents/ designated corporate authorities can log in to system, and make the payments for transactions that they have already performed or to prepay an amount. This may be achieved by integration with EFT and/or payment gateways.

• A batch being billed preferably has at least the following fields: Completion/Processed date; service provider case number; service provider client number; Client/matter number - Internal to client system; Sub-matter number (If applicable); Service provider Rate; Number of transactions; Service provider Fee

• System can provide billing file (Fixed format CSV file) which can be imported into client's systems, e.g. to facilitate charges to End Users.

• Individual/company can preferably view their statement online.

• An open source billing engine may be used to keep TCO low.

The Billing Engine may provide some or all of the following features:

• Customer DB - Underlying engine can have its own repository of customers or e-CANOC system's user repository can be integrated.

• Items - Services provided can be added as items & assigned the price. • Flat or fixed pricing - System can bill static types fees, i.e. administrative and other fixed based fees unrelated to transaction volumes.

• Pricing Plans/packages - Can define and apply pricing plans, including tiered pricing

• Billing templates - Customizing logos & other information. • Invoice generation - Can be automatic/manual.

• Billing Cycle - Billing cycle may be configurable. System can preferably handle recurring billing. - -

• Prepaid facility - Support prepaid payments; and decrement accounting for prepaid amounts.

• Billing invoices - Print/ email/ online invoices may be supported.

• Billing and Balance Updates - Billing and adjustment may occur in real-time and/or in batch.

• Billing Updates - Customer may be able to submit billing detail updates for routing to appropriate personnel for review and update.

• Payments methods - Cheques, EFT, cash, credit cards can be supported. Payment options can be configured. • Reports - System can provide reports for each customer, accounts reports.

• Notification - Notifications to customers can be configured, e.g. prepaid balance has reached min threshold, due date reminder notification, late fee etc.

• Integration with Payment Services - Billing software can be integrated with payment services. • Incorporate the Business Rules - Incorporate Business rules, e.g. include VAT and discounts in the Total amount.

• Multilanguage - localization from a language perspective.

• Localization (multi-currency) - can bill each country in their respective currency. • If credit cards details are stored - regulatory compliance may be required.

• Chaining Customer - System may provide flexible hierarchy of customer, i.e. parent subsidiary relationship to chain billing together to account for different department, division or geographical elements of one customer.

• Flat transaction Pricing - Flat or fix transaction pricing can be available. • Tiered Pricing - Pricing is preferably flexible and may provide for tier transaction pricing based on volume.

User Interfaces

User interfaces preferably provide • Intuitive screen layouts

• Input validation

• Navigation bars on each page to facilitate movement within the application

• 'Single click' actions - -

• Icon shortcut tool bars are used where appropriate

• Drop down lists are used where appropriate

• Page scroll bars

• The ability to change text size • Color contrast optimized for maximum legibility.

• If a keyboard is unavailable, the arrow keys can be used for controlling the cursor position and the 'Enter' key will operate as 'single click'

Security Security is an important aspect of the e-CANOC portal as the system contains customer data, their legal & important documents.

Network Security - SSL/ TSL may be used for encrypted communication between client and server. A firewall may be deployed preventing direct access to all backend systems.

Data Security - Document data can be encrypted before storing. Oracle IRM is used to ensure that users can perform only designated operations on a document. Oracle IRM Protection is preferably applicable both within the system and outside it. Evident e- sealing technology is used to ensure document integrity.

Application Security - To minimize security flaws at the application level, some or all of the following features may be provided:

1. Input validation may remove all known malicious characters that are not needed for business use to help minimize session poisoning, SSI Injection flaws.

2. Whenever a document is being uploaded, it may be checked for malware / viruses. A Captcha test (a type of challenge-response test) may be used to ensure that the response is not generated by a computer. The size of a document is preferably not more than a specified limit 3. Password is preferably not stored in plain text, instead, a hashing algorithm such as MD5 or SHA-256 will create a signature of the password for storage. 4. Use of generic invalid credential message like "Invalid username/ password" "Authentication Failed", avoiding specific messages like "Invalid username" OR "Invalid Password". - -

5. Random Session IDs Session identifiers may be created using cryptographically Strong Number Generators.

6. For Session Fixation attack prevention, Authenticated Session Refresh may be put in place to provide a new authenticated session identifier after the user authenticates. This session identifier is different from the one used to prior to authentication.

7. When a session is given to a client it is preferably ensured by the server that the session is coming from the same address (IP) to which had been provided the session. 8. Secure Cookies containing authenticated session identifiers preferably include the secure and HTTP Only tags.

9. Cookies may be sent over an encrypted channel (e.g. SSL).

10. Sensitive data such as password, username etc. is preferably not stored in the cookies. 11. XML Bounds Checking - Every XML element preferably has a pre-defined maximum character length defined. Additionally, a maximum size for the entire

SOAP message may be enforced by the server.

12. Generic SOAP faults - detailed exception messages are not included in SOAP faults. Instead, generic messages are sent. 13. A Data access controller may be used to limit access to unauthorized data,

URL.

Server-side Security - Some or all of the following features may be provided: 1. Database connection pooling may be used to ensure availability. 2. Secure socket layer (SSL) may be used for encrypted communication between client and server.

3. Encrypted database passwords - password used for database connection strings may be stored in encrypted format.

4. Database administrator preferably ensures database server software is up-to- date.

5. System may ensure latest third party application security patches have been installed. - -

User Authentication - A risk based authentication system may be used, having the following characteristics:

1. Five Authentication Levels from 1 to 5 are defined and may be used depending on the Level of Risk of any Transaction.

2. Each increasing Level of Authentication is preferably applied only if the previous Level of Authentication has been passed successfully.

3. Following are the five levels of authentication in ascending order of risk: Level 1 : Login Password: A login User Id and password.

Level 2: Transaction Password: Required for key operations like document upload.

Level 3: Grid Authentication: User is supplied with a grid at the time of user registration, for example:

A B C D E F G

12 32 43 54 63 43 27

H I J K L M N

62 19 76 87 90 40 93

While performing key operations, user is asked to supply transaction password.

If the transaction password is correct, three fields are chosen from grid at random, and user is asked to supply numbers for those fields (e.g. C, F, K)

Level 4: Knowledge Based Authentication: Allows the system to question the user about user details obtained during the user registration process to confirm his authenticity like Passport Number, Date of Birth etc.

Level 5: Out-of-band Authentication: System generates a unique authentication code and sends it to user via email. This is entered by the user when a transaction is to be processed.

4. A Default Required Authentication level may be assigned to each operation being performed through the system. For example:

- -

5. By default, all normal operations are preferably assigned an Authentication level from 1-3.

6. Certain operations which occur in exceptional scenarios may be assigned Authentication Level 4 (or higher), for example "First Time Login" and "First Login after Transaction Password Reset"

In case an Intrusion detection system (IDS) detects unwanted attempts at accessing the authentication level of a particular operation, the system might increase the required authentication level or terminate the session. Cases such as requests received from an unrecognized IP addresses may be handled by the system by either raising authentication level or session termination.

Opinion Templates

Opinion templates are provided by the system for the notary or other verifying agent to complete and apply their signature or seal to. Examples of templates are shown in Figures 8A - 8F.

An Apostille template is shown in Figure 8A. Narrative for the Apostille opinion is dynamically generated based on Notary information. However, the Apostille agent can edit this information. Different types of notarization template are shown in Figures 8B - 8D. For All Notary Certifications/Opinions, a text block is included, stating, "My Commission does expire on [date]" or "My Commission does not expire". Two types of certification template (one for companies and one for individuals) are shown in Figures 8E - 8F.

System Architecture

The system architecture of the example embodiment will now be described. The architecture is shown in Figure 9. The architecture and implementation details (such as specific technologies and products used) are given purely by way of example, and many other implementations of the system are possible. - -

Business layer components

Eight different components are provided in the business layer. Each component may interact with external subsystems like jBPM (Java business process management), jBilling, and IRM, etc. Each Component is represented by Interfaces. One Interface may communicate to other Interfaces. Communicating Interface may be present at same component or different components. Business layer components are listed below with a description of their functionality.

Billing Module. This module provides the following: a) Import of payment information received from Revenue collection system. b) Invoice generation and billing for Revenue Stamps and Apostille Service fees, i.e. billing on behalf of clients (government). c) Invoice generation and payment for post-paid/pre-paid internal billing, i.e. service provider billings to clients.

User and Rights Management. This module performs the required level of user authentication for the operation being performed and determines user categories and access control information. This system is integrated through Alfresco to the LDAP server for user authentication. This module acts as the user/corporate entity management system. The user/ corporate entity creation, deletion, modification and suspension is handled by this system.

CMS & Workflow Component. The core process flow integration with jBPM is performed by this module. Starting/Stopping/Cancellation/Re-assignment of e- CANOC processes are the responsibility of this module. Tracking the status of the processes is also part of the same. Alfresco CMS integration is performed using this module. This component also interacts with the following modules:

• User and Rights Management - To manage rights/roles on stored content • Utility component - For general system wide operations

• Auditing Component - To generate comprehensive log of electronic data being processed

• System Component - To manage system configuration. - -

• Document Validation & Security (Internal)

CMS is invoked using the Repository Foundation Services or Web Services exposed by Alfresco. Workflow is invoked using the Java APIs provided by jBPM.

Utility component. This component contains generic frequently used utility functions like PDF generation etc. Other services can call this module for various features.

Document validation & Security. Oracle IRM along with an LDAP compliant Directory Server & Entrust Identity Guard are used to ensure that users can perform only designated operations on documents. Oracle IRM Protection is applicable both within the system and outside it. This module is used for writing wrapper APIs used to call the external Evident and Oracle IRM sub-systems. Oracle IRM is invoked using its Web Services. Evident is used to facilitate sealing of transaction data which can be later used as long-term independently verifiable evidence.

System Component. The System component is used to load/manage the system configuration and property information. This module is called either during system deployment or during administrative operations.

Auditing Component. This module is used to perform Auditing of all required information related to the processes being executed by/in the system. This will also retrieve the Auditing information from the various sub-systems to provide an integrated Audit Log.

Reporting Component. This module exposes services for creating charts and reports. Java APIs exposed by Jasper Report and Jfreecharts are used. Preferably, this component does not integrate to any of the subsystems.

External components

External components used by the system will now be described.

Oracle IRM. Oracle IRM is used to ensure that users can perform only designated operations on the documents. Oracle IRM Protection is applicable for documents - -

present both within the system and outside it. This interacts with LDAP compliant Directory Server to authenticate the user to allow him his requested operation on the document.

Evident. Evident is used using the SAAS Model to facilitate sealing of document data which can be later used as independently verifiable evidence. The Evidence SDK APIs compatible with Java and Red Hat Linux are used to implement document validation functionality in the e-CANOC system. The Evident seal is kept with the document to prove: • That the data has not been changed since originally sealed, i.e. what is in the document

• Who requested the data to be sealed

• When - timestamp of sealing the data

• Applicable evidence meta-data, i.e. the parties involved with execution of the document and their capacity.

jBilling. jBilling Engine is used to estimate and generate invoices for e-CANOC services and make online payments. It is invoked by billing module using Java APIs.

Alfresco CMS/jBPM Workflow. Alfresco is an open source Enterprise Content Management System (CMS), primarily implemented in Java. The extensibility and configurability is achieved in Alfresco using the Spring Framework. jBPM workflow engine embedded into Alfresco CMS is used to provide Workflow. The e-CANOC system uses Web Services or Foundation Services to interact with Alfresco.

LDAP compliant directory server. An LDAP (Lightweight Directory Access Protocol) compliant Directory server will be used to store User and Group credentials as well as to provide a first factor authentication.

Secure ID Authentication System. Entrust's Identity Guard is the secure ID Management system used to provide grid based Multi-Factor Authentication. This IS configured to be used with the LDAP compliant Directory Server for Authentication. - -

User Interface

Sample user interface screens are shown in Figures 10 - 18. These show various screens used, for example, by an Apostille agent in processing an Apostille request.

A Login Screen/Home Page is shown in Figure 10. Preferably, there is a main home screen in which user can select the type of operation that he wants to perform (Apostille or Notarization or Oath or certification). Depending upon what he selects from this screen, the corresponding operation's login screen is displayed to him/her.

An Agent Main Page is illustrated in Figure 11. This also provides a general template for many of the interface screens after login.

A screen for New User Registration by Agent (upper half of the screen) is shown in Figure 12. The corresponding lower half of the screen is shown in Figure 13.

A screen for Batch Creation is shown in Figure 14. IRM Parameters may be taken as input either on this screen or on a separate screen. User type - whether manual or electronic may also be captured here.

An Agent's "My Queue" screen, showing a work queue, is shown in Figure 15. Different action icons are preferably shown for different operations (e.g. Apostille, Notarization, Oath, Certification).

Figure 16 shows a screen where the Agent starts the Apostilling process. Figure 17 illustrates the Agent applying Seal and Stamp. Figure 18 illustrates the completion of the Apostille process.

Figures 19 to 25 are user interface flow diagrams for the interface elements implementing various processes. The Home Page interface flow is illustrated in Figure 19. The Work Queue Page is illustrated in Figure 20. While defining the batch, User type - whether manual or electronic, may also be captured. The Administration interface is illustrated in Figure 21. Update user profile functionality will allow administrator to remove a NOC (notary/oath/certification) agent from set corporate. - -

The Events Page (for the events calendar) is illustrated in Figure 22. Figure 23 illustrates the Collaboration Page (multiple signing). The Reports Page of the interface is illustrated in Figure 24. A "My Account" Page for managing a user's account details is illustrated in Figure 25.

Internal system specification

The system interface design is illustrated in Figures 26 A - 26B. A class-relationship diagram for the system design is illustrated in Figures 27 A - 27C.

Figure 28 is a system deployment diagram, illustrating hardware components for a deployment of the system. In this embodiment, the deployment has the following features:

1. e-CANOC system is deployed on three boxes, having following subsystems/components : a. UI components, e-CANOC business layer, Alfresco CMS, Workflow & Billing Engine b. Database server c. Oracle IRM, ID management system, Directory server 2. Additionally, SAN (storage area network) boxes are provided on which actual documents are stored. Documents can be archived to an external storage device as and when required.

3. Clustering is available on e-CANOC box (Active- Active) & database server

(Active-Passive). This caters to both failover and load balancing support. 4. System is designed to allow the components to be divided further onto different servers with minimal changes (say by changing configuration settings), to enable alternative deployments.

5. Directory server used is MS Windows Active Directory server

The e-CANOC system is preferably developed using the Seam framework since:

1. Open source development platform for building rich Internet applications in Java.

2. It provides multi browser support.

3. It has powerful integration with jBPM - -

4. Well integrated with technologies such as AJAX, JSF, and EJB 3.0.

The development environment may use a variety of technologies, such as Eclipse IDE, JBoss AS (J2EE App Server), Java from Sun Microsystems, Rich faces (UI framework), middle tier: EJB 3.0 (Enterprise Java Bean) + JBoss Seam; Hibernate (ORM); PostgreSQL (Database management system).

Certification examples

The document being verified can be sealed using Evident seals including a date/time stamped algorithm or hash which can also capture and embed fingerprints, retinal scans or any type of biometric data that is desired to be included in the algorithm about the signing party. Then that document can be further certified and sealed (including a date time stamped algorithm and biometric data). This can then be layered by the next document such as a notarial certificate which can be sealed embedding biometric data about the notary and then another such as an apostille giving details about the apostilling agent and when, where and how signed, or a consular stamp and signature. Each layer has data about when where and how it has been signed and if any seal at any level is broken then validation cannot take place. If you cannot validate the document you cannot rely upon it and the process must begin again from the first document in order to claim that the documents are all authentic and can be relied upon. The documents come together in the end to form one document with multiple sealing events in it and can't be pulled apart, thus, they have been electronically grommeted together.

For example, the documents relating to a Secretarial certificate, say, a Certificate of Incorporation, Memorandum of Association and Bye laws of a company have been scanned through a scanner and put in PDF format or typed out in a word processor. Each document can be uploaded into the management system from a computer's drive let's say, for example, the C: drive. These documents are referred to in the Secretarial certificate that has been prepared in the system and signed in the system and then sealed. The document is now in the system as a signed and sealed Secretarial Certificate. The notary can then attest to the fact that he or she has witnessed the Company Secretary sign the document in their presence. The Notarised document can - -

then be sent via the system to be Apostilled by the Apostilling agent. At each step the time and date and bio metric information of the signing party can be captured and embedded in the document as proof that the parties are who they say they are so the chance of falsification or fraud is greatly reduced when compared with what takes place today in the paper or manual world.

Another application in which the system can be employed is a de facto trust arrangement whereby the resultant document (e.g. constitutional documents that have been certified by the Company Secretary, notarized and apostilled) can be stored offline and upon request from a third party, such as, a bank or law firm requesting "Know your client" information about the company. The information can be released to the requesting party once the authorizing party has given its consent/approval to release the information held offline to the requesting law firm or bank.

Media files can also be certified, sworn, notarized apostilled and consularised using the described system.

It will be understood that the present invention has been described above purely by way of example, and modification of detail can be made within the scope of the invention.

Claims

- -CLAIMS

1. A method of verifying documents using an electronic document verification system, comprising: sending, from a first terminal client, a verification request to a verification server; creating a verification transaction entry in a database associated with the verification server; receiving at least one electronic document to be verified; transmitting the document to a verifying user at a second terminal client; receiving verification confirmation from the verifying user at the second terminal client; generating an electronic verification confirmation document; and outputting the electronic verification confirmation document.

2. A method according to claim 1, comprising retrieving the document to be verified from an electronic document repository associated with the system, preferably wherein the verification request comprises information identifying the document to be retrieved.

3. A method according to claim 1, wherein receiving at least one document comprises uploading an electronic document from the first terminal client to the verification server or a document upload server associated with the verification server.

4. A method according to claim 1, wherein receiving comprises digitally imaging a paper document.

5. A method according to claim 3 or 4, comprising storing the received document in an electronic document repository associated with the verification server or document upload server.

6. A method according to any of the preceding claims, comprising associating information rights management information with the received document. - -

7. A method according to any of the preceding claims, comprising associating information rights management information with the electronic verification confirmation document.

8. A method according to claim 6 or 7, wherein information rights management information is usable to control access to and/or use of the document, preferably to restrict document actions to specified users or groups of users, the actions preferably including one or more of: viewing, editing, and printing the document.

9. A method according to any of the preceding claims, comprising generating an electronic tamper-proof seal for the received document or for each of a plurality of received documents.

10. A method according to any of the preceding claims, comprising generating an electronic tamper-proof seal for the verification confirmation document.

11. A method according to any of the preceding claims, comprising performing verification for a group of documents, and generating a group electronic tamper-proof seal for the group of documents.

12. A method according to claim 11, comprising further generating a respective individual electronic tamper-proof seal for each document in the group, preferably wherein the group seal is generated for a collection of files including one or more of: the documents in the group; one or more verification confirmation documents generated for one or more documents in the group; and individual tamper-proof seals for the documents and/or verification confirmation documents.

13. A method according to any of claims 9 to 12, wherein generating an electronic tamper-proof seal comprises generating an electronic seal file to be associated with a document or group of documents, preferably comprising performing a hash operation on the document or file or group of documents or files to be sealed and storing the result of the hash operation in the electronic seal file. - -

14. A method according to any of the preceding claims, comprising applying a digital signature and/or a digital seal of the verifying user to the electronic verification confirmation document.

15. A method according to any of the preceding claims, wherein verification comprises at least one of: legalising the document or providing an Apostille certificate for the document; notarizing the document; certifying the document; and taking an oath in respect of the document.

16. A method according to any of the preceding claims, wherein outputting comprises printing the electronic verification confirmation document.

17. A method according to any of the preceding claims, wherein outputting comprises electronically transmitting the verification confirmation document to at least one recipient.

18. A method according to claim 17, comprising receiving from the first terminal client a selection of at least one recipient, the selection preferably included in the verification request, and transmitting the verification confirmation document to each selected recipient.

19. A method according to any of the preceding claims, comprising providing a verification confirmation template to the verifying user and, in response to receiving verification confirmation from the verifying user, generating the verification confirmation document based on the template.

20. A method according to claim 19, wherein the template is selected from a plurality of stored templates, preferably wherein the template is populated with data, preferably data from the verification request or database or data stored locally at the verifying user's terminal client.

21. A method according to claim 20, comprising receiving modifications to the template input by the verifying user at the second terminal client and generating the verification confirmation document using the received modifications. - -

22. A method according to any of claims 19 to 21, comprising receiving an indication of a verification type preferably from the first terminal client, and generating or selecting the template based on the indicated verification type.

23. A method according to any of the preceding claims, wherein verification relates to verifying the signature of the document by one or more signatories, the method comprising: receiving, from the verifying user at the second terminal client, a message indicating that the document is ready for signature; transmitting a signature request to one or more terminal clients associated with the one or more signatories; and receiving confirmation of signature from the one or more terminal clients.

24. A method according to claim 23, comprising applying electronic signatures for the one or more signatories to the document and/or the electronic verification confirmation document.

25. A method according to claim 23 or 24, comprising displaying a log-in status of one or more signatories to the verifying user, the log-in status preferably indicating whether the signatories are currently logged- in to the system.

26. A method according to any of claims 23 to 25, comprising displaying a notification at a signatory terminal client requesting signature.

27. A method according to any of the preceding claims, wherein the document to be verified is a previously verified document, the method comprising accessing, by the verifying user, information in a database relating to a verifier identified in the document, the information preferably including a representation of a signature of the verifier.

28. A method according to any of the preceding claims, comprising receiving a selection of one of a plurality of verifying users to perform the verification. - -

29. A method according to claim 28, comprising assigning the verification transaction to a work queue associated with an administrative user; accessing the verification transaction by the administrative user in the administrative work queue, and receiving the selection of the verifying user from the administrative user.

30. A method according to claim 28 or 29, wherein selecting the verifying user comprises assigning the verification transaction to a work queue associated with the verifying user; preferably wherein the verifying user selects the verification transaction in the work queue to access the verification transaction.

31. A method according to any of the preceding claims, comprising generating billing information relating to the verification transaction.

32. A method according to claim 31, comprising transmitting an invoice to and/or debiting an account associated with a user, preferably an end user requesting verification or a verifying user.

33. A method according to any of the preceding claims, comprising transmitting the verified document and/or the verification confirmation document to a further verifying user for performing a further verification.

34. A method according to any of the preceding claims, comprising authenticating the verifying user, preferably by reference to stored credentials for the verifying user.

35. A method according to any of the preceding claims, comprising authenticating a user associated with the first terminal client.

36. A method according to any of the preceding claims, wherein the electronic document to be verified comprises a digital media file, preferably one of an audio file, a video file and an image file.

37. A method of verifying signing of documents by multiple signatories using an electronic document signing and verification system, comprising: receiving an electronic document; - -

transmitting the document to a verifying user at a first terminal client; transmitting the document to one or more further terminal clients associated with respective signatories; in response to an indication from the verifying user at the first terminal client, transmitting a message to each of the further terminal clients requesting signing by each signatory; receiving a signature confirmation message from each further terminal client; receiving confirmation from the verifying user that the multiple signatures have been received; generating an electronic verification confirmation document; and outputting the electronic verification confirmation document.

38. A method of verifying documents using an electronic document verification system, comprising: receiving an electronic document as an input document to be verified; receiving verification confirmation from a verifying user in relation to the input document; generating a verification confirmation document; generating an electronic seal relating to one or both of the input document being verified and the verification confirmation document; outputting the input document, the verification confirmation document and the electronic seal.

39. A method according to claim 38, wherein the outputting step comprises generating an output document comprising the input document, the verification confirmation document and the seal.

40. A method according to claim 39, comprising performing a further verification in relation to the output document, the further verification comprising: receiving a verification confirmation from a verifying user in relation to the output document; generating a second verification confirmation document; generating a second electronic seal relating to one or both of the output document being verified and the second verification confirmation document; - -

generating a second output document comprising the output document, the second verification confirmation document and the second electronic seal.

41. A method according to any of claims 38 to 40, wherein the input document comprises a sealed verified document.

42. A method according to any of claims 38 to 41, wherein the output document and/or the second output document is in the form of a single file representing the sealed verified document.

43. An electronic document verification system comprising: a document repository for storing electronic documents; a database for storing verification transaction data; an interface for interfacing with a plurality of user terminal clients; software for receiving a verification request from a user terminal client and storing verification transaction data for the request in the database; software for receiving a document upload from a user terminal client and storing the uploaded document in the document repository; software for transmitting information relating to a verification transaction to a user terminal client associated with a verifying user and receiving a verification response from the verifying user; software for generating a verification confirmation document in response to a verification response; and software for transmitting the verification confirmation document to one or more recipients.

44. A system according to claim 43, further comprising at least one of: an electronic sealing module for generating an electronic tamper-evident seal for a document; an information rights management module for associating document usage rights information with a document; a user management and/or authentication system for managing system user information and/or authenticating users and/or processing user logins; - -

software for providing a client user interface for requesting verification of a document; software for providing a client user interface for uploading a document; software for providing a client user interface for managing verification transactions and/or performing administrative tasks relating to verification transactions; software for providing a client user interface for performing verification of a document by a verifying user; and workflow management software for assigning verification transactions to users.

45. An electronic document verification system comprising: means for sending, from a first terminal client, a verification request to a verification server; means for creating a verification transaction entry in a database associated with the verification server; means for receiving at least one electronic document to be verified; means for transmitting the document to a verifying user at a second terminal client; means for receiving verification confirmation from the verifying user at the second terminal client; means for generating an electronic verification confirmation document; and means for outputting the electronic verification confirmation document.

46. A system according to any of claims 43 to 45, further comprising means for performing a method as claimed in any of claims 1 to 42.

47. A computer program or computer program product comprising software code adapted, when executed on a data processing apparatus, to perform a method as claimed in any of claims 1 to 42.