WO2011005869A2

WO2011005869A2 - Method and system for generating and using biometrically secured embedded tokens in documents

Info

Publication number: WO2011005869A2
Application number: PCT/US2010/041224
Authority: WO
Inventors: Aziz Amirali Currim Valliani; Anandakumar Varatharajah; William Carl Bergschneider
Original assignee: Entrust & Title Ltd., A Bvi Corporation
Priority date: 2009-07-07
Filing date: 2010-07-07
Publication date: 2011-01-13
Also published as: WO2011005869A3

Abstract

A computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method including receiving a request from a user to sign a document by a service provider, obtaining a transaction identifier (ID), obtaining biometric data for the user, applying a hash function to the document to obtain a hash value, obtaining a TokenType ID associated with the user, generating a token using the TokenType ID, the biometric data, the transaction ID, and the hash value, where the token includes a machine-readable representation of data, and embedding the token on the document to obtain a token embedded document.

Description

METHOD AND SYSTEM FOR GENERATING AND USING BIOMETRICALLY SECURED EMBEDDED TOKENS IN

DOCUMENTS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims benefit of U.S. Provisional Application

No. 61/270,262, filed on July 7, 2009 that is entitled, "EMBEDDED COMMUNICATION WHERE THE ORIGINATOR CAN BE AUTHENTICATED," and incorporated herein by reference.

[0002] The present application claims benefit of U.S. Provisional Application

No. 61/270,263, filed on July 7, 2009 that is entitled, "EMBEDDED BIOMETRICS WHERE INDIVIDUALS ASSOCIATED WITH A TRANSACTION CAN BE AUTHENTICATED BY THE "GENUINENESS" OF DOCUMENTS EXECUTED VIA A PROCESS OF BIOMETRIC IDENTIFICATION AND AUTHENTICATION," and incorporated herein by reference.

[0003] The present application claims benefit of U.S. Provisional Application

No. 61/272,623, filed on October 14, 2009 that is entitled, "entrusted TOKEN- STORAGE OF LARGE (>1GB) AMOUNT OF RELEVANT OF IRRELEVANT DATA IN A BAR-CODE LIKE TOKEN, AND PROTECT IT WITH BIOMETRICS OR PASSWORD, WHICH CAN BE PLACED ON TO A DOCUMENT(S) IN A RELATIVELY SMALL AREA (E.G., 1" X 1") AND THEN BE ABLE TO REPRODUCE THE DOCUMENTS WITH PROPER APPROVALS AND AUTHORITY," and incorporated herein by reference.

BACKGROUND

[0004] Many documents used today require one or more signatures to make them valid and/or legally binding. For example, a contract requires the contracting parties to sign, and an affidavit used in a court proceeding requires the author of the affidavit (i.e., the affiant) to sign the affidavit. In both cases, if the relevant documents are not signed, they may not be used for their intended purpose. [0005] The requirement that a document be signed introduces the possibility that the signature on the document is forged. The forgery may be the result of an individual signing for another individual (i.e., Bob asserts he is Joe and then sign's Joe's name on the document) or the appropriate individual signs a document but the content of the document is subsequently changed. In the later case, while the document has been signed by the appropriate signatory, the signatory has not reviewed the changed document and, as such, the sign document should not be valid.

[0006] To address the above issues, documents requiring a signature are typically notarized for a notary. However, the notary typically does not have any means to confirm, with certainty, that the individual appearing before them to sign a document is in-fact the appropriate individual. For example, Bob may create a fake government identification (ID), which states his name is Joe. Bob may present the fake government ID to the notary, who is unable to detect that the fake government ID is in-fact fake. Bob may subsequently sign a document in front of the notary as Joe and the notary may record that Joe signed the document. In this scenario, Bob successfully forged Joe's signature and had it notarized.

[0007] In another example, Joe may sign a contract and have it notarized. Joe may then give the notarized contract to Bob. Bob may create a new document that looks like the notarized contract and in-fact includes the appropriate notary seal, but the content of the contract has been modified. In this case, Bob may be able to represent to third parties that the new document is the contract signed by Joe. In this scenario, it is very difficult (and potentially not possible) for the third-party to verify that Joe in-fact signed the document that has been represented to them as the contract signed by Joe. Further, Joe may have difficulty proving that he did not sign the new document. SUMMARY

[0008] In general, in one aspect, the invention relates to computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising receiving a request from a user to sign a document by a service provider, obtaining a transaction identifier (ID), obtaining biometric data for the user, applying a hash function to the document to obtain a hash value, obtaining a TokenType ID associated with the user, generating a token using the TokenType ID, the biometric data, the transaction ID, and the hash value, wherein the token comprises a machine-readable representation of data, and embedding the token on the document to obtain a token embedded document.

[0009] In general, in one aspect a computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising receiving data corresponding to a machine-readable representation of data from a user, wherein the machine- readable representation of data is affixed on a physical document, obtaining an encrypted transaction identifier (ID) from the data, decrypting the encrypted transaction ID to obtain the transaction ID using a service provider key, obtaining a first hash value from a service provider backend using the transaction ID, obtaining an encrypted hash value from the data, decrypting the encrypted hash value to obtain a second hash, determining whether the first hash value is equal to the second hash value, when the first hash value is not equal to the second hash value, notifying the user of an error, when the first hash value is equal to the second hash value determining whether the user is authorized to view an electronic version of the physical document, and providing the electronic version of the physical document to the user, when the user is authorized to view the electronic version of the physical document.

[0010] In general, in one aspect, the invention relates to computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising receiving scanned barcode data associated with a two-dimensional (2D) barcode from a user, wherein the 2D barcode is printed on a physical document, obtaining an encrypted transaction identifier (ID) from the scanned barcode data, decrypting the encrypted transaction ID to obtain the transaction ID using a service provider key, obtaining a first hash value from a service provider backend using the transaction ID, obtaining an encrypted hash value from the scanned barcode data, decrypting the encrypted hash value to obtain a second hash, determining that the first hash value is equal to the second hash value, determining that the user is authorized to view an electronic version of the physical document, providing the electronic version of the physical document to the user, receiving a document operation request from the user for a related document, and providing the user access to the related document based on an access permission of the user.

[0011] In general, in one aspect, a computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising receiving message to send from a sender to a recipient, wherein the message comprises message content, applying a hash function to the message content to obtain a message identifier (ID), obtaining sender biometric data, sending the message ID and the sender biometric data to service provider backend, receiving, in response to the sending, a token from the service provider, wherein the token comprises an encrypted sender ID and an encrypted message ID, wherein the encrypted message ID is generated using the sender biometric data, and sending the message and the token to the recipient.

[0012] In general, in one aspect, a computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising receiving, from a sender, a message and a token by a recipient, wherein the message comprises message content, wherein the token comprises an encrypted sender identifier (ID) and an encrypted message ID, sending the token to a service provider backend, receiving, in response to the sending, a first message ID from the service provider backend, wherein the service provider is configured to decrypt the encrypted sender ID to obtain the sender ID, obtain sender biometric data using the sender ID, and decrypt the encrypted message ID using the sender biometric data to obtain the first message ID, and applying a hash function to the message content to obtain a second message ID, determining whether the first message ID is equal to the second message ID, when the first message ID is not equal to the second message ID, notifying the recipient that the sender is not verified, when the first message ID is equal to the second message ID, notifying the recipient that the sender is verified.

[0013] Other aspects of the invention will be apparent from the following description and the appended claims.

BRIEF DESCRIPTION OF DRAWINGS

[0014] FIG. 1 shows a system in accordance with embodiments of the invention.

[0015] FIGs. 2A-2C shows tokens and a token embedded document in accordance with embodiments of the invention.

[0016] FIG. 3 shows a flow diagram in accordance with embodiments of the invention.

[0017] FIGs. 4, 5, 6A-6C, 7A-7B, and 8 show flowcharts in accordance with embodiments of the invention.

[0018] FIG. 7C shows an example in accordance with embodiments of the invention.

[0019] FIGs. 9A-9E show example tokens in accordance with embodiments of the invention. [0020] FIGs. 10A- 1OB show flow diagrams in accordance with embodiments of the invention.

DETAILED DESCRIPTION

[0021] Specific embodiments of the invention will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency.

[0022] In the following detailed description of embodiments of the invention, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0023] In general, embodiments of the invention relate to using biometric data to sign physical and electronic documents. Further, embodiments of the invention relate to using machine-readable representation of data, such as two- dimensional (2D) barcodes and/or Radio-Frequency Identification (RFID) tags, to encode the signature information of the document signatories. Further, embodiments of the invention relate to embedding the machine-readable representation of data on the signed physical documents. Further, embodiments of the invention relate to tracking related documents (e.g., documents for a given transaction).

[0024] In one or more embodiments of the invention, the term "biometric data" refers to one or more pieces of biometric data. Each piece of biometric data may correspond to a fingerprint, an iris scan, a signature obtained using a sensor tablet, an image of an individuals face (for use in facial recognition), or any other biometric information of an individual. Further, the particular piece (or pieces) of biometric data obtained from the users and witnesses of the system may vary depending on the implementation of the invention. For example, in one implementation, the biometric data obtained for a user is an iris scan; in another implementation of the invention, the biometric data obtained from a user is a right-hand thumb print and a signature.

[0025] FIG. 1 shows a system in accordance with embodiments of the invention. The system includes a service provider backend (SPB) (100), service provider storage (SPS) (102), and one or more client systems (104). Each of these components is described below.

[0026] In one embodiment of the invention, the SPB (100) is configured to interface with the client systems (104) and the SPS (102) to perform the functions described below in FIGs. 4, 5, 6A-6C, 7A-7B, and 8. More specifically, the SPB (100) is configured to implement the following services to perform the functions described below in FIGs. 4, 5, 6A-6C, 7A-7B, and 8. The services include a Central Identification Management Service (CIMS) (106), a Token Generation Service (TGS) (108), a Token Storage Service (TSS) (110), an Access Control Management Service (ACMS) (112), a Token Validation Service (TVS) (114), a Usage Tracking Service (UTS) (116), a User Authentication Service (UVS) (118), a Token Reading Service (TRS) (120), and a Metadata Management Service (MDMS) (122). Each of these services is described below.

[0027] In one embodiment of the invention, the Central Identification

Management Service (CIMS) (106) is configured to register users in the SPB (100) as described, for example, in FIG. 4 below. In one embodiment of the invention, a user may not use the other services in the SPB (100) without first registering with the CIMS (106).

[0028] In one embodiment of the invention, the Token Generation Service

(TGS) (108) is configured to generate a token and embed the token on the corresponding document, as described, for example, in FIGs. 6A-6C. The TGS (108) is configured to interface with the UVS (118), the MDMS (122), and the TSS (110). More specifically, the TGS (108) interfaces with the UVS (118) to confirm that the user and, if applicable, the witness, are authenticated prior to creating a token. Further, the TGS (108) is configured to interface with the MDMS (122) in order to determine the specific user parameters for creating and embedding the token on the document. Finally, the TGS (112) is configured to provide the TSS (110) the embedded token document (i.e., the document on which the token is embedded), the original document, and, optionally, the token.

[0029] In one embodiment of the invention, the Token Storage Service (TSS)

(110) is configured to store the embedded token document, the original document, optionally, the token in the appropriate locations in the SPS (102). Further, the TSS (110) includes functionality to manage the vaults, sub-vaults (as described in FIG. 5 below), and access to content stored therein (as described in FIG. 7B below).

[0030] In one embodiment of the invention, the Access Control Management

Service (ACMS) (112) is configured to maintain user access permissions. More specifically, in one embodiment of the invention, the ACMS (112) may be configured to maintain a listing of all documents a given user may access as well as what document operations the user may perform on each of the listed documents.

[0031] In another embodiment of the invention, the ACMS (112) maintains a list of roles, where each role specifies one or more document operations. Further, each document is associated with a list of roles. Thus, a user may access a document if the user is associated with a role and the document the user wishes to access is also associated with the role.

[0032] Examples of document operations, but are not limited to, redacted viewing, viewing, redacted read-only, read-only, redacted related, and related. The "viewing" document operation allows a user to only view a transaction log associated with the document. The "redacted viewing" document operation allows a user to only view redacted transaction log associated with the document. The "reading" document operation allows a user to view a transaction log associated with the document and to view the document. The "redacted reading" document operation allows a user to view a transaction log associated with the document and to view a redacted version of the document. The "related" document operation allows a user to view a transaction log associated with the document, to read the document, and to view a list of documents related to the document. The "redacted related" document operation allows a user to view a transaction log associated with the document, to view the document, and to view a redacted list of documents related to the document. The information that is redacted may vary across roles, documents, and users.

[0033] In one embodiment of the invention, the Token Validation Service

(TVS) (114) is configured to validate scanned barcode data, which is received from the TRS (120), to determine whether the token is valid. More specifically, the TVS (114) includes functionality to confirm that the token is associated with the proper document and that the token was signed by the appropriate signatories. The functionality of the TVS (114) is described in FIGs. 7A-7B and 8 below.

[0034] In one embodiment of the invention, the Usage Tracking Service (UTS)

(116) is configured to track the information related to the creation of the token as well as all subsequent reads of the token.

[0035] In one embodiment of the invention, the User Authentication Service

(UVS) (118) is configured to authenticate a user that is attempting to use the SPB (100). More specifically, the UVS (118) authenticates the identity of the user using information previously stored by the CIMS (106) during registration of the user.

[0036] In one embodiment of the invention, the Token Reading Service (TRS)

(120) is configured to receive and parse the scanned barcode data from a user to extract the various components in the token for use by the TVS (114). [0037] In one embodiment of the invention, the Metadata Management Service

(MDMS) (122) is configured to maintain the metadata associated with a user. For example, the MDMS (122) may store the following information for a user: (i) Customer ID, which uniquely identifies the customer in system; (ii) account IDs, which uniquely identifies the various accounts of the customer; (iii) user ID, which identify users associated with each account ID; (iv) TokenType IDs and token parameters associated with the TokenType ID; (v) encryption keys associated with the customer ID; and (vi) encryption keys associated with each account ID. Those skilled in the art will appreciate that if a user wishes to use the system as an individual (instead of, for example, using the system as an owner or employee of a legal entity), then the MDMS (122) may not store all of the above information for the user.

[0038] In one embodiment of the invention, the TokenType ID is associated with token parameters used by the TGS (108) and the TVS (114). The token parameters may be specified by the service provider, a customer, a user, or any combination thereof.

[0039] The token parameters may include, but are not limited, (i) token size; (ii) token shape; (iii) page to embed the token on document; (iv) location on the page of the document to embed the token; (v) document type, indicating the type of document (e.g., .pdf, .tiff, .jpeg, .cad, .doc, .docx, etc.) in which tokens associated with the TokenType ID will be embedded; (vi) encryption algorithm to encrypt data in token; (v) the number of 2D barcodes to include in the token; and (vi) 2D barcode format to use of each of the 2D barcodes.

[0040] In one embodiment of the invention, if the token is implemented as a

RFID tag or any other machine-readable representation of data, then the token parameters may be different than those listed above.

[0041] In one embodiment of the invention, the SPS (102) is configured to store: (i) user data (124) obtained during the registration process by the CIMS (106), (ii) log data corresponding to information logged by the UTS (116), (iii) documents (original and embedded token documents) (130), which may be stored in one or one or more vaults (and sub-vaults) (128) (described below), and (iv) optionally, the tokens (132) generated by the TGS (108).

[0042] In one embodiment of the invention, the SPB (100) is implemented using one or more computing devices. Further, the client systems (104) are implemented using one or more computing devices. In one embodiment of the invention, a computing device is any physical or virtual device that may be used for performing various embodiments of the invention (as described below). The physical device may correspond to any physical system with functionality to implement one or more embodiments of the invention. For example, the physical device may be implemented on a general purpose computing device (i.e., a device with a processor(s) and an operating system) such as, but not limited to, a server, a desktop computer, a laptop computer, a gaming console, a mobile device (e.g., a mobile phone, a smart phone, a personal digital assistant, a gaming device, etc.).

[0043] Alternatively, the physical device may be a special purpose computing device that includes an application-specific processor(s)/hardware configured to only execute embodiments of the invention. In such cases, the physical device may implement embodiments of the invention in hardware as a family of circuits and limited functionality to receive input and generate output in accordance with various embodiments of the invention. In addition, such computing devices may use a state-machine to implement various embodiments of the invention.

[0044] In another embodiment of the invention, the physical device may correspond to a computing device that includes a general purposes processor(s) and an application-specific processor(s)/hardware. In such cases, one or more portions of the invention may be implemented using the operating system and general purpose processor(s), and one or more portions of the invention may be implemented using the application- specific processor(s)/hardware. [0045] The virtual device may correspond to a virtual machine. Broadly speaking, the virtual machines are distinct operating environments configured to inherit underlying functionality of the host operating system (and access to the underlying host hardware) via an abstraction layer. In one or more embodiments of the invention, a virtual machine includes a separate instance of an operating system, which is distinct from the host operating system. For example, one or more embodiments of the invention may be implemented on VMware® architectures involving: (i) one or more virtual machines executing on a host computer system such that each virtual machine serves as host to an instance of a guest operating system; and (ii) a hypervisor layer serving to facilitate intra-host communication between the one or more virtual machines and host computer system hardware. Alternatively, one or more embodiments of the invention may be implemented on Xen^® architectures involving: (i) a control host operating system (e.g., Dom 0) including a hypervisor; and (ii) one or more VMs (e.g., Dom U) executing guest operating system instances using VMware^®. The invention is not limited to the aforementioned exemplary architectures. VMware^® is a registered trademark of VMware, Inc. Xen^® is a trademark overseen by the Xen Project Advisory Board.

[0046] Further, regardless of the implementation of the computing devices, the computing devices may include (or be operatively connected to) one or more of the following: associated memory (e.g., random access memory (RAM), cache memory, flash memory, etc.), a storage device (e.g., a hard disk, an optical drive such as a compact disk drive or digital video disk (DVD) drive, a flash memory stick, etc.), one or more input mechanisms (e.g., a keyboard, a touch screen, a mouse, a microphone), a display (e.g., a liquid crystal display (LCD), a plasma display, or cathode ray tube (CRT) monitor), speakers, and one or more communication interfaces (e.g., a network interface (wired and/or wireless), a Bluetooth Interface, a Universal Serial Bus (USB) interface, a Firewire interface, etc.). [0047] In one embodiment of the invention, the client systems (104) interact with the SPB (100) via a web browser on the client system (104). In such embodiments, the SPB (100) provides the services described above to the client systems (104) using a software-as-a-service (SaaS) model.

[0048] In one embodiment of the invention, the SPS (102) is implemented as one or more persistent storage devices. Examples of persistent storage devices include, but are not limited to, disk arrays, and tape libraries. The SPB (100) may be directly or indirectly connected, e.g., over a network, to the SPS (102). The network may be wired, wireless, or any combination thereof. The SPB (100) may be directly or indirectly connected, e.g., over a network, to the client systems (104). The network may be wired, wireless, or any combination thereof.

[0049] FIGs. 2A-2C shows tokens and token embedded documents in accordance with embodiments of the invention. Referring to FIG. 2A, FIG. 2A shows a token (200) that includes a 2D barcode (202). The token (200) may also include (but not shown in FIG. 2A) additional information such as images, text (alphabetic, numeric, alphanumeric), symbols, or any combination thereof.

[0050] In one embodiment of the invention, the 2D barcode (202) is an optical machine-readable representation of data. The 2D barcode (202) may represent data as black and white or colored patterns of squares, dots, hexagons and other geometric patterns. Examples of 2D barcode formats include, but are not limited to, PDF417, MicroPDF417, 2D barcodes satisfying ISO/IEC 18004:2006, ISO/IEC 16023, ISO/IEC 16022:2006, ISO/IEC 15415-2, ISO/IEC 15418:2009, ISO/IEC 15424:2008, ISO/IEC 15434:2009, and ISO/IEC 15459. Embodiments of the invention are not limited to 2D barcodes described above, rather, embodiments of the invention may be implemented to use any machine-readable representation of data such as RFID tags and other optical machine-readable representations of data. In one embodiment of the invention, the RFID tag is a passive RFID tag and includes (i) an integrated circuit for storing and processing information, modulating and demodulating a radio-frequency (RF) signal, and other specialized functions and (ii) an antenna for receiving and transmitting the signal. Further, the passive RFID tag requires an external power source to enable the integrated circuit to perform the required functions. In other embodiments of the invention, the RFID tag may be implemented as an active RFID tag or a battery-assisted passive RFID tag. In this scenario, the aforementioned RFID tags include an internal power source, which powers (at least in part) the integrated circuit.

[0051] Referring to FIG. 2B, FIG. 2B shows a token (204) that includes two or more 2D barcodes (206, 208). The token (204) may also include (but not shown in FIG. 2A) additional information such as images, text (alphabetic, numeric, alphanumeric), symbols, or any combination thereof.

[0052] In one embodiment of the invention, the token (204) may include different types of machine-readable representations of data. For example, the token (204) may include a 2D barcode and a RFID tag.

[0053] Referring to FIG. 2C, FIG. 2C shows a token (212) embedded on a document (210). In one embodiment of the invention, the location (including particular page in document and location on particular page) is specified in the token parameters associated with the TokenType ID.

[0054] FIG. 3 shows a flow diagram in accordance with embodiments of the invention. More specifically, FIG. 3 shows a witness hierarchy in accordance with embodiments of the invention. The witness hierarchy is used to establish a chain of trust in the registration process such that users registered in the system (including the witnesses themselves) are registered by witnesses that have been verified (directly or indirectly) by the service provider. Said another way, the witness hierarchy gives the service provider and users of the system confidence that a user registered in the system is in- fact who they say they are.

[0055] Turning to FIG. 3, the service provider (300) (or more specifically, one or more employees or agents of the service provider (300)) designate one or more super witnesses (304). A super witness (304) has the authority to designate and witness the registration of one or more executive witnesses (306). An executive witness (306) has the authority to designate and witness the registration of one or more standard witnesses (308). Further, any of the above witnesses (302) have the authority to witness the registration of any user (310) (where the user is not a witness or where the user is witness in a lower level of the hierarchy). The registration process for a user (including witnesses) is described in FIG. 4 below.

[0056] Those skilled in the art will appreciate that the witness hierarchy may include fewer or more levels than are shown in FIG. 3.

[0057] FIGs. 4, 5, 6A-6C, 7A-7B, and 8 show flowcharts in accordance with one or more embodiments of the invention. While the various steps in these flowcharts are presented and described sequentially, one of ordinary skill will appreciate that some or all of the steps may be executed in different orders, may be combined or omitted, and some or all of the steps may be executed in parallel.

[0058] FIG. 4 shows a flowchart for registering a user in accordance with embodiments of the system. In Step 400, the service provider backend (SPB) receives a request to initiate user registration. In Step 402, basic information of the user who is being registered is obtained. Examples of the basic information include, but are not limited to, user name (first, middle, last), mailing address, e-mail address, and password. In Step 404, information about the witness who is witnessing the user registration is received. The information about the witness may correspond to a user identifier (ID) for the witness. As discussed above, the witness must be registered in the SPB prior to acting as a witness for a user registration.

[0059] In Step 406, a determination is made about whether the witness is a valid witness to register the particular user. The determination includes (i) determining whether the witness is registered in the SPB, and (ii) whether the witness, based on the witness hierarchy, has sufficient authority to register the user. For example, if the user being registered is an executive witness, then the witness must be designated as a super witness. However, if the user being registered is a non-witness user, then a super witness, executive witness, or a standard witness may witness the user's registration. If the witness is a valid witness to register the user, then process proceeds to Step 408; otherwise the process proceeds to Step 404, where another witness is selected.

[0060] In Step 408, the biometric data for the witness is received. In one embodiment of the invention, the biometric data of the witness is captured by a client system (or a device operatively connected thereto) being used for the user registration during the user registration. In Step 410, if the captured witness biometric data (i.e., the biometric data for the witness obtained in Step 408) matches the stored witness biometric data (i.e., the biometric data stored by the SPB), then the process proceeds to Step 412; otherwise the process ends as the witness has not been authenticated and, accordingly, may not witness the registration of the user.

[0061] In Step 412, the biometric data for the user is received. In one embodiment of the invention, the biometric data of the user is captured by a client system (or a device operatively connected thereto) being used for the user registration during the user registration. In Step 414, electronic copies of the user identification documents are received. Examples of user identification documents may include, but are not limited to, a user's driver license, a user's passport, a user's birth certificate, a user's social security card, a user's military identification card, any other government issued identification, or any combination thereof.

[0062] In Step 416, a photograph of the user is received. In one embodiment of the invention, the photograph of the user is captured by a client system (or a device operatively connected thereto) being used for the user registration during the user registration. In Step 418, the biometric data for the witness is received. In one embodiment of the invention, the biometric data of the witness is captured by a client system (or a device operatively connected thereto) being used for the user registration during the user registration.

[0063] In Step 420, if the captured witness biometric data (i.e., the biometric data for the witness obtained in Step 418) matches the stored witness biometric data (i.e., the biometric data stored by the SPB), then the process proceeds to Step 422; otherwise the process ends as the witness has not verified one or more of Steps 414, 416, and 418, and, accordingly, may not witness the registration of the user. In Step 422, the registration process is completed. In one embodiment of the invention, completing the registration process may include generating a user ID for the user and, if appropriate, associating the user ID with an Account ID (where the Account ID is associated with a customer ID). In one embodiment of the invention, if the user is part of a legal entity (e.g., a corporation, a partnership, a non-profit, a governmental organization, or a non-governmental organization, or any other business organization, then the user ID for the user is associated with the appropriate Account ID. For example, if the user is an employee of the research group of a corporation, then the corporation may be associated with a customer ID and the research group may be associated with an Account ID. Finally, because the user is an employee of the research group, the user ID for the user is associated with the Account ID for the research group. In one embodiment of the invention, completing the registration of the user includes storing all the data about/from the user in the SPS. Further, information about who witnessed the registration as well as when the registration occurred is also stored.

[0064] FIG. 5 shows a flowchart for creating vaults and sub-vaults in accordance with embodiments of the invention. In Step 500, a vault is created. In one embodiment of the invention, the vault corresponds to a document storage mechanism (or data structure or set of data structures) that is configured to store documents, maintain relationships between documents, and to control access to documents, via the CIMS (106 in FIG. 1). In one embodiment of the invention, when the vault is created, the vault is associated a vault ID, which identifies the particular vault in the system.

[0065] In Step 502, a determination is made about whether to create sub-vaults within the vault created in Step 500. If sub-vaults are to be created, the process proceeds to Step 504; otherwise the process proceeds to Step 506. In Step 504, one or more sub-vaults are created. In one embodiment of the invention, for each sub-vault that is created, the sub-vault is associated a vault ID, which identifies the particular sub-vault in the system. In one embodiment of the invention, each vault ID is a unique ID within the system. Accordingly, a sub- vault may be directly accessed using the appropriate vault ID, without requiring any knowledge of the vault (i.e., the vault in which the sub-vault conceptually resides).

[0066] In one embodiment of the invention, a vault may be created for a business transaction, such as a real estate deal and sub-vaults may be specified as means of organizing the documents related to the various sub-parts of the transaction. For example, a sub-vault may be created to documents related to the financing of the real estate deal and another sub-vault may be created for the engineering documents related to the buildings to be construed as part of the real estate deal. By specifying vaults and sub-vaults, relationships between the documents may be maintained. For example, all documents within the same vault and/or sub-vault may be deemed as related documents. In addition, by specifying vaults and sub-vaults and associating documents with particular vaults or sub-vaults, access to the various documents may be controlled at a more granular level.

[0067] Returning to FIG. 5, in Step 506, access permissions for the vault are specified. Specifying access permissions for the vault may include specifying one or more roles for the vault, where each role is associated with a role ID and defines one or more documents operations (such as the document operations described above) associated with the role. In Step 508, if sub-vaults have been designated, then access permissions for the vault are specified. Specifying access permissions for the vault may include specifying one or more roles for the vault, where each role is associated with a role ID and defines one or more documents operations (such as the document operations described above) associated with the role.

[0068] FIGs. 6A-6C show a process for generating and embedding a token on a document in accordance with embodiments of the invention.

[0069] In Step 600, a request to embed a token on a document is received. In

Step 602, the number of signatories to the document is obtained. In Step 604, a signatory is selected. In Step 606, the biometric data for the signatory is obtained. In one embodiment of the invention, the biometric data of the signatory is captured by a client system (or a device operatively connected thereto) from which the request in Step 600 was sent. In one embodiment of the invention, Step 606 is witnessed. In such cases, a witness (e.g., a super witness, an executive witness, or a standard witness) may provide their biometric data before and, optionally, after the signatory has provided their biometric data. Further, the signatory's biometric data is only accepted if the witness biometric data matches the stored witness biometric data each time the witness provides their biometric data (i.e., before the signatory provides biometrics data and, if appropriate, after the signatory provides biometric data).

[0070] In Step 608, the signatory's biometric data obtained in Step 606 is compared with the signatory's biometrics data previously provided to the SPB (100 in FIG. 1) to determine if they match (i.e., biometric data provided during the registration of the signatory). If the result of the comparison is a match, the process proceeds to Step 610; otherwise the process ends as the selected signatory is not a valid signatory either because they have not registered with the SPB or the biometric data obtained in step 606 does not match the stored biometric data in the SPB.

[0071] In Step 610, a determination is made about whether there are any other signatories for the document. If so, the process proceeds to Step 604; otherwise the process proceeds to Step 612. In Step 612, the transaction ID is obtained. The transaction ID may correspond to a transaction with which the document is associated. For example, if the document is a real estate contract for a construction project, then the transaction ID may a unique ID associated with the construction project.

[0072] In Step 614, the transaction ID is encrypted with a service provider key.

The service provider key corresponds to an encryption key maintained by the service provider. Further, the encryption algorithm used in Step 614 is designated by the service provider. In Step 616, the original document on which to embed the token is obtained.

[0073] In Step 618, a hash function is applied to the original document to obtain a hash value. In one embodiment of the invention, the hash value may be used as a document ID for the original document. In one or more embodiments of the invention, a hash function is a function that includes functionality to receive an input and produce a pseudo-random output. In one or more embodiments of the invention, the hash function may include functionality to convert a variable length input into a fixed length output. For example, the hash function may correspond to GOST, HAVAL, MD2, MD4, MD5, PANAMA, SNEERU, a member of the RIPEMD family of hash functions, a member of the SHA family of hash functions, Tiger, Whirlpool, S-Box, P-Box, any other hash function, or combination thereof.

[0074] In Step 620, a signatory is selected. In Step 622, the hash value obtained in Step 620 is encrypted to obtain an encrypted hash value. In one embodiment of the invention, encrypting the hash value includes using an encryption algorithm and the biometric data of the selected signatory as a key(s) for the encryption algorithm.

[0075] In one embodiment of the invention, encrypting the hash value with biometric data may include using the biometric data (or portions thereof) as an encryption key in an encryption algorithm to encrypt the hash value. In another embodiment of the invention, the biometric data (or portions thereof) may be used to generate an encryption key, which is subsequently used with the encryption algorithm to encrypt the hash value.

[0076] In Step 624, a determination is made about whether there are any other signatories for the document to process. If so, the process proceeds to Step 620; otherwise the process proceeds to Step 626. In Step 626, the TokenType ID is obtained. In one embodiment of the invention, the TokenType ID is obtained using the user ID corresponding to one of the signatories. In one embodiment of the invention, the TokenType ID is associated with an Account ID and the Account ID is obtained using the User ID associated with one of the signatories. For example, if the signatory is an owner of a company (associated with Customer ID), then the owner is assigned as User ID in the system and the User ID is related to an Account ID. In another example, the TokenType ID may be obtained using the Account ID and a Customer ID.

[0077] In Step 628, the TokenType ID is used to obtain token parameters (as described above) which are used to generate the token along with the encrypted transaction ID (obtained in Step 614) and the encrypted hash values (obtained in Step 622). In one embodiment of the invention, the token generation may also include, as input, an unencrypted document hash, and/or an encrypted hash value generated using an encryption key associated with an Account ID or a Customer ID. This may also include any other data required by the service provide, customer, or user. In one embodiment of the invention, generating the token includes determining the data to be included in the token (e.g., encrypted transaction ID, encrypted hash values, unencrypted document hash, etc.), determining the order in which to arrange the data in the token, determining the number of 2D barcodes to include in the token, determining (if appropriate) the data to be included in each of the 2D barcodes, determining the 2D barcode format, size and shape for each of the 2D barcodes in the token, and generating the token based on the above determinations. At this stage, the process proceeds to Step 630 in FIG. 6B or Step 642 in FIG. 6C. [0078] Referring to FIG. 6B, FIG. 6B shows a process in which the token embedded document is not associated with a vault or sub-vault. In Step 630, the token is embedded on the original document to obtain an embedded token document. Embedding the token in the original document may include using the TokenType ID to obtain information about the page in the document to embed the token and the location (x, y) on the page at which to embed the token. Optionally, a z-coordinate may be used to determine whether the token is embedded below the main text level on the page, at the main text level on the page, or above the main text level on the page.

[0079] In Step 632, the embedded token document is sent to the client system that initiated the request in Step 600. In Step 634, the original document is stored in the SPS (102 in FIG. 1). In Step 636, the hash value of the document is stored in the SPS (102 in FIG. 1). In Step 638, optionally, the token embedded document is stored in the SPS (102 in FIG. 1).

[0080] In Step 640, the token generation usage information is recorded. The token generation usage information may include, but is not limited to, Customer ID (if applicable), Account ID (if applicable), Transaction ID, TokenType ID, size of original document, size of biometric data received for generating the token, date and time of request for token generation, size of token embedded documents, date and time token embedded document was returned (if token generation was successful), status of token generation (e.g., success, failure, explanation of reasons for failure), user IDs corresponding to signatories used to generate token, and user IDs corresponds to witness (if any). In one embodiment of the invention, the storing action in Steps 634, 636, 638, 640, may include specifying access permissions for the stored data (e.g., specifying roles for each of the data).

[0081] Referring to FIG. 6C, FIG. 6C shows a process in which the token embedded document is associated with a vault or sub-vault. In Step 642, the token is embedded on the original document to obtain an embedded token document. Embedding the token in the original document may include using the TokenType ID to obtain information about the page in the document to embed the token and the location (x, y) on the page at which to embed the token. Optionally, a z-coordinate may be used to determine whether the token is embedded below the main text level on the page, at the main text level on the page, or above the main text level on the page.

[0082] In Step 644, the embedded token document is sent to the client system that initiated the request in Step 600. In Step 646, the vault or sub-vault associated with the transaction ID is identified. In one embodiment of the invention, the TSS maintains a mapping between transaction ID and vault ID (corresponding to a vault or sub- vault). In Step 648, the original document is stored in the identified vault or sub-vault. In Step 650, the hash value of the document is stored in the identified vault or sub-vault. In Step 652, optionally, the token embedded document is stored in the identified vault or sub-vault. In one embodiment of the invention, storing a document (original or token embedded document) and/or a token in a vault or sub- vault includes associating the document (or token) with a vault ID. Associating the document (or token) with a vault ID may include creating one or more of the following mappings: (i) transaction ID - vault ID and/or (ii) document ID (e.g., hash value for the document) - vault ID.

[0083] In Step 654, the token generation usage information is recorded. The token generation usage information may include, but is not limited to, Customer ID (if applicable), Account ID (if applicable), Transaction ID, TokenType ID, size of original document, size of biometric data received for generating the token, date and time of request for token generation, size of token embedded documents, date and time token embedded document was returned (if token generation was successful), status of token generation (e.g., success, failure, explanation of reasons for failure), user IDs corresponding to signatories used to generate token, and user IDs corresponds to witness (if any).

[0084] In one embodiment of the invention, the storing action in Steps 648,

650, and 652, may include specifying access permissions for the stored data. For example, roles may be associated with each of data stored in Steps 648, 650, and 652, and 654. The roles (as described above) may be used to control access to the data by the CIMS.

[0085] FIGs. 7A-7B shows a flowchart for validating a token in accordance with embodiments of the system. In Step 700, scanned barcode data corresponding to a token (e.g., a token generated using the process shown in FIGs. 6A-6C) is received from a client system. In one embodiment of the invention, the scanned barcode data is obtained by scanning the token, which is affixed to a physical document, using a barcode scanner. In another embodiment of the invention, the scanned barcode data is obtained as follows: (i) obtain image (e.g., JPEG, TIFF, etc.) of the 2D barcode and (ii) generate the scanned barcode data from the image of the 2D barcode.

[0086] In one embodiment of the invention, data stored in the RFID tag is obtained using a RFID reader (or interrogator). In such cases, the data obtained in Step 700 is data from a RFID tag and not data scanned barcode data.

[0087] In one embodiment of the invention, the token may be affixed to the document as a printed image on the physical document or as a printed label affixed to the physical document by an adhesive. In another embodiment of the invention, if the token includes a RFID tag, then the data to be stored in the token is stored in the RFID tag and RFID tag is affixed to the physical document by an adhesive.

[0088] In Step 702, the encrypted transaction ID is extracted and decrypted from the scanned barcode data (or data from a RFID tag) using a service provider key (and decryption algorithm specified by the service provider). In Step 704, a determination is made about whether the transaction ID is valid (i.e., is there a corresponding transaction ID specified in system). If the transaction ID is not valid, the process ends; otherwise the process proceeds to Step 706. In Step 706, the original document is obtained. In one embodiment of the invention, the original document is obtained using the transaction ID. [0089] In Step 708, a hash function (as described above) is applied to the original document to obtain a hash value. In one embodiment of the invention, the hash value may be obtained from the SPS using the transaction ID. In such embodiments, Step 706 and 708 may not be performed. In Step 710, a hash value is obtained from the token. In one embodiment of the invention, the hash value is obtained from the token by extracting an encrypted hash value and decrypting the encrypted hash value using a service provider key, a customer key, or an account key, as appropriate. Alternatively, if the token includes an unencrypted hash value, the hash value may be obtained directly from the token, without the need for decryption.

[0090] In Step 712, the hash value calculated in Step 708 is compared with the hash value obtained in Step 710 to determine if they match. If there is a match, the process proceeds to step 714; otherwise the process ends. If the process ends at this stage, it may be assumed that the token was modified by a malicious party. In Step 714, a determination is made about whether the user, who is using the client system that provided the scanned barcode data (or data from the RFID tag), is authenticated {e.g., Steps 716 and 718 were previously performed). If the user is authenticated, the process proceeds to Step 720; otherwise, the process proceeds to Step 716.

[0091] Referring to FIG. 7B, in Step 716, the biometric data for the user is requested and received. In one embodiment of the invention, the biometric data of the user is captured by a client system (or a device operatively connected thereto) currently being used for the user.

[0092] In one embodiment of the invention, if the user is unable to provide the requested biometric data, then the user may require a witness to authenticate the user using other user identification documents, e.g., a user's driver license, a user's passport, a user's birth certificate, a user's social security card, a user's military identification card, any other government issued identification, or a combination thereof. The witness may compare user identification documents presented by the user to the electronic copies of the user identification documents stored in the SPS. If the witness verifies the user identification documents, then the witness may authenticate the user. Based on the witness' authentication, the biometric data for the user, which is stored in the SPS, is obtained. Examples of the user identification documents and witness biometric data required to authenticate a user who is unable to provide the requested biometric data is shown in FIG. 1C.

[0093] Referring to FIG. 1C, "U" refers to the user, "W" refers to the witness,

"S" refers to a signature obtained using a sensor tablet, "F" refers to a fingerprint, "P" refers to a passport, "B" refers to biometric data other than the biometric data requested by the SPB for the user in order to perform step 718, "H" refers to a national identity card {e.g., a certificate of citizenship), "O" refers to another government issued user identification {e.g., a driver license, etc.), "D" refers to other supporting documents related to the transaction in which the document (and token affixed thereto) is being verified in FIGs. 7 A and 7B.

[0094] In another embodiment of the invention, the user may be re-registered with the SPB, where the registration is witnessed. Following the re- registration, the user's previously stored biometric data {i.e., the biometric data used in the token generation) may be obtained and used as described in the remainder of FIG. 7B.

[0095] In one embodiment of the invention, when a user is unable to provide the requested/required biometric data, the reason the user is unable to provide the requested/required biometric data is recorded by the SPB and associated with the user and/or the particular token being requested. Further, during subsequent attempts to read the particular token and/or to authenticate the user's biometrics, a witness may obtain the previously provided reason.

[0096] Continuing with FIG. 7B, in Step 718, the user's biometric data obtained in Step 716 is compared with the user's biometrics data previously provided to the SPB (100 in FIG. 1) to determine if they match (i.e., biometric data provided during the registration of the signatory as a user of the system). If the result of the comparison is a match, the process proceeds to Step 720; otherwise the process ends as the user is not a valid user either because they have not registered with the SPB or the biometric data obtained in step 716 does not match the biometric data in the SPB.

[0097] In Step 720, the user access permissions are obtained. In one embodiment of the invention, the user access permissions may include the roles (as described above) associated with the user. In one embodiment of the invention, the roles may be associated on a per-document basis, on a per-vault basis, on a per-sub-vault basis, or any combination thereof. In Step 722, the document access permissions are obtained. In one embodiment of the invention, the document access permissions may include the role(s) associated with the document that is the subject of the document operation request.

[0098] In Step 724, a determination is made about whether the user can perform a given document operation based on the role(s) associated with the user and the role(s) associated with the document that is the subject of the document operation request. In one embodiment of the invention, the document operation request may be an explicit request from the user to perform a document operation on a document. In other embodiments of the invention, the document operation request may be implied as part of, for example, the token validation process. In such cases, once the Step 712 has been successfully completed (i.e., there is a match between the hash values obtained in Steps 708 and 710), the SPB automatically sends a document operation request to provide the user with an electronic version (which may be redacted) of the original document associated with the transaction ID. If the user is allowed to perform the above document operation request, the process proceeds to Step 724; otherwise the process proceeds to Step 728.

[0099] In Step 726, the document operation request is performed. In one embodiment of the invention, the document operation request includes providing the user with an electronic version (which may be redacted) of the original document. At this stage, the user may confirm that the physical document (on which the token is printed or affixed, via a label) matches the electronic version of the original document. If the electronic version of the original document matches the physical document, the user may have confidence that the physical document is in-fact the document for which the token was generated and, by extension, that was signed by the signatories of the physical document.

[00100] In Step 728, a determination is made about whether the user has requested to perform any other document operation requests. Examples of document operation requests include, but are not limited to, viewing the token usage information for the token (i.e., the token scanned in Step 700), receiving a list of documents related to the physical document, and viewing one or more the related documents. In one embodiment of the invention, all documents with the same transaction ID, in the same sub-vault, and/or in the same vault may be deemed related documents. If the user has requested to perform any other document operation requests, the process proceeds to Step 722; otherwise, the process ends.

[00101] FIG. 8 shows a flowchart for validating the signatories of a document in accordance with embodiments of the system.

[00102] In Step 800, the number of signatories to the document is obtained. In Step 802, a signatory is selected. In Step 804, the biometric data for the signatory is obtained. In one embodiment of the invention, the biometric data of the signatory is captured by a client system (or a device operatively connected thereto) from which the process in FIG. 8 was initiated. In one embodiment of the invention, Step 804 is witnessed. In such cases, a witness (e.g., a super witness, an executive witness, or a standard witness) may provide their biometric data before and, optionally, after the signatory has provided their biometric data. Further, the signatory's biometric data is only accepted if the witness biometric data matches the stored witness biometric data each time the witness provides their biometric data (i.e., before the signatory provides biometrics data and, if appropriate, after the signatory provides biometric data).

[00103] In another embodiment of the invention, the biometric data for one or more of the signatories may be obtained from the SPB. More specifically, the transaction ID may be used to identify which users signed the original document. Using this information, the SPB may obtain the biometric data of the corresponding users from the SPS. The biometric data may then be used to verify the signatories of the document.

[00104] Returning to FIG. 8, in Step 806, the encrypted hash value corresponding to the signatory identified from the scanned barcode data (or data from the RFID tag) (obtained, for example, in FIG. 7 A, Step 700) is obtained. In Step 808, the encrypted hash value (obtained in Step 806) is decrypted using biometric data of the signatory and the appropriate encryption algorithm to obtain a decrypted hash value.

[00105] In Step 810, a determination is made about whether the decrypted hash value matches a stored hash value. If the decrypted hash value matches a stored hash value, then the process proceeds to Step 812; otherwise the process proceeds to Step 816. In one embodiment of the invention, the stored hash value is obtained by the SPB (100 in FIG. 1) using the transaction ID associated with the token. The hash value may be stored in the SPB (see e.g., FIG. 6B, 636) or the hash value may be calculated by applying the hash function to the original document (obtained using the transaction ID). Further, a match in Step 810 indicates that the signatory signed the original document with which the token is associated.

[00106] In Step 812, a determination is made about whether there are any other signatories for the document. If so, the process proceeds to Step 802; otherwise the process proceeds to Step 814. In Step 814, if all signatories are validated, then the user of the client system is notified that the document signatories have been confirmed. Said another way, the biometric data of the signatories obtained in Step 804 positively indentifies that these signatories signed the original document (using, for example, the process shown in FIGs. 6A-6C). In Step 816, the user is notified that one or more signatories have not been verified.

[00107] The following discussion describes examples in accordance with embodiments of the invention. The examples are not intended to limit the scope of the invention.

[00108] Referring to FIGs. 9A-9E, the following example describes a construction project in downtown Toronto. The Property Development Company (PDC) signs up as a customer of the SPB and is assigned Customer ID "CIDl." Further, PDC creates an account for all transactions in Canada, which SPB assigns an Account ID of "AIDl," which is associated with the CIDl. Further, the PDC creates a transaction ID "TID" for the construction project in Toronto.

[00109] The PDC subsequently specifies the token parameters to use in all tokens generated for transactions associated with AIDl . The token parameters are associated with TokenType IDl and TokenType IDl is associated with AIDl.

[00110] The PDC then specifies the creation of a vault, which is associated with vault ID "VID" and three sub-vaults: (i) "SVIDl" for documents related to the financing of the construction project, (ii) "SVID2" for engineering drawings related to the construction project, and (iii) "SVID3" for permits related to the construction project. Each of the vaults and sub- vaults is associated with one or more roles, where each role specifies one or more document operations.

[00111] The service provider then designates the CEO of the PDC as the super witness. The CEO is subsequently registered as a user in accordance with FIG. 4. The CEO then designates and witnesses the registration of an executive witness, namely, the VP of Construction, Canada. Finally, the VP of Construction, Canada designates and witnesses the registration of standard witnesses, namely, the project manager (M) of the construction project, the lead architect (A) on the construction project, and the lead structural engineer on the construction project. The standard witnesses subsequently witness the registration of various engineers and architects working on the construction project.

[00112] Similarly, the City of Toronto (CT) signs up as a customer of the SPB and is assigned Customer ID "CID2." Further, CT creates an account the Building Permit Department (BPD), which SPB assigns an Account ID of "AID2," which is associated with the CID2.

[00113] The BPD subsequently specifies the token parameters to use in all tokens generated for transactions associated with AID2. The token parameters are associated with TokenType ID2 and TokenType ID2 is associated with AID2.

[00114] The service provider then designates the Mayor of Toronto as the super witness. The Mayor is subsequently registered as a user in accordance with FIGs. 6A-6C. The Mayor then designates and witnesses the registration of an executive witness, namely, the Lead Building Permit Manager. Finally, the Lead Building Permit Manager designates and witnesses the registration of standard witnesses, namely, the Building Permit Manager, Downtown Toronto (BPD M). The standard witness subsequently witnesses the registration of an engineer in the Build Permits Department (BPD E).

[00115] Finally, the landowner (O) (i.e., the owner of the land on which the construction project is taking place) is registered as a user in the SPB. The project manager of the construction project may witness the registration of the landowner. During or after the registration process of each of the aforementioned users, each user is assigned one or more roles, which dictate what data in the SPS the particular user may access.

[00116] Continuing with the example, the landowner and the PDC may sign a construction agreement in accordance with the process in 6A-6C. The token generated and embedded on the construction agreement using TokenType IDl is shown in FIG. 9A. Referring to FIG. 9A, Token A includes a 2D barcode. The 2D barcode has encoded therein, (i) TID encrypted using the service provider key, (ii) optionally, the Construction Agreement Hash encrypted using the service provider key, (iii) the Construction Agreement Hash encrypted using the biometric data of the project manager (M), and (iv) the Construction Agreement Hash encrypted using the biometric data of the landowner (O).

[00117] Token A, once generated, is embedded in the construction agreement in accordance with the TokenType IDl . Further, the original document and resulting token embedded document are stored in the sub-vault identified by SVIDl.

[00118] The architects for the PDC generate engineering drawings, which are subsequently approved and signed by the lead architect (A) and the project manager (M) in accordance with the process in 6A-6C. The token generated and embedded on the construction agreement using TokenType IDl is shown in FIG. 9B. Referring to FIG. 9B, Token B includes a 2D barcode. The 2D barcode has encoded therein, (i) TID encrypted using the service provider key, (ii) optionally, the Engineering Drawings Hash encrypted using the service provider key, (iii) the Engineering Drawings Hash encrypted using the biometric data of the lead architect (A), and (iv) the Engineering Drawings Hash encrypted using the biometric data of the project manager (M).

[00119] Token B, once generated, is embedded in the engineering drawings in accordance with the TokenType IDl. Further, the original document and resulting token embedded document are stored in the sub-vault identified by SVID2.

[00120] The Engineering Drawings with embedded Token B are subsequently printed to obtain printed Engineering Drawings. The printed Engineering Drawings are sent to the BPD for review and approval. [00121] An engineer (BPD E) at the BPD reviews and approves the printed engineering drawings. As part of the review and approval process, the engineer may scan Token B and obtain the electronic version of the Engineering Drawings in accordance with the process shown in FIGs. 7A-7B. Further, the engineer may confirm that the lead architecture approved and signed the Engineering Drawings in accordance with the process shown in FIG. 8. Once approved, the engineer (BPD E) signs the approved engineering drawings in accordance with FIG. 6A-6C.

[00122] When signing the approved engineering drawings, the engineer may: (i) scan in the printed engineering drawings, which include Token B, and subsequently sign the scanned-in document; (ii) sign the electronic version of the Engineering Drawings that include embedded Token B; or (iii) sign the electronic version of the Engineering Drawings that do not include embedded Token B. In options (i) and (ii), the resulting token embedded document will include both Token B and Token C (as shown in FIG. 9C).

[00123] Referring to FIG. 9C, Token C is generated using TokenType ID2 and includes a 2D barcode. The 2D barcode has encoded therein, (i) TID encrypted using the service provider key, (ii) optionally, the Engineering Drawings Hash encrypted using the service provider key, (iii) the Engineering Drawings Hash encrypted using the Building Permit Department Key (BPD KEY), and (iv) the Engineering Drawings Hash encrypted using the biometric data of the engineer (BPD E). Token C, once generated, is embedded in the engineering drawings in accordance with the TokenType ID2. Further, the original document and resulting token embedded document are stored in the sub-vault identified by SVID3 and are accessible to the lead architect and the project manager.

[00124] The approved engineering drawings are subsequently reviewed and approved by the Building Permit Manager, Downtown Toronto (BPD M). The Building Permit Manager, Downtown Toronto may obtain an electronic version of the approved engineering drawings in accordance with the process in FIGs. 7A-7B. Upon approval, the Building Permit Manager, Downtown Toronto may generate a building permit and subsequently sign the building permit in accordance with the process in FIGs. 6A-6C. The token generated and embedded on the building permit using TokenType ID2 is shown in FIG. 9D. Referring to FIG. 9D, Token D includes a 2D barcode. The 2D barcode, has encoded therein, (i) TID encrypted using the service provider key, (ii) optionally, the Building Permit Hash encrypted using the service provider key, (iii) the Building Permit Hash encrypted using the Building Permit Department Key, (iv) the building permit number encrypted using the Building Permit Department Key, and (v) the Building Permit Hash encrypted using the biometric data of the Building Permit Manager, Downtown Toronto (BPDJVI).

[00125] Token D, once generated, is embedded in the building permit in accordance with TokenType ID2. Further, the original document and resulting token embedded document are stored in the sub-vault identified by SVID3 and are accessible to the lead architect and the project manager.

[00126] Finally, during the building inspection, the engineer (BPD E) conducting the building inspection may review the printed approved engineering drawings. Further, during the inspection, the engineer may also scan the appropriate tokens on the approved engineering drawing in order to obtain electronic versions of the approved engineering drawings to confirm that the printed engineering drawings he is reviewing match the engineering drawings he previously approved. Electronic versions of the approved engineering drawings may be obtained by the engineer (BPD E) at the BPD via a client system connected to SPB via a wireless network, while the engineer is at the construction site.

[00127] In one embodiment of the invention, the engineer may download the electronic versions of the approved engineering drawings on to a mobile computing device, such as a laptop. The electronic versions of the approved engineering drawings may be encrypted using the engineer's biometric data. Further, the application on the mobile computing device, used to secure the electronic versions of the approved engineering drawings may be configured to destroy (or render inaccessible) the electronic versions of the approved engineering drawings on the mobile computing after a specified duration of time.

[00128] In order to access the electronic versions of the approved engineering drawings at the construction site, the engineer provides the required biometric data and, upon successful authentication, the electronic versions of the approved engineering drawings are decrypted and displayed on the mobile computing device.

[00129] Upon a successful inspection by the engineer, the Building Permit Manager, Downtown Toronto may generate an occupancy permit and subsequently sign the occupancy permit in accordance with the process in FIGs. 6A-6C. The token generated and embedded on the occupancy permit using TokenType ID2 is shown in FIG. 9E. Referring to FIG. 9E, Token E includes a 2D barcode. The 2D barcode, has encoded therein, (i) TID encrypted using the service provider key, (ii) optionally, the Occupancy Permit Hash encrypted using the service provider key, (iii) the Occupancy Permit Hash encrypted using the Building Permit Department Key, (iv) the occupancy permit number encrypted using the Building Permit Department Key, and (v) the Occupancy Permit Hash encrypted using the biometric data of the Building Permit Manager, Downtown Toronto (BPD M).

[00130] Token E, once generated, is embedded in the building permit in accordance with TokenType ID2. Further, the original document and resulting token embedded document are stored in the sub-vault identified by SVID3 and are accessible to the lead architect and the project manager.

[00131] If the landowner (O) subsequently asserts the he did not sign the construction agreement, the process shown in FIG. 7A-7B may be used to verify that the construction agreement was in-fact signed and the process shown in FIG. 8 may be used to verify that the landowner did in-fact sign the construction agreement. [00132] Further, a TID may be used to identify all related documents for the construction project. For example, if a user obtains a first document with the TID, the user may then be able to review other documents with the same TID or, if present, other documents in the vault or sub-vault in which the first document is stored.

[00133] Referring to FIGs. 10A- 1OB, FIGs. 10A- 1OB show an example of validating the sender of a communication using the SPB in accordance with embodiments of the invention.

[00134] Referring to FIG. 1OA, a sender generates an electronic message for a recipient on a client system (e.g., an electronic mail communication, a short message service (SMS) message, multi-media messaging service, etc.). The client system subsequently applies a hash function to the message (or more specifically the content of the message) to obtain a message ID and obtains biometric data from the sender (see e.g., FIG. 4, Step 412). The client system then sends the message ID and sender's biometric data to the SPB.

[00135] The SPB, upon receipt of the message ID and sender's biometric data, encrypts the message ID using the sender's biometric data (and an appropriate encryption algorithm). Further, the SPB obtains and encrypts a sender ID (e.g., a name, address, e-mail, numeric code, alphanumeric code, etc.) with a service provide key. The SPB subsequently generates a token (e.g., the token shown in FIGs. 2A-2B) that encodes the encrypted message ID and encrypted sender ID, and sends the resulting token to the sender (or more specifically, the client system used by the sender). The sender (via their client system) sends the message and token (together or separately) to a client system of the recipient. For example, the message may be sent via SMS and the token may be sent via MMS. In another example, the message and token are sent in a single electronic mail communication. Alternatively, the message may be sent in one electronic mail communication and the token may be sent in another electronic mail communication. [00136] Referring to FIG. 1OB, the receiver upon receipt of the message and the token, send (via their client system) the token to the SPB. The SPB extracts the encrypted sender ID from the token and decrypts the encrypted sender ID using the service provider key. The decrypted sender ID is used to obtain the sender's biometric data stored on the SPS (not shown), which is accessible via the SPB. The SPB extracts the encrypted message ID from the token and decrypts the encrypted message ID using the sender's biometric data. The SPB subsequently provides the message ID to the receiver.

[00137] The receiver (or more specifically, the client system used by the receiver) subsequently applies a hash function to the message (or more specifically the content of the message) to obtain a message ID. The message ID calculated by the receiver is compared with the message ID obtained from the SPB. If they match, the sender is verified; if not then the sender of the message is not verified.

[00138] Computer readable program code to perform embodiments of the invention may be stored on a computer readable medium such as a compact disc (CD), a diskette, a tape, physical memory, or any other physical computer readable storage medium that includes functionality to store computer readable program code to perform embodiments of the invention. In one embodiment of the invention the computer readable program code, when executed by a processor(s), is configured to perform embodiments of the invention.

[00139] While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other embodiments can be devised which do not depart from the scope of the invention as disclosed herein. Accordingly, the scope of the invention should be limited only by the attached claims.

Claims

CLAIMS What is claimed is:

1. A computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising:

receiving a request from a user to sign a document by a service provider;

obtaining a transaction identifier (ID);

obtaining biometric data for the user;

applying a hash function to the document to obtain a hash value;

obtaining a TokenType ID associated with the user;

generating a token using the TokenType ID, the biometric data, the transaction

ID, and the hash value, wherein the token comprises a machine-readable representation of data; and

embedding the token on the document to obtain a token embedded document.

2. The computer readable medium of claim 1, further comprising:

storing the token embedded document in a service provider storage; and recording transaction information associated with embedded the token on the document.

3. The computer readable medium of claim 2, further comprising:

setting an access permission associated with the token embedded document, wherein the access permission is used to determine which users can access the token embedded document in the service provider storage.

4. The computer readable medium of claim 3, wherein the access permission is one selected from a group consisting of redacted viewing, viewing, redacted read-only, read-only, redacted related, and related.

5. The computer readable medium of claim 2, wherein the transaction information comprises a user ID for the user, a time the token was generated, and a date on which the token was generated.

6. The computer readable medium of claim 2, wherein storing the token embedded data in the service provider storage comprises storing the token embedded document in a vault, wherein access to the vault is controlled using an access control management service.

7. The computer readable medium of claim 1, wherein the machine readable representation of data is an optical machine-readable representation of data.

8. The computer readable medium of claim 1, wherein the optical machine-readable representation of data is a two-dimensional (2D) barcode.

9. The computer readable medium of claim 1, wherein the machine-readable representation of data is a radio-frequency identification (RFID) tag.

10. The computer readable medium of claim 1, further comprising:

registering the user prior to receiving the request from the user to sign the document.

11. The computer readable medium of claim 10, wherein registering the user comprises obtaining biometric data for a witness.

12. The computer readable medium of claim 11, wherein the witness is one selected from a group consisting of a standard witness, an executive witness, and a super witness.

13. The computer readable medium of claim 1 , wherein the biometric data comprises one selected from a group consisting of a fingerprint of the user, an iris scan of the user; a signature of the user obtained using a sensor tablet, and an image of the user's face.

14. The computer readable medium of claim 1, wherein the biometric data comprises two selected from a group consisting of a fingerprint of the user, an iris scan of the user; a signature of the user obtained using a sensor tablet, and an image of the user's face.

15. The computer readable medium of claim 1, wherein generating the token using the TokenType ID comprises:

encrypting the transaction ID with a service provider key to obtain an encrypted transaction ID;

encrypting the hash value with the biometric data and an encryption algorithm to obtain a first encrypted hash value; and

generating the machine readable representation of data using the encrypted transaction ID and the first encrypted hash value.

16. The computer readable medium of claim 15, wherein generating the token using the TokenType ID further comprises:

encrypting the hash value with a legal entity encryption key to obtain a second encrypted hash value, wherein the user is one selected from a group consisting of the owner of the legal entity and an employee of the legal entity,

wherein generating the machine readable representation of data further comprises using the second encrypted hash value.

17. The computer readable medium of claim 1, wherein embedding the token on the document further comprises:

determining a size and shape of the token using the TokenType ID;

wherein generating the machine readable representation of data further comprises using the size and shape of the token.

18. The computer readable medium of claim 1, wherein embedding the token on the document comprises:

determining a page in the document to embed the token using the TokenType

ID; and

determining a location of the page in the document to embed the token using the TokenType ID,

wherein the token is embedded on the document at the location on the page in the document.

19. A computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising:

receiving data corresponding to a machine-readable representation of data from a user, wherein the machine-readable representation of data is affixed on a physical document;

obtaining an encrypted transaction identifier (ID) from the data;

decrypting the encrypted transaction ID to obtain the transaction ID using a service provider key;

obtaining a first hash value from a service provider backend using the transaction ID;

obtaining an encrypted hash value from the data;

decrypting the encrypted hash value to obtain a second hash;

determining whether the first hash value is equal to the second hash value; when the first hash value is not equal to the second hash value, notifying the user of an error;

when the first hash value is equal to the second hash value:

determining whether the user is authorized to view an electronic version of the physical document; and

providing the electronic version of the physical document to the user, when the user is authorized to view the electronic version of the physical document.

20. The computer readable medium of claim 19, further comprising:

authenticating the user prior to determining whether the user is authorized to view the electronic version of the physical document, wherein authenticating the user comprises obtaining biometric data from the user and comparing the obtained biometric data with stored biometric data by the service provider backend.

21. The computer readable medium of claim 19, wherein decrypting the encrypted hash value to obtain the second hash comprises:

obtaining biometric data from the user;

obtaining a TokenType ID for the token using the transaction ID;

identifying an encryption algorithm using the TokenType ID; and

decrypting the encrypted hash value using the biometric data and the encryption algorithm.

22. The computer readable medium of claim 19, wherein decrypting the encrypted hash value to obtain the second hash comprises:

obtaining biometric data for a signatory of the physical document, wherein the user is not the signatory;

obtaining a TokenType ID for the token using the transaction ID;

identifying an encryption algorithm using the TokenType ID; and

23. The computer readable medium of claim 19, wherein decrypting the encrypted hash value to obtain the second hash comprises:

decrypting the encrypted hash value using the service provider key.

24. The computer readable medium of claim 19, wherein obtaining the first hash value from the service provider backend using the transaction ID, comprises:

obtaining an electronic version of the physical document using the transaction ID; and applying a hash function to the electronic version of the physical document to obtain the first hash value.

25. The computer readable medium of claim 19, wherein the data is obtained using a barcode scanner and the machine readable representation of data is a two- dimensional (2D) barcode.

26. The computer readable medium of claim 19, wherein the token is affixed to the physical document as one selected from a group consisting of a printed image of the token on the physical document and a label comprising printed the image of the token, wherein the label is affixed to the physical document.

27. The computer readable medium of claim 19, wherein receiving the data comprises:

receiving an image of the optical machine readable representation of data.

28. The computer readable medium of claim 19, wherein the data is obtained using a barcode scanner, and wherein the machine-readable representation of data is a radio-frequency identification (RFID) tag.

29. A computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising:

receiving scanned barcode data associated with a two-dimensional (2D) barcode from a user, wherein the 2D barcode is printed on a physical document;

obtaining an encrypted transaction identifier (ID) from the scanned barcode data;

obtaining an encrypted hash value from the scanned barcode data; decrypting the encrypted hash value to obtain a second hash;

determining that the first hash value is equal to the second hash value;

determining that the user is authorized to view an electronic version of the physical document;

providing the electronic version of the physical document to the user;

receiving a document operation request from the user for a related document; and

providing the user access to the related document based on an access permission of the user.

30. The computer readable medium of claim 26, wherein the access permission is one selected from a group consisting of redacted viewing, viewing, redacted read-only, read-only, redacted related, and related.

31. The computer readable medium of claim 26, wherein the document operation request is one selected from a group consisting of viewing information associated with the related document, reading the related document, and modifying the related document.

32. The computer readable medium of claim 28, wherein the information associated with the related document comprising at least one selected from a group consisting of a signatory of the related document, date the signatory signed the related document, time the signatory signed the related document, and a TokenType ID of a token in related document.

33. The computer readable medium of claim 26, wherein the related document is associated with the transaction ID.

34. The computer readable medium of claim 30, wherein the related document is associated with a vault ID and wherein the transaction ID is associated with the vault ID.

35.A computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising:

receiving message to send from a sender to a recipient, wherein the message comprises message content;

applying a hash function to the message content to obtain a message identifier

(ID);

obtaining sender biometric data;

sending the message ID and the sender biometric data to service provider backend;

receiving, in response to the sending, a token from the service provider, wherein the token comprises an encrypted sender ID and an encrypted message ID, wherein the encrypted message ID is generated using the sender biometric data; and

sending the message and the token to the recipient.

36. The computer readable medium of claim 32, wherein the encrypted sender ID is generated using a service provider key and a sender ID.

37. The computer readable medium of claim 32, wherein the message and the token are sent to the recipient in a single electronic mail communication.

38. The computer readable medium of claim 32, wherein the message is sent to the recipient in a first electronic mail communication and the token is sent to the recipient in a second electronic mail communication.

39. The computer readable medium of claim 32, wherein the sender biometric data comprises one selected from a group consisting of a fingerprint of the sender, an iris scan of the sender; a signature of the sender obtained using a sensor tablet, and an image of the sender's face.

40. The computer readable medium of claim 32, wherein the message is a short message service (SMS) message and the token is sent to the recipient in a multimedia messaging service (MMS) message.

41. A computer readable medium comprising computer readable program code embodied therein for causing a processor to perform a method, the method comprising:

receiving, from a sender, a message and a token by a recipient, wherein the message comprises message content, wherein the token comprises an encrypted sender identifier (ID) and an encrypted message ID;

sending the token to a service provider backend;

receiving, in response to the sending, a first message ID from the service provider backend, wherein the service provider is configured to:

decrypt the encrypted sender ID to obtain the sender ID, obtain sender biometric data using the sender ID, and

decrypt the encrypted message ID using the sender biometric data to obtain the first message ID; and

applying a hash function to the message content to obtain a second message ID; determining whether the first message ID is equal to the second message ID; when the first message ID is not equal to the second message ID, notifying the recipient that the sender is not verified;

when the first message ID is equal to the second message ID, notifying the recipient that the sender is verified.

42. The computer readable medium of claim 38, wherein the encrypted sender ID is decrypted, using a service provider key, to obtain the sender ID.

43. The computer readable medium of claim 38, wherein the message and the token are received by the recipient in a single electronic mail communication.

44. The computer readable medium of claim 38, wherein the message is received by the recipient in a first electronic mail communication and the token is received by the recipient in a second electronic mail communication.

45. The computer readable medium of claim 38, wherein the message is a short message service (SMS) message and the token is received in a multi-media messaging service (MMS) message.

46. The computer readable medium of claim 38, wherein the sender biometric data comprises one selected from a group consisting of a fingerprint of the sender, an iris scan of the sender, a signature of the sender obtained using a sensor tablet, and an image of the sender's face.