Generation and sharing of secure data records for point-in-time verification of identity and location, including for enabling robust event recordal, secure execution of documents via external user verification process which generates unique check-in event data and / or identity exchange via external user verification process which generates unique check-in event data

Abstract

The present invention relates, in various embodiments, to technology configured to facilitate generation and sharing of secure data records for point-in-time verification of identity and other associated data. Embodiments of the invention are primarily directed to enable generation of robust digital records representative of point-in-time events involving known persons at known locations, in a format which enables sharing for a range of downstream purposes. The technology is in some embodiments applicable to documents executed electronically and via "wet signatures" (i.e. where a physical handwritten signature is applied in pen). In further embodiments the technology provides two-way confirmation of identity, thereby to facilitate interaction between two parties. In some embodiments this is used in the context voice and / or text communications between a business and a customer, or between two private individuals (for example in the context of a transaction). While some embodiments will be described herein with particular reference to those applications, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts.

Description

GENERATION AND SHARING OF SECURE DATA RECORDS FOR POINT-IN-TIME VERIFICATION OF IDENTITY AND LOCATION, INCLUDING FOR ENABLING ROBUST EVENT RECORDAL, SECURE EXECUTION OF DOCUMENTS VIA EXTERNAL USER VERIFICATION PROCESS WHICH GENERATES UNIQUE CHECKIN EVENT DATA AND / OR IDENTITY EXCHANGE VIA EXTERNAL USER VERIFICATION PROCESS WHICH GENERATES UNIQUE CHECK-IN EVENT DATAFIELD OF THE INVENTION

[0001] The present invention relates, in various embodiments, to technology configured to facilitate generation and sharing of secure data records for point-in-time verification of identity and other associated data, for example location. Embodiments of the invention are primarily directed to enable generation of robust digital records representative of point-in-time events involving known persons at known locations, in a format which enables sharing for a range of downstream purposes. The technology is in some embodiments applicable to documents executed electronically and via “wet signatures” (i.e. where a physical handwritten signature is applied in pen). In further embodiments the technology provides two-way confirmation of identity, thereby to facilitate interaction between two parties. In some embodiments this is used in the context voice and / or text communications between a business and a customer, or between two private individuals (for example in the context of a transaction where there is a desire to ensure that a seller is a trusted individual and not a “scammer”). While some embodiments will be described herein with particular reference to those applications, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts.BACKGROUND

[0002] Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field.

[0003] Smartphones and other mobile devices have become central to modern society. These devices intrinsically allow users to capture point-in-time information, for example via location tracking applications, metadata tagging of photographs, and the like. However, such intrinsic features fallshort of technical requirements to generate secure records of activities and events in an organised and / or conveniently usable manner.

[0004] Execution of documents is an unavoidable necessity in many areas of modern society, both in a commercial and personal context. There are inherent challenges in gaining certainty as to whethera particulardocument was executed by the purported signatory. Approaches for overcoming this range from unreliable (for example having a witness execute alongside the signatory, which is readily fraudulently achieved) to cumbersome (for example having a lawyer or the like perform manual identify verification for the signatory and, where relevant, witnesses). There are also issues associated with fraudulent identification and the like, which affect reliability of the overall process.

[0005] There are a number of technologies which have sought to improve document execution practices by allowing electronic execution (and providing additional security layers in that regard). However, those have tended to be unsuitable for widescale adoption by the general public. In general terms, the field of computing directed towards electronic execution of documents remains faced with a wide range of technical problems, requiring technical solutions in the field of computing technology to overcome.

[0006] Remote interactions have for some time become the norm when it comes to communication. For example, this includes situations where a provider (e.g. business) interacts with a customer via voice / video / text communications. In such scenarios, there are inherent challenges in verifying the identities of the parties. For example, a provider wishes to know that they are actually interacting with a particular customer (and not an imposter), and likewise a customer wishes to know that they are dealing with a legitimate provider (and not some form of scam).

[0007] Various approaches are commonly used to assist a provider in verifying (theoretically) the identity of a person with whom they are interacting, for example the use of passcodes, secret questions, personal information, and the like. These are imperfect solutions.SUMMARY OF THE INVENTION

[0008] It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

[0009] Example embodiments are described below in the section marked “claims”.

[0010] A system configured to enable generation and sharing of secure data records for point- in-time verification of identity and location, the system including: an authentication module configuredto perform biometric authentication of a user of a mobile device, thereby to verify an identity of the user of the mobile device based on a predefined identity record; a location module configured to determine an authentication location of the mobile device, including positional data determined at a time corresponding to the biometric authentication; a record generation module configured to cause storing of a check-in record in a cloud-hosted database, wherein the check-in record includes components which provide data representative of (i) the biometric authentication; (ii) the verified identity; (iii) the authentication location; and (iv) an authentication time; an encoding module configured to cause encoding of: (i) a record URL which is configured to, when accessed, cause rendering of data extracted from the check-in record; and (ii) a QR code configured to cause accessing of the record URL; and an event image generation module configured to cause generation of an event image containing graphical representations of: (i) one or more components of the checkin record; and (ii) the QR code; such that the event image is able to be shared via communications channels, and data displayed in the event image is able to be verified against data stored in the cloud-hosted database via the record URL.

[0011] One embodiment provides a method for facilitating document execution, the method including: accessing an authored electronic document; operating an External Verification Compliant (EVC) document generation module thereby to process the authored electronic document and generate an EVC document containing content from the authored electronic document, wherein the EVC document has an associated unique document code (UDC) which is unique to the EVC document; wherein an external user verification system is configured enable generation of check-in records via user verification software applications executing at distributed user devices, wherein each check in record is generated via a process wherein a user of a given one of the user devices is required to undergo biometric identity verification, wherein each check-in record is associated with data representative of:(i) successful biometric identity verification for the user;(ii) one or more additional check-in-specific data values; and(iii) a unique Check-In Record Identifier (CRI) for the check-in record;

[0012] wherein a check-in record management system is configured to securely maintain data representative of the check-in records, such that a given record is able to be viewed via a data query including the associated CRI for that record; and wherein the EVC includes a field into which a signatory inputs an execution CRI, being a CRI associated with execution of the document at the time of execution.

[0013] One embodiment provides a system configured to enable inter-party identification verification in the context of an electronic remote interaction, the system including: a server system which is configured to communicate with a plurality of mobile devices which each execute respective instances of User Verification Software Application (UVSA), wherein the UVSA executes at a plurality of user devices, wherein each instance of the UVSA is configured to perform a check in process which includes:(i) performing a point-in-time biometric identify verification of a specific person having an associated with a UVSA ID;(ii) generating a Check In Record (CIR), wherein the CIR is a dataset including (a) data including data representative of the biometric identification verification (and preferably location); (b) data representative of one or more artefacts of objective point-in-time evidence; and (c) a Check In Record Identifier (CRI) which uniquely identifies the Check in Record; and(iii) transmitting the CIR to the server system;

[0014] wherein the server system is additionally configured to process CIRs received from instances of the UVSA and store those CIRs in a CIR database, wherein the CIR database is configured to enable access to data for a given CIR based on a query which includes the CRI forthat CIR, wherein the access includes enabling rendering of a web page at a client device, the web page being configured to present the data the given CIR in a predefined format; wherein the system includes a prompt-trigger module associated with the server system, wherein the prompt-trigger module is configured to receive, from an external prompt-requestor module, input representative of a specified UVSA ID and, in response: (a) cause the instance of the UVSA associated with that UVSA ID to display a CIR-prompt for generation of a CIR having defined CIR parameters; (b) monitor for generation of a CIR having defined attributes corresponding to the CIR-prompt; and (c) in the case that a CIR having defined attributes corresponding to the CIR-prompt is identified, cause transmission of the CRI for that CIR to the prompt-requestor module; such that an operator of the prompt requestor module is able to access the CIR having defined attributes corresponding to the CIR-prompt, thereby perform data validation relative to the defined CIR parameters.

[0015] Reference throughout this specification to “one embodiment”, “some embodiments” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in some embodiments” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment, but may refer to the same embodiment in some cases. Furthermore, the particular features, structures orcharacteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

[0016] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0017] In the claims below and the description herein, any one of the terms comprising, comprised of or which comprises is an open term that means including at least the elements / features that follow, but not excluding others. Thus, the term comprising, when used in the claims, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Any one of the terms including or which includes orthat includes as used herein is also an open term that also means including at least the elements / features that follow the term, but not excluding others. Thus, including is synonymous with comprising.

[0018] As used herein, the term “exemplary” is used in the sense of providing examples, as opposed to indicating quality. That is, an “exemplary embodiment” is an embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

[0020] FIG. 1A provides a representation of an implementation of user verification technology described herein according to one embodiment.

[0021] FIG. 1 B provides a representation of an implementation user verification technology according to one embodiment.

[0022] FIG. 2A illustrates a verification method according to one embodiment.

[0023] FIG. 2B illustrates a verification method according to one embodiment.

[0024] FIG. 3A to FIG. 3C illustrate example screenshots according to one embodiment.

[0025] FIG. 4A illustrates an example technology framework according to one embodiment.

[0026] FIG. 4B illustrates an example technology framework according to one embodiment.

[0027] FIG. 5A illustrates a method according to one embodiment.

[0028] FIG. 5B illustrates a method according to one embodiment.

[0029] FIG. 6A illustrates an example technology framework according to one embodiment.

[0030] FIG. 6B illustrates an example technology framework according to one embodiment.

[0031] FIG. 7A illustrates a method according to one embodiment.

[0032] FIG. 7B illustrates a method according to one embodiment.DETAILED DESCRIPTION

[0033] The present invention relates, in various embodiments, to technology configured to facilitate generation and sharing of secure data records for point-in-time verification of identity and other associated data. Embodiments of the technology provide advantages in the operation of computer technology to enable significant improvements in relation to data integrity and trust in the digital world. These enable generation of robust digital records representative of point-in-time events involving known persons at known locations, in a format which enables sharing for a range of downstream purposes.

[0034] A range of improvements in computer technology resulting from the innovative record generation and sharing technology disclosed herein, described by reference to “check-in records: (CIRs) which are defined subject to respective check in record generation procedures. For example:• Some embodiments apply the technology forthe purposes of generation evidentiary records, for example to evidence that best practice has been followed during a building / construction task, to verify that a particular person (e.g. a particular person with a known and proven identify) completed a designated task at a designated location, and a wide range of other applications.• Some embodiments apply this technology as a means to efficiently map between biometric identification of an individual and formal verification of identify (e.g. against governmentbased databases). For example, each biometric identity set up for the system is matched to a government issued ID (also using biometric means), meaning that a name and biometric identity can be verified as a particular person of that name. Accordingly, use of a check-in record allows a third-party business (or the like) to perform a relatively simple “know your customer” check to determine that a person / user is indeed who they claim substantially in real time.• Some embodiments apply the technology in the context of executing documents, and may be implemented to documents that are executed electronically and those that are executed via “wet signatures” (i.e. where a physical handwritten signature is applied in pen).• Some embodiments apply the technology in a manner that enables two-way confirmation of identity, thereby to facilitate interaction between two parties. In some embodiments this is used in the context voice and / or text communications between a business and a customer, or between two private individuals (for example in the context of a transaction).• Some embodiments apply the technology to provide accountability to posts / comments made in online environments (e.g. social media and / or forums), requiring a userto perform a check in and enterthe CIR unique identifierwhenever posting / commenting, such that online actions can be associated with point-in-time verification of biometric identity.• Some embodiments apply the technology to collect evidence of real-world recordings, for example as a means to evidence meter readings (for example water / gas / electricity meters). This may allow users to provide their own meter readings to service providers in a manner which is able to be verified in terms of user, time and location (with images).• Some embodiments apply the technology to enable verification of documents such as medical prescriptions. For example, a CIR may be generated by a prescribing doctor, with photo of a paper prescription in true and correct form, which may be used by a pharmacist to verify a hard copy prescription’s accuracy.

[0035] While some embodiments will be described herein with particular reference to those applications, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts.Check-In Record Generation Technology

[0036] In overview, technology described in the embodiments below relates to generation of evidentiary records via mobile devices (also referred to herein as check-in records, or CIRs). These evidentiary records each provide a reliable set of data relating to a real-world event, including details of biometric authentication, verified identity, location, date / time, and optionally other information (including captured media items, such as images, video and / or audio). The technology is additionally configured to facilitate convenient sharing of these records - without requiring specialised software for a recipient - using a combination of fixed images and database retrieval (optionally in combination with additional layers of security / sources of truth).

[0037] FIG. 1A illustrates a system according to one embodiment, being a system configured to enable generation and sharing of secure data records for point-in-time verification of identity and location. The system includes an example mobile device 120. Mobile device 120 executes computer executable code, illustrated as a mobile app module 130. In an alternate embodiment functions of mobile app module 130 are in part or in whole native to an operating system which executes on device 120.

[0038] Mobile app module 130 includes an authentication module 132 configured to perform biometric authentication of a user of a mobile device, thereby to verify an identity of the user of the mobile device based on a predefined identity record.

[0039] The predefined identity record is preferably defined based on a process which leverages an official (e.g. government backed) identity document or system. For example, in one embodiment a user is required to undertake an identity registration process, whereby they provide a government issued photo ID, which is preferably validated against an official registry, and a point-in-time captured biometric signal (e.g. facial capture) is matched against that photo ID thereby to verify that the user in indeed the same person as in the government-issued ID. In some cases government digital ID systems are used. In any case, the mobile app module is able to generate a biometric data set (e.g. biometric token) against which future biometric authentications are able to be matched, with this providing robust evidence that a person who matches a particular official / government backed ID is the user of the app.

[0040] In some embodiments the predefined identity record carries with it a plurality of verified values, for example extracted from official databases (or verified against official databases) in conjunction with user identity. These may include, for example, official identification numbers (e.g. license numbers, student ID numbers, director ID numbers, medical insurance numbers, and the like), which may be optionally added to CIRs defined in accordance with the disclosure below.

[0041] Authentication module 132 operates in conjunction with a biometric input module 131. In the present embodiment biometric input module 131 is configured to obtain media (e.g. image) data from an image capture device provided by mobile device 120. Module 131 is additionally configured to extract facial biometric data from captured media data (including utilisation of live-capture video). Alternate and / or additional biometric data may be used). This data is used by authentication module 132 to enable comparison of biometric data against an existing repository of biometric data, thereby to enable identity verification. In the illustrated embodiment authentication module 132 is in communication with a cloud-based authentication and identification verification service 141 . By way of example, encrypted biometric data may be transmitted from authentication module 132 to service 141 , optionally in combination with an anticipated identity, and service 141 responds with a signal representative of either successful identity verification or unsuccessful identity verification. In some embodiments identify authentication and / or verification is performed at the local device without accessing a cloud-based service. Authentication module 132 additionally in this embodiment performs further tasks to ensure appropriate levels of robustness in identity verification. This may include capture of extended video data in which a subject is instructed to perform certain physical tasks, for example movement of the head and presentation of raised fingers. This is processed to ensure that the biometric signal is derived from a live video capture of a subject, as opposed to being based on pre-recorded image information.

[0042] Based on the operation of authentication module 132, record generation module 134 is provided with a data set uniquely identifying an individual for whom identity verification has been successfully completed. This preferably includes a name, and additionally a unique identifier associated with that identity, thereby to allow resolution of uncertainties given the potential for duplicate names. Record generation module 134 in response triggers generation of a new check-in record (CIR). A CIR is a data structure which uniquely binds a set of information comprising identify in combination with other data artefacts which may include location, point-in-time captured images (or other media items, such as video or audio), consent / agreement in relation to specified terms, and others.

[0043] A location module 133, for example with access to a GPS sensor and optionally barometric sensor, is configured to determine an authentication location of the mobile device, including positional data determined at a time corresponding to the biometric authentication. For example, this time maybe within a threshold number of seconds of collection of the biometric input data which led to identity verification. In this manner, the authentication location corresponds to the location of the mobile device at or around the time at which biometric data was collected from the user. Record generation module 134 is presented with the authentication location information from location module 133, and adds that data to the new check-in record. The location data may be cross-referenced against an external database thereby to predict an address / location based on GPS coordinates.

[0044] Additional data is also added to the new check-in record, for example a check-in time, including date information, and optionally media such as images captured by the same device within a threshold time of record generation (e.g. a prescribed number of seconds preceding or following the biometric authentication). In some cases the CIR is generated (with a unique ID assigned) and able to be updated with additional data, such as images, for a prescribed period of time (for example under one minute, or more preferably under 30 seconds).

[0045] The additional data may include additional data associated with the authenticated identity, for example other identification numbers (e.g. student ID, director ID, medical insurance ID, social security number, etc), allowing for a CIR to share such an identification number in conjunction with a record of biometric authentication.

[0046] Additional data requirements fora given CIR may be predefined by an automated process, for example where a CIR is generated in response to a prompt, the prompt having an associated CIR data requirement template. For example, and as discussed in examples further below, a CIR may be prompted by a third party, and the prompt may use a template associated with data requirements (for example requesting a particular image, a license number, a student ID number, a director ID number, agreement to a contract or set of terms, and so on). This allows businesses and other parties to request particular forms of CIRs for defined purposes. In some embodiments a user is able to manually select from a plurality of template CIR types when creating a CIR.

[0047] Record generation module 134 is configured to cause storing of a check-in record in a cloud-hosted database 144 (a copy may also be maintained locally on the user’s device(s). In this embodiment, the check-in record contains identical information both at the mobile app side and at a server side. At the server side, a record generation and encoding module 142 operates in communication with check-in record generation module 134, thereby to coordinate generation of corresponding data. The check-in record includes components which provide data representative of (i) the biometric authentication; (ii) the verified identity; (iii) the authentication location; (iv) an authentication time; and (v) other data artefacts such as media (e.g. images).

[0048] An encoding module 136 configured to cause encoding of: (i) a record URL which is configured to, when accessed, cause rendering of data extracted from the check-in record; and (ii) a QR code configured to cause accessing ofthe record URL. Some orall functions of encoding module 136 may optionally be performed by server-side module 142. In any event, the encoded information is available by mobile app module 130. This enables an event image generation module to causegeneration of an event image containing graphical representations of: (i) one or more components of the check-in record; and (ii) the QR code. This event image is able to be shared via various communications channels (e.g. MMS, email, WhatsApp and other messaging apps, Facebook Messenger and other social media-based communications, and other messaging platforms) via a sharing module 138, allowing evidence of a check-in event to be shared quickly and conveniently with third parties, without requiring those third parties to execute a specialist software application. Furthermore, data displayed in the event image is able to be verified against data stored in the cloud- hosted database via the record URL. In this manner, the event image may be used as a primary source of truth, validated against a secondary source of truth provided via database 144 (accessed via a predefined URL / QR Code or the like). That is, the event image is able to be viewed by a user, and in the event that the user wishes to confirm authenticity, then the QR code I hyperlink is used to download data from database 144, thereby to enable rendering of CIR data downloaded from a trusted central data source. Preferably additional security is implemented to prevent phishing and / or other fraudulent activities (e.g. in-app rendering which ensures the web domain is valid and correctly references database 144 ass opposed to a fraudulent data source) /

[0049] In a further embodiment there may be one or more additional layers of data integrity. For example, in a further embodiment a hashing algorithm is used to generate hashed digests of the event record and / or components of the event record, and add those to a further storage repository (which may include a blockchain). The hashing algorithm is repeatable, such that either or both of data provided by the event image and corresponding data stored in database 144 can be audited against hash digests thereby to ensure that neither has been modified and / or tampered with since the time of creation.

[0050] FIG. 3A illustrates an example user interface display which shows an example event image 300 generated as discussed above. Event image 300 includes the following components:• A unique validation number 301 (for example an alphanumeric UID). This number may be used to uniquely identify a check-in record defined in database 144. For example, a user may visit a defined webpage, and input the unique validation number, thereby to access a rendering of the relevant event record based on data downloaded from database 144. The unique validation number may optionally form part of the record URL.• Name information 302. As illustrated, this is a first name / last name combination. This may additionally include a unique identification number associated with the verified identity.• Biometric authentication image data 303. In the present embodiment this includes an image extracted from the biometric input data, showing a facial region of the user who’s identify is verified.• Location data 304, which in this example is displayed as address information. This address information is preferably derived from GPS information (and / or elevation / altitude information). In some embodiments GPS information and / or other spatial information is provided in addition and / or as an alternative.• Time information, which in this case is defined by time and date. Time zone information may also be provided, based on the location data.• A hyperlink 306. It will be appreciated that embedding of hyperlinks is not possible under certain image encoding standards, and / or may not be compatible in certain viewing applications. In some embodiments the hyperlink is excluded.• A QR code 307. This is encoded thereby to access a web page which is configured to extract and present components of the check-in record from database 144 (e.g. a hyperlink is encoded in the QR code, optionally being an in-app link or a conventional web domain link). Database 144 may provide access to additional information (for example captured content, such as images, video, audio and other content able to be captured by device hardware), as discussed further below. The QR code may be embedded / watermarked on captured content (such as a photo or video), allowing for the captured content to in effect have an embedded hyperlink through visual attributes.• A validation checkmark 308, which optionally provides information regarding a manner by which the check-in record is validated. This may optionally reference a source of identity verification associated with service 141.

[0051] Additional metadata may also be appended to the image file, for example any one or more of the following components of information. This additional metadata may be contained and / or encoded into existing metadata fields defined by an IPTC Photo Metadata Standard via a predefined algorithm.• A device UID on which the mobile app was executing.Biometric signature information associated with the identify verification.• GPS and other data for the location information (e.g. including barometric).• Additional identify information, for example a identify UID used by service 141 .

[0052] FIG. 3A illustrates a “share” button 310. This optionally accesses conventional sharing functions available via the operating system of device 102, for example displaying options of various sharing technologies and / or applications (e.g. iMessage, MMS, email, Airdrop, other applications, and the like). This facilitates conventional sharing of the compiled event image 300.

[0053] FIG. 3A illustrates an “add photo” button 309. This allows a user to associate a captured image with the check-in record. In this regard, the system of FIG. 1A includes a captured image management module 137 which is configured to:(i) Identify a captured image captured via hardware of the mobile device satisfying predefined requirements. For example, the predefined requirements may optionally include a requirement that the capture is performed via an in-app controlled access to image capture hardware, a requirement that the image is captured within a predefined number of seconds of the biometric data input (optionally preceding or following), a requirement that the image is captured within a threshold distance of the location data derived corresponding to biometric data input, and / or other requirements. These may be verified using in-app measures (e.g. app-controlled image capture) and / or processing of image metadata.(ii) Generate a watermarked version of that captured image containing visual representations of (A) one or more components of the check-in record; and (B) the QR code. An example watermarked image is provided in FIG. 3B. The watermarked version of the captured image 310 includes check in record information 312 and the check in record QR code 312, and additionally contains text data generated by the user 31 1 . The example of FIG. 3B provides a user interface rendering including additional Ul components, which are not necessarily present in a final compiled watermarked captured image.

[0054] A photo is used as an example only; other forms of content captured via the device (such as video, audio, motion, and the like) may also be used. That is, wherever the example of a photo or image is used, this should be read as a feature that is able to be exchanged with other forms of captured content.

[0055] The mobile app module includes an upload module configured to cause storing of the watermarked version of the captured image in the cloud-hosted database in a manner accessible via the record URL (for example as associated images or the like).

[0056] Sharing module 138 is additionally configured to enable sharing of watermarked images generated by module 137. This provides a quick and effective means for a person to share a photo of a real-world artefact (for example a delivery, signature of a document, evidence of works completed, and so on) with third parties in a manner which enable robust confirmation of associated location and identity.

[0057] FIG. 3C illustrates an example history interface accessible via button 311 of FIG. 3A. This provides a list of historical check-ins performed by device 120 (and resulting CIRs).

[0058] In some embodiments one or more additional data integrity modules is / are configured to provide additional robustness to data integrity. For example, these may operate at the app and / or server side, and create immutable evidence to support data generated by the app module and / or server system. In an example embodiment, this includes a module which is configured to apply a predefined hash algorithm to one or more components of a check-in record (optionally including an image itself, being a captured image or event image), and / or data derived from to one or more components of the check-in record, and cause storage of one or more digests generated by the hash algorithm. For instance, the one or more digests are added to a blockchain. In this manner, there is an immutable record in the form of a repeatable hash algorithm, digest which may be used to verify that data extracted at a specific point in time is unchanged from data that was defined at an earlier point in time.

[0059] In some embodiments, a check-in record is used to facilitate management of individuals arriving at a location. For example, this could be for the purposes of security, site management, employment / employee management event entry, transportation, and so on. An example is provided in FIG. 1 B, which illustrates, in addition to the subject matter of FIG. 1A, a site-specific check in terminal 150. This may, for example, be a tablet device or other mobile device. A user performs a check-in as discussed above using device 120 and app 130, thereby to generate an event image. The QR code of that event image is then read using an image capture module 151 . This allows a data access module 152 to access via the QR code URL data from secure database 144. This data is processed by a rules module 153, optionally to verify whether access is to be granted (for example based on verified ID, which may be compared to a list of expected persons, and based on a check that the check-in record is representative of a correct accurate time and place). Based on output of the rules module a check-in register module 154 may update a check in database 155, thereby to confirm that a person of verified identity has arrived and been acknowledged. A check-out module 156 may also be used, thereby to manually check out people based on scanning of the QR code from a further event image, or based on other data representing that device 120 is no longer within a predefined geographic boundary.

[0060] It will be appreciated that the technology discussed above may serve numerous purposes, including site-specific check ins via a terminal 150, and numerous others. For example, use cases include:• Performing a check-in in combination with execution of a document. For example, a person signs a document and performs a check in, and manually adds the check-in unique number (validation number) to the document. This provides evidence of location and identity of a person signing a document. Preferably this is supplemented with a photo of the signed document carrying the validation / verification number, which is watermarked via model 137 with the associated check-in record details, thereby closing an evidentiary loop.• Verifying that works have been completed, and the quality of completed works. This confirms that a person has been in a specific place at a specific time, in combination with watermarked image data.• Confirming that auditing personnel have indeed physically attended specific locations at which inspections are to be performed.• Evidencing damage to goods or the like (for example rental vehicles upon collection, goods as delivered by couriers, and the like).• Work attendance (e.g. to prevent wage theft and the like). For example, a CIR can be used to confirm attendance at a work location, for the purposes of commencing and / or completing a work shift.• Online dating, for example in conjunction with existing dating apps, for users to provide evidence confirming their identity and appearance in a quick and high-trust manner (for example by providing a CIR to another person with whom they are communicating).• Confirming signing of documents or other agreements. For example, a user is able to create a CIR when executing a document, photograph the document for storage with the CIR, and add the CIR unique identifier to the document. Preferably the process flow allows for the CIR unique identifier to be added to the document before a photo is taken and added to the CIR (e.g. in a time-critical manner).• Managing corporate governance. For example, company directors are prompted to generate a CIR as evidence of agreeing to decisions, motions and the like, thereby to maintain a record for corporate accountability.

[0061] This presents a representative selection only; the scope for applications of technology discussed herein is far wider.

[0062] FIG. 2A illustrates a method according to one embodiment, as described below. This method is performed by a user of a smartphone which provides relevant functionalities, either via a downloaded app or via native operating system functions.

[0063] Block 201 represents a process whereby the user triggers a new check-in. For example, this may be facilitated by a Ul button component which includes text data indicating such a purpose. This leads to a biometric data capture process at block 202. For example, the user interface may provide instructions to the user, for example requiring positioning the face in a defined relationship to a forward-facing camera component, movement of the head, holding of a hand / fingers in a specified configuration, and so on. Data collected via the camera component is processed at block 203. This includes two distinct processes:(i) Processing image data thereby to validate that there was a successful live capture of facial data, based on (for example) validation of image artefacts such as presence of defined movements, hand position, and so on. Depth-of-field data may also be used. These and other technologies may be applied to ensure that the technology verifies presence of a live human, as opposed to utilisation of pre-recorded image data.(ii) Identify verification based on facial biometric data extracted from the captured image data. In the illustrated example this is performed via an external biometric authentication service 210, with two-way data exchange via line 221 . This may include uploading of an encrypted biometric signature, and return of data (also preferably encrypted) verifying a particular identify, for example with a name and a unique identity code. In further embodiments identify verification is performed locally based on a local biometric signature / token against which captured biometric data is matched (e.g. service 210 is provided via locally executing software).

[0064] Block 204 represents a record generation process, which generates a new check-in record in local data including data representative of the biometric authentication and identity verification, data representative of current location, a timestamp, and other data. This is communicated to a cloud-based server / database system 211 (see line 222), such that the same record data is stored at both locations. An encoding process is performed at block 205 (optionally in whole or in part performed by server 211) thereby to define a unique identifier for the check in, a unique URL at which data for the check in can be accessed, and a QR code encoding that URL and optionally other information.

[0065] Block 206 represents an image generation process, whereby an image (e.g. JPEG or other known format image) is compiled including aspects of check-in record data and encoded data, for example as shown in FIG. 3A. This is then optionally shared to a 3rdparty device 212 (see line224), which is able to verify information in the image against image in server / database 211 (see line225), for example using a URL, QR code or UID.

[0066] Block 207 represents an additional data management process, whereby additional information (such as images and the like) are able to be captured, validated, watermarked, and associated with the check in record.

[0067] FIG. 2B illustrates a modified method, in which server / database 211 provides additional information via line 226 to a secondary security system 213. System 213 is configured to maintain further immutable evidence relating to check-in record creation, for example by subjecting check-in record data to a hashing algorithm, thereby to enable later verification that a record remains unchanged. In some cases, system 213 stores data, optionally including hash digests, using blockchain technology thereby to ensure immutability of that information. Blockchain and other technologies may be incorporated for additional data integrity (for example where data relating to each CIR is added to a blockchain, for example including a hash or the like formed using data from or defining the CIR).

[0068] Whilst the CIR generation technology described above is able to be used to generate CIRs that are shared / recorded for subsequent purposes which do not necessarily rely on further processing, there are also embodiments in which CIRs are used in the context of additional automated software which performs processing based on data extracted from identifiable CIRs, and / or initiates prompting and / or compliance procedures which require generation of CIRs. Two main examples are discussed below, relating to document execution and to remote identify verification / trust management.

[0069] In some embodiments, an additional layer of access rights management is applied to CIRs, for example via an embedded identifier, which enables the overarching system to control which users are able to view particular records via URL access. For example, when defining a CIR, a user may specify an option in relation to sharing, which may for example allow the user to specify parameters such as the following:• Share only with specified parties, for example an employer, a known third party, or the like. A drop-down menu or the like may be made available.• Share only with persons who have a passcode (the user may share a passcode via alternate means, thereby to allow access to a specified on or more CIRs). For example, a user may be invited to set a passcode for each CRI when generating, and a user seeking to access a hyperlink for that CRI is prompted to enter that passcode.• Share only for a limited time period (for example, after a specified time period, the URL is deleted or no longer usable by the general public, in the case of the latter requiring authorisation such as a passcode from the CRI-creating user for subsequent access). In some cases, CIRs that will have temporary lifespans are allocated shorter unique identifiers.

[0070] In some cases, the technology is configured to allow pre-setting of template settings for a CRI. For example, an employer provides employees with access to use a specific template, e.g. a CRI template to be used when commencing a shift, and privacy settings for CRIs defined in that manner are preset such that they are made available via the cloud database only to the employer.

[0071] It will be appreciated that, in spite of privacy settings that are applied for CRIs in the secure could database, a user is able to share a CIR image just as they would with any other image file.Technology for Secure Execution of Documents

[0072] Various embodiments relate to technology configured to enable secure execution of documents via an external user verification process which generates unique check-in event data, for example the CIR generation and sharing technology described further above. In that regard, the user verification process may facilitate generation and sharing of secure data records for point-in- time verification of identity and location. Embodiments of the invention are primarily directed to enable generation of records representative of point-in-time events involving known persons at known locations. The technology is in some embodiments applicable to documents executed electronically and via “wet” signatures.

[0073] In overview, the document management technology described herein leverages a multipurpose user verification platform, which is configured to enable a user to generate point-in-time evidence representing real-world events. For example, such a platform may be used to confirm presence at locations (e.g. for parole / quarantine purposes), to document photographic evidence (for example in the context of generating reports and / or documenting work practices), and a range of other purposes. The present specification details systems and methods which allow such a platform to be applied in the context of executing documents (for instance executing contracts, agreeing to terms and conditions, signing waivers, and so on).

[0074] The verification platform, for example insofar as such platform technology is described in the embodiments below, facilitates generation of evidentiary records via mobile devices. These evidentiary records each provide a reliable set of data relating to a real-world event, including details of biometric authentication, verified identity, verified location, verified date / time, and optionally other point-in-time verified information (including captured images). The technology is additionally configured to facilitate convenient sharing of these records (or a subset thereof) - without requiring specialised software for a recipient - using a combination of fixed images and database retrieval (optionally in combination with additional layers of security / sources of truth).Terms and Abbreviations - Execution of Documents Examples

[0075] The following terms and abbreviations are in the context of document management embodiments, and provided here for the sake of convenient reference.• User Verification Software Application (UVSA): A software application that is configured to execute on mobile devices (which may form part of an operating system or pre-installed software) which is configured to perform biometric verification of a user. Preferably this is biometric verification against a predefined identity record, which is pre-verified using government / official identification documents. Example UVSA technology is described below, in the context of a UVSA which is configured to perform a biometric identity verification and in response generate a “Check-In Record” which confirms identity and other data attributes (e.g. time, location, photo data, input of codes from documents and so on).• Check-In Record: a set of data which is generated by a UVSA which provides point-in-time evidence of user identity and other information (e.g. time, location, photo data, input of codes from documents and so on).• Check-In Record Identifier (CRI): a number / code which uniquely identifies a Check-In Record. In some embodiments a CRI is embedded into a QR code and / or other code, thereby to facilitate access to a URL which is configured to display data contained in the relevant Check-In Record. In this regard, in the embodiments described below, a Check-In Record may be viewed and shared as an image file, via accessing a database using a unique code / number, and / or also as a URL. The URL (and / or unique code / number) may be accessed from the image file, thereby to verify authenticity of information in the image file.• UVSA System: a cloud-hosted system which enables access to view UVSA Check-In Records, based on the CRI. For example, this may be used to confirm details of a particular Check-In Record, for example in the context of validating authentic execution of a documentas described herein. The UVSA System optionally uses data integrity technologies such as blockchains to prevent modification of Check-In Records. The UVSA System additionally manages user enrolment, which includes initial verification of user identity, for example using approved government-issued ID documents, thereby to generate a predefined identity record which in respect of which (and / or against which) subsequent biometric authentication is performed.• UVSA ID: a number / code which uniquely identifies a user for the purposes of a UVSA system. The UVSA ID is in preferred embodiments similar to a phone number or an email address, in the sense that it facilitates communication / identification, without conveying confidential / sensitive personal information in itself.• Authoring Terminal. A computing device which is used in the context of authoring a document, for example via a word processing software application.• Standard Electronic Document: a conventional or non-conventional electronic document, for example in a file format such as “.docx”, “,PDF” or other known formats. In some cases, such Standard Electronic Documents are able to be modified by a process described herein, for example by adding additional visible and / or non-visible information.• External Verification Compliant (EVC) Document: a document that has been modified as described herein to be compliant with an external verification process which is performed using a UVSA. This facilitates document execution (electronic and / or wet-sign) which records evidence of user biometric verification which is linked to the document.• Unique Document Code (UDC, or EVC UDC): a code which uniquely identifies an EVC Document, for example an alphanumeric code. In some embodiments the UDC is embedded into a QR code or the like, thereby to facilitate convenient reading of the UDC via a smartphone (optionally in combination with triggering of an action via a USVA).• EVC Document Integrity Value (EVC DIV): a code which is used to verify integrity of an EVC Document, for example to confirm that a particular version of a document has not been subjected to unauthorised modified after creation. For example, this may be based on a hashing algorithm or the like. The EVC DIV may be integrated into the UDC.External Verification Compliant Document Management System (EVC DMS): a cloud- hosted system which manages data relating to EVC Documents. For example, the EVC DMS maintains a database of EVC Documents, identifiable by UDCs, which maintains statusand other information for EVC Documents. This may include the likes of: (i) a document status; (ii) an EVC DIV, or other document integrity information; (iii) details of parties who have executed a document; and / or (iv) CRIs associated with document execution. Although the embodiments described herein focus on a cloud-hosted system,• Viewer Application: A software application which is configured to enable viewing of an EVC Document. This may be a specialist application, or a general application (e.g. a PDF viewer) optionally with additional code (e.g. plugins) which enable integration with EVC document technology. For example, the Viewer Application is in some embodiments configured to interact with the EVC DMS. This may be used to additional security, e.g. via watermarking and / or embedded security related data.• Execution CRI: A CRI which is associated with execution of an EVC Document.

[0076] It will be appreciated that the concepts represented by such terms should not be limited based on specific examples and / or these abbreviations.Example EVC Document Generation

[0077] In overview, the present technology operates in the context of a framework which includes multiple different systems / devices. An example framework will now be described by reference to FIG. 4A.

[0078] The framework of FIG. 4A facilitates various methods for facilitating document execution. One such method includes a step of accessing an authored electronic document. For example, this may be an electronic document accessed via an Authoring Terminal 400. In the embodiment shown in FIG. 4A, the Authoring Terminal includes a Document Authoring Module 401 , which may be for instance a word processing software application which is used to author text-based documents. In other embodiments the Document Authoring Module executes on a different computing device. FIG. 4A shows a document in the form of a Sample Contract 410. A wide range of document may be used for this purpose.

[0079] The method then includes a process whereby Authoring Terminal 400 is used to operate an External Verification Compliant (EVC) Document Generation Module 402 (which may be a standalone software application, or a plugin / functionality provided through the Document Authoring Module). EVC Document Generation Module 402 is configured to modify an existing document, in this case being Sample Contract 410. In particular, Module 402 is configured to convert Sample Contract 410 into an EVC Document, in this example being shown as Sample Contract 410’. Thisincludes processing Sample Contract 410 and generate an EVC document containing content from the authored electronic document, and additional features. The additional features include a unique document code (UDC), being a code, which is unique to the EVC document. Additionally, as illustrated, the additional features include an EVC Document Execution Block 411. This Execution Block includes information to facilitate execution of the Sample Contract via EVC technology described herein.

[0080] The EVC Document may have other attributes, for example relating to modification prevention and the like. This may be a custom file type, readable only by a specific Viewer Application, or a standardised file type (e.g. PDF) which is readable via a standardised type of viewer application (with functionality, such as plug-ins, provided to enable EVC compatibility). An example Viewer Application 480 is shown in FIG. 4B. It will be appreciated that a Viewer Application is not necessarily used for wet-sign documents.

[0081] In some embodiments the EVC Document Generation Module is accessed via a “print” style feature in a software application. For example, there may be a “Print to PDF” option by default, and a “Print to EVC PDF option” for the present purposes.

[0082] The EVC Document Generation Module may provide functionality to enable a user to review and approve the EVC document, prior to designating that a document is “Active” for the purposes of being executed.

[0083] The EVC Document Generation Module is in communication with an EVC Document Management System 421 , which is a cloud-hosted system 420. EVC DMS 421 receives from Module 402 various data related to each generated EVC Document. This data is able to be viewed, and in some cased modified, via a EVC Document Management Interface 403 which may be executed at the Authoring Terminal. Access rights (for example user accounts, password protection, multi-factor authentication and the like) restrict access to EVC Document data held in EVC DMS 421 based on credentials of a user of EVC Document Management Interface 403.

[0084] Data held by EVC DMS 421 in relation to a given EVC Document (i.e. data provided to EVC DMS 421 via Module 402 and / or Interface 403), such as in relation to Sample Contract 410’ may include some or all of the following:• The UDC for the EVC Document.• Details of intended signatories for the EVC Document (optionally / preferably including UVSA IDs for those signatories). Details of intended signatures may be added via either or both of Module 402 and Interface 403.• A document execution status. Where there are defined intended signatures, this may include details of which of those signatories have executed the EVC Document, for instance allowing transition from “not-executed” to “partially executed” to “fully executed”. Where a document is intended for execution by multiple persons on separate occasions, the document execution status may include details of each person who has executed a version of the document (for example via respective UVSA IDs).• Document execution verifications, for example Execution CRIs for each person who has executed the document. This allows a user of Interface 403 functionality to verify document execution by reference to a Check-In Record (and / or particular verified user via a UVSA ID) associated with document execution, as discussed in more detail further below.• A copy of the document in its “approved” form (or potentially forms).• A EVC Document Integrity Value defined for the EVC Document. The EVC DIV is preferably defined by Module 402 when generating the EVC Document. The EVC DIV may be defined via various means, thereby to provide a value which enables verification that content of the EVC Document has not been modified. For example, a hash of text and / or image content may be used (optionally excluding content defined in the EVC Document Execution Block). The EVC DIV is preferably generated based on a predefined document integrity algorithm which inputs data extracted from EVC Document. This algorithm is repeatable, such that the EVC DIV is able to be generated on multiple occasions, resulting in the same value in the case that the EVC Document has not been modified / tampered with as compared with a “valid” state defined for EVC DMS 421 (e.g. as defined valid via Module 402 and / or Interface 403).• A document validity status. For example, a user of EVC Document Management Interface 403 may set a status that a document is “valid”, “expired”, “executed”, “partially executed”, or the like.Document access / viewing histories, logs, etc.• Document execution parameters / rules. These may include, for instance: requirement for witnesses; “wet” sign requirements; requirement to insert signing location (which may be validated against details associated with execution CRI), etc.

[0085] Once generated, an EVC Document is able to be shared. For example, this may include sharing via email and / or other file transmission technologies, and in the case of documents that are to be “wet” signed, sharing of physical paper forms of the EVC Document. In some cases, rather than sharing a file, the document is viewable only in an online form, based on data accessed via EVC DMS 421 . Such an online form may in some cases be available for printing and “wet” sign (which may be facilitated / assisted by use of a user’s unique UVSA ID).

[0086] The EVC Document Execution Block may contain a range of artefacts which facilitate document execution. These may include any one or more of the following:• One or more fields configured to receive details of executing parties. These may be prepopulated via Module 402 and / or Interface 403 where the parties are known at the time of EVD Document generation.• One or more fields configured to receive signatures. These may optionally include textbased signatures, image-based signatures, handwritten signatures (including “handwritten” via touchscreen or the like), and other signature types. One approach is to require a form of signature in combination with an Execution CRI; in other embodiments an Execution CRI is used as a “signature” in itself.• An artefact (for example a URL, alphanumeric code, QR code, or the like) which triggers execution of the UVSA to initiate a check-in process, preferably being a check-in process specific to execution of the particular EVC Document (e.g. based on the UDC). For example, in a preferred embodiment the EVC Document Execution Block contains a QR code, and a user of a mobile device scans that QR Code, resulting in launching of the UVSA with in-app context to trigger a check-in event based on the EVC Document’s UDC.• A readable version of the EDC DIV. That is, the EDC DIV for the valid and unaltered version of the document (e.g. prior to inclusion of the EVC Document Block) is inserted into the EVC Document Block.

[0087] The EVC Document Execution Block may be defined by multiple locations in the EVC Document, and is not limited to a single location “block”. That is, the term “block” is used to describe a concept whereby the EVC Document generation process adds content to a standard document.

[0088] An example method showing the process of EVC Document generation and sharing is provided in FIG. 5A. Block 501 represents a document authoring process, whereby the main body (e.g. text) of a document is authored, for example via conventional word processing software. Block 502 represents a process whereby the document is converted into an EVC Document, as described above. The document is then saved at block 503 (e.g. saved in an online viewable form, and / or as a sharable physical file such as an EVC compatible PDF or the like).

[0089] Block 504 represents a process including steps whereby a user reviews a generated EVC Document, confirms valid status, and the EVC DMS server is updated accordingly. The user is able to optionally revise EVC Document status via the EVC Document Management Interface at later time.

[0090] Block 505 represents a process whereby the EVC Document is provided to executing parties, for example as an electronic document (physical file or online view) and / or in physical hard copy format (for example where wet-sign is required). The document then undergoes an execution process (described below). Data representative of the execution is provided to the EVC DMS, and made available via interface 403. In some cases interface 403 executes on other terminals, for example to enable executing parties and / or other users to view document execution status. Such functionalities of Interface 403 may optionally be integrated into the UVSA and / or Viewer Application 480.Example EVC Document Execution Processes

[0091] For execution of an EVC Document, such as Smart Contract 410’, an external user verification system is leveraged to facilitate such execution (in this case being the instances of the UVSA executing in user devices, in conjunction with UVSA System 122). This system is configured enable generation of check-in records via user verification software applications (UVSA) executing at distributed user devices, such as user device 430. The user devices may include smartphones and other computing devices. A check-in record management system, in the form of UVSA System 422, is configured to securely maintain data representative of the check-in records, such that a given record is able to be viewed via a data query including the associated CRI for that record.

[0092] Each check in record is generated via a process wherein a user of a given one of the user devices is required to undergo biometric identity verification. Preferably, each check-in record is associated with data representative of:(i) successful biometric identity verification for the user;(ii) one or more additional check-in-specific data values (e.g. including geolocation); and(iii) a unique Check-In Record Identifier (CRI) for the check-in record.

[0093] In the case of EVC Document execution, the one or more additional check-in-specific data values include the UDC for the particular EVC Document. By inputting that value, a user creates a contextual nexus between the EVC Document and the Check-In Record being generated. In some embodiments, the UDC is pre-populated, for example in a preferred embodiment the EVC Document Execution Block contains a QR code, and a user of a mobile device scans that QR Code, resulting in launching of the UVSA with in-app context to trigger a check-in event based on the EVC Document’s UDC.

[0094] In a preferred embodiment, the presence of a UDC in a Check-In Record designates that Check-In Record as an Execution Check-In Record, and the relevant CRI as an Execution CRI. Each Execution CRI is transmitted to EVC DMS 421 , thereby to update a record for the relevant EVC Document with evidence in relation to execution.

[0095] In preferred embodiments, the Execution CRI is entered into the EVC Document. This may be achieved in various ways, including:• A user inputting the Execution CRI via Viewer Application 480 (with EVC Document Plugin). In this case, the Viewer Application is configured to interact with EVC DMS 421 to: (i) communicate the Execution CRI to EVC DMS 421 ; and / or (ii) verify that the Execution CRI inputted by the user matches an Execution CRI already provided to EVC DMS 421 by UVSA 431 . The latter may require input into the EVC Document of the user’s UVSA ID (either by the user at that juncture, or previously via the EVD Document generation process).• Pushing of the Execution CRI to the EVC Document via EVC DMS 421 and Viewer Application 480 (with EVC Document Plugin). That is, the user generates an Execution CRI via the UVSA, and that triggers a process whereby the Execution CRI is entered into the document.• Manual input of the Execution CRI into an electronic document in absence of an EVC Document Plugin which enables interaction with EVC DMS 421 .Manual input of the Execution CRI into a hard-copy document.

[0096] In each case, the user may be prompted to use the UVSA to capture a photo showing the EVC Document with that Execution CRI present, for storage in association with the relevant Execution Check-In Record (preferably immediately after addition of any additional user signature data). This creates a closed loop whereby there is evidence of an intention to execute the EVC Document, and evidence that the EVC Document was actually executed by the person purported to be executing the document.

[0097] Where the Viewer Application 480 (with EVC Document Plugin), or other appropriate technology, is used, the EVC DIV is preferably used at the time of execution thereby to verify authenticity of the content of the EVC Document. This may in some cases be performed without need to contact the EVC DMS, for example where the EVC DIV is stored in the Document Execution Block (optionally embedded in the UDC), and Viewer Application 480 is configured to perform the relevant document integrity algorithm.

[0098] FIG. 5B shows an example EVC Document execution method by an “executing party”, being a user who may or may not be specifically identified in the EVC Document.

[0099] Block 511 represents a process whereby the executing party reviews the EVC Document (in electronic form or hard-copy). When viewed in electronic form via a compatible Viewer Application, the Viewer Application performs a process to verify EVC Document Status via the EVC DMS. The Viewer Application optionally also verifies authenticity, for example by way of the EVC DIV and / or comparing the document to an authentic version held by the EVC DMS. At the end of this stage, the executing party decides to execute the EVC document (and is warned if the document is problematic based on status and / or authenticity).

[0100] Block 512 represents a process whereby the executing party provides the EVC Document’s UDV to the UVSA, for example by scanning a QR code via a mobile device (or other technique, such as a hyperlink or manual input). Where a URL linked mechanism is used (e.g. QR Code or hyperlink) the URL preferably launches the UVSA with content for a check-in based on the UDC, and / or links to an app store for download of the UVSA (which may require user registration steps) as per block 513.

[0101] Block 514 represents a process whereby the user of the UVSA performed a check-in based on the EVC Document UDC thereby to generate an Execution CRI at block 515. At Block 516 the Execution CRI is inputted into EVC Document (by the user and / or via communication through the UVSA, EVC DMS and Viewer Application), and other execution steps performed.

[0102] Block 517 represents a process whereby execution status is updated with the EVC DMS, achieved via either or both of uploading of information via the UVSA (e.g. UDC and Execution CRI) and the Viewer Application (e.g. any inputted details in the EVC Execution Block).

[0103] Block 517 represents a process whereby secondary evidence of execution is generated, for example by capturing of photos via the UVSA showing the EVC Document in an executed form. These images, if captured within predefined constraints (e.g. time and position relative to commencement of generation of Execution Check-In Record) are stored in association with the Execution Check-In Record. In another example, a Post-Execution Check-In Record is generated for these images, with a Post-Execution CRI.

[0104] It will be appreciated that the above disclosure provides improved technology for facilitating execution of documents, as compared with existing computerised solutions. For example, there is a closed loop which confirms intentional valid execution verified through biometric authentication at the time of execution, with such biometric authentication being evidenced both in the document itself and via independent sources.Example Document Execution Methods

[0105] FIG. 5A and FIG. 5B provide example methods according to embodiments. These provide practical use-cases for the frameworks of FIG. 4A and FIG. 4B.

[0106] The example of FIG. 5A relates to an interaction with a representative (human or Al) of a business, “Business X”, interacting with a human customer “Customer Y”. The relevant communication session commences at Block 501 .

[0107] A CIR Prompt Process is initiated at Block 502. This presently includes transmission of a query from a terminal operated by Business X to the UVSA System, which includes the UVSA ID for Customer Y. The UVSA System then generates prompt data at Block 503, and causes transmission of prompt data to the relevant instance of the UVSA executing at the user device of Customer Y. This causes a CIR-Prompt notification to be displayed at Customer Y device on which the UVSA is installed (Block 504), which enables Customer Y to initiate a check-in process which is based on the prompt initiation at Block 502.

[0108] In an alternate embodiment, rather than (or in addition to) sending a notification to the UVSA of Customer Y via the UVSA System, a hyperlink which has the same practical effect as the prompt notification may be transmitted via alternate means, for example via a text-based message in the communication session between Business X and Customer Y.

[0109] In either event, a UVSA check-in commences at Block 505. This includes display of information relating to Business X, for example including trust rating information and / or warnings (any preferably a “please confirm that you are currently interacting with Business X via a telephone call”, or the like). Because this is displayed within the UVSA app environment, there is a high degree of confidence that information regarding UVSA verified identity of Business X is correct. In the case that the prompt comes from an entity that does not have robust authentication, or in the case of other flags (e.g. business name has changed and / or is too similar to a more robustly verified business) warnings may be displayed. In the event that Customer Y is sufficiently satisfied that the prompt has indeed been generated validly by Business X, they go through the check-in process (which includes a biometric authentication as discussed below).

[0110] Assuming the check-in is successfully completed, and a CIR is generated, that CIR is sent to the UVSA System at Block 506. The CIR has data attributes which allow UVSA System to associate that CIR with the associated CIR-Prompt Process. The UVSA System then transmits (Block 507) the CIR details (e.g. link to record in CIR Database and / or CIR image) such that they are received by the user who initiated the CIR Prompt Process at Block 502. This allows the initiator to verify that the person with whom they are interacting is likely to be who they purport (or at least that the relevant Customer Y was prepared to provide a CIR in response to the Prompt).[0011 1] In the example of FIG. 5B, there is a communication session between two humans (Block 501), Person A and Person B, which may be via any electronic means. Forthe sake of example, we shall assume that Person A wishes to purchase a bicycle from Person B, having responded to an advertisement on an online classifieds platform (e.g. Facebook Marketplace or the like).

[0112] At Block 512, a CIR Prompt Process is initiated by Person A. In this example, Person A performed this via their instance of the UVSA via a process that includes generating a CIR, and inputting a UVSA ID for Person B. In this example, Person A is able to provide instructions to Person B for additional information required in Person B’s CIR. For example, this might include “please provide photos of the bicycle” and “please verify your location”. The UVSA System then generates prompt data at Block 513, and causes transmission of prompt data to the relevant instance of the UVSA executing at the user device of Person B. This causes a CIR-Prompt notification to be displayed at Person B device on which the UVSA is installed (Block 514), which enables Person B to initiate a check-in process which is based on the prompt initiation at Block 512.

[0113] In an alternate embodiment, rather than (or in addition to) sending a notification to the UVSA of Person B via the UVSA System, a hyperlink which has the same practical effect as the prompt notification may be transmitted via alternate means, for example via a text-based message in the communication session between Person A and Person B. In another embodiment, the promptprocess may be integrated into a social media platform or the like. In another embodiment, Person A’s CIR is in image form, and contains a hyperlink / QR code which allows Person B to link directly into their UVSA to provide a “response” CIR.

[0114] In any event, a UVSA check-in commences at Block 515. This presently includes display of the CIR generated by Person A. In the event that Person B is sufficiently satisfied, they go through the check-in process.

[0115] Assuming the check-in is successfully completed, and a CIR is generated, that CIR is sent to the UVSA System at Block 516 (and / or sent as an image to Person A). The CIR has data attributes which allow UVSA System to associate that CIR with the associated CIR-Prompt Process. The UVSA System then transmits (Block 517) the CIR details (e.g. link to record in CIR Database and / or CIR image) such that they are received by the user (Person A) who initiated the CIR Prompt Process at Block 512 via their instance of the UVSA This allows Person A to verify that the person with whom they are interacting is likely to be who they purport (or at least that the relevant Person B was prepared to provide a CIR in response to the Prompt). It also allows for review of verified-to-be- current images showing the bicycle that is being considered for purchase. This allows a greatly increased level of trust in these sorts of transactions between individuals who would not know one another.

[0116] In some embodiments, document execution is enhanced by the use of official director ID number or the like, whereby as part of a pre-verification process associated with UVSA ID creation or management, a user is able to have their authorisation to execute documents on behalf of a corporate entity formally pre-verified, allowing such authorisation to be incorporated into CIRs used in the context of document execution.Robust Identity Exchange Technology

[0117] Some embodiments relate to technology configured to enable robust / reliable identity exchange via an external user verification process which generates unique check-in event data (for example the CIR generation and sharing technology described further above). For example, in some embodiments the technology provides two-way confirmation of identity, thereby to facilitate interaction between two parties. In some embodiments this is used in the context voice and / or text communications between a business and a customer, or between two private individuals (for example in the context of a transaction).

[0118] In overview, the technology described herein leverages a multi-purpose user verification platform, which is configured to enable a user to generate point-in-time evidence representing real-world events. For example, such a platform may be used to confirm identity (via biometrics) plus other evidence such as location, photographic evidence (for example in the context of generating reports and / or documenting work practices), and a range of other purposes. The present specification details systems and methods which allow such a platform to be applied in the context of peer-to-peer identify verification.

[0119] The verification platform, for example insofar as such platform technology is described in the embodiments below, facilitates generation of evidentiary records via mobile devices. These evidentiary records each provide a reliable set of data relating to a real-world event, including details of biometric authentication, verified identity, location, date / time, and optionally other information (including captured images). The technology is additionally configured to facilitate convenient sharing of these records (or a subset thereof) - without requiring specialised software for a recipient - using a combination of fixed images and database retrieval (optionally in combination with additional layers of security / sources of truth).

[0120] As a high-level overview of an example use case, the technology may be applied where a business wishes to engage with a customer via electronic communications (e.g. voice chat or text chat). The user representing the business is able to trigger a prompt for the customer to perform a “check-in” via the verification platform. This prompt provides the customer with independently verified evidence that the business is indeed legitimate (e.g. is who it purports to be). The check-in allows the business to verify that the customer with whom it is interacting is indeed who they purport to be. As such, there is a 2-way trust exchange, and the engagement can continue on that basis.

[0121] Another example use case is where there are two regular persons who wish to verify each other’s identifies (for example in the context of a private sale transaction, prior to meeting for a romantic date, or the like). One party shares a check-in record to the other party, and that prompts a return check-in record to be generated by the other party. That is returned to the first party (optionally with a final return confirmation), thereby to provide a 2-way trust exchange. In the case of a sale of goods, the check-in record may be associated with point-in-time photos showing the goods in question, thereby providing evidence of current possession (and optionally condition) of goods.Terms and Abbreviations - Identity Exchange Technology

[0122] The following terms and abbreviations are used in the context of identity exchange technology embodiments, and provided here for the sake of convenient reference.• User Verification Software Application (UVSA): A software application that is configured to execute on mobile devices (which may form part of an operating system or pre-installed software) which is configured to perform biometric verification of a user. Preferably this is biometric verification against a predefined identity record, which is pre-verified using government / official identification documents (or a government approved digital ID system). Example UVSA technology is described below, in the context of a UVSA which is configured to perform a biometric identity verification and in response generate a “Check-In Record” which confirms identity and other data attributes (e.g. time, location, photo data, input of codes from documents and so on).• Check-In Record (CIR): a set of data which is generated by a UVSA which provides point- in-time evidence of user identity and other information (e.g. time, location, photo data, input of codes from documents and so on).• Check-In Record Identifier (CRI): a number / code which uniquely identifies a Check-In Record. In some embodiments a CRI is embedded into a QR code and / or other code, thereby to facilitate access to a URL which is configured to display data contained in the relevant Check-In Record. In this regard, in the embodiments described below, a Check-In Record may be viewed and shared as an image file, and also as a URL. The URL may be accessed from the image file, thereby to verify authenticity of information in the image file.• UVSA System: a cloud-hosted system which enables access to view UVSA Check-In Records, based on the CRI. For example, this may be used to confirm details of a particular Check-In Record, for example in the context of validating authentic execution of a document as described herein. The UVSA System optionally uses data integrity technologies such as blockchains to prevent modification of Check-In Records. The UVSA System additionally manages user enrolment, which includes initial verification of user identity, for example using approved government-issued ID documents (or a government approved digital ID system), thereby to generate a predefined identity record which in respect of which (and / or against which) subsequent biometric authentication is performed.• UVSA ID: a number / code which uniquely identifies a user for the purposes of a UVSA system. The UVSA ID is in preferred embodiments similar to a phone number or an email address, in the sense that it facilitates communication / identification, without conveying confidential / sensitive personal information in itself.• Enterprise Terminal. A computing device which is used by a representative of an enterprise (e.g. a business / service provider), which executes software including an Enterprise UVSA Module.• Enterprise UVSA Module-, a software application / module which allows a business to interact with the UVSA System. This differs from the regular EVSA, in the sense that authentication is not for an individual (i.e. biometric), and is instead for a business. This requires a different approach to authentication and security, and may for example require a specific key be installed on the Enterprise Terminal.

[0123] It will be appreciated that the concepts represented by such terms should not be limited based on specific examples and / or these abbreviations.Technology Overview - Identity Exchange

[0124] Embodiments include systems configured to enable inter-party identification verification in the context of an electronic remote interaction. For example, an “electronic remote interaction” may include a voice call, text-based chat, video call, or the like. Basically, this is any situation where two parties are not in the same physical location, and hence direct identify verification is challenging.

[0125] Preferred embodiments include a server system, in the form of a UVSA System. This UVSA System is configured to communicate with a plurality of user devices (for example mobile devices) which each execute respective instances of the UVSA.

[0126] Each instance of the UVSA is configured to perform a check in process which includes at least the following steps:(i) Performing a point-in-time biometric identify verification of a specific person having an associated with a UVSA ID. For example, when configuring their individual UVSA ID, a given user undergoes a process thereby to verify their identity (for example using government- issued IDs or a government approved digital ID system) and generate a biometric token for the purposes of the UVSA. The point-in-time biometric identify verification uses that biometric token. The process for verification preferably includes a requirement to perform physical tasks, thereby to improve certainty that image data collected via a camera module for the purposes of facial biometric verification represents an actual live real world person.(ii) Generating a CIR, wherein the CIR is a dataset including (a) data including data representative of the biometric identification verification; (b) data representative of one ormore artefacts of objective point-in-time evidence; and (c) a Check In Record Identifier (CRI) which uniquely identifies the Check in Record. The data requirements (parameters) for a given CIR may be stipulated via settings defined by a third party that prompts for a CIR, as discussed further below.(iii) Transmitting the CIR to the UVSA System for storage in a CIR Database.

[0127] The UVSA System is configured to process CIRs received from instances of the UVSA and store those CIRs in a CIR database. The CIR database is configured to enable access to data for a given CIR based on a query which includes the CRI for that CIR (for example via a hyperlink or QR code generated by the UVSA for a user in relation to a given CIR). This access includes enabling rendering of a web page at a client device, the web page being configured to present the data the given CIR in a predefined format.

[0128] Preferably the UVSA is configured to perform a step including generation of an image file which represents the CIR. The image file may have an embedded hyperlink / QR code / other artefact which allows a viewer to verify authenticity of information in the image against the CIR Database.

[0129] The UVSA System includes a prompt-trigger module. This prompt-trigger module is configured to receive, from an external prompt-requestor module, input representative of a specified UVSA ID (a “prompt-trigger”). For example, the external prompt-requestor module may be provided by either of the following:• An instance of the UVSA. This is relevant where there is a human-human interaction where both parties seek verification of ID.• An instance of an Enterprise UVSA Module (as defined above). This is relevant where the interaction is between a business and a customer (which should be construed broadly to include a potential customer).

[0130] In response to the prompt-trigger, the prompt-trigger module is configured to:(i) Cause the instance of the UVSA associated with that UVSA ID to display a CIR-prompt for generation of a CIR having defined CIR parameters. For example, this may be displayed on a mobile device in a similar manner to other app-based notifications, and / or presented in the app.(ii) Monitor for generation of a CIR having defined attributes corresponding to the CIR-prompt.For example, in one embodiment the prompt-trigger (and the CIR prompt) includes a uniqueidentifier, and that unique identifier is embedded in the CIR. In this case, the prompt-trigger module may monitor records in the CIR Database for a CIR which contains that unique identifier, and identify that CIR as having defined attributes corresponding to the CIR-prompt. In another embodiment an alphanumeric code is communicated to the UVSA user via the electronic remote interaction. In this case, the prompt-trigger module may monitor records in the CIR Database for a CIR which contains that alphanumeric code, and identify that CIR as having defined attributes corresponding to the CIR-prompt. The alphanumeric code need not be unique; a database query based on the code may be refined by other parameters such as time and / or UVSA ID.(iii) In the case that a CIR having defined attributes corresponding to the CIR-prompt is identified, cause transmission of the CRI for that CIR to the prompt-requestor module. This allows a user of the prompt-requestor module to access and review the CIR, and verify identity of the relevant user and other data artefacts.

[0131] In terms of “other data artefacts”, the prompt-requestor module is preferably configured to stipulate parameters for the CIR that is to be prompted. For example, this may include one or more of the following:• Identity verification.• Current device location.• One or more photos captured within a prescribed time window relative to finalisation of the CIR (e.g. with instructions of what should be photographed, such as documents, items, and the like). The photos may also be subject to additional metadata review (e.g. to ensure location matches current device location).• User physiological data (e.g. heart rate, etc).• An alphanumeric code (e.g. the unique identifier for the prompt-trigger / CIR prompt), or a code communicated to the user via the electronic remote interaction.

[0132] This allows that an operator of the prompt-requestor module to access the CIR having defined attributes corresponding to the CIR-prompt, and thereby perform data validation relative to the defined CIR parameters. For example, depending on the defined CIR parameters, this could include:• Verifying that the biometrically verified identity corresponds to the identity purported via the electronic remote interaction (this may include verification against customer records).• Verifying a current device location. For example, there may be reasons for which location is important, for example where there will be a remote unlocking of a door, and there is a desire to know that it is indeed the correct person and they are indeed in the correct location.• Checking content of photos. This may serve a wide range of purposes, including providing additional documentary evidence (e.g. photo of health insurance card), evidence of real world objects (e.g. photo of item that is being offered for sale), evidence of current physical appearance (e.g. for dating applications). .• Checking physiological data (e.g. heart rate, etc), for example in the context of a medically- related check-in.• Verifying the alphanumeric code.

[0133] In some embodiments the CRI-prompt is associated with data indicative of a trust rating associated with the prompt-requestor module. For example, this may include:• A trust rating that includes data representative of an identity and level of identity authentication of the prompt-requestor module. This represents a degree of confidence with which the UVSA verifies that the user engaging in the remote communication on the side of the prompt-requestor module is indeed a representative of a party purported by the promptrequestor module. The trust rating might be based on a gold / silver / bronze / other status, based on the level of robust verification associated with a prompt-requestor module. This is optionally based on a form of authentication required by the prompt-requestor module (e.g. a hardware-based authenticator key may be required for gold-standard). There may optionally be levels of user biometric authentication, with a limited number of biometric tokens associated with a given Enterprise UVSA Module.• A trust rating that includes data representative of one or more warnings in relation to the prompt-requestor module. For instance, this may be relevant where the prompt-requestor module asks for information beyond identity verification (e.g. location, photos, etc). The warnings may also occur where a prompt-requestor module has attributes which give rise to flags of the like representative of a possible fraud / scam scenario.

[0134] In some embodiments, each UVSA is user configurable to accept CIR-prompts only from prompt-requestor modules having predefined prompt-requestor attributes. For example, this may include a user of a UVSA module pre-configuring their instance of the UVSA based on service providers with which they have accounts. These may be selectable based on a list of known authenticated service providers made available through the UVSA. For example, a user when performing configuration of the UVSA selects, from a list of service providers, “XYZ Bank” as they are customer of XYZ Bank, and this allows XYZ Bank access to send CIR-prompts. Entities purporting to be XYZ Bank, but without access to the authenticated prompt-requestor module, are unable to provide CIR prompts to that user.

[0135] In some embodiments, the predefined prompt-requestor attributes may include a requirement that a CIR-prompt include a CIR from the requestor. For example, the trigger-requestor module may be integrated into the UVSA, so that a user is able to generate a CIR and use that as a basis to cause a CIR-prompt for another user (e.g. by inputting the other user’s UVSA ID either in the CIR or via another input interface).

[0136] By combining the previous two examples, a user is able to receive CIR-prompts from: (i) only those Enterprise UVSA Modules meeting specified criteria (for business-human scenarios); and (ii) from standard instances of the UVSA (for human-human scenarios). This may be incorporated into use of online platforms such as social media platforms.Example Technology Framework

[0137] FIG. 6A illustrates a framework according to one embodiment. This relates to a use case where an Enterprise user interacts with a customer. In particular, FIG 6A illustrates an Enterprise Computing Environment 600 operated on behalf of a service provider “Business X”, and a User Device Environment operated by a person “Customer Y”.

[0138] A representative of Business X operates a Provider Remote Interaction Interface 605 (e.g. a voice communications application, or conventional telephone device) to interact with a Customer Remote Interaction Interface 624. As part of this interaction, Business X wants to verify that Customer Y is who they purport to be. This is achieved via UVSA System 610.

[0139] ECE 600 includes an Enterprise Device 602 (e.g. a desktop or laptop computer) which is configured to execute an EVSA Module 603, and an associated authenticator key 604. The authenticator key is provided subject to a verification process that occurs between a client-side Enterprise Verification Module 601 and a server-side enterprise verification module 611 of UVSA System 610. In some embodiments this verification process includes manual steps.

[0140] EUM 603 allows a user to input a UVSA ID for Customer Y, thereby to cause a transmission to Prompt-Trigger Module (PTM) 612 of UVSA System 610. The UVSA ID for Customer Y is in some cases already known to Business X, and is some cases communicated by Customer Y to Business X via the CRIA / PRIA communication. It is noteworthy that a UVSA ID is not a particularly sensitive item of personal information in the context of this technology framework.

[0141] The transmission from EUM 603 to PTM 612 includes details ofthe EUM / ECE (i.e. verified identity of Business X), the UVSA ID for Customer Y, and optionally a set of defined required parameters for a CIR that is to be prompted for Customer Y (e.g. requirements for location data, instructions for photos to be captured, etc). In this example we assume that the defined required parameters are limited to biometric identify verification, given the hypothetical context.

[0142] In this example, UVSA 621 executing on user device 622 of UDE 620 has been configured via an initial setup process whereby user verification (e.g. against government issued ID or a government approved digital ID system) is performed in conjunction with user verification module 614 of UVSA System 610. It is assumed that UVSA 621 is used for a range of purposes, beyond the example described here.

[0143] In response to the transmission from EUM 603, and assuming that transmission meets defined requirements for authenticity and the like, PTM 612 sends a transmission to UVSA 621 executing on user device 622 of UDE 620. This causes UVSA 621 to prompt generation of a CIR by the user of device 622, which is purportedly Customer Y. The user then performs the check-in process, including biometric verification, thereby to generate a CIR. In this embodiment, the transmission sent by PTM 612 to UVSA 621 includes a code which is embedded into the CIR, such that the CIR is able to be associated with the initiating request from EUM 603. This may include data representative of Business X.

[0144] It is noted that user device 622 and user device 623 may be the same hardware device.

[0145] The prompted CIR is transmitted by UVSA 621 to CIT Database 613. In this embodiment, EUM 602 is configured to monitor CIR Database 613 for a CIR that corresponds to the request provided to the PTM, such that a user of EUM 602 is notified promptly and enabled to view the relevant CIR, thereby to verify Customer Y.

[0146] In the example of FIG. 6B, ECE 600 is replaced by a second UDE 620’, having a user device 622’ which executes an instance if the UVSA 621 ’, and a user device 623’ which executes an instance of the CRIA 624’. This is similar to the example of FIG. 6A, except that the CIR prompt is initiated from another UVSA user. For example, this is useful in the context of a Person A who wishesto enter into a personal sale transaction with Person B, and the parties wish to make sure that they are both legitimate. So, Person A performs a check-in via UVSA 621 ’, and selects a menu option such as “request handshake check-in”. Person A then inputs the UVSA ID for Person B, and UVSA 621 ’ sends a transmission to PTM 612 which is similar to that sent by EUM 602 in the previous example. As a key difference, UVSA 621 provides data representative of the CIR generated at UVSA 621 ’ in conjunction with providing a CIR prompt. This allows both Person A and Person B to review respective CIRs from the other person. Optionally one of those CIRs includes photos of goods for sale, thereby to verify condition and possession.Example Methods - Identity Exchange

[0147] FIG. 7A and FIG. 7B provide example methods relating to embodiment level implementations of the identify exchange technology described above.

[0148] In the example of FIG. 7A, functional block 701 represents commencement of a communication session, which may include voice, messaging, or the like. In this example, the communication session is between a business “Business X” (e.g. via a call centre operative working for Business X) and a customer “Customer Y”.

[0149] Block 702 represents a process whereby Business X informs Customer Y that they will need to verify the identity of Customer Y, and triggers a CRI prompt process. The user representing Business X inputs into their UVSA system a UVSA ID for Customer Y. Preferably, Business X collects UVSA IDs for all of their verified customers, for example where UVSA technology is used to facilitate Know Your Customer (KYC) protocols.

[0150] Block 703 represents a proves whereby the UVSA system generates prompt data, which is communicated to a specific instance of the UVSA which is associated with the UVSA ID used to trigger the prompt data. This may appear as a notification on the relevant device, as represented by block 705. The prompt, when accessed via foreground launching of the UVSA, triggers a check in process having defined attributes, and in-app data that verifies the identity of Business X. This identity verification preferably results from an enterprise-level enrolment process for businesses, which is manually managed, as opposed to an automated business enrolment process, thereby to ensure a high degree of security.

[0151] In an alternate embodiment, a hyperlink or the like is sent by Business X to Customer Y via a text message or the like, this serving the same functional purpose, in that it causes a specific functionality to be performed by the UVSA instance of Customer Y, i.e. triggering the relevant UVSA check-in process.

[0152] Block 705 represents a process whereby a user completes the triggered UVSA check-in process via their instance of the UVSA. This provides information relating to Business X, including their official verification status, and any relevant warnings held by the UVSA System.

[0153] When the check-in process is completed, a CIR is defined. This is communicated to the UVSA system as represented by block 706. Then, at block 707, the user representing Business X is able to access the relevant CIR, and verify Customer Y. For example, the CIR provides data to verify that: (i) Customer Y has performed biometric authentication; and (ii) the biometric authentication matches an identify pre-verified against a government-issued ID (or a government approved digital ID system). The manner by which the CIR details are sent to the prompt initiator may include: (i) automated communication, for example where the CIR includes an identifier which is associated with the trigger, thereby allowing a software module to monitor for generation of a CIR containing that identifier; and (ii) manual communication, for example sending of a message containing a CIR identifier and / or CIR image. In some embodiments additional data processing and automation is performed such that the user representing Business X simply receives a notification representing that Customer X has been successfully biometrically identified.

[0154] In the example of FIG. 7B, functional block 71 1 represents commencement of a communication session, which may include voice, messaging, or the like. In this example, the communication session is between a human user “Person A” and human user “Person B”. Both Person A and Person B have their own instances of the UVSA, and have already completed the relevant user identity verification procedures (e.g. biometric comparison with government issued ID, thereby to create a biometric token for subsequent use which in essence tracks to the government issued ID). In this manner, it will be appreciated that CIR generated by the UVSA is able to provide verification of details such as government-recognised full name.

[0155] Block 712 represents a process whereby Person A generates a CIR for the purposes of peer-to-peer identify sharing, and as part of this inputs into the UVSA the UVSA ID of Person B. This causes the UVSA system to generate a prompt for the UVSA instance of Person B (see block 713), which is displayed by the relevant smartphone / device as represented by block 714. Block 715 represents a process whereby this prompt is followed, resulting in display of the CIR for Person A allowing Person B to verify that Person A matches who they purport to be (and other provided details, for example via photos of goods for sale I other subject matter). This is followed by a check-in process for Person B, with a resulting CRI being transmitted to the UVSA system as per block 716. This CRI includes an identifier associated with the triggering CRI generated by Person A, allowing for the CRI of Person B to be automatically made available (e.g. via a notification) to Person A via the UVSA of Person A. Person A is then able to verify that the user is indeed Person B.

[0156] It will be appreciated that there are other ways in which UVSA and CIR technology as described herein are able to be used for identity sharing, beyond what is disclosed in the above example methods.Conclusions and Interpretation

[0157] Although specific embodiments of the present invention have been described, it will be understood by those of skill in the art that there are other embodiments that are equivalent to the described embodiments. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrated embodiments, but only by the scope of the appended claims.

[0158] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, FIG., or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

[0159] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0160] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention.

[0161] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. Inother instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

[0162] Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limited to direct connections only. The terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other.Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

Claims

CLAIMS1 . A system configured to enable generation and sharing of secure data records for point-in- time verification of identity and location, the system including: an authentication module configured to perform biometric authentication of a userof a mobile device, thereby to verify an identity of the user of the mobile device based on a predefined identity record; a location module configured to determine an authentication location of the mobile device, including positional data determined at a time corresponding to the biometric authentication; a record generation module configured to cause storing of a check-in record in a cloud- hosted database, wherein the check-in record includes components which provide data representative of (i) the biometric authentication; (ii) the verified identity; (iii) the authentication location; and (iv) an authentication time; an encoding module configured to cause encoding of: (i) a record URL which is configured to, when accessed, cause rendering of data extracted from the check-in record; and (ii) a QR code configured to cause accessing of the record URL; and an event image generation module configured to cause generation of an event image containing graphical representations of: (i) one or more components of the check-in record; and (ii) the QR code; such that the event image is able to be shared via communications channels, and data displayed in the event image is able to be verified against data stored in the cloud-hosted database via the record URL.

2. A system according to claim 1 including a captured image management module which is configured to: (i) identify a captured image captured via hardware of the mobile device satisfying predefined requirements; (ii) generate a watermarked version of that captured media item containing visual representations of (A) one or more components of the checkin record; and (B) the QR code.

3. A system according to claim 2 wherein the watermarked version of the captured media item additionally contains (C) text data generated by the user.

4. A system according to claim 2 or claim 3 including an upload module configured to cause storing of the watermarked version of the captured media item in the cloud-hosted database in a manner accessible via the record URL.

5. A system according to any preceding claim wherein the encoding module is additionally configured to generate an alphanumeric UID which is uniquely representative of the checkin record.

6. A system according to any preceding claim including a data integrity module which is configured to apply a predefined hash algorithm to one or more components of the check-in record, and / or data derived from to one or more components of the check-in record, and cause storage of one or more digests generated by the hash algorithm.

7. A system according to claim 6 wherein the one or more digests are added to a blockchain.

8. A system according to any preceding claim wherein the authentication module is configured to perform biometric authentication based on a live video capture of the user, which requires that the user perform a defined physical activity.

9. A system according to any preceding claim wherein the verification of an identity of the user of the mobile device based on a predefined identity record is performed based on existing stored validated biometric identity records.

10. A system according to any preceding claim including a check-in terminal, wherein the checkin terminal is configured to operate at a known location, includes a scanner device for performing biometric identification; a check-in verification module for verifying that the checkin record satisfies data requirements; and a data management module configured to maintain a record of persons arriving at the known location based on respective check-in records.11 . A method configured to enable generation and sharing of secure data records for point-in- time verification of identity and location, the method including: causing an authentication module to perform biometric authentication of a user of a mobile device, thereby to verify an identity of the user of the mobile device based on a predefined identity record; causing a location services module to determine an authentication location of the mobile device, including positional data determined at a time corresponding to the biometric authentication; causing a record generation module to initiate generation of a check-in record in a cloud- hosted database, wherein the check-in record includes components which provide data representative of (i) the biometric authentication; (ii) the verified identity; (iii) the authentication location; and (iv) an authentication time;causing an encoding module to initiate encoding of: (i) a record URL which is configured to, when accessed, cause rendering of data extracted from the check-in record; and (ii) a QR code configured to cause accessing of the record URL; and causing an event image generation module configured to initiate generation of an event image containing graphical representations of: (i) one or more components of the check-in record; and (ii) the QR code; such that the event image is able to be shared via communications channels, and data displayed in the event image is able to be verified against data stored in the cloud-hosted database via the record URL.

12. A method according to claim 11 including performing a captured media item management process which is configured to: (i) identify a captured media item captured via hardware of the mobile device satisfying predefined requirements; (ii) generate a watermarked version of that captured media item containing visual representations of (A) one or more components of the check-in record; and (B) the QR code.

13. A method according to claim 12 wherein the watermarked version of the captured media item additionally contains (C) text data generated by the user.

14. A method according to claim 12 or claim 13 including performing an upload process configured to cause storing of the watermarked version of the captured media item in the cloud-hosted database in a manner accessible via the record URL.

15. A method according to any one of claims 1 1 to 14 wherein the encoding module is additionally configured to generate an alphanumeric UID which is uniquely representative of the check-in record.

16. A method according to any one or claims 11 to 15 including performing a data integrity process which is configured to apply a predefined hash algorithm to one or more components of the check-in record, and / or data derived from to one or more components of the check-in record, and cause storage of one or more digests generated by the hash algorithm.

17. A method according to claim 16 wherein the one or more digests are added to a blockchain.

18. A method according to any one of claims 1 1 to 17 wherein the authentication module is configured to perform biometric authentication based on a live video capture of the user, which requires that the user perform a defined physical activity.

19. A method according to any one of claims 11 to 18 wherein the verification of an identity of the user of the mobile device based on a predefined identity record is performed based on existing validated biometric identity records stored in a central location.

20. A method according to any preceding claim including performing a process at a check-in terminal, wherein the check-in terminal is configured to operate at a known location, includes a scanner device for performing biometric authentication; a check-in verification module for verifying that the check-in record satisfies data requirements; and a data management module configured to maintain a record of persons arriving at the known location based on respective check-in records.21 . A method for facilitating document execution, the method including: accessing an authored electronic document; operating an External Verification Compliant (EVC) document generation module thereby to process the authored electronic document and generate an EVC document containing content from the authored electronic document, wherein the EVC document has an associated unique document code (UDC) which is unique to the EVC document; wherein an external user verification system is configured to enable generation of check-in records via user verification software applications executing at distributed user devices, wherein each check in record is generated via a process wherein a user of a given one of the user devices is required to undergo biometric identity verification, wherein each checkin record is associated with data representative of:(i) successful biometric identity verification for the user;(ii) one or more additional check-in-specific data values; and(iii) a unique Check-In Record Identifier (CRI) for the check-in record; wherein a check-in record management system is configured to securely maintain data representative of the check-in records, such that a given record is able to be viewed via a data query including the associated CRI for that record; and wherein the EVC includes a field into which a signatory inputs an execution CRI, being a CRI associated with execution of the document at the time of execution.

22. A method according to claim 21 wherein, in respect of the execution CRI, the relevant instance of the user verification software application receives an input the UDC for the EVCdocument, and wherein the check-in record associated with the execution CRI is defined to contain data representative of the UDC.

23. A method according to any one of claims 21 to 22, in respect of the execution CRI, the relevant instance of the user verification software application receives an input the UDC for the EVC document, and wherein in response the user verification software application performs a query of an EVC document management system which maintains current status data for each EVC document, thereby to verify a current acceptable status for the EVC document.

24. A method according to any one of claims 21 to 23 wherein the EVC document is associated with a document integrity value which is generated based on a document integrity algorithm which inputs data extracted from EVC document.

25. A method according to claim 24 wherein the EVC document is viewed via a document viewer application, and wherein the document viewer application has a functionality to cause performance of the document integrity algorithm in respect of the EVC document being viewed, thereby to verify that the EVC document has not been modified relative to the version generated by the EVC document generation module.

26. A method according to claim 24 or claim 25 wherein the UDC includes a value derived from the document integrity value.

27. A method according to claim 24 or claim 25 wherein the EVC document generation module embeds the document integrity value into the EVD document.

28. A method according to any one of claims 24 to 26 wherein the EVC document generation module provides the document integrity value to an EVC document management system which maintains a current status data for each EVC document.

29. A method according to any one of claims 24 to 27 wherein the document integrity algorithm includes a hash of content defined by the authored electronic document.

30. A method according to any one of claims 21 to 29 wherein the EVC document is viewed via a document viewer application, and wherein the document viewer application has a functionality to enable execution of the document including insertion of the execution CRI.31 . A method according to claim 30 wherein the document viewer application is configured to provide the inserted execution CRI to a EVC document management system upon execution of the document.

32. A method according to claim 31 wherein the EVC document management system is additionally configured to receive each execution CRI upon generation from instances of the user verification software application, and wherein upon execution a process is performed to match the inserted execution CRI against a CRI maintained by the EVC document management system, thereby to validate the inserted execution CRI.

33. A method according to any one of claims 21 to 32 wherein the EVC document is executed via wet signature with a manually inserted execution CRI, and wherein the user verification software application is configured to associate media captured of the wet-signed EVC document with the manually inserted CRI with a check-in record that includes the UDC.

34. A method according to claim 33 wherein the CRI of the check-in record that includes the UDC and is associated with the media captured of the wet-signed EVC document with the manually inserted CRI is transmitted to a EVC document management system and associated with the EVC document.

35. A method according to any one of claims 21 to 34 wherein the user verification software application is configured to generate an image file containing UDC for the EVC document and the execution CRI.

36. A method according to claim 35 wherein the image file is associated with an image which shows the EVC document in an executed state including the execution CRI.

37. A method according to any one of claims 21 to 36 wherein a check-in record management system is configured to securely maintain data representative of the check-in records in a format where the check-in record data is unable to be modified.

38. A method according to claim 37 wherein the data representative of the check-in records is maintained as a blockchain.

39. A method according to any one of claims 21 to 38 wherein the EDC document contains an optically readable indicia which, when read by a mobile device, causes the mobile device to display an interface configured to facilitate generation of the execution CRI for that document.

40. A method according to any one of claims 21 to 39 wherein an EVC document management system is provided and configured to maintain data representative of a current status for each of a plurality of EVC documents, including execution CRIs for EVC documents that have been executed.

41. A system configured to enable inter-party identification verification in the context of an electronic remote interaction, the system including: a server system which is configured to communicate with a plurality of mobile devices which each execute respective instances of User Verification Software Application (UVSA), wherein the UVSA executes at a plurality of user devices, wherein each instance of the UVSA is configured to perform a check in process which includes:(i) performing a point-in-time biometric identify verification of a specific person having an associated a UVSA ID;(ii) generating a Check In Record (CIR), wherein the CIR is a dataset including (a) data including data representative of the biometric identification verification; (b) data representative of one or more artefacts of objective point-in-time evidence; and (c) a Check In Record Identifier (CRI) which uniquely identifies the Check in Record; and(iii) transmitting the CIR to the server system; wherein the server system is additionally configured to process CIRs received from instances of the UVSA and store those CIRs in a CIR database, wherein the CIR database is configured to enable access to data for a given CIR based on a query which includes the CRI for that CIR, wherein the access includes enabling rendering of a web page at a client device, the web page being configured to present data representative of the given CIR in a predefined format; wherein the system includes a prompt-trigger module associated with the server system, wherein the prompt-trigger module is configured to receive, from an external promptrequestor module, input representative of a specified UVSA ID and, in response: (a) cause the instance of the UVSA associated with that UVSA ID to display a CIR-prompt for generation of a CIR having defined CIR parameters; (b) monitor for generation of a CIR having defined attributes corresponding to the CIR-prompt; and (c) in the case that a CIR having defined attributes corresponding to the CIR-prompt is identified, cause transmission of the CRI for that CIR to the prompt-requestor module; such that an operator of the prompt requestor module is able to access the CIR having defined attributes corresponding to the CIR-prompt, thereby perform data validation relative to the defined CIR parameters.

42. A system according to claim 41 wherein the CRI-prompt is associated with data indicative of a trust rating associated with the prom pt- requestor module.

43. A system according to claim 42 wherein the trust rating includes data representative of an identity and level of identity authentication of the prompt-requestor module.

44. A system according to claim 42 or claim 43 wherein the trust rating includes data representative of one or more warnings in relation to the prompt-requestor module.

45. A system according to any one of claims 41 to 44 wherein the prompt-request module is associated with a service provider, wherein the service provider is robustly authenticated.

46. A system according to any one of claims 41 to 45 wherein each UVSA is user configurable to accept CIR-prompts only from prompt-requestor modules having predefined promptrequestor attributes.

47. A system according to claim 46 wherein the predefined prompt-requestor attributes include a prompt-requestor identity corresponding to a limited set of authenticated prompt-requestor identities which are selected by the user.

48. A system according to claim 46 or claim 47 wherein the predefined prompt-requestor attributes include a CRI having defined CRI parameters.

49. A system according to any one of claims 41 to 48 wherein the UVSA is additionally configured to generate an image file representative of the CIR, wherein the image file includes the (a) data including data representative of the biometric identification verification; (b) data representative of one or more artefacts of objective point-in-time evidence; and (c) Check In Record Identifier (CRI) which uniquely identifies the Check in Record.

50. A system according to claim 49 wherein the image file includes a QR code which embeds the CRI and is configured to access a web page for the CIR.51 . A method according to any one of claims 21 to 40 wherein the check in record is a check-in record generated by a system according to any one of claims 1 to 20.

52. A method according to any one of claims 41 to 50 wherein the Check In Record is a checkin record generated by a system according to any one of claims 1 to 20.

Images