WO2019237175A1

WO2019237175A1 - Method and system for assessing participants

Info

Publication number: WO2019237175A1
Application number: PCT/CA2018/050725
Authority: WO
Inventors: Robert Day; Scott Dellinger
Original assignee: Integrity Advocate Inc.
Priority date: 2018-06-14
Filing date: 2018-06-14
Publication date: 2019-12-19

Abstract

A method of assessing a participant taking part in accessing a host web page is disclosed. The method involves causing a processor to receive host identifying information and a participant identifier when a participant device accesses the host web page, and to determine whether the host identifying information is associated with an application entry. When the host identifying information is associated with the application entry, the method further involves causing the processor to receive a reference image and an initial participant image, the reference image depicting a reference identifier and a reference participant image. The method further involves causing the processor to: associate the participant identifier, the reference image and the initial participant image with a session entry; associate an identifier-validated indicator with the session entry when an identifier match criterion is satisfied; and associate an image-validated indicator with the session entry when an image match criterion is satisfied.

Description

METHOD AND SYSTEM FOR ASSESSING PARTICIPANTS

FIELD

This disclosure relates generally to assessing a participant taking part in accessing a host web page.

BACKGROUND

Assessing participants taking part in accessing an online host web page may allow a host operating the host web page to verify that a particular participant is the correct individual accessing the host web page and that a particular participant was accessing the online host web page for a desired of amount of time. Traditional methods of assessing participants involve installing monitoring software on participant devices associated with the participant, or involve assessments performed directly by the host. However, requiring participants to install monitoring software can be cumbersome. Further not all hosts have the capability, capacity or desire to monitor and assess every participant accessing the host web page.

SUMMARY

In one embodiment, there is provided a method of assessing a participant taking part in accessing a host web page. The method involves: causing at least one processor to receive, from a participant device, host identifying information identifying the host web page and a participant identifier identifying the participant when the participant device accesses the host web page; and causing the at least one processor to determine whether the host identifying information is associated with an application entry stored in an application table. The method further involves, when the host identifying information is associated with the application entry, causing the at least one processor to at least receive a reference image and an initial participant image from the participant device. The reference image depicts a reference identifier and a reference participant image. The method further involves, when the host identifying information is associated with the application entry, causing the at least one processor to at least: associate the participant identifier, the reference image and the initial participant image with a session entry stored in an session table, the session entry representing a host web page access session associated with the participant; associate an identifier-validated indicator with the session entry when the reference identifier and the participant identifier satisfy an identifier match criterion; and associate an image-validated indicator with the session entry when the reference participant image and the initial participant image satisfy an image match criterion. In another embodiment, there is provided a method of configuring a host web page. The method involves embedding a script element into the host web page. The script element includes host identifying information identifying the host web page, a participant identifier identifying a participant taking part in accessing the host web page, and a location of non-transitory instructions which, when executed by at least one processor, directs the at least one processor to perform the method described above or any of its variants. The script element further includes code for directing a participant device associated with the participant to transmit the host identifying information and the participant identifier to the at least one processor and to cause the at least one processor to execute the non-transitory instructions, such that when the participant device accesses the host web page and processes the script element, the participant device transmits the host identifying information and the participant identifier to the at least one processor and causes the at least one processor to execute the non-transitory instructions.

In another embodiment, there is provided a system including a computer readable medium storing non-transitory instructions, which, when executed by the at least one processor, cause the at least one processor to execute the method described above or any of its variants. BRIEF DESCRIPTION OF DRAWINGS

Figure 1 is a schematic representation of an illustrative system for assessing participants.

Figure 2 is a schematic representation of an assessment server of the system of Figure

1 in accordance with one embodiment.

Figure 3 is an entity-relationship diagram of an application database of the assessment server of Figure 2.

Figure 4 is a schematic representation of a userdata entry of the application database of Figure 3.

Figure 5 is a schematic representation of a user entry of the application database of

Figure 3.

Figure 6 is a schematic representation of an order entry of the application database of

Figure 3.

Figure 7 is a schematic representation of an orderitem entry of the application database of Figure 3.

Figure 8 is a schematic representation of a camerafail entry of the application database of Figure 3.

Figure 9 is a schematic representation of an application entry of the application database of Figure 3.

Figure 10 is a schematic representation of a demo entry of the application database of

Figure 3.

Figure 11 is a schematic representation of a participant entry of the application database of Figure 3.

Figure 12 is a schematic representation of a participantdata entry of the application database of Figure 3. Figure 13 is a schematic representation of a participantsession entry of the application database of Figure 3.

Figure 14 is a schematic representation of a tracking entry of the application database of

Figure 3. Figure 15 is a schematic representation of a flagtype entry of the application database of

Figure 3.

Figure 16 is a schematic representation of a selectedflagtype entry of the application database of Figure 3.

Figure 17 is a schematic representation of a flagstatus entry of the application database of Figure 3.

Figure 18 is a schematic representation of a participantdataflag entry of the application database of Figure 3.

Figure 19 is a schematic representation of a welcome page generated according to user interface codes of the assessment server of Figure 2. Figure 20 is a schematic representation of a login page generated according to the user interface codes of the assessment server of Figure 2.

Figure 21 is a schematic representation of a registration page generated according to the user interface codes of the assessment server of Figure 2.

Figure 22 is a schematic representation of a host account page generated according to the user interface codes of the assessment server of Figure 2.

Figure 23 is a schematic representation of an add application page generated according to the user interface codes of the assessment server of Figure 2.

Figure 24 is a schematic representation of add application codes in program memory of the assessment server of Figure 2. Figure 25 is a schematic representation of an application region of the host account page of Figure 22 including an inactive instance of the application entry of Figure 9.

Figure 26 is a schematic representation of an edit application page generated according to the user interface codes of the assessment server of Figure 2.

Figure 27 is a schematic representation of a first activate application page generated according to the user interface codes of the assessment server of Figure 2.

Figure 28 is a schematic representation of a second activate application page generated according to the user interface codes of the assessment server of Figure 2.

Figure 29 is a schematic representation of a third activate application page generated according to the user interface codes of the assessment server of Figure 2.

Figure 30 is a schematic representation of activate application codes in the program memory of the assessment server of Figure 2.

Figure 31 is a schematic representation of the application region of Figure 25 including an active instance of the application entry of Figure 9.

Figure 32 is a schematic representation of an application information region of the edit application page of Figure 26.

Figure 33 is a schematic representation of a host server of the system of Figure 1 in accordance with one embodiment.

Figure 34 is a schematic representation of a hostparticipant entry of the participant database of Figure 41.

Figure 35 is a schematic representation of a script tag embedded into FITML code of a host web page.

Figure 36 is a schematic representation of a participant assessment request sent by the host server of Figure 33 to the assessment server of Figure 2. Figure 37 is a schematic representation of vary script tag codes in program memory of the host server of Figure 33.

Figure 38 is a schematic representation of a host web page generated according to the user interface codes of the host server of Figure 33.

Figure 39 is a schematic representation of participant data collection server codes in the program memory of the assessment server of Figure 2.

Figures 40A and 40B are schematic representations of participant data collection browser codes transmitted to a participant device of the system of Figure 1 by the assessment server of Figure 2.

Figure 41 is a schematic representation of a camera fail panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 42 is a schematic representation of a privacy policy panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 43 is a schematic representation of a collect initial participant image panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 44 is a schematic representation of a submit initial participant image panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 45 is a schematic representation of an initial participant image capture demonstration panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 46 is a schematic representation of a collect reference image panel generated according to the participant data collection browser codes of Figures 40A and

40B. Figure 47 is a schematic representation of a submit reference image panel generated according to the participant data collection browser codes of Figures 40A and

40B.

Figure 48 is a schematic representation of a reference image capture demonstration panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 49 is a schematic representation of a participant tracking and proctoring panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 50 is a schematic representation of the host web page of Figure 38 having the participant tracking and proctoring panel of Figure 49 collapsed.

Figure 51 is a schematic representation of the participant tracking and proctoring panel of Figure 49 further a presence input panel generated according to the participant data collection browser codes of Figures 40A and 40B.

Figure 52 is a schematic representation of end session codes in the program memory of the assessment server of Figure 2.

Figures 53A and 53B are schematic representations of participant assessment codes in the program memory of the assessment server of Figure 2.

Figure 54 is a schematic representation of a reviewer account page generated according to the user interface codes of the assessment server of Figure 2.

Figure 55 is a schematic representation of a reviewer interface generated according to the user interface codes of the assessment server of Figure 2.

Figure 56 is a schematic representation of a participant information panel generated according to the user interface codes of the assessment server of Figure 2.

Figure 57 is a schematic representation of an add flag panel generated according to the user interface codes of the assessment server of Figure 2. Figure 58 is a schematic representation of an edit flag panel generated according to the user interface codes of the assessment server of Figure 2.

Figure 59 is a schematic representation of a no-session page generated according to the user interface codes of the assessment server of Figure 2. Figure 60 is a schematic representation of a reviewed session region of the reviewer account page of Figure 54.

Figure 61 is a schematic representation of unlock session codes in the program memory of the assessment server of Figure 2.

Figure 62 is a schematic representation of clean session codes in the program memory of the assessment server of Figure 2.

Figure 63 is a schematic representation of assessment request response codes in the program memory of the assessment server of Figure 2.

Figure 64 is a schematic representation of an assessment results region of the host account page of Figure 22. Figure 65 is a schematic representation of an expanded row of the assessment results region of Figure 64.

DETAILED DESCRIPTION

An illustrative system including an assessment server 102, a host device 104, a host server 106, at least one participant device 108, and at least one reviewer device 110 is shown generally at 100 in Figure 1.

In the embodiment shown, the host device 104 and the host server 106 are associated with a host. The host may be an organization that provides or operates a plurality of host web pages using the host server 106, and an individual of that organization may operate the host device 104 on behalf of the organization. Some host web pages may provide content that requires an assessment of participants taking part in accessing that content, and may specifically require the host to verify an identity of, or to proctor the participation of, participants. For example, a particular host web page may provide an on-line continuing education webinar which requires the host to verify an identity of a participant taking part in the webinar and also to confirm that participant was in fact physically present for the duration of the webinar. Another host web page may provide on-line notarization services, which require the host to verify an identity of a participant seeking to use the on-line notarization service. Another host web page may administer online focus groups in which participants participate in providing opinions and reactions in response to products and questions and which require the host to assess a demographic of the participant and a reaction of the participant to the products or the questions.

For such host web pages, the host may outsource the assessment of the participant to a third party, such as an assessment provider associated with the assessment server 102 for example. In the embodiment shown, the assessment provider is an organization which provides participant assessment services, including participant identity verification and participant proctoring services for example, for a plurality of different hosts.

The host may use the host device 104 to communicate with the assessment server 102 to register a particular host web page requiring participant assessment services with the assessment server 102. Once the host web page is successfully registered, the assessment server 102 then provides the host (such as via the host device 104) with a participant assessment application that can be embedded into the particular host web page.

The host then uses the host server 106 to embed the participant assessment application into the host web page (via a script element described below for example) such that when a participant associated with the at least one participant device 108 accesses the host web page, the participant assessment application enables the assessment server 102 to collect participant data associated with the participant from the at least one participant device 108.

The assessment server 102 can then analyze the participant data automatically to validate or invalidate a host web page access session associated with the participant. The assessment server 102 can also task reviewers associated with the at least one reviewer device 110 to analyze the participant data to validate or invalidate the host web page access session. The validation or invalidation of the host web page access session is then communicated by the assessment server 102 to the host via the host server 106 or the host device 104.

Assessment Server

As described above, the assessment provider is an entity which provides participant assessment services on behalf of a plurality of hosts. In the embodiment shown, the assessment provider provides such participant assessment services via the assessment server 102. An illustrative embodiment of the assessment server is shown generally at 102 in Figure 2. The assessment server 102 includes a processor circuit, which in the embodiment shown includes at least one microprocessor 120, and a clock 122, an input/output (“I/O”) interface 124, a program memory 128, and a storage memory 126, all in communication with the assessment server microprocessor 120.

The clock 122 maintains values representing a current date and time, and provides such values to the assessment server microprocessor 120 for storage in various data stores in the storage memory 126 as discussed below. The I/O interface 124 includes an internet interface 130 for communicating, over various components of the internet shown generally at 132 with the participant device 108, the reviewer device 110, the host device 104 and the host server 106. Although only a single host device 104, host server 106, participant device 108 and reviewer device 110 are shown in the embodiment of Figure 1 , alternative embodiments may include a large number of host devices 104, host servers 106, participant devices 108 and reviewer devices 110.

The program memory 128 and the storage memory 126 may each be implemented as one of, or as a combination of, a random access memory (“RAM”), a hard disk drive (“HDD”), and other computer-readable and/or -writable memory. In alternative embodiments (not shown), the assessment server 102 may be partly or fully implemented using different hardware logic, which may include discrete logic circuits and/or an application specific integrated circuit (“ASIC”), for example. The storage memory 126 generally stores information obtained by the assessment server 102, and thus the storage memory 126 may more generally be referred to as an information store. The program memory 128 generally include codes for directing the assessment server microprocessor 120 to execute various functions of assessment server 102, including functions which allow the assessment server 102 to provide the participant assessment services.

The program memory 128 includes various blocks of code, including operating system codes 140 of an operating system for assessment server 102. In the embodiment shown, the operating system codes 140 implement a Linux operating system. The program memory 128 also includes hypertext transfer protocol (“HTTP”) server codes 142, which include codes that make various assessment provider web pages available to hosts and reviewers accessing the assessment server 102 over the internet 132 such as to the host via the host device 110 and the reviewer via the reviewer device 110 for example. In the embodiment shown, the HTTP server codes 142 include codes of Apache HTTP server and VMWare software codes. The program memory 128 also includes application server codes 144, which include codes that make application functionality available to hosts and participants accessing the assessment server 102 over the internet 132 such as to the host via the host server 106 and the participant via the participant device 108 for example. In the embodiment shown, the application server codes 144 include Java EE platform codes, .NET framework codes and PHP application server codes.

The program memory 128 also includes database management system (“DBMS”) codes 146 for managing an application database 150 and an image database 152 in the storage memory 126. An embodiment of the application database 150 is shown generally in Figure 3 and is a relational database including a plurality of tables. The various tables of the application database 150 can each store various entries as described below. The various entries each include various fields, and an instance of such an entry can store particular values in such fields.

Referring to Figure 3, the application database 150 includes a userdata table 160 that can store any number of instances of a userdata entry shown generally at 161 in Figure 4. An instance of the userdata entry 161 stores personal data associated with a user registered with the assessment server 102, such as the reviewer or the host for example. In the embodiment of Figure 4, the userdata entry 161 includes an identifier field 162, which stores an integer (a userdata identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the userdata entry 161 uniquely in the userdata table 160 (shown in Figure 3). The userdata entry 161 also includes a firstname field 164 and a lastname field 166 for storing a first name and a last name respectively, an address field 168, a city field 170 for storing an address, a jurisdiction 172 for storing a jurisdiction

(such as a province, state, prefecture or territory for example, a country field 174 for storing a country; a postalcode field 176 for storing a postal code (or zip code for example), and a company field 182 for storing a company name. The userdata entry 161 also includes a created field 178 which stores a date and time of when an instance of the userdata entry 161 was created, and a modified field 180 for storing a date and time of when an instance of the userdata entry 161 was updated.

Referring back to Figure 3, the application database 150 also includes user table 190 that can store any number of instances of a user entry shown generally at 191 in Figure 5. An instance of user entry 191 represents a user of the assessment server 102, and may represent a particular host or a particular reviewer for example, and stores login information of that user. In the embodiment of Figure 5, the user entry 191 includes an identifier field 192 which stores an integer (a user identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the user entry 191 uniquely in the user table 190 (shown in Figure 3).

The user entry 191 also includes an email field 194 for storing an electronic mail address, a password field 196 for storing a password (and may store the password in hash form), and a username field 198 for storing a user name. In certain instances of the user entry 191 , the username field 198 may store, as the user name, the electronic mail address stored in the email field 194.

The user entry 191 also includes userdataidentifier field 200, which stores a userdata identifier stored in the identifier field 162 an instance of the userdata entry 161 (shown in Figure 4), such that an instance of the user entry 191 identifies an instance of the userdata entry 161. In the embodiment shown, only one instance of the user entry 191 can identify a particular instance of the userdata entry 161 , and thus the user table 190 is shown in Figure 3 as having a 1 :1 relationship to the userdata table 160.

Each instance of the user entry 191 is also associated with a roletype indicator representing a role of the user of the assessment server 102. An instance of the user entry 191 may be associated with a“host” roletype indicator if the user is a host or a “reviewer” roletype indicator if the user is a reviewer.

Referring back to Figure 3, the application database 150 includes an order table 230 that can store any number of instances of an order entry shown generally at 231 in Figure 6. An instance of the order entry 231 represents a particular order for participant assessment services made by a host, and stores various billing and order status information. In the embodiment of Figure 6, the order entry 231 includes an identifier field 232 which stores an integer (an order identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the order entry 231 uniquely in the order table 230 (shown in Figure 3). The order entry 231 also includes a billinginformation field 234 which can store billing information, such as a company name, a first name, a last name, a street address, a city, a jurisdiction (such as a province, state, prefecture or territory for example), a country, and a postal or zip code for example

The order entry 231 further includes a useridentifier field 249 which stores a user identifier stored in the identifier field 192 of an instance of the user entry 191 (shown in Figure 5), and thus an instance of the order entry 231 identifies an instance of the user entry 191. Further, in the embodiment shown, several instances of the order entry 231 can identify a same instance of the user entry 191 , generally representing that one user can make a plurality of different orders. Thus the order table 230 is shown in Figure 3 as having a N:1 relationship to the user table 190, The order entry 231 further includes a transactionidentifier field 250 for storing a transaction identifier received from a payment processor 251 (shown in Figure 2) or an invoice identifier as described below, an invoiced field 252 for storing a date and time when an invoice is issued by the assessment provider, and a paid field 254 for storing a date and time when a transaction occurred or an invoice payment was received by the assessment provider. The order entry 231 also includes a created field 256 which stores a date and time when an instance of the order entry 231 was created, and a modified field 258 for storing a date and time when an instance of the order entry 231 was updated.

Referring back to Figure 3, the application database 150 also includes an orderitem table 280 that can store any number of instances of an orderitem entry shown generally at 281 in Figure 7. An instance of the orderitem table 280 generally stores information the assessment services purchased by a host and whether these assessment services are currently active, as explained in greater detail below. In the embodiment of Figure 7, the orderitem entry 281 includes an identifier field 282 which stores an integer (an orderitem identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the orderitem entry 281 uniquely in the orderitem table 280 (shown in Figure 3).

The orderitem entry 281 also includes a product field 286 which stores an indicator representing at least one participant assessment service provided by the assessment provider. For example, the orderitem entry 281 can store a participant identity verification indicator representing participant identity verification services and/or a participant proctoring service indicator representing participant proctoring services. The orderitem entry also includes a unitprice field 288 for storing a price of each assessment unit of the participant assessment service.

The orderitem entry 281 also includes an orderidentifier field 284 which stores an order identifier stored in the identifier field 232 of an instance of the order entry 231 (shown in Figure 6) and an applicationidentifier field 296 which stores an application identifier in an identifier field 312 of an instance of the application entry 311 (show in Figure 9 and described below) in an application table 310 (shown in Figure 3). More generally, the orderitem entry 281 functions to associate an instance of the order entry 231 and an instance of the application entry 311. Further, because the orderitem entry 281 stores the indicator representing at least one participant assessment service, the orderitem entry 281 also associates at least one participant assessment service with an instance of the application entry 311 to indicate which participant assessment services are provided by that instance of the application entry 311.

The orderitem entry 281 further includes a quantity field 290 for storing a representation of a number of assessment units originally purchased relative to a number of assessment units available for use. In the embodiment shown, the quantity field 290 stores a ratio of “# of available assessments” to“# of purchased assessments”. The orderitem entry 281 also includes a status field 292 for storing an“active” label if the quantity field 290 stores a positive ratio and an“inactive” label if the quantity field 290 stores a negative ration. The orderitem entry 281 also includes a created field 294 which stores a date and time when an instance of the orderitem entry 281 was created.

Referring back to Figure 3, the application database 150 also includes a camerafail table 300 that can store any number of instances of a camerafail entry shown generally at 301 in Figure 8. An instance of the of the camerafail entry 301 represents an action to be performed by a participant device 108 when a web camera associated with the participant device 108 is not operational. In the embodiment of Figure 8, the camerafail entry 301 includes an identifier field 302 which stores an integer (a camerafail identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the camerafail entry 301 uniquely in the camerafail table 300 (shown in Figure 3). The camerafail entry 301 also includes a name field 304 which identifies the action to be performed by the participant device 108.

In the embodiment shown, the camerafail table 300 stores at least the following instances of the camerafail entry 301 :

• a“fail gracefully” instance which stores“fail gracefully” in the name field 304;

• a“go back one page” instance which stores“go back one page” in the name field

304; and

• a“redirect to URL” instance which stores“redirect to URL in the name field 304.

Referring back to Figure 3, the application database 150 also includes the application table 310 that can store any number of instances of the application entry shown generally at 311 in Figure 9. An instance of the application entry 311 generally represents a participant assessment application which can be embedded into a host web page. In the embodiment of Figure 9, the application entry 311 includes an identifier field 312 which stores an integer (an application identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the application entry 311 uniquely in the application table 310.

The application entry 311 also includes a useridentifier field 314 which stores a user identifier stored in the identifier field 192 of an instance of the user entry 191 (shown in Figure 5) representing a host, and thus an instance of the application entry 311 identifies an instance of the user entry 191 representing a host. In the embodiment shown, several instances of the application entry 311 can identity the same instance of the user entry 191 , generally indicating that a particular host can be associated with a plurality of different participant assessment applications. Thus the application table 310 is shown in Figure 3 as having a N:1 relationship to the user table 190.

The application entry 311 further includes an applicationname field 315 for storing a name of an assessment application, a hostwebpageURL field 317 for storing a uniform resource locator (“URL”) of a host web page, and a initialparticipantimagejext field 316, a participantidentification text field 318, a participantidentificationl prompt field 320, a participantidentification2_prompt field 322, and a participantidentification3_prompt field 324 all for storing respective text strings representing customized messages to be displayed to participants accessing a host web page having the participant assessment application embedded therein as described below.

The application entry 311 further includes a camerafailidentifier field 326 for storing a camerafail identifier stored in the identifier 302 of an instance of the camerafail entry 301 (shown in Figure 8), and a camerfailredirectURL field 328 for storing a URL of a web page. More generally, an instance of the application entry 311 identifies an instance of the camerafail entry 301. In the embodiment shown, more than one instance of the application entry 311 can identify a same instance of the camerafail entry 301 , generally representing that a particular participant assessment application will identify a particular camera fail action for participant devices which do not have operational web cameras. Thus the application table 310 is shown in Figure 3 as having a N:1 relationship to the camerafail table 300.

The application entry 311 further includes information which may be used by the host to identify an instance of the application entry 311 in the application table. In the embodiment shown, the application entry 311 includes an APIkey field 333 which stores a code for identifying an entity (such as the host server 106 for example) calling the assessment server 102 and a generatedapplicationidentifier field 334 which stores a“web page embeddable application” identifier for identifying an instance of the application entry 311 uniquely in the application table 310. The application entry 311 also includes a created field 335 which stores a date and time when an instance of the application entry 311 was created, and a modified field 336 for storing a date and time when an instance of the application entry 311 was updated.

Referring back to Figure 3, the application database 150 also includes a demo table 370 that can store any number of instances of a demo entry shown generally at 371 in Figure 10. An instance of the demo entry 371 provides a record of a participant device accessing a host web page having an inactive participant assessment application embedded therein. In the embodiment of Figure 10, the demo entry 371 includes an identifier field 372 which stores an integer (a demo identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the demo entry 371 uniquely in the demo table 370.

The demo entry 371 also includes an applicationidentifier field 374 which stores an application identifier stored in the identifier field 312 of an instance of the application entry 311 (shown in Figure 9), and thus an instance of the demo entry 371 identifies an instance of the application entry 311. In the embodiment shown, several instances of the demo entry 371 can identify the same instance of the application entry, generally indicating that a host web page having an inactive participant assessment application can be accessed a plurality of different times by participant devices. Thus the demo table 370 is shown in Figure 3 as having a N:1 relationship to the application table 310.

The demo entry 371 also includes a demoURL field 376 for storing a URL of the host web page having an inactive participant assessment application embedded therein and a created field 378 which stores a date and time when an instance of the demo entry 371 was created.

Referring back to Figure 3, the application database 150 also includes a participant table 380 that can store any number of instances of a participant entry shown generally at 381 in Figure 11. More generally, an instance of the participant entry 381 represents a participant assessing a host web page having an active participant assessment application embedded therein, and stores various participant information. In the embodiment of Figure 11 , the participant entry 381 includes an identifier field 382 which stores an integer (participant identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the participant entry 381 uniquely in the participant table 380 (shown in Figure 3).

The participant entry 381 also includes an applicationidentifier field 384 which stores an application identifier stored in the identifier field 312 of an instance of the application entry 311 (shown in Figure 9), and thus an instance of the participant entry 381 identifies an instance of the application entry 311. In the embodiment shown, more than one instance of the participant entry 381 can identify a same instance of the application entry 311 , generally representing that a host web page having an active participant assessment application can be accessed by a plurality of different participants. Thus the participant table 380 is shown in Figure 3 as having a N:1 relationship to the application table 310.

The participant entry 381 further incudes a hostparticipantidentifier field 386 which stores a host participant identifier provided by the host server 106, a firstnameparticiptantidentifier field 388 which stores a firstname participant identifier provided by the host server 106 and a lastnameparticiptantidentifier field 390 which stores a lastname participant identifier provided by the host server 106. The participant entry 381 also includes a created field 392 which stores a date and time when an instance of the participant entry 381 was created, and a modified field 394 for storing a date and time when an instance of the participant entry 381 has been updated.

Referring back to Figure 3, the application database 150 also includes a participantdata table 400 that can store any number of instances of a participantdata entry shown generally at 401 in Figure 12. An instance of the participantdata entry 401 generally represents a piece of participant data collected from a participant device 108 using an active participant assessment application and stores various information associated with that piece of participant data. In the embodiment of Figure 12, the participantdata entry 401 includes an identifier field 402 which stores an integer (a participantdata identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the participantdata entry 401 uniquely in the participantdata table 400 (shown in Figure 3).

The participantdata entry 401 also includes a participantidentifier field 404 which stores a participant identifier stored in the identifier field 382 of an instance of the participant entry 381 (shown in Figure 11), and thus an instance of the participantdata entry 401 identifies an instance of the participant entry 381. In the embodiment shown, more than one instance of the participantdata entry 401 can identify a same instance of the participant entry 381 , generally representing that plurality of different pieces of participant data can be collected when a participant device assesses a host web page. Thus the participantdata table 400 is shown in Figure 3 as having a N:1 relationship to the participant table 380.

The participantdata entry 401 also includes a capturedata field 406 for storing a uniform resource identifier (“URI”) identifying a storage location of the participant data in the image database 152 (shown in Figure 2) and a capturetype field 408 for storing a representation of an image type of the participant data. In the embodiment shown, the participant data may be participant images captures by the web camera associated with the participant device 108 and the capturetype field 408 can store one of at least four values, namely “initial participant image”, “reference image 1”, “reference image 2”, “reference image 3” and“subsequent participant image” as described below.

The participantdata entry 401 also includes an IPaddress field 410 for storing an internet protocol (IP) address, a useragent field 412 for storing a text string representing user agent information (including representations of an application type, an operating system, a software vendor and a software version associated with a participant device 108 for example), a browser field 414 for storing a text string representing a software version of a browser application associated with a participant device 108 and a resolution field 416 for storing a representation of a resolution of a web camera associated with a participant device 108. The participantdata entry 401 also includes a created field 418 which stores a date and time when an instance of the participantdata entry 401 was created, and a modified field 420 for storing a date and time when an instance of the participantdata entry 401 was updated.

Referring back to Figure 3, the application database 150 also includes a participantsession table 450 that can store any number of instances of a participantsession entry shown generally at 451 in Figure 13. An instance of the participantsession entry 451 represents a record of a host web page access session of a participant assessing a host web page having an active participant assessment application embedded therein, and further represents a session entry which can be validated or invalidated. In the embodiment of Figure 13, the participantsession entry 451 includes an identifier field 452 which stores an integer (a participantsession identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the participantsession entry 451 uniquely in the participantsession table 450 (shown in Figure 3).

The participantsession entry 451 also includes a participantidentifier field 404 which stores a participant identifier stored in the identifier field 382 of an instance of the participant entry 381 (shown in Figure 11), and thus an instance of the participantsession entry 451 identifies an instance of the participant entry 381. In the embodiment shown, more than one instance of the participantsession entry 451 can identify a same instance of the participant entry 381 , generally indicating that a same participant can assess a same host web page a plurality of different times and that a respective session entry will be created each time. Thus the participantsession table 450 is shown in Figure 3 as having a N:1 relationship to the participant table 380.

The participantsession entry 451 further incudes a sessionstart field 456 and a sessionend field 458 for storing an earliest date and time and a latest date and time respectively stored in the created fields 418 of instances of the participantdata entry 401 (shown in Figure 12) which identify a same instance of the participant entry 381 (shown in Figure 11) as the participantsession entry 451. An instance of the participantsession entry 451 can thus be associated with at least one participantdata entry 401 , generally indicating that a session entry can be associated with a plurality of different pieces of participant data. In this respect, a participantdata entry 401 is associated with an instance of the participantsession entry 451 if (a) the participant identifier stored in the participantidentifier field 404 is the same as the participant identifier stored in the participantidentifier field 454 of that instance of the participantsession entry 451 and (b) the date and time stored in the created field 418 is equal to, or after, the date and time stored in the sessionstart field 456 of that instance of the participantsession entry 451 and before, or earlier than, the date and time stored in the sessionend field 458 of that instance of the of the participantsession entry 451.

The participantsession entry 451 further includes an image_autovalidated field 460, a identifierl autovalidated field 462, a identifier2_autovalidated field 464, a identifier3_autovalidated field 466, for storing respective date and times and indicating that certain pieces of participant data has been automatically validated by the assessment server 102. The participantsession entry 451 further includes a previoussession autovalidated field 467 for storing a date and time and indicating that certain pieces participant data have been automatically validated using a pre-existing (previous) instance of the participantsession entry 451. The participantsession entry 451 further includes a previoussessionidentifier field 468 for storing a participantsession identifier identifying this previous instance of the participantsession entry 451. The participantsession entry 451 further includes a sessionautovalidated field 469 for storing a date and time and indicating that an instance of the participantsession entry 451 has been automatically validated by the assessment server 102.

The participantsession entry 451 further includes a sessionreviewed field 470 for storing a date and time and indicating an instance of the participantsession entry 451 has been reviewed by a reviewer using the reviewer device 110 (shown in Figures 1 and 2). The participantsession entry 451 further includes a revieweridentifier field 472 for storing an user identifier stored in the identifier field 192 of an instance of the user entry 191 (shown in Figure 5) representing that reviewer, and an instance of the participantsession entry 451 thus identifies an instance of the user entry 191 representing a reviewer. In the embodiment shown, more than one instance of the participantsession entry 451 can identify a same instance of the user entry 191 , generally indicating that one reviewer can review a number of host web page access sessions. Thus the participantsession table 450 is shown in Figure 3 as having a N:1 relationship to the user table 190.

The participantsession entry 451 also includes a sessionlocked field 476 for storing an user identifier stored in the identifier field 192 of an instance of the user entry 191 (shown in Figure 5) associated with a reviewer while the reviewer is reviewing.

The participantsession entry 451 also includes a sessioncleaned field 474 for storing a date and time and indicating that certain instances of the participantdata entry 401 associated with the participantsession entry 451 has been deleted using clean session codes 1670 (shown in Figure 2) described below.

Referring back to Figure 3, the application database 150 also includes a tracking table 440 that can store any number of instances of a tracking entry shown generally at 441 in Figure 14. An instance of the tracking entry 440 represents a record of a presence input entered by a participant using a participant device 104. In the embodiment of Figure 14, the tracking entry 441 includes an identifier field 442, which in the embodiment shown, stores an integer (a tracking identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the tracking entry 441 uniquely in the tracking table 440 (shown in Figure 3).

The tracking entry 441 also includes a tracktype field 444 which stores a tracktype indicator representing an activity tracked by the tracking entry 441. For example, in the embodiment shown, the tracktype field 444 can store“presence input”.

The tracking entry 441 also includes a participantsessionidentifier field 446 which stores a participantsession identifier stored in the identifier field 452 of an instance of the participantsession entry 451 (shown in Figure 13), and thus an instance of the tracking entry 441 identifies an instance of the participantsession entry 451. In the embodiment shown, more than one instance of the tracking entry 441 can identify a same instance of the participantsession entry 451 , which generally indicates that more than one presence input may be entered by a participant during a host web page access session. The tracking table 440 is thus shown in Figure 3 as having a N:1 relationship to the participantsession table 450.

The tracking entry 441 also includes a created field 448 which stores a date and time when an instance of the tracking entry 441 was created.

Referring back to Figure 3, the application database 150 also includes a flagtype table 480 that can store any number of instances of a flagtype entry shown generally at 481 in Figure 15. An instance of the flagtype table 481 represents a flag type which identifies a specific participant action or other subject matter, and is identified by a particular flag associated with a piece of participant data to represent a type of that flag. In the embodiment of Figure 15, the flagtype entry 481 includes an identifier field 482 which stores an integer (a flagtype identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the flagtype entry 481 uniquely in the flagtype table 480 (shown in Figure 3). The flagtype entry 481 also includes a name field 484 which stores a text string describing the flag type. The flagtype entry 481 also includes a userselectable field 486 for storing a Boolean value of “TRUE” if an instance of the flagtype entry 481 may selected for a particular assessment server application by a host or a Boolean value of “FALSE if an instance of the flagtype entry 481 cannot be selected.

In the embodiment shown, the flagtype table 480 stores at least the following instances of the flagtype entry 481 :

• a“participant not in view” instance which stores“1” in the identifier field 482, “participant not in view” in the name field 484 and“TRUE” in the userselectable field 486;

• a “multiple participants” instance which stores “2” in the identifier field 482, “multiple participants” in the name field 484 and“TRUE” in the userselectable field

486;

• a“utilised electronic device/headphones” instance which stores“3” in the identifier field 482, “utilised electronic device/headphones” in the name field 484 and “FALSE” in the userselectable field 486;

• an“other” instance which stores“4” in the identifier field 482,“other” the name field 484 and“FALSE” in the userselectable field 486; • an“clear image of participant identification not provided” instance which stores“5” in the identifier field 482,“clear image of participant identification not provided” in the name field 484, and“FALSE” in the userselectable field 486;

• an “clear image of participant not provided” instance which stores “6” in the identifier field 482,“clear image of participant not provided” in the name field 484, and“FALSE” in the userselectable field 486;

• an “information unclear” instance which stores “8” in the identifier field 482, “information received was unclear and/or did not meet requirements” in the name field 484, and“FALSE” in the userselectable field 486;

• an“identifier does not match” instance which stores“9” in the identifier field 482, “identifier on participant identification does not match identifier of participant session” in the name field 484, and“FALSE” in the userselectable field 486;

• a“possible unethical behavior” instance which stores“10” the identifier field 482, “possible unethical behavior” in the name field 484, and “FALSE” in the userselectable field 486; and

• a“non-participation” instance which stores“11” in the identifier field 482, “non participation” in the name field 484, and“FALSE” in the userselectable field 486.

Referring back to Figure 3, the application database 150 also includes a selectedflagtype table 490 that can store any number of instances of a selectedflagtype entry shown generally at 491 in Figure 16. An instance of the selectedflagtype entry 491 represents which of the flag types which store“TRUE” in the userselectable field 486 were selected by a host for a particular participant assessment application.

In the embodiment of Figure 16, the selectedflagtype entry 491 includes an applicationidentifier field 492 which stores an application identifier stored in the identifier field 312 of an instance of the application entry 311 (shown in Figure 9) and a flagtypeidentifier field 494 which stores an flagtype identifier stored in the identifier field

382 of an instance of the flagtype entry 481 (shown in Figure 15). The selectedflagtype entry 491 thus associates an instance of the flagtype entry 481 with an instance of the application entry 311. In the embodiment shown, more than one instance of the selectedflagtype entry 491 can identify a same instance of the application entry 311 and more than one instance of the selectedflagtype entry 491 can identify a same instance of the flagtype entry 481 in the flagtype table 480, generally representing that a particular flag type may be associated with a plurality of different participant assessment applications and further that a particular participant assessment application may be associated with a plurality of different flag types. The selectedflagtype table 490 is thus shown in Figure 3 having a N:1 relationship to the application table 310 and a N:1 relationship to the flagtype table 480.

Referring back to Figure 3, the application database 150 also includes a flagstatus table 500 that can store any number of instances of a flagstatus entry shown generally at 501 in Figure 17. An instance of the flagstatus entry 501 represents a status of a flag, and is identified by a particular flag associated with a piece of participant data to represent a status of that flag. In the embodiment of Figure 17 the flagstatus entry 501 includes an identifier field 502 which stores an integer (a flagstatus identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the flagstatus entry 481 uniquely in the flagstatus table 480 (shown in Figure 3). The flagstatus entry 501 also includes a name field 504 which stores a text string representing a flag status.

In the embodiment shown, the flagstatus table 500 stores at least the following instances of the flagstatus entry 501 :

• an“initiated” instance which stores“initiated” in the name field 504;

• a“confirmed” instance which stores“confirmed” in the name field 504; and

· a“resolved” instance which stores“resolved” in the name field 504.

Referring back to Figure 3, the application database 150 also includes a participantdataflag table 510 that can store any number of instances of a participantdataflag entry shown generally at 511 in Figure 18. An instance of the participantdataflag entry 511 represents a flag which can be associated with a piece of participant data. In the embodiment of Figure 18, the participantdataflag entry 511 includes an identifier field 512 which stores an integer (a participantdataflag identifier) assigned by the DBMS codes 146 (shown in Figure 2) to identify an instance of the participantdataflag entry 511 uniquely in the participantdataflag table 510. The participantdataflag entry 511 also includes a participantdataidentifier field 514 which stores a participantdata identifier stored in the identifier field 402 of an instance of the participantdata entry 401 (shown in Figure 12), and thus an instance of the participantdataflag entry 511 identifies an instance of the participantdata entry 401. In the embodiment shown, more than one instance of the participantdataflag entry 511 can identify a particular instance of the participantdata entry 401 , generally indicating that multiple flags can be associated with a particular piece of participant data. Thus the participantdataflag table 510 is shown in Figure 3 having a N:1 relationship to the participantdata table 400. Further, because an instance of the participantdataflag entry 511 is identifies an instance of the participantdata entry 401 (shown in Figure 12) and an instance of the participantdata entry 401 is in turn associated with a particular instance of the participantsession entry 451 (shown in Figure 13, described above), an instance of the participantdataflag entry 511 is also associated (via the instance of the participantdata entry 401) with that instance of the participantsession entry 451.

The participantdataflag entry 511 also includes a flagtypeidentifier field 516 which stores a flagtype identifier stored in the identifier field 482 of an instance of the flagtype entry 481 (shown in Figure 15) and a flagstatusidentifier field 518 which stores a flagstatus identifier stored in the identifier field 502 of an instance of the flagstatus entry 501 (shown in Figure 17), and more generally, instance of the participantdataflag entry 511 identifies an instance of the flagtype entry 481 and an instance of a flagstatus entry 501. This generally indicates a flag status and a flag type of that a particular flag. In the embodiment shown, more than one instance of the participantdataflag entry 511 can identify a same instance of the flagtype entry 481 and more than one instance of the participantdataflag entry 511 can identify a same instance of the flagstatus entry 501 in the flagstatus table 500, which generally indicates that more than one flag can be of the same flag type and more than one flag can have the same flag status. Thus the participantdataflag table 510 is shown in Figure 3 having a N:1 relationship to the flagtype table 480 and having a N:1 relationship to the flagstatus table 500. The participantdataflag entry 511 further includes a comment field 520 for storing a text string representing a comment. The participantdataflag entry 511 further includes a created field 522 which stores a date and time when an instance of the participantdataflag entry 511 was created and a createdbyjdentifier field 524 which stores a user identifier stored in the identifier field 192 of an instance of the user entry 191 (shown in Figure 5) associated with a reviewer that created an instance of the participantdataflag entry 511. The participantdataflag entry 511 further includes a modified field 526 for storing representations of a date and time when an instance of the participantdataflag entry 511 was updated and a modifiedbyjdentifier field 528 which stores a user identifier stored in the identifier field 192 of an instance of the user entry 191 (shown in Figure 5) associated with a reviewer that modified the instance of the participantdataflag entry 511. In the embodiment shown, more than one instance of the participantdataflag entry 511 in the participantdataflag table 510 can identify a particular instance of the user entry 191 representing a reviewer, generally indicating that a particular reviewer may add and modify multiple flags. Thus the participantdataflag table 510 is shown in Figure 3 having a N:1 relationship to the user table 190.

Referring back to Figure 2, the program memory 128 includes user interface codes 530 for communicating with various user interfaces for users of the assessment server 102. For example, in the embodiment shown, the user interface codes 530 include various codes (such as FITML codes and scripts or applications for producing HTML codes, for example) to enable the host associated with the host device 104, the participant associated with the participant device 108, and the reviewer associated with the reviewer device 110 to use a browser application of the host device 104, the participant device 108 and the reviewer device 110 to interact with assessment provider web pages in various ways such as those described below, for example.

The examples that follow illustrate various assessment provider web pages for display on a browser application of the host device 104, the participant device 108 and the reviewer device 110. A customized application on the host device 104, the participant device 108 and the reviewer device 110 may display similar information and receive similar information. Add User and User Login Codes

Referring to Figure 19, a welcome page produced to the user interface codes 530 for display in the browser application of the host device 104 or the reviewer device 110 is shown generally at 540. The welcome page 540 in the embodiment shown may be accessed by navigating the browser application of the host device 104 or the reviewer device 110 to a particular URL, such as to the URL“integrityadvocate.com” for example. The welcome page 540 includes an“Apps” link 550, which when selected by a user (such as the host associated with the host device 104 or the reviewer associated with the reviewer device 110), directs the user interface codes 530 to direct the browser application of the host device 104 or the reviewer device 110 to an exemplary login page shown generally at 560 in Figure 20.

Referring to Figure 20, the login page 560 may prompt the user to login to, or register with, the assessment server 102. In the embodiment shown, the login page 560 includes an email input field 562, a password input field 564, a login button 566 and a register button 568. When the user selects the register button 568, the user interface codes 530 direct the browser application of the host device 104 or the reviewer device 110 to display a registration page shown generally at 570 in Figure 21.

Referring to Figure 21 , the registration page 570 includes a first name input field 572, a last name input field 574, an email input field 576, a company input field 578, a password input field 580, a confirm password input field 582, a register button 584 and a return to login page button 586. The user may choose and enter a first name, a last name, an electronic mail address and a name of a company associated with the user in, respectively, the first name input field 572, the last name input field 574, the email input field 576 and the company input field 578. The user may then choose and enter a password in the password input field 580 and confirm password input field 582 and then select the register button 584. When the user selects the register button 584, the user interface codes 530 transmit the values entered in the input fields 572, 574, 576, 578, 580 and 582 to add user codes 590 in the program memory 128 (shown in Figure 2) in an add user request. However, if the user selects the return to login page button 586, the user interface codes 530 direct the browser application of either the host device 104 or the reviewer device 110 back to the login page 560 shown in Figure 20.

The add user codes 590 may respond to this add user request by directing the assessment server microprocessor 120 to add a new instance of the user entry 191 (shown in Figure 5) to the user table 190 (shown in Figure 3). This new instance of the user entry 191 may store the electronic mail address entered in the email input field 576 in the email field 194, may store the password entered in the password input field 580 and the confirm password input field 582 in the password field 196, and may be associated with a roletype indicator representing a role of the user. In the embodiment shown, the new instance of the user entry 191 may be associated with a roletype indicator identifying the“host” by default.

The add user codes 590 may also respond to this add user request by directing the assessment server microprocessor 120 to transmit an error message to the browser application of the host device 104 or the reviewer device 110 indicating, for example, the electronic mail address entered in the email input field 576 of the registration page 570 is unavailable, or that the passwords entered in the confirm password input field 582 and the password entered in the password input field 580 are not the same password.

Referring back to Figure 20, when the user is already registered with the assessment server 102, the user may enter an electronic mail address into the email input field 562 and enter a password into the password input field 564, and select the login button 566. When the user selects the login button 566, the user interface codes 530 is directed to transmit the values entered in the input fields 562 and 564 to user login codes 610 in the program memory 128 (shown in Figure 2) in a user login request.

The user login codes 610 may respond to the user login request by determining whether the user table 190 includes a user table entry 191 storing the electronic mail address entered in the input field 562 in the email field 194 and storing the password entered in the password input field 564 in the password field 196. If the electronic mail address entered and the password entered does not both match an instance of the user entry 191 , the assessment server microprocessor 120 may transmit an error message to the browser application of the host device 104 or the reviewer device 110 indicating that, for example, the electronic mail address entered could not be found or that the password entered is incorrect.

If the electronic mail address entered and the password entered do both match an instance of the user entry 191 , the assessment server microprocessor 120 directs the user interface codes 530 to direct the browser application to display an account page based on the roletype indicator associated with the matched instance of the user entry 191. For example, where the matched instance of the user entry 191 is associated with a “host” roletype indicator, the user interface codes 530 may direct the browser application of the host device 104 to display the host account page shown generally 620 in Figure 22. However, where the matched instance of the user entry 191 is associated with the

“reviewer” roletype indicator, the user login codes 610 may direct the user interface codes 530 to direct the browser application of the reviewer device 110 to display the reviewer account page shown generally at 1530 in Figure 54.

Host Account Page Referring to Figure 22, the host account page 620 includes an application region 621 , an assessment results region 622, a user information region 624 and a change password region 628.

The user information region 624 allows the host to update the instance of the userdata entry 161 (shown in Figure 4) and the instance of the user entry 191 (shown in Figure 5) representing the host. In the embodiment shown, the user information region 624 includes an email input field 630, a first name input field 632, a last name input field 634, a company input field 638, an address input field 640, a city input field 642, a country selection list 644, a jurisdiction selection list 646 and an update account button 648.

The host may enter alternative, or additional, values in the input fields 630, 632, 634, 638, 640 642 and these selection lists 644 and 646, and select the update account button 648.

When the host selects the update account button 648, the user interface codes 530 transmit the values in the input fields 630, 632, 634, 638, 640 642 and the selection lists 644 and 646 to the assessment server microprocessor 120 in an update user request. In response to the update user request, the assessment server microprocessor 120 may, in certain situations, (1) update the email field 194 and the username field 198 of the instance of the user table 191 representing the host based on the values entered by the host in the email input field 630 and (2) update the firstname field 164, the lastname field 166, the address field 168, the city field 170, the jurisdiction 172, the country field 174, the postalcode field 176 and the company field 182 of the instance of the userdata entry 161 representing the host based on the values entered by the host in the first name input field 632, the last name input field 634, the address input field 640, the city input field 642, the jurisdiction selection list 646, the country selection list 644, the postal code input field 636, and the company input field 638 respectively.

The change password region 628 allows the host to update the password stored in the password field 196 of the instance of the user entry 191 (shown in Figure 5) representing the host. In the embodiment shown, the change password region 628 includes a current password input field 650, a new password input field 652, a confirm new password input field 654, and a change password button 656. The host may enter the current password in the current password input field 650, choose and enter a new password in the new password input field 652 and the confirm new password input field 654, and then select the change password button 656. When the host selects the change password button 656, the user interface codes 530 transmits the values entered in the input fields 650, 652 and 654 to the assessment server microprocessor 120 in a change password request. In response to the change password request, the assessment server microprocessor 120 may, in certain situations, store the new password in the password field 196 of the instance of the user entry 191 representing the host.

Add Application

As described above, the host may be an organization which engages the assessment provider to provide participant assessment services for a particular host web page. Participant assessment applications (represented by an instance of the application entry 311 (shown in Figure 9)) allow the assessment provider to provide the participant assessment services at a particular host web page. The application region 621 of the host account page (shown in Figure 22) generally allows the host to add new instances of the application entry 311 (shown in Figure 9) to the application table 310 (shown in Figure 3) using the host device 108 to register a particular host web page with the assessment server 102. The application region 621 also allows the host to edit existing instances of the application entry 311.

In the embodiment of Figure 22, when there are no instances of the application entry 311 which identify the instance of the user entry 191 representing with the host, the application region 621 only includes an add new application button 660. If the host selects the add new application button 660, user interface codes 530 direct the browser application of the host device 104 to display an add application page shown generally at 670 in Figure 23. Referring to Figure 23, the add application page includes an application name input field 672, an host web page URL input field 674, an initial participant image text input field 676, a participant identification text input field 678, a first participant identification prompt input field 680, a second participant identification prompt input field 682, a third participant identification prompt input field 684, a camera fail selection list 690, a camera fail redirect URL input field 692, flag selection region 694, a save button 702 and a cancel button 704.

The host may choose and enter a text string representing an application name in the application name input field 672 and choose and enter one or more host web page URLs which locate one or more host web pages in the host web page URL input field 674. The host web page URLs locates one or more host web pages for which the host desires participant assessment services provided by the assessment provider. For example, the host user may offer a first online webinar at a first host web page having the URL “www.hostuser.com/webinar1” and a second online webinar at a second host web page having the URL“www.hostuser.com/webinar2”. The host may determine that participant assessment services are required for participants accessing both the first online webinar and the second online webinar, and may wish to verify an identity of the participants and to ensure that the participants view the entire webinar before providing participants with credit for the webinar. In the embodiment shown, the host enters“Webinar 1 and Webinar 2 Participant Assessment” in the application name input field 672 and enters both the URL“www.hostuser.com/webinar1” and the URL“www.hostuser.com/webinar2” in the host web page URL input field 674.

The host user may also choose and enter respective text strings representing customized messages in the initial participant image text input field 676, the participant identification text input field 678, the first participant identification prompt input field 680, the second participant identification prompt input field 682, the third participant identification prompt input field 684. These respective customized messages entered in the input fields 676, 678, 680, 682, 684 are displayed to a participant accessing the registered host web page (pointed to by an URL entered in the host web page URL input field 674 for example). In this respect, the customized message entered in the first participant identification prompt input field 680, the second participant identification prompt input field 682, the third participant identification prompt input field 684 may specify a type of photo identification which will be accepted by the host in to verify the identity of a participant, and may specifically request a“government photo identification” or a“corporate identification card” for example. In the embodiment shown, there may be a default message of “position your government photo ID using the provided guides (as seen below), then click Take Preview” in the first participant identification prompt input field 680.

The host may further select a camera fail option from the camera fail selection list 690. Each camera fail option may specify a particular instance of the camerafail entry 301 (shown in Figure 8) stored in the camerafail table 300 (shown in Figure 3), and accordingly may include a respective option for the “fail gracefully” instance of the camerafail entry 301 , the“go back one page” instance of the camerafail entry 301 and the “redirect to URL” instance of the camerafail entry 301. If the host selects the“redirect to URL” instance of the camerafail entry 301 in the camera fail selection list 690, the host may be prompted to choose and enter a web page URL in the camera fail redirect URL input field 692.

The flag selection region 694 of the add application page 670 may include respective selection buttons for each instance of the flagtype entry 481 (shown in Figure 15) in the flagtype table 480 (shown in Figure 3) which stores“TRUE” in the userselectable field 496 (indicating that the instance of the flagtype entry 481 can be selected for a particular participant assessment application by the host). For example, in the embodiment shown, the flag selection region 694 includes a selection button 696 corresponding to the “participant not in view” instance of the flagtype entry 481 , a selection button 698 corresponding to the “multiple participants” instance of the flagtype entry 481 and a selection button 700 corresponding to the “utilised electronic device/headphones” instance of the flagtype entry 481. In other embodiments where alternative, or additional, instances of the flagtype entry 481 store“TRUE” in the userselectable field 496, the flag selection region 694 may include alternative, or additional, selection buttons. The host may use the selection buttons 696, 698 and 700 to select participant actions that the host considers undesirable and which should result in a host web page access session to be assessed by the assessment server 102 as being invalid. However, depending on the content of the host web page, the host may opt not to select one or more of the selection buttons 696, 698 and 700 that represent participant actions that may be irrelevant to the host.

After the host enters values in the input fields 672, 674, 676, 678, 680, 682, 684, 692, selections in the camera fail selection list 690 and selections in one or more of the selection buttons 696, 698 and 700, the host may select the save button 702. If the host selects the save button 702, the user interface codes 530 transmit the values entered in the input fields 672, 674, 676, 678, 680, 682, 684, 692 and the selections entered via the camera fail selection list 690 and the selection buttons 696, 698 and 700 to add application codes 710 in the program memory 128 (shown in Figure 2) in an add application request. However, if the host selects the cancel button 704, the user interface codes 530 direct the browser application of the host device 104 to re-display the host account page 620 shown in Figure 22.

The add application codes 710 are illustrated schematically in Figure 24 and generally include blocks of code for directing the assessment server microprocessor 120 (shown in Figure 2) to add an instance of the application entry 311 (shown in Figure 9) to the application table 310 (shown in Figure 3) in response to the add application request. The add application codes 710 begin at block 712, which includes codes for directing the assessment server microprocessor 120 to determine whether (1) a text string representing an application name has been entered in the application name input field 672, (2) at least one host web page URL has been entered in the host web page URL input field 674 and (2) a text string representing a customized message has been entered in the first participant identification prompt input field 680. If a value has not been entered for one or more of the input fields 672, 674 or 680, the add application codes 710 continue at block 713, which includes codes for directing the assessment server microprocessor 120 to transmit an error message to the browser application of the host device 104 indicating that an application name is required, at least one host web page URL is required, and/or at least one a participant identification prompt is required. The add application codes 710 then end.

However, if values have been entered for all of the input fields 672, 674 and 680, the add application codes 710 continue at block 714, which includes codes for directing the assessment server microprocessor 120 to determine if the host selected the“redirect to URL” option in the camera fail selection list 690. If the host had selected the“redirect to URL” option, the add application codes 710 continue at block 716, which includes codes for directing the assessment server microprocessor 120 to determine whether a web page URL has been entered in the camera fail redirect URL input field 692. If a web page URL has not been entered, the add application codes continue at block 717, which include codes for directing the assessment server microprocessor 120 to transmit an error message to the browser application of the host device 104 indicating that a camera fail redirect URL is required. The add application codes 710 then end.

However, if at block 714 the host had not selected the“redirect to URL” option or if at block 716 a web page URL has been entered, the add application codes continue at block 715. Block 715 includes codes for directing the assessment server microprocessor 120 to add a new instance of the application entry 311 (shown in Figure 9) to the application table 310 (shown in Figure 3). This new instance of the application entry 311 stores a user identifier identifying the instance of the user entry 191 representing the host in the useridentifier field 314.

This new instance of the application entry 311 also stores a camerafail identifier identifying an instance of the camerafail entry 301 (shown in Figure 8) in the camerafailidentifier field 326 based on the camera fail option selected by the host in the camera fail selection list 690 (shown in Figure 23). For example, if the host selected the “fail gracefully” option in the camera fail selection list 690, the camerafailidentifier field 326 stores the camerafail identifier identifying the “fail gracefully” instance of the camerafail entry 301 ; if the host selected the“go back one page” option in the camera fail selection list 690, the camerafailidentifier field 326 stores the camerafail identifier identifying the“go back one page” instance of the camerafail entry 301 ; and if the host selected the “redirect to URL” option in the camera fail selection list 690, the camerafailidentifier field 326 stores the camerafail identifier identifying the“redirect to URL” instance of the camerafail entry 301 and the camerfailredirectURL field 328 stores the web page URL entered in the camera fail redirect URL input field 692.

This new instance of the application entry 311 also stores the text string entered in the application name input field 672 (“Webinarl and Webinar2 Participant Assessment” in the embodiment shown) in the applicationname field 315, the URL entered in the host web page URL input field 674 (“www.hostuser.com/webinar1” and “www.hostuser.com/webinar2” in the embodiment shown) in the hostwebpageURL field

317, the customized message entered in the initial participant image text input field 676 in the initialparticipantimage_text field 316, the customized message entered by the host in the participant identification text input field 678 in the participantidentification text field

318, the customized message entered in the first participant identification prompt input field 680 in the participantidentificationl prompt field 320, the customized message entered in the second participant identification prompt input field 682 in the participantidentification2_prompt field 322 and the customized message entered in the in third participant identification prompt input field 684 in the participantidentification3_prompt field 324.

The add application codes 710 continue at block 718, which includes codes for directing the assessment server microprocessor 120 to determine whether the host selected one or more of the selection buttons 696, 698 and 700 in the flag selection region 694. If so, the add application codes 710 continue at block 719 which includes codes for directing the assessment server microprocessor 120 to add a new instance of the selectedflagtype entry 491 (shown in Figure 16) to the selectedflagtype table 490 (shown in Figure 3) for each selection button 696, 698 and 700 selected by the host. All new instances of the selectedflagtype entry 491 store the application identifier identifying the application entry 311 added at block 715 in the application identifier field 492. Each new instance of the selectedflagtype entry 491 also stores a flagtype identifier identifying a particular instance of the flagtype entry 481 (shown Figure 15) in the flagtypeidentifier field 494 based on which ones of the selection buttons 696, 698 and 700 were selected by the host. For example, if the host selected the selection button 698 and 700, two instances of the selectedflagtype entry 491 would be added, with (a) one instance storing a flagtype identifier identifying the“multiple participants” instance of the flagtype entry 481 in the flagtypeidentifier field 494 and (b) another instance storing a flagtype identifier identifying the“utilised electronic device/headphones” instance of the flagtype entry 481. The add application codes 710 continue at block 720 described below.

If the assessment server microprocessor 120 determines at block 718 that the host did not select any of the selection buttons 696, 698 and 700 in the flag selection region 694, the add application codes 710 continue directly at block 720. Block 720 includes codes for directing the application server codes 144 (shown in Figure 2) to generate a“web page embeddable application” identifier and an APIkey and to store the generated“web page embeddable application” identifier and the generated APIkey in the generatedapplicationidentifier field 334 and the APIkey field 333 of the application entry 311 added at 715. The add application codes 710 then end. When the add application codes 710 end, the user interface codes 530 may direct the browser application of the host device 104 back to the host account page 620 shown in Figure 22.

Edit Application

If the host successfully added a participant assessment application (represented by an instance of the application entry 311 added by the add application codes 710) such that there are instances of the application entry 311 (shown in Figure 5) in the application table 310 (shown in Figure 3) which identifies the instance of the user entry 191 (shown in Figure 5) representing the host, the application region 621 of the host account page 620 (shown in Figure 22) becomes populated as shown in Figure 25. Referring to Figure 25, the application region 621 includes an application name column 732, a host web page URL column 734, an appID column 736, a status column 738, and a created column 740.

The application region 621 further includes a row representing the new participant assessment application. Although there is only a single row 730 shown in the embodiment of Figure 25, if there is more than one instance of the application entry 311 identifying the instance of the user entry 191 representing the host, then the application region 621 may include respective rows representing each such application entry 311.

The row displays information stored in the new instance of the application entry 311. In the embodiment of Figure 25, the row displays the text string stored in the applicationname field 315 in application name column 732 (“Webinarl and Webinar2 Participant Assessment” in row 730), the host web page URLs stored in the hostwebpageURL field 317 in the host web page URL column 734 (“www.hostuser.com/webinar1” and“www.hostuser.com/webinar2” in row 730), the“web page embeddable application” identifier stored in the generatedapplicationidentifier field 334 in the appID column 736 and the date and time in the created field 335 in the created column 740.

The row also displays an indication of whether the new instance of the application entry 311 represented by the row is active or inactive in the status column 738, based on whether there are any instances of the orderitem entry 281 (shown in Figure 7) which identifies the instance of the application entry 311 and which stores“active” in the status field 292. For example, if there are no instances of the orderitem entry 281 which identifies the instance of the application entry 311 represented by the row, the row displays“Inactive (Unpaid)” in the status column 738 (shown in the embodiment of Figure 25). Alternatively, if there are is at least one instance of the orderitem entry 281 which identifies the instance of the application entry 311 represented by the row, the row may display (1) “Active (#% remaining)” if the instance of the orderitem entry 281 stores “active” in the status field 292 and a positive ratio in the quantity field 290 or (2)“Inactive ((-)#% remaining)” if the instance of the orderitem entry 281 stores“inactive” in the status field a status field 292 and zero in the quantity field 290. The row representing the new instance of the application entry 311 further includes an edit button 752, an activate button 754 and a delete button 756. If the host selects the edit button 752, the user interface codes 530 direct the browser application of the host device 104 to an edit application page shown generally at 760 in Figure 26.

Referring to Figure 26, the edit application page 760 displays information stored in a particular instance of the application entry 311 (shown in 9), as well as information stored in any instances of the orderitem entry 281 (shown in Figure 7) identifying that instance of the application entry 311 and any instance of the order entry 231 (shown in Figure 6) associated (via an instance of the orderitem entry 281) with that instance of the application entry 311. In the embodiment shown, the edit application page 760 includes an application information region 762, an edit application region 764, a save button 806 and a cancel button 808.

The application information region 762 includes an applicationID field 770, an API key field 772, a script tag field 773, a status indicator shown generally at 774 and a history region 778. The applicationID field 770 displays the“web page embeddable application” identifier stored the generatedapplicationidentifier field 334 of the instance of the application entry 311 and the API key field 772 displays the API key in the APIkey field 333 of that instance of the application entry 311. The script tag field 773 displays a script element, such as a script tag, generated by the assessment server 102 and which may be embedded in the host web page. The script element generally includes the“web page embeddable application” identifier described above.

The status indicator 774 displays the ratio stored in the quantity field 290 of the orderitem entry 281 (shown in Figure 7) which identifies the instance of the application entry 311. In the embodiment of Figure 26, the status indicator 774 includes a total gauge 776 representing a total quantity of participant assessments purchased for the participant assessment application (“# of purchased assessments” stored in the quantity field 290), an available gauge 775 representing a quantity of participant assessments still available to be used (“# of available assessments” stored in the quantity field 290) and a % remaining indicator 777 displaying the ratio of the available quantity to the total quantity (ration stored in the quantity field 290). The history region 778 may, in certain situations, store a purchase history described below and an indication of whether the participant assessment application is currently active, inactive, or in demonstration mode for example. In the embodiment of Figure 26, there are no instances of the orderitem entry 281 identifying the instance of the application entry 311 representing the participant assessment application and thus the % remaining indicator 777 displays“0/0 participants” and the history region 778 does not include any purchase history and displays that the participant assessment application is in demonstration mode.

The edit application region 764 includes input fields and selection lists similar to the input fields and selection lists of the add application page 670 (shown in Figure 23) and includes an application name input field 782, a host web page URL input field 784, an initial participant image text input field 786, a participant identification text input field 788, a first participant identification prompt input field 790, a second participant identification prompt input field 792, a third participant identification prompt input field 794, a camera fail selection list 800, a camera fail redirect URL input field 802 and a flag selection region 804. The host may modify an instance of the application entry 311 by entering alternative, or additional values in the input fields 782, 784, 786, 788, 790, 792, 794, and/or 802, in the camera fail selection list 800 or using the selection buttons in the flag selection region 804 and selecting the save button 806. If the host selects the save button 806, the user interface codes 530 transmit the values in the input fields 782, 784, 786, 788, 790, 792, 794, and 802, and the selections from the camera fail selection list 800 and the flag selection region 804 to the assessment server microprocessor 120 in a modify application request. The assessment server microprocessor 120 may then modify the instance of the application entry 311 based on the received values and selections in response to the modify application request, and may also update the modified field 336 with a current representation of a date and time from the clock 122 (shown in Figure 2). In modifying the instance of the application entry 311 , the assessment server microprocessor 120 may send error messages if the assessment server microprocessor 120 determines that certain required values have not been entered by the host in the application name input field 782, the host web page URL input field 784, the participantidentificationl prompt field 320, and the camerafailredirectURL field 328 for example. If the host selects the cancel button 808, the user interface codes 530 direct the browser application of the host device 104 to re-display the host account page 620 (shown in Figure 22) without updating the instance of the application entry 311 (shown in Figure 9).

Referring back Figure 25, if the host selects the delete button 756 of a row representing by an instance of the application entry 311 (shown in Figure 9), the user interface codes 530 direct the assessment server microprocessor 120 to delete the corresponding instance of the application entry 311 from the application table 310 (shown in Figure 3).

Activate Application

Referring to Figure 25, once the host decides to purchase specific participant assessment services provided by the assessment provider, the host may select the activate button 754 of a row associated an instance of the application entry 311 (shown in Figure 9). When the host selects the activate button 754, the user interface codes 530 direct the browser application of the host device 104 to display a first activate application page shown generally at 810 in Figure 27. Referring to Figure 27, the first activate application page 810 generally allows the host to select one or more types of assessment services offered by the assessment provider. The first activate application page 810 includes an assessment package information region 812 displaying assessment packages and which function to associate at least one participant assessment service indicator with an instance of the orderitem entry 281 (shown in Figure 7). In the embodiment of Figure 27, assessment package information region 812 displays (1) a“basic” assessment package includes the participant identity verification indicator representing participant identity verification services and (2) a “standard” assessment package including to the participant identity verification indicator and a participant proctoring service indicator representing participant proctoring services. Other embodiments may display and include additional, or alternative, assessment packages. For example, other embodiments may include a further“premium” assessment package including participant identity verification, participant proctoring and participant engagement tracking services. The assessment package information region 812 also displays the base cost associated with each assessment package (CAD3.50 per participant for the “basic” assessment package and CAD5.00 per hour per participant for the“standard” assessment package in the embodiment of Figure 27), and further includes a selection button 814 and 816 for selecting an assessment package.

When the host selects either the selection button 814 or 816, the user interface codes 530 (shown in Figure 2) direct the browser application of the host device 104 to display a second activate application page shown generally at 820 in Figure 28. In the embodiment of Figure 28, the second activate application page 820 includes an assessment package indicator 822, a customization region 824, a subtotal indicator 826 and a purchase button 828.

The assessment package indicator 822 displays the assessment package selected by the host on the first activate application page 810. In the embodiment of Figure 28, the host selected the “standard” assessment package (by selecting the selection button 816 shown in Figure 27), and the assessment package indicator 822 thus displays“standard”. The assessment package indicator 822 also includes a“change this” button 830. If the host selects the“change this” button 830, the user interface codes 530 direct the browser application of the host device 104 to re-display the first activate application page 810 (shown in Figure 27) to allow the host to select a different assessment package.

The customization region 824 allows the host to customize the assessment package, and may display different fields based on the assessment package selected by the host. In the embodiment of Figure 28, as the host selected the“standard” assessment package the customization region 824 includes a participant number input field 834 and a session duration selection list 836. In other embodiments, the customization region 824 may include additional, fewer, or alternative customization options. For example, the“basic” assessment package may not include a session duration selection list 836.

The participant number input field 834 allows the host to enter a number representing a total quantity of participant assessments. The session duration selection list 836 allows the host to select an average duration of a host web page access session associated with participants taking part in accessing the host web page, such as “1 hour or less”, “between 1 and 2 hours” and“between 2 and 3 hours” for example. The user interface codes 530 may then display a dynamic subtotal for the customized “standard” assessment package in the subtotal indicator 826 based on the base price of the “standard” assessment package, the number entered in the participant number input field 834, and the duration selected in the session duration selection list 836. In the embodiment of Figure 28, as the host selected the “standard” assessment package, entered“500” into the participant number input field 834 and selected“1 hour or less” in the session duration selection list 836, the user interface codes 530 may display the subtotal CAD2500.00 in the subtotal indicator 826, corresponding to 500 (number of participants) x 1 (duration) x CAD5.00 (base cost). The host may then select the purchase button 828.

In certain embodiments, the user interface codes 530 may include codes for determining whether the participant number entered in the participant number input field exceeds a minimum participant number. If the participant number entered does not exceed a minimum participant number, the user interface codes 530 may direct the browser application to (1) display an error message in the subtotal indicator 826 that that a minimum number participants are required and (2) disable the purchase button 828. If the participant number entered does exceed the minimum participant number, the user interface codes 530 may display the dynamic subtotal as described above.

When the host selects the purchase button 828, the user interface codes 530 direct the browser application of the host device 104 to display the third activate application page shown generally at 840 in Figure 29. The third activate application page 840 generally allows the host user device to enter payment for the assessment package selected by the host and activate the participant assessment application. Referring to Figure 29, the third activate application page 840 generally includes an assessment provider package indicator 842, a customization indicator 844, a total indicator 845, a billing information region 846, a payment information region 848, a pay by credit card button 852 and a pay by invoice button 854.

The assessment package indicator 842 is similar to the assessment package indicator 822 of the second activate application page 820 (shown in Figure 28) and displays the assessment package selected by the host on the first activate application page 810 (shown in Figure 27) and also displays“change this” button 860 similar to the“change this” button 830 of the second activate application page 820 described above.

The customization indicator 844 displays the customization options selected by the host on the second activate application page 820 (shown in Figure 28). In the embodiment of Figure 29, the customization indicator 844 display“500 participants” (as the host had entered“500” in the participant number input field 834) and“average session duration: 1 hour or less” (as the host had selected“1 hour or less” in the session duration selection list 836). The customization indicator 844 also includes a“change this” button 862. If the host selects the“change this” button 862, the user interface codes 530 direct the browser application of the host device 104 to re-display the second activate application page 820 shown in Figure 28 to allow the host to re-enter or re-select customization options.

The total indicator 845 displays the subtotal amount displayed in the subtotal region 826 of the second activate application page 820 (shown in Figure 28), a tax amount dynamically calculated based on which jurisdiction is selected by the host in the billing information region 846, and a total amount equal to the subtotal amount plus the tax amount. In the embodiment of Figure 29, the subtotal amount is CAD2500.00, the tax amount is CAD300.00 (corresponding to 12% of the subtotal amount as “British Columbia” is selected in the billing information region 846), and the total amount is CAD2800.00.

The billing information region 846 includes input fields and selection lists for billing information. In this respect, the host may enter a first name, a last name, an address, a city, a zip code, an electronic mail address and a company. The host may also select a country and a jurisdiction. In certain embodiments, the input fields and selection lists of the billing information region 846 can automatically display values from the instance of the userdata entry 161 (shown in Figure 4) and the instance of the user entry 191 (shown in Figure 5) representing the host.

The payment information region 848 includes input fields and selection list for credit card information. In this respect, the host can enter a first name on a credit card, a last name on the credit card, a card number of the credit card and verification digits of the credit card. The host can also select a card type of the credit card and an expiry date of the credit card.

The host may enter or modify the values in the input of the billing information region 846 and the payment information region 848, and then either select the pay by credit card button 852 or the pay by invoice button 854. If the user selects either the pay by credit card button 852 or the pay by invoice button 854, the user interface codes 530 transmit the values and selections entered by the host on the first activate application page 810 (shown in Figure 27), the second activate application page 820 (shown in Figure 28) and the third activate application page 840 (shown in Figure 29) to activate application codes 900 in the program memory 128 (shown in Figure 2) in an activate application request.

The activate application codes 900 are illustrated schematically in Figure 30 and generally include blocks of code for directing the assessment server microprocessor 120 (shown in Figure 1) to activate an instance of the application entry 311 by adding a new instance of the order entry 231 (shown in Figure 6) to the order table 230 (shown in Figure 3) and a new instance of the orderitem entry 281 (shown in Figure 7) to the orderitem table 280 (shown in Figure 3) in response to the activate application request. Referring to Figure 30, the activate application codes 900 begin at block 902, which includes codes for directing the assessment server microprocessor 120 to determine whether the host selected the pay by credit card button 852 or the pay by invoice button 854 on the third activate application page 840 (shown in Figure 29).

If the host selected the pay by credit card button 852, the activate application codes 900 continue at block 904, which includes codes for directing the assessment server microprocessor 120 to determine if all information required for submitting a transaction request to the payment processor 251 (shown in Figure 2) has been entered by the host. In the embodiment shown, this includes determining whether the required values have been entered in the billing information region 846 and the payment information region 848 of the third activate application page 840. If the assessment server microprocessor 120 determines that any of the information required has not been entered, the activate application codes 900 continue at block 906 which includes codes for directing the assessment server microprocessor 120 to transmit an error message to the browser application of the host device indicating that, for example, additional billing and payment information is required. The activate application codes 900 then end.

If all information required has been entered, the activate application codes 900 continue at block 908, which include codes for directing the assessment server microprocessor 120 to generate and transmit a transaction request to the payment processor 251. The transaction request can conform to the ISO 8583 standard for financial transaction card originated interchange messages. If the transaction request is approved, an approved transaction response is returned to the assessment server microprocessor 120 and if the transaction request is declined, a declined transaction response is returned to the assessment server microprocessor 120.

The activate application codes 900 continue at block 910, which includes codes for directing the assessment server microprocessor 120 to determine whether the transaction response received from the payment processor 251 is the approved transaction response or the declined transaction response. If the assessment server microprocessor 120 determines that the declined transaction response was received, the activate application codes 900 continue at block 912, which includes codes for directing the assessment server microprocessor 120 to transmit to the browser application of the host device 104 a declined message indicating that the transaction request was declined. The activate application codes 900 then end.

If the assessment server microprocessor 120 determines at block 910 that approved transaction response was received, the activate application codes 900 continue at block 914, codes for directing the assessment server microprocessor 120 to generate and transmit a transaction receipt including representations of the transaction amount, a transaction date and time, and a transaction identifier to the browser application of the host device 104. The transaction response generally includes data elements representing as the transaction identifier and the transaction date and time.

The activate application codes 900 continue at block 916, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the order entry 231 (shown in Figure 6) to the order table 230 (shown in Figure 3). This new instance of the order entry 231 stores a user identifier identifying the instance of the user entry 191 (shown in Figure 5) representing the host in the useridentifier field 249 and stores values entered by the host on the third activate application page 840 (shown in Figure 29) and received in the transaction response in other fields. For example, in the embodiment shown, block 916 include codes for directing the assessment server microprocessor 120 to store the first name, the last name, the address, the city, the jurisdiction, the country, the zip code, the electronic mail address and the company entered in the billing information region 846 in the billinginformation field 234, the transaction identifier received in the transaction response in transactionidentifier field 250 and the transaction date and time received in the transaction response in the paid field 254.

The activate application codes 900 continue at block 918, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the orderitem entry 281 (shown in Figure 7) to the orderitem table 280 (shown in Figure 3).

The new instance of the orderitem entry 281 stores an order identifier identifying the order entry 311 added at block 916 in the orderidentifier field 284. The new instance of the orderitem entry 281 also stores an indicator representing at least one participant assessment service in the product field 286 and stores the unit price stored in in the unitprice field 288. The indicator representing the at least one participant assessment service is based on the assessment package selected by the host on the first activate application page 810 (shown in Figure 27). For example, in the embodiment shown, as the host selected the“standard” assessment package on the first activate application 810, the product field 286 of the new instance of the orderitem entry 281 would store a participant identity verification indicator and a participant proctoring service indicator in the product field 286 and would store“CAD5.00/hr” in the unitprice field 288.

The new instance of the orderitem entry 281 also stores the participant number entered in the participant number input field 834 of the second activate application page 820 in the quantity field 290. Further, as described above, the quantity field 290 stores a ratio of “# of available assessments” to “# of purchased assessments”. The “# of available assessments” decrease each time a participant is assessed using the participant assessment application as described below. For example, in the embodiment shown, the quantity field 290 may initially store “500/500” because “500” was entered in the participant number input field 834 and subsequently purchased by the host. When the participant assessment application assesses a participant, the assessment is tracked by decreasing the“# of available assessments” in the quantity field 290 to“499” such that the ratio stored in the quantity field 290 becomes“499/500”. Block 918 further includes codes for directing the assessment server microprocessor 120 to store either“active” in the status field 292 if the ratio stored in the quantity field 290 is positive and“inactive” in the status field 292 if the ratio stored in the quantity field 290 is zero.

The new instance of the orderitem entry 281 also stores an application identifier identifying the instance of the application entry 311 (shown in Figure 9) in the applicationidentifier field 296. As described above, when an instance of the application entry 311 is identified by an instance of the orderitem entry 281 storing“active” in the status field 292 and a positive ratio in the quantity field 290, the instance of the application entry 311 will be considered active. The activate application codes 900 then end.

Referring back to block 902, if the assessment server microprocessor 120 determines that the host selected the pay by invoice button 854 on the third activate application page 840 (shown in Figure 29), the activate application codes 900 continue at block 920, which includes codes for directing the assessment server microprocessor 120 to determine if all information required for generating an invoice has been entered by the host. The information required for generating the invoice may be different from the information required at block 904 for generating a transaction request. For example, in the embodiment shown, block 920 may include codes for directing the assessment server microprocessor 120 to determine whether a value has been entered for the input fields of the billing information region 846 only, while disregarding any values entered (or not entered) in the payment information region 848. If the assessment server microprocessor 120 determines that any of the information required has not been entered, the activate application codes 900 continue at block 922, which includes codes for directing the assessment server microprocessor 120 to transmit an error message to the browser application of the host device 104 indicating that, for example, additional billing information is required. The activate application codes 900 then end. If the microprocessor determines at block 920 that all information required has been entered, the activate application codes 900 continue at block 924, which includes codes for directing the assessment server microprocessor 120 to generate and transmit a transaction invoice including representations of (1) an invoiced amount equal to the total amount displayed in the total indicator 845 (shown in Figure 29), (2) an invoice date and time being a current date and time retrieved from the clock 122 (shown in Figure 2), and (3) an invoice identifier, to the browser application of the host device 104.

The activate application codes continue at block 926, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the order entry 231 (shown in Figure 6) to the order table 230 (shown in Figure 3) (similar to the codes of block 916 described above). This new instance of the order entry 231 stores a user identifier which identifies the instance of the user entry 191 (shown in Figure 5) representing the host in the useridentifier field 249, stores values entered by the host on the third activate application page 840 (shown in Figure 29) in the billinginformation field 234, stores the invoice identifier generated at block 920 in the transactionidentifier field 250 and stores the invoice date and time generated at block 920 in the invoiced field 252.

The activate application codes 900 continue at block 928, which includes codes for directing the assessment server microprocessor 120 to determine whether the issued invoice has been paid. In the embodiment shown, the assessment server microprocessor 120 may determine whether there is a date and time in the paid field 254 of the instance of the order entry 231. If there is no date and time in the paid field 254, the activate application codes 900 then end.

Flowever, if there is a date and time in the paid field 254, such as when the assessment provider manually added a date and time when payment for theinvoice issued at block 924 was received, the activate application codes 900 continue at block 930. Block 930 includes codes for directing the assessment server microprocessor 120 to add a new instance of the orderitem entry 281 (shown in Figure 7) to the orderitem table 230 (shown in Figure 3) (similar to the codes of block 918 described above).

Similar to the orderitem entry 281 added at block 918, this new instance of the orderitem entry 281 stores an order identifier identifying the order entry 231 added at block 926 in the orderidentifier field 284. The new instance of the orderitem entry 281 also stores an indicator representing at least one participant assessment service in the product field 286, stores the associated unit price in the unitprice field 288, and the participant number entered in the participant number input field 834 (shown in Figure 28) in the quantity field 290. Block 918 further includes codes for directing the assessment server microprocessor 120 to store“active” in the status field 292 if the ratio stored in the quantity field 290 is positive or“inactive” in the status field 292 if the ratio stored in the quantity field 290 is zero.

The new instance of the orderitem entry 281 also stores an application identifier identifying an instance of the application entry 311 (shown in Figure 9) in the applicationidentifier field 296. As described above, when an instance of the application entry 311 is identified by an instance of the orderitem entry 281 storing“active” in the status field 292 and a positive ratio in the quantity field 290, the instance of the application entry 311 will be considered active. The activate application codes 900 then end.

When the host navigates back to the host account page 620 (shown in Figure 22) after successfully activating a participant assessment application (represented by an instance of the application entry 311), referring now to Figure 31 , the row representing the instance of the of application entry 311 in the applications region 621 now displays an indication that the participant assessment application is“active” in the status column 738. Further, in the embodiment of Figure 31 , as the participant assessment application has not yet been used to assess any participants, the row 730 further displays“(0% used)” in the status column 738, indicating that the ratio in the quantity field 290 of that instance of the orderitem entry 281 is 100%.

Further, the row 730 representing the participant assessment application now displays a renew button 758 instead of the activate button 754 and no longer displays the delete button 756. If the host selects the renew button 758, the user interface codes 530 direct the browser application of the host device 104 to renew application pages similar to the first activate application page 810 (shown in Figure 27), the second activate application page 820 (shown in Figure 28) and the third activate application page 840 (shown in Figure 29) to add another instance of the order entry 231 to the order table 230 (shown in Figure 3) and another instance of the orderitem entry 281 to the orderitem table 280 (shown in Figure 3).

If the host selects the edit button 752, the user interface codes 530 direct the browser application of the host device 104 to the edit application page 760 (shown in Figure 26). Flowever, referring to Figure 32, the status indicator 774 of the participant assessment application information region 762 now displays the total gauge 776 as corresponding to the“# of purchased assessments” stored in the quantity field 290 of the instance of the orderitem entry 281 created by the activate application codes 900, the available gauge 775 as corresponding to the“# of available assessments” stored in the quantity field 290, and the %remaining indicator 777 as the ratio in the quantity field 290 (displaying“100% remaining (500/500 participant) in the embodiment shown).

Additionally, the history region 778 now displays a row 940 representing the instance of the order entry 231 (shown in Figure 6) and the instance of the orderitem entry 281 (shown in Figure 7) created by the activate application codes 900. The row 940 includes a date field 942, a product description field 944, a usage field 955 and a link to receipt 946. The date field 942 displays the date and time stored in the paid field 254 of the instance of the order entry 231. The product description field 944 displays the “# purchased assessments” stored in the quantity field 290 of the instance of the order entry 231 and an indicator representing the at least one participant assessment service stored in the product field 286 of the instance of the order entry 231. The usage field 955 displays a value of used assessments based on the“# of purchased assessments” and the“# of available assessments” stored in the quantity field 290 of the instance of the order entry 231. The link to receipt 946 includes codes for causing the user interface codes 530 to direct the browser application of the host device 104 to a web page or panel displaying the receipt generated by block 914 or the invoice generated by block 924 of the activate application codes 900 (shown in Figure 30) when the link to receipt 946 is selected by a host. Host Server

Referring back to Figure 1 , as described above, the host may be an organization that provides or operates a plurality of host web pages using the host server 106. After the host adds a new instance of the application entry 311 (shown in Figure 9, representing a participant assessment application) to register particular host web pages (such as “www.hostuser.com/webinar1” and“www.hostuser.com/webinar2” for example) with the assessment server 102 using the host device 104, the host uses the host server 106 to embed the participant assessment application into the registered host web page(s). An illustrative embodiment of the host server 106 is shown in Figure 33. The host server 106 includes a processor circuit, which in the embodiment shown includes at least one microprocessor 950, and a clock 952, an input/output (“I/O”) interface 954, a program memory 958, and a storage memory 956 all in communication with the host server microprocessor 950.

The clock 952 maintains values representing a current date and time, and provides such values to the host server microprocessor 950 for storage in various date stores in the storage memory 956 as discussed below. The I/O interface 954 includes an internet interface 960 for communicating, over various components of the internet shown generally at 962, with external components of the world wide web including the participant device 108 and the assessment server 102. Although only one participant device 108 is shown in the embodiment of Figure 1 , alternative embodiments may include a plurality of participant devices 108.

The program memory 958 and the storage memory 956 may each be implemented as one of, or as a combination of more than one of, a random access memory (“RAM”), a hard disk drive (“HDD”), and other computer-readable and/or -writable memory. The storage memory 956 generally stores information obtained by the host server 106, and thus the storage memory 956 may more generally be referred to as an information store.

The program memory 958 generally include codes for directing the host server microprocessor 950 to execute various functions of host server 106, including functions which allow the host server 106 to provide the host web pages. In the embodiment of Figure 33, the program memory 958 includes various blocks of code, includes operating system codes 970 of an operating system for host server 106. The program memory 958 further includes hypertext transfer protocol (“HTTP”) server codes 972, which include codes for making various web pages available to participants accessing the host server 106 over the external components of the internet 962 such as to the participant via the participant device 108. In the embodiment shown, the HTTP server codes 142 include codes of Apache HTTP server and VMWare software codes.

In the embodiment shown, the program memory 958 also includes database management system (“DBMS”) codes 974 which include codes for managing a participant database 976 in the storage memory 956. In the embodiment shown, the participant database 976 is a relational database including a plurality of tables, including a hostparticipant table 980 that can store any number of instances of a hostparticipant entry shown generally at 981 in Figure 34. An instance of the hostparticipant entry 981 represents a participant that accesses a host web page of the host server 106, and stores various participant information. In the embodiment of Figure 34, the hostparticipant entry 981 includes an identifier field 982 which stores an integer (a hostparticipant identifier) assigned by the DBMS codes 974 (shown in Figure 33) to identify an instance of the hostparticipant entry 981 uniquely in the hostparticipant table 980. The hostparticipant entry 981 also includes a firstname field 984 for storing a first name of a participant (a firstname participant identifier) and a lastname field 986 for storing a last name of the participant (a lastname participant identifier), a username field 988 for storing a username, and a password field 990 for storing a password.

Referring back to Figure 33, the program memory 958 also includes user interface codes 1060 for communicating with participant devices 108 accessing the host server 106. For example, in the embodiment shown, the user interface codes 1060 include various codes (such as HTML codes and scripts or applications for producing HTML codes, for example) to enable a participant associated with a participant device 108 to use a browser application of the participant device 108 to interact with host web pages in various ways. The program memory 958 also includes participant access codes 1062 for providing or denying a participant access to specific host web pages. In this respect, the participant access codes 1062 may include codes that direct the host server microprocessor 950 to (1) respond to a sign up request from a new participant by adding a new instance of the hostparticipant entry 981 (shown in Figure 34) (storing appropriate values) to the hostparticipant table 980 (shown in Figure 41), (2) respond to a login request from an existing participant to sign into a host web page by granting or denying access to the host web page and (3) respond to a sign out request from the existing participant to sign out of the host web page.

The program memory 958 also includes vary script tag codes 1064 to vary the script tag to include unique participant identifiers that identify a particular participant. In this respect and as noted above, the host may use to the host server 106 to embed the participant assessment application into the host web page. Referring to Figure 35, in the embodiment shown, the host may embed the participant assessment application by embedding a script element 1002 into a FITML code 1000 of the host web page. For example, the host may embed, as the script element 1002, a script tag which was generated by the assessment server 102 and displayed to the host in the script tag field 773 of the edit application page 760 (shown in Figure 26) to embed the participant assessment application. The script tag may have the following form:

<scriptsrc=7/integrityadvocate.com/lntegrity/Embed?appid=XXXXX-XXXXX-XXXXX" asyncx/script>

A script tag embedded into the HTML code of the host web page will be processed by the browser application of the participant device 108 when the browser application launches the host web page. Processing the script tag causes the browser application of the participant device 108 to send a participant assessment request shown generally at 1010 in Figure 36.

In the embodiment of Figure 36, the participant assessment request 1010 message includes a header 1012 and a body 1014. The header 1012 generally specifies a method of the participant assessment request 1010 and includes a host field 1016 which includes the URL locating the assessment server 102. The header 1012 also includes a referer field 1018 which includes the URL locating the host web page 1075 as the resource from which the participant assessment request 1010 originated. In other words, the host web page is identified in the referer field 1018 as the web page currently requesting access to the assessment server 102. The body 1014 incudes the script tag 1002. The participant assessment request also provides certain participant identifiers and certain host identifying information from the host server 106 directly to the assessment server 102. In this respect:

• The “appid” string of the script tag 1002 includes the “web page embeddable application” identifier stored in the generatedapplicationidentifier field 334 of an instance of the application entry 311 (shown in Figure 9) provided to the host after the instance of the application entry 311 was added. The script tag 1002 thus functions as host identifying information to locate that instance of the application entry 311 within the application table 310 (shown in Figure 3) using the“web page embeddable application” identifier.

· The vary script tag codes 1064 generally include codes for directing the host server microprocessor 950 to vary the script tag to include unique participant identifiers representing a participant currently accessing the host web page.

• The referer field 1018 stores a URL locating the host web page, which will be corresponded to the URL stored in the hostwebpageURL field 317 of an instance of the application entry 311 (shown in Figure 9) to determine whether the host web page is in fact registered with the assessment server 102. The referer field 1018 thus also functions as host identifying information.

The assessment server 102 responds to the participant assessment request 1010 by injecting certain participant data collection browser codes effecting a participant data collection interface into the host web page displayed on the browser application of the participant device 108 as described below. The participant data collection interface may prompt the participant to submit participant data to the assessment server 102 and may also automatically collect and transmit certain participant data to the assessment server 102 as also described below. The vary script tag codes 1064 are illustrated schematically in Figure 37 and execute in response to receiving a login request a login request for example, from an existing participant to access a host web page which is (or is a gateway web page controlling access to a host web page) registered with the assessment server 102. In other embodiments, certain blocks of the vary script tag codes 1064 may execute automatically after a set interval.

Referring to Figure 37, the vary script tag codes 1064 begin at block 1070, which includes codes for directing the host server microprocessor 950 to vary the script tag 1002 embedded in the host web page to include the hostparticipant identifier stored in the identifier field 982, the firstname participant identifier stored in the firstname field 984 and the lastname participant identifier stored in the lastname field 986, all of an instance of the hostparticipant entry 981 (shown in Figure 34) representing the existing participant. For example, block 1070 may include codes for directing the host server microprocessor 950 to vary the script tag 1002 to include the hostparticipant identifier, the firstname participant identifier and the lastname participant identifier as follows:

<scriptsrc=7/integrityadvocate.com/lntegrity/Embed?appid=XXXXX-XXXXX- XXXXX&participantid=123456&participantfirstname=John& participantlastname=Smith" asyncx/script>

The vary script tag codes 1064 may then continue at optional block 1072, which includes codes for directing the host server microprocessor 950 to vary the script tag 1002 embedded in the host web page to include an alternative application name. This optional block 1072 may be useful when the participant database 976 (shown in Figure 33) requires a unique application name for each participant, such as if the participant database 976 requires the application name to include the hostparticipant identifier stored in the identifier field 982 of an instance of the hostparticipant entry 981 (shown in Figure 34) for example. For example, optional block 1072 may include codes for directing the host server microprocessor 950 to vary the script tag 1002 to include the application name as follows: <scriptsrc="//integrityadvocate.com/lntegrity/Embed?appid=XXXXX-XXXXX- XXXXX&participantid=123456&participantfirstname=John& participantlastname=Smith& applicationname=

Webinar1%20and%20Webinar2%20Participant%20Assessment%20ID12356"

asyncx/script>

The vary script tag codes 1064 may then continue at optional block 1074, which includes codes for directing the host server microprocessor 950 to vary the script tag 1002 embedded in the host web page to include a custom camerafail redirect URL. This optional block 1072 may be useful when the host requires a unique redirect URL for each participant, such as when a home web page for each participant includes the hostparticipant identifier stored in the identifier field 982 of an instance of the hostparticipant entry 981 (shown in Figure 34) for example. For example, optional block 1074 may include codes for directing the host server microprocessor 950 to vary the script tag to include a redirect URL as follows: <scriptsrc=7/integrityadvocate.com/lntegrity/Embed?appid=XXXXX-XXXXX-

XXXXX&participantid=123456&participantfirstname=John& participantlastname=Smith& camerafailurl= https%3A%2F%2Fwww.hostuser.com%2FparticipantlD123456" asyncx/script>

The vary script tag codes 1064 then end. Generally, when the vary script tag codes 1064 vary a script tag 1002, the participant assessment request 1010 (shown in Figure 36) includes the script tag 1002 as varied in the body 1014.

Collecting Participant Data

As described above, if the participant access codes 1062 (shown in Figure 33) determine that a participant is permitted to access a host web page having a participant assessment application embedded therein, the user interface codes 1060 (shown in Figure 33) direct the browser application of the participant device 108 associated with the participant to launch the host web page. An example of a host web page is shown generally at 1075 in Figure 38. In the embodiment shown, the host web page comprises an online quiz. In other embodiments, the host web page may comprise other content, such as an online webinar, an online study group or an online notarization service, for example.

As also described above, if the participant assessment application is embedded into the host web page 1075 using a script tag as varied by the vary script tag codes 1064, the script tag as varied is processed by the browser application of the participant device 108 when the host web page 1075 is launched, which causes the browser application of the participant device 108 to transmit the participant assessment request 1012 (shown in Figure 38) including the script tag as varied to the assessment server 102. As noted above, the participant assessment request 1010 includes participant identifiers including the hostparticipant identifier, the firstname participant identifier and the lastname participant identifier (all included in the script tag 1002) from the instance of the hostparticipant entry 981 (shown in Figure 34) stored in the hostparticipant table 980 (shown in Figure 33) of the host server 106. The participant assessment request 1010 also includes the host identifying information including the “web page embeddable application” identifier (included in the script tag 1002) and the URL locating the host web page (included in the referer field 1018).

Referring back to Figure 2, the program memory 128 of the assessment server 102 also includes participant data collection server codes 1080 which begin in response to receiving the participant assessment request from the browser application of the participant device 108. The participant data collection server codes 1080 are schematically illustrated in Figure 39, and generally include codes for directing the assessment server microprocessor 120 to communicate with the participant device 108 (shown in Figure 1) to collect participant data during the host web page access session associated with the participant and to add (a) instances of the participant entry 381 (shown in Figure 11) to the participant table 380 (shown in Figure 3), (b) instances of the participantdata entry 401 (shown in Figure 12) to the participantdata table 400 (shown in Figure 3) and (c) instances of the participantsession entry 451 (shown in Figure 13) to the participantsession table 450 (shown in Figure 3) to store the participant data.

Referring to Figure 39, the participant data collection server codes 1080 begin at block 1082, which includes codes for directing the assessment server microprocessor 120 to determine whether the application table 310 (shown in Figure 3) contains an instance of the application entry 311 (shown in Figure 9) which is associated with the host web page 1075 identified by the host identifying information received in the participant assessment request. In the embodiment shown, block 1082 includes codes for directing the assessment server microprocessor 120 to determine whether there is an instance of the application entry 311 which (1) stores the web embeddable assessment application identifier contained in the script tag in the generatedapplicationidentifier field 334 and (2) stores the URL address of the host web page 1075 contained in the referer header portion of the participant assessment request in the hostwebpageURL field 317. If no instance of the application entry 311 is found, the participant data collection codes 1080 then end. The assessment server 102 thus disregards a participant assessment request unless the participant assessment request includes host identifying information associated with an instance of the application entry 311 in the application table 310.

Flowever, if an instance of an application entry 311 is located, the participant data collection server codes 1080 continue at block 1084, which includes codes for directing the assessment server microprocessor 120 to determine whether that instance of the application entry 311 has been activated. In the embodiment shown, block 1084 includes codes for directing the assessment server microprocessor 120 to determine whether there is at least one instance of the orderitem entry 281 (shown in Figure 7) in the orderitem table 280 (shown in Figure 3) which (1) stores an application identifier identifying the application entry 311 located at block 1082 in the applicationidentifier field 296 and (2) stores“active” in the status field 292.

If the instance of the application entry 311 has been activated, the participant data collection server codes 1080 continue at block 1086, which includes codes for directing the assessment server microprocessor 120 to determine whether the participant table 380 (shown in Figure 3) already includes an instance of the participant entry 381 (shown in Figure 11) representing the participant identified by the participant identifiers in the participant assessment request and also identifying the application entry 311 located at block 1082. In the embodiment shown, block 1086 includes codes for directing the assessment server microprocessor 120 to determine whether there is an instance of the participant entry 381 which (1) stores an application identifier identifying the application entry 311 located at block 1082 in the applicationidentifier field 384, (2) stores the participant identifier contained in the script tag in hostparticipantidentifier field 386 (3) stores the firstname participant identifier contained in the script tag in the firstnameparticiptantidentifier field 388 and (4) stores the lastname participant identifier contained in the script tag in the last name field 390.

If an existing instance of the participant entry 381 is found, the participant data collection server codes 1080 continue at block 1088 as described below. By determining whether there is an existing instance of the participant entry 381 associated with a particular participant accessing a particular host web page, the assessment server microprocessor 120 may aggregate participant data collected for that particular participant accessing that particular host web page to a single instance of the participant entry 381. This may allow for more efficient review of participant data.

However, if no existing instance of the participant entry 381 is found, the participant data collection server codes 1080 continue at block 1090, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the participant entry 381 (shown in Figure 11) to the participant table 380 (shown in Figure 3). This new instance of the participant entry 381 (1) stores the application identifier identifying the application entry 311 identified at block 1082 in the applicationidentifier field 384 field, (2) stores the hostparticipant identifier contained in the script tag in the hostparticipantidentifier field 386, (3) stores the firstname participant identifier contained in the script tag in the firstnameparticiptantidentifier field 388 and (4) stores the lastname participant identifier contained in the script tag in the last name field 390. The participant data collection server codes 1080 continue at block 1088.

Block 1088 includes codes for directing the assessment server microprocessor 120 to configure participant data collection browser codes based on the application entry 311 (shown in Figure 9) located at block 1082 and optionally also based on any additional customization information included in the script tag, and to transmit the configured participant data collection browser codes to the browser application of the participant device 108. In this respect, block 1088 may include codes directing the assessment server microprocessor 120 to configure the participant data collection browser codes based on at least one of (1) the application name stored in the applicationname field 315, (2) the customized messages stored in the initialparticipantimagejext field 316, the participantidentification text field 318, the participantidentificationl prompt field 320, the participantidentification2_prompt field 322, and the participantidentification3_prompt field 324, and (3) the camera fail option stored in the camerafailidentifier field 326 and the URL stored in the camerfailredirectURL field 328, all of the instance of the application entry 311. Block 1088 may also include codes for directing the assessment server microprocessor 120 to further configure the participant data collection browser codes based on an application name and a camera redirect URL contained in the script tag if the script tag was varied using at least one of the optional blocks 1072 and 1074 of the vary script tag codes 1064 (shown in Figure 37). Configuration of the participant data collection browser codes based on the script tag may override or take precedence over configurations of the participant data collection browser codes based on values contained in the fields of the instance of the application entry 311.

Block 1088 may further include codes for configuring the participant data collection browser codes based on whether the application entry 311 located at block 1082 represents a participant assessment application providing only participant identity verification services or a participant assessment application providing both participant identify verification and participant proctoring services. For example, Block 1088 may also include codes for directing the assessment server microprocessor 120 to exclude portions of the participant data collection browser codes if the instance of the orderitem entry 281 (shown in Figure 7and located at bock 1084 for example) which identifies the application entry 311 identified at block 1082 does not store the participant proctoring service indicator in the product field 286 but to include additional portions of the participant data collection browser codes if the instance of the orderitem entry 281 (shown in Figure 7) does store the participant proctoring service indicator in the product field 286.

Block 1088 also includes codes for directing the assessment server microprocessor 120 to transmit the configured participant data collection browser codes to the browser application of the participant device 108. The participant data collection server codes 1080 continue at block 1092, which includes codes for directing the assessment server microprocessor 120 to wait for participant data from the browser application of the participant device 108.

The browser application of the participant device 108 executes the participant data collection browser codes upon receipt from the assessment server microprocessor 120 of the assessment server 102. An embodiment of the participant data collection browser codes 1096 is illustrated schematically in Figures 40A and 40B, and generally include codes that allow the participant to actively collect and submit participant data to the assessment server 102, and also codes that allow the participant device 108 to passively collect and submit participant data to the assessment server 102.

Referring to Figure 40A, the participant data collection browser codes 1096 begin at block 1098, which includes codes for directing the browser application to determine whether the participant device 108 includes a web camera and whether the participant has granted the host web page access to the web camera. For example, block 1098 may include getUserMedia codes that utilize Web Real-Time Communication (“WebRTC”) application program interfaces (“APIs”) and libraries to request a real-time video stream from the web camera of the participant device 108 and which return an indication of whether a video stream is available. If the participant device 108 does not include the web camera or if the participant has denied permission to access the web camera, the participant data collection browser codes 1096 continue at block 1100, which includes codes for directing the browser application to display a camera fail panel which overlays the host web page 1075, an embodiment of which is shown generally at 1150 in Figure 41.

The camera fail panel is configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) based on the instance of the camerafail entry 301 (shown in Figure 8) identified by the camerafail identifier stored in the camerafailidentifier field 326 of the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39). As described above, the camerafailidentifier field 326 of the instance of the application entry 311 may store a camerafail identifier identifying any one of at least three instances of camerafail entry 301 (shown in Figure 8) based on which camera fail option was selected by the host for the host web page 1075 using the camera fail selection list 690 on the add application page 670 (shown in Figure 23): (1) the “fail gracefully” instance of the camerafail entry 301 , (2) the “go back one page” instance of the camerafail entry 301 and (3) the“redirect to URL” instance of the camerafail entry 301. If the instance of the application entry 311 identifies the“go back one page” instance of the camerafail entry 301 , the camera fail panel may be similar to camera fail panel 1150 shown in Figure 41 , and may include both a message region 1152 and a continue button 1154. The message region may display an error message that the browser application is unable to access the web camera and a warning message that the host web page access session of the host web page may be returned as invalid if the browser application remains unable to access the web camera. The continue button 1154 may be configured

(such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to direct the browser application of the participant device 108 to re-display an immediately previous web page accessed by the browser application of the participant device 108.

If the instance of application entry 311 identifies the“redirect to URL” instance of the camerafail entry 301 , the camera fail panel may also be similar to camera fail panel 1150 shown in Figure 41 and may include both the message region 1152 and the continue button 1154. However, the continue button 1154 may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to direct the browser application of the participant device 108 to display a web page at the URL stored in the camerfailredirectURL field 328 of the instance of application entry 311 or the camera redirect URL contained in the script tag.

If the instance of the application entry 311 identifies the“fail gracefully” instance of the camerafail entry 301 , the camera fail panel 1150 may only include the message region.

The participant data collection browser codes 1096 then end.

Referring back to Figure 40A, if at block 1098, the participant device 108 does include a web camera and the participant has granted the host web page access to the web camera, the participant data collection browser codes 1096 continue at block 1102, which includes codes for directing the browser application to display a privacy policy panel, an embodiment of which is shown generally at 1160 in Figure 42.

Referring to Figure 42, the privacy policy panel 1160 overlays the host web page 1075 and includes a camera stream region 1162, an accept privacy policy button 1164 and a privacy policy link 1166. The privacy policy link 1166 may include codes that direct the browser application of the participant device 108 to display a privacy policy page of the assessment provider if selected by the participant. The privacy policy page may display a privacy policy as to how participant data collected by the assessment provider will be used and stored, as well as when and how participant data will deleted. The participant may select the accept privacy policy button 1164 to indicate that the participant accepts the privacy policy contained on the privacy policy page.

The camera stream region 1162 displays a real-time video stream acquired from the web camera. For example, block 1102 may include codes that communicate with the web camera of the participant device 108 to acquire a real-time video stream from the web camera, and may include getllserMedia codes that utilize WebRTC APIs and libraries, for example.

Referring back to Figure 40A, when the participant selects the accept privacy policy button 1164, the participant data collection browser codes 1096 continue at block 1104, which includes codes for directing the browser application of the participant device 108 to display a collect initial participant image panel, an embodiment of which is shown generally at 1170 in Figure 43. The collect initial participant image panel 1170 generally allows the participant to capture an initial participant image including a representation of the participant.

Referring to Figure 43, the collect initial participant image panel 1170 overlays the host web page 1075 and includes an initial participant image message region 1172, a camera stream region 1174 having a guideline 1176, an initial participant image prompt region 1178, and a capture image button 1179.

The initial participant image message region 1172 may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to display the customized message stored in the initialparticipantimagejext field 316 of the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39). As described above, the customized message stored in the initialparticipantimagejext field 316 of the instance of the application entry 311 (shown in Figure 9) is the customized message entered by the host in the initial participant image text input field 676 on the add application page 670 (shown in Figure 23) for a particular host web page and accordingly, the initial participant image message region 1172 may display different customized messages for different host web pages. If there is no customized message stored in the initialparticipantimagejext field 316, the initial participant image message region 1172 may not display any message.

The camera stream region 1174 displays a real-time video stream acquired from the web camera. For example, similar to block 1102, block 1104 may include codes that communicate with the web camera of the participant device 108 to acquire a real-time video stream from the web camera of the participant device 108, and may specifically include getllserMedia codes that utilize WebRTC APIs and libraries.

The guideline 1176 overlays the camera stream region 1174 and functions to guide the participant in positioning the participant’s head relative to a field of view of the web camera for capturing the initial participant image. The guideline 1176 may not be displayed in some embodiments of the collect initial participant image panel 1170. The initial participant image prompt region 1178 displays a prompt message to also guide the participant in positioning the participant’s face for capturing the initial participant image. In the embodiment of Figure 43, initial participant image prompt region 1178 displays “Center your face using the green guideline, the click the ‘Capture Image’ button to preview the image”.

The participant may select the capture image button 1179 capture a frame of the real time video stream displayed in the camera stream region 1174. Referring back to Figure 40A, when the participant user selects the capture image button 1179, the participant data collection browser codes 1096 continue at block 1106, which includes codes for directing the browser application of the participant device 108 to display a submit initial participant image panel, an embodiment of which is shown generally at 1180 in Figure 44. The submit initial participant image panel 1180 generally allows the participant to submit the initial participant image to the assessment server 102.

Referring to Figure 44, the submit initial participant image panel 1180 overlays the host web page 1075 and includes an initial participant image message region 1182, a camera stream region 1184, an initial participant image prompt region 1186, a submit image button 1188 and a re-capture image button 1190.

In the embodiment shown, the initial participant image message region 1182 displays a customized message identical to the customized message displayed in the initial participant image message region 1172 of the collect initial participant image panel 1170 (shown in Figure 43) and the initial participant image prompt region 1186 displays a prompt message identical to the prompt message displayed in the initial participant image prompt region 1178 of the collect initial participant image panel 1170 (shown in Figure 43). In other embodiments, the initial participant image message region 1182 may display a different customized message and the initial participant image prompt region 1186 may display a different prompt message. The camera stream region 1184 displays the frame of the real-time video stream captured by participant when the participant selected the capture image button 1179 of the collect initial participant image panel 1170 (shown in Figure 43).

Referring back to Figure 40A, the participant data collection browser codes 1096 continue at block 1107, which includes codes for directing the browser application of the participant device 108 to determine whether the participant selects the re-capture image button 1190 or the submit image button 1188. If the participant selects the re-capture image button 1190, the participant data collection browser codes 1096 return to block 1104 and direct the browser application of the participant device 108 to re-display the collect initial participant image panel 1170 shown in Figure 43.

Flowever, if the participant selects the submit image button 1188, the participant data collection browser codes 1096 continue at block 1108, which includes codes for directing the browser application of the participant device 108 to determine whether a human face can be detected in the frame of the real-time video stream displayed in the camera stream region 1184. For example, the codes of block 1108 may include codes that direct the browser application of the participant device 108 to use clmtrakr, ccv, OpenCV, Google Cloud vision and/or headtrackr APIs and libraries to, for example, return a “TRUE” value if a face is detected in the frame and to return a“FALSE” value if a face is not detected in the frame.

If a face is not detected in the frame for a first time, the participant data collection browser codes 1096 continue at block 1110, which includes codes for directing the browser application of the participant device 108 to display an initial participant image capture demonstration panel, an embodiment of which is shown generally at 1200 in Figure 45. The initial participant image capture demonstration panel 1200 generally provides additional instructions to the participant for capturing the initial participant image.

Referring to Figure 45, the initial participant image capture demonstration panel 1200 includes demonstration graphic 1202, a written instructions region 1204, and a re-capture image button 1206. The demonstration graphic 1202 is a graphical gif which demonstrates successive steps for positioning a participant’s face relative to the guideline 1176 to capture the initial participant image. In other embodiments, the demonstration graphic 1202 may be at least one static image illustrating the successive steps or may be a video of the successive steps. The written instructions region 1204 includes further instructions to the participant, and may ask the participant to ensure that their face is clearly visible within the guideline 1176, to ensure that their face is well lit, and that their face is facing the web camera for example. The written instructions region 1204 also includes a warning message that the host web page access session may be invalidated if the participant does not take and submit a clear initial participant image.

If the participant selects the re-capture image button 1206, the participant data collection browser codes 1096 return to block 1104 and thereby direct the browser application of the participant device 108 to re-display the collect initial participant image panel 1170 shown in Figure 43.

Referring back to Figure 40A, if at block 1108 a face is not detected in the frame for a second time (such as when the participant captures a second frame of the real-time video stream of the web camera using the collect initial participant image panel 1170 and submits the second frame using the submit initial participant image panel 1180) or if a face is detected in the frame, the participant data collection browser codes 1096 continue at block 1111 , which includes codes for directing the browser application of the participant device 108 to transmit the frame as an initial participant image including a representation of the participant in an initial participant image message to the assessment server 102. The initial participant image message may include additional information about the browser application of the participant device 108 and the participant device 108, including an URL of the host web page 1075, user agent information associated with the browser application of the participant device 108, a browser type of the browser application of the participant device 108, an IP address of the participant device 108, and a resolution of the web camera of the participant device 108.

Block 1111 also includes codes for directing the browser application to display an indication that the frame was successfully transmitted to the assessment server 102. For example, in the embodiment of Figure 44, block 1111 includes codes for directing the browser application of the participant device 108 to briefly display an“Image Submitted” message in the camera stream region 1184 after the frame is transmitted to the assessment server 102.

Once the initial participant image message is transmitted to the assessment server 102, the participant data collection browser codes 1096 continue at block 1112, which includes codes for directing the browser application of the participant device 108 to display a collect reference image panel, an embodiment of which is shown generally at 1210 in Figure 46. The collect reference image panel 1210 generally allows the participant to capture a reference image including a representation of a participant identification, such as a government photo identification or a corporate photo identification for example.

In the embodiment shown in Figure 46, the collect reference image panel 1210 overlays the host web page 1075 and includes a reference image message region 1212, a camera stream region 1214 having a guideline 1215, a reference image prompt region 1216, and a capture image button 1218.

Similar to the initial participant image message region 1172 of the collect initial participant image panel 1170 (shown in Figure 43), the reference image message region 1212 may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to display the customized message stored in the participantidentification text field 318 of the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39). As described above, the customized message stored in the participantidentification text field 318 of the instance of the application entry 311 (shown in Figure 9) is the customized message entered by the host in the participant identification text input field 678 on the add application page 670 (shown in Figure 23) and accordingly, the reference image message region 1212 may display different customized messages for different host web pages. If there is no customized message stored in the participantidentification text field 318, the reference image message region 1212 may not display any message.

The camera stream region 1214 displays a real-time video stream acquired from the web camera in the camera stream. For example, similar to blocks 1102 and 1104, block 1112 may also include codes that communicate with the web camera of the participant device 108 to acquire a real-time video stream from the web camera and may specifically include getllserMedia codes that utilize WebRTC APIs and libraries.

The guideline 1215 overlays the camera stream region 1214 and functions to guide the participant in positioning the participant identification relative to a field of view of the web camera. The guideline 1215 may not be displayed in some embodiments of the collect reference image panel 1210. The reference image prompt region 1216 displays a prompt message to also guide the participant in positioning the participant identification and in capturing the reference image. The prompt message may also specify what type of participant identification will be accepted to validate the host web page access session of the host web page. For example, some host web pages may require the participant to submit government photo identification for validation, whereas other host web pages may require the participant to submit company photo identification. In this respect, the reference image prompt region 1216 may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to display the customized message stored in the participantidentificationl prompt field 320 of the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39). As described above, the customized message stored in the participantidentificationl prompt field 320 of an instance of the application entry 311 (shown in Figure 9) is the customized message entered by the host in the first participant identification prompt input field 680 on the add application page 670 (shown in Figure 23), and accordingly, the reference image prompt region 1216 may display different customized messages for different host web pages. For example, the reference image prompt region 1216 may display “please provide a government photo identification” for host web pages requiring government photo identification and may display“please provide a corporate photo identification” for host web pages requiring corporate photo identification. Further, if there is no customized message in the participantidentification text field 318, the reference image prompt region 1216 may not display any message.

The participant may select the capture image button 1218 to capture a frame of the real time video stream displayed in the camera stream region 1214. Referring back to Figure 40A, when the participant selects the capture image button 1218, the participant data collection browser codes 1096 continue at block 1114, which includes codes for directing the browser application of the participant device 108 to display a submit reference image panel, an embodiment of which is shown generally at 1220 in Figure 47. The submit reference image panel generally allows the participant to submit the reference image to assessment server 102.

Referring to Figure 47, the submit reference image panel 1220 overlays the host web page 1075 and includes a reference image message region 1222, a camera stream region 1224, an reference image prompt region 1226, a submit image button 1228 and a re-capture image button 1230.

In the embodiment shown, the reference image message region 1222 displays a customized message identical to the customized message displayed in the reference image message region 1212 of the collect reference image panel 1210 (shown in Figure 46) and the reference image prompt region 1226 displays a prompt message identical to the prompt message displayed in the reference image prompt region 1216 of the collect reference image panel 1210 (shown in Figure 46). In other embodiments, the reference image message region 1222 may display a different customized message and the reference image prompt region 1226 may display a different prompt message. The camera stream region 1224 displays the frame of the real-time video stream captured by participant when the participant selected the capture image button 1218 on the collect reference image panel 1210 (shown in Figure 46).

Referring back to Figure 40A, the participant data collection browser codes 1096 continue at block 1116, which includes codes for directing the browser application of the participant device 108 to determine whether the participant selected the re-capture image button 1230 or the submit image button 1228. If the participant selects the re-capture image button 1230, the participant data collection browser codes 1096 return to block 1112 and thereby direct the browser application of the participant device 108 to re-display the collect reference image panel 1210 shown in Figure 46.

Flowever, if the participant selects the submit image button 1228, the participant data collection browser codes 1096 continue at block 1118, which includes codes for directing the browser application of the participant device 108 to determine whether a human face can be detected in the frame of the real-time video stream displayed in the camera stream region 1224 of the submit reference image panel 1220 (shown in Figure 47). For example, the codes of block 1118 may include codes that direct the browser to use clmtrakr, ccv, OpenCV and/or headtrackr APIs and libraries to, for example, return a “TRUE” value if a face is detected in the frame and to return a“FALSE” value if a face is not detected in the frame.

If a face is not detected in the frame for a first time, the participant data collection browser codes 1096 may continue at optional block 1120, which includes codes for directing the browser application of the participant device 108 to display a reference image capture demonstration panel, an embodiment of which is shown generally at 1240 in Figure 48. The reference image capture demonstration panel 1240 generally provides additional instructions to the participant as to how to capture the reference image.

In the embodiment of Figure 48, the reference image capture demonstration panel 1240 includes demonstration graphic 1242, a written instructions region 1244, and a re-capture image button 1246. The demonstration graphic 1202 is a graphical gif which demonstrates successive steps for positioning a participant identification relative to the guideline 1215 for capturing the reference image. In other embodiments, the demonstration graphic 1242 may be at least one static image illustrating the successive steps or may be a video of the successive steps. The written instructions region 1244 includes instructions to the participant for capturing the reference image, and may instruct the participant to ensure that first and last name identifiers on the participant identification are displayed as large as possible in the frame and that a participant image on the participant identification remains visible. The written instructions region 1244 also includes a warning message to the participant that the host web page access session may be invalidated if the participant does not take and submit a clear reference image.

Referring back to Figure 40A, when the participant user selects the re-capture image button 1246, the participant data collection browser codes 1096 return to block 1112 and thereby direct the browser application of the participant device 108 to re-display the collect reference image panel 1210 shown in Figure 46.

If at block 1118, a face is not detected in the frame for a second time (such as when the participant captures a second frame of the real-time video stream of the web camera using the collect reference image panel 1210 and submits the second frame using the submit reference image panel 1220) or if a face is detected in the frame, the participant data collection browser codes 1096 continue at block 1122, which includes codes for directing the browser application of the participant device 108 to transmit the frame as a reference image including a representation of the participant identification in a reference image message to the assessment server 102. The reference message may include additional information about the browser application of the participant device 108 and the participant device 108, including an URL of the host web page 1075, user agent information associated with the browser application of the participant device 108, a browser type of the browser application of the participant device 108, an IP address of the participant device 108, and a resolution of the web camera of the participant device 108.

Block 1122 also includes codes for directing the browser application to display an indication that the frame was successfully transmitted to the assessment server 102. For example, in the embodiment shown, block 1122 includes codes for directing the browser application to briefly display an“Image Submitted” message in the camera stream region 1224 of the submit reference image panel 1220 after the frame is transmitted to the assessment server 102.

In certain embodiments, the instance of the application entry 311 (shown in Figure 9) associated with the host web page 1075 may require the participant to capture and submit more than one reference image, and may require a reference image of a second participant identification and a reference image of a third participant identification. For example, in such embodiments, the participant data collection browser codes 1096 may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to include additional blocks of code similar to blocks 1112, 1114, 1116, 1118 and 1122 and which generally include codes to cause the browser application to display additional collect reference image panels similar to the collect reference image panel 1210 (shown in Figure 46) and additional submit reference image panels similar to the submit reference image panel 1220 (shown in Figure 47) to allow the participant to capture, re-capture and submit additional reference images corresponding to the second participant identification and the third participant identification in, respectively, a second reference image message and a third reference image message to the assessment server 102. Further, in these embodiments, the reference image prompt message region of these additional collect reference image panels and additional submit reference image panels (similar to the reference image prompt region 1216) may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to display customized messages stored in the participantidentification2_prompt field 322 and the participantidentification3_prompt field 324 of the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39).

Referring back to Figure 40A and as described above, the participant data collection browser codes 1096 are configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) based whether the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39) represents a participant assessment application providing only participant identity verification services or a participant assessment application providing both participant identify verification and participant proctoring services.

In embodiments where the instance of the application entry 311 represents a participant assessment application for providing only participant identity verification services, the participant data collection browser codes 1096 may be configured to end after block 1122, as all participant data (in the form of the initial participant image included in the initial participant image message transmit at block 1106 and the reference image included in the reference image message transmit at block 1122) required for participant identity verification has been transmitted to the assessment server 102.

However, referring to Figure 40A and 40B, in embodiments where the instance of the application entry 311 represents a participant assessment application for providing both participant identification verification and participant proctoring services, the participant data collection browser codes 1096 may be configured to continue at block 1124 after block 1122. Block 1124 includes codes for directing the browser application to display a participant tracking and proctoring panel, an embodiment of which is shown generally at 1250 in Figure 49. The participant tracking and proctoring panel 1250 generally allows the browser application of the participant device 108 to transmit subsequent participant images and presence inputs to the assessment server 102 and also allows the participant assessment application to automatically terminate the host web page access session of a host web page.

Referring to Figure 49, the participant tracking and proctoring panel 1250 overlays the host web page 1075 and includes a rules region 1252, a camera stream region 1254, a close panel button 1256 and a control panel element 1258.

The rules region 1252 may be configured (such as by block 1088 of the participant data collection server codes 1080 shown in Figure 39) to display rules based on which instances of the flagtype entry 481 (shown in Figure 15) is associated (via an instance of the selectedflagtype entry 491 shown in Figure 16) with the instance of the application entry 311 (shown in Figure 9) located at block 1082 of the participant data collection server codes 1080 (shown in Figure 39). As described above, an applicationidentifier field 492 of an instance of the selectedflagtype entry 491 stores an application identifier which identifies the instance of the application entry 311 , while the flagtypeidentifier field 494 of that instance of the selectedflagtype entry 491 stores a flagtype identifier which identifies an instance of the flagtype entry 481 (see block 718 of the add application codes 710 shown in Figure 24), based on which flags were selected by the host buttons 696, 698 and 700 of the add application page 670 (shown in Figure 23). Accordingly, the rules region 1252 may display different rules for different host web pages. For example, in the embodiment of Figure 49, the host selected the selection button 696 for the host web page 1075 on the add application page 670 (shown in Figure 23) and the instance of the application entry 311 associated with the host web page 1075 is thus associated (via the instance of the selectedflagtype entry 491) with the“participant not in view” instance of the flagtype entry 481. The rules region 1252 was thus configured to display the rule“you must remain at the computer for the duration of the session”.

The camera stream region 1254 is similar to the camera stream region 1174 of the collect initial participant image panel 1170 and the camera stream region 1214 of the collect reference image panel 1210 and displays a real-time video stream acquired from the web camera of the participant device 108. For example, block 1124 may include getUserMedia codes that utilize Web Real-Time Communication APIs and libraries.

When the participant selects the close panel button 1256, the participant data collection browser codes 1096 direct the browser application of the participant device 108 to collapse the participant tracking and proctoring panel 1250 to allow the participant to access the host web page 1075 during the host web page access session. An embodiment of the host web page 1075 having a collapsed participant tracking and proctoring panel 1250 is shown in Figure 50. Further, the expanded participant tracking and proctoring panel 1250 shown in Figure 49 and the host web page 1075 having the collapsed participant tracking and proctoring panel 1250 shown in Figure 50 both display the control panel element 1258. When the participant selects the control panel element 1258, the participant data collection browser codes 1096 direct the browser application of the participant device 108 to either collapse an expanded participant tracking and proctoring panel (such as to collapse the expanded participant tracking and proctoring panel 1250 shown in Figure 49) or expand a collapsed participant tracking and proctoring panel (such as to expand the collapsed participant tracking and proctoring panel 1250 shown in Figure 50). In the embodiment shown, block 1124 may include codes directing the browser application of the participant device 108 to display the control panel element 1258 as a draggable element on the host web page 1075 and may include dragElement codes for example. This may allow the participant to move the control panel element 1258 away from interactive elements of the host web page 1075 during the host web page access session as the participant is accessing the host web page 1075. In other embodiments, the control panel element 1258 may be a fixed element.

Referring back to Figure 40B, the participant data collection browser codes 1096 then continue at participant tracking codes shown generally at 1126 and participant proctoring codes shown generally at 1128. In the embodiment shown, the participant data collection browser codes 1096 continue at the participant tracking codes 1126 and the participant proctoring codes 1128 concurrently. In other embodiments, the participant data collection codes may only continue at the participant tracking codes 1126 or only continue at the participant proctoring codes 1128.

The participant tracking codes 1126 generally include codes for directing the browser application of the participant device 108 to continually detect a portion of the participant, such as head of the participant and to prompt the participant for presence input when the head of the participant cannot be detected. The participant tracking codes 1126 can thus assess whether the participant remains at the participant device 108 for the session period of the host web page access session of the host web page 1075.

The participant tracking codes 1126 begin at block 1130, which includes codes for directing the browser to continuously track a head associated with the participant for the session period of the host web page access session. For example, block 1130 may include codes that direct the browser to use clmtrakr, ccv, OpenCV, headtrackr and/or Google Cloud Vision APIs and libraries for example, to return events, such as headtrackingEvents, at regular intervals. In the embodiment shown, block 1130 may return a headtracking Event every two seconds, for example. In other embodiments, block 1130 may return headtrackingEvents after a longer or a shorter interval. The returned headtrackingEvents may have coordinate attributes“x, y, z” that identify an estimated position of the head in relation to a center of the real-time stream contained in the camera stream region 1254 (shown in Figure 49) and may thus indicate an estimated position of the head in relation to a center of the field of view of the web camera of the participant device 108. Some of the returned headtracking Events may also have coordinate attributes“null” that identify that the head cannot be detect in the real-time stream and thus indicate that the head is, or has moved, outside the field of view of the web camera.

The participant tracking codes 1126 continue at block 1134, which includes codes that direct the browser application of the participant device 108 to monitor the returned headtrackingEvents determine whether any of the returned headtracking Events are coordinate attributes “null”. If no returned headtrackingEvents is coordinate attributes “null”, indicating that the head constantly remains within the field of view of the web camera, the participant tracking codes 1132 then end when the host web page access session of the host web page 1075 end, such as when the browser application of the participant device 108 is directed away from the host web page 1075 to a different web page URL for example.

However, if at block 1132, one of the returned headtrackingEvents is coordinate attributes “null”, the participant tracking codes 1126 continue at block 1133, which includes codes for initiating a presence timer. In the embodiment shown, the presence timer is for 10 minutes. In other embodiments, the presence timer may be may be for a longer or shorter period of time.

The participant tracking codes 1126 continue at block 1134, which includes codes for directing browser application of the participant device 108 to continue to monitor the returned headtrackingEvents and determine whether any of the returned headtrackingEvents is coordinate attributes “x, y, z”. If one of the returned headtrackingEvents after the presence timer is coordinate attributes“x, y, z”, indicating that a head has returned to the field of view of the web camera, at any point before the presence timer expires, the participant tracking codes 1126 return to block 1132 and continue to monitor the returned headtrackingEvents to determine whether any of the returned headtrackingEvents is coordinate attributes“null” as described above. However, if all the returned headtracking Events after the presence timer has been initiated is coordinate attributes“null” and the presence timer expires, the participant tracking codes 1126 continue at block 1135, which includes codes for directing the browser application to display a presence input panel, an embodiment of which is shown generally at 1260 in Figure 51 , overlaying the participant tracking and proctoring panel 1250 (shown in Figure 49). Block 1135 also includes codes for directing the browser application of the participant device 108 to initiate an input timer. In the embodiment shown, the input timer may for be one minute. In other embodiments, the input timer may be for a longer or shorter period of time.

Referring to Figure 51 , in the embodiment shown, the presence input panel 1260 includes a presence prompt region 1262 displaying a warning message and a presence input button 1264. The warning message may indicate that if the presence input button 1264 is not selected before the input timer expires, the host web page access session of the host web page will be automatically ended.

Referring back to Figure 40B, the participant tracking codes 1264 then continue at block 1 136, which includes codes for directing the participant device 108 to determine if the participant selects the presence input button 1264 before the input timer expires. If at block 1 136, the participant does select the presence input button 1264 before the input timer expires, the participant tracking codes 1126 continue at block 1137, which includes codes for directing the browser application to transmit the presence input in a presence input message to the assessment server 102. The participant tracking codes 1126 then return to block 1132 and continue to monitor the returned headtracking Events to determine whether any of the returned headtracking Events are coordinate attributes“null” as described above. If the participant remains outside the field of view of the web camera of the participant device 108 (such that the headtracking Events returned by block 1130 is consistently coordinate attributes“null”), the participant may be directed to the presence input panel 1260 and prompted to select the presence input button 1264 several times during the host web page access session of the host web page. If the participant consistently selects the presence input button 1264 before the input timer expires, block 1137 may transmit several presence input messages to the assessment server 102. The participant tracking codes 1126 then end when the host web page access session of the host web page 1075 end, such as when the browser application of the participant device 108 is directed away from the host web page 1075 to a different web page URL for example.

However, if at block 1136, the participant does not select the presence input button 1264 before the input timer expires, the participant tracking codes 1126 automatically continue at block 1138 after the input timer expires. Block 1138 includes codes for directing the browser application of the participant device 108 to automatically end the host web page access session of the host web page 1075 and may include codes for directing the browser application away from the host web page 1075 to a different web page URL for example. The participant tracking codes 1126 then end, as the host web page access session of the host web page 1075 has ended.

Still referring to Figure 40B, the participant proctoring codes 1128 generally include codes for directing the browser application of the participant device 108 to automatically capture subsequent participant images and to transmit these subsequent participant images to the assessment server 102. The participant proctoring codes 1128 begin at block 1140, which includes codes for directing the browser application of the participant device 108 to automatically capture a frame of the real-time video stream displayed in the camera stream region 1254 of the participant tracking and proctoring panel 1250 (shown in Figure 49). The participant proctoring codes 1128 continue at block 1141 , which includes codes for directing the browser application of the participant device 108 to transmit the frame captured at block 1140 as a subsequent participant image including a representation of the participant in a subsequent participant image message to the assessment server 102. The subsequent participant image message may include additional information about the browser application of the participant device 108 and the participant device 108, including an URL of the host web page 1075, user agent information associated with the browser application of the participant device 108, a browser type of the browser application of the participant device 108, an IP address of the participant device 108, and a resolution of the web camera of the participant device 108. The participant proctoring codes 1128 continue at block 1142, which includes codes for directing the browser application of the participant device 108 to wait for an interval period of five seconds. In other embodiments, the interval period may be for a shorter or longer period of time. After the interval period, the participant proctoring codes 1128 then return to block 1140 to capture another frame of the real-time video stream displayed in the camera stream region 1254 of participant tracking and proctoring panel 1250 (shown in Figure 49) and continue from block 1140 as described above. The participant proctoring codes 1128 can thus capture a plurality of subsequent participant images and transmit a plurality of subsequent participant image messages to the assessment server 102 during the session period of the host web page access session of the host web page 1075.

The participant proctoring codes 1128 then end when the host web page access session of the host web page 1075 ends, such as when the browser application of the participant device 108 is directed away from the host web page 1075 to a different web page URL for example. In this respect, the participant proctoring codes 1128 would also end due to block 1138 of the participant tracking codes 1126 ending the host web page access session in response to the participant not selecting the presence input button 1264 of the presence input panel 1260 (shown in Figure 51) before the input timer expires.

Referring back to Figure 39, the participant data collection server codes 1080 remain at block 1092 until participant data is received from the participant device 108. In the embodiment shown, the participant data may be the initial participant image in the initial participant image message transmitted by block 1110 of the participant data collection browser codes 1096 (shown in Figure 40A), the reference image in the reference image message transmitted by block 1122 of participant data collection browser codes 1096 (shown in Figure 40A), the presence inputs in the presence input message(s) transmitted by block 1137 of the participant tracking codes 1126 (shown in Figure 42B) and the subsequent participant image(s) in the subsequent participant image message(s) transmitted by block 1141 of the participant proctoring codes 1128 (shown in Figure 40B).

Upon receipt of the initial participant image message (transmitted by block 1110 of the participant data collection browser codes 1096) at block 1280, the participant data collection server codes 1080 continue at block 1284. Block 1284 includes codes for directing the assessment server microprocessor 120 to store the initial participant image received in the initial participant image message in the image database 152 (shown in Figure 2).

The participant data collection server codes 1080 continue at block 1286, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the participantdata entry 401 (shown in Figure 12) representing the initial participant image to the participantdata table 400. The new instance of the participantdata entry 401 stores a participant identifier identifying the participant entry 381 located at block 1086 or added at block 1090 in the participantidentifier field 404, stores an URI identifying the storage location of the initial participant image in the image database 152 in the capturedata field 406 and stores“initial participant image” in the capturetype field 408.

This new instance of the participantdata entry 401 also stores information contained in the initial participant image message in other fields, and may (1) store the URL of the host web page 1075 in the captureURL field 409, (2) store the user agent information associated with the browser application of the participant device 108 in the useragent field 412, (3) store the browser type of the browser application of the participant device 108 in the browser field 414, (4) store the IP address of the participant device 108 in the IP address field 410, and (5) store the resolution of the web camera of the participant device 108 in the resolution field 416. This new instance of the participantdata entry 401 also stores a current date and time obtained from the clock 122 (shown in Figure 2) in the created field 418.

The participant data collection server codes 1080 continue at block 1286, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the participantsession entry 451 (shown in Figure 13) to the participantsession table 450 (shown in Figure 3). This new instance of the participantsession entry 451 stores a participant identifier identifying the participant entry 381 (shown in Figure 11) located at block 1086 or added at block 1090 in the participantidentifier field 454. This new instance of the participantsession entry 451 also stores the current date and time stored the created field 418 of the participantdata entry 401 added at block 1284 in the sessionstart field 456. The participantdata entry 401 added at block 1284 is thus associated with the participantsession entry 451 added at block 1286 because (a) the participant identifier stored in the participantidentifier field 404 is the participant identifier stored in the participantidentifier field 454 of that instance of the participantsession entry 451 and (b) the date and time stored in the created field 418 is equal to, or after, the date and time stored in the sessionstart field 456 of that instance of the participantsession entry 451.

The participant data collection server codes 1080 continue at block 1288, which includes codes for causing the assessment server microprocessor 120 to wait for additional participant data from the browser application of the participant device 108.

Upon receipt of the reference image message transmitted by block 1122 of the participant data collection browser codes 1096 (shown in Figure 40A) at block 1290, the participant data collection server codes 1080 continue at block 1292. Block 1292 includes codes for directing the assessment server microprocessor 120 to store the reference image received in the reference image message in the image database 152 (shown in Figure 2).

The participant data collection server codes 1080 continue at block 1294, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the participantdata entry 401 (shown in Figure 12) representing the reference image to the participantdata table 400. The new instance of the participantdata entry 401 stores a participant identifier identifying the participant entry 381 located at block 1086 or added at block 1090 in the participantidentifier field 404, stores a URI identifying the storage location of the reference image in the image database 152 in the capturedata field 406 and stores“reference image 1” in the capturetype field 408.

This new instance of the participantdata entry 401 also stores information contained in the reference image message received at block 1290 in other fields, and may (1) store the URL of the host web page 1075 in the captureURL field 409, (2) store the user agent information associated with the browser application of the participant device 108 in the useragent field 412, (3) store the browser type of the browser application of the participant device 108 in the browser field 414, (4) store the IP address of the participant device 108 in the IP address field 410, and (5) store the resolution of the web camera of the participant device 108 in the resolution field 416. This new instance of the participantdata entry 401 also stores a current date and time obtained from the clock 122 (shown in Figure 2) in the created field 418. The participantdata entry 401 added at block 1294 is thus also associated with the participantsession entry 451 added at block 1286 because (a) the participant identifier stored in the participantidentifier field 404 is the same as the participant identifier stored in the participantidentifier field 454 of that instance of the participantsession entry 451 and (b) the date and time stored in the created field 418 is equal to, or after, the date and time stored in the sessionstart field 456 of that instance of the participantsession entry 451. As described above, in certain embodiments, the participant data collection browser codes 1096 may be configured to direct the browser application of the participant device to transmit second and third reference image messages to the assessment server 102. In such embodiments, the participant data collection server codes 1080 include additional blocks of code similar to blocks 1290, 1292 and 1294 to store these additional reference images and to add additional instances of the participantdata entry 401 (shown in Figure 12) to the participantdata table 400 (shown in Figure 3) representing these additional reference images. These additional instances of the participantdata entry 401 may store “reference image 2” and“reference image 3” in the capturetype field 408.

The participant data collection server codes 1080 continue at block 1296, which includes codes for causing the assessment server microprocessor 120 to wait for additional participant data from the browser application of the participant device 108.

Upon receipt of a presence input message transmitted by block 1122 of participant data collection browser codes 1096 (shown in Figure 40A) at block 1300, the participant data collection server codes 1080 continue at block 1302. Block 1302 includes codes for directing the assessment server microprocessor 120 to add a new instance of the tracking entry 441 (shown in Figure 14) representing the presence input to the tracking table 440 (shown in Figure 3). This new instance of the tracking entry 441 stores a participantsession identifier identifying the participantsession entry 451 added at block 1286 in the participantsessionidentifier field 446. The participant data collection server codes 1080 then return to block 1296 to cause the assessment server microprocessor 120 to wait for additional participant data, which may be another presence input message for example.

Upon receipt of a subsequent participant image message transmitted by block 1141 of the participant proctoring codes 1128 (shown in Figure 40B) at block 1310, the participant data collection server codes 1080 continue at block 1312. Block 1312 includes codes for directing the assessment server microprocessor 120 to store the subsequent participant image received in the subsequent participant image message in the image database 152 (shown in Figure 2).

The participant data collection server codes 1080 continue at block 1314, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the participantdata entry 401 (shown in Figure 12) representing the subsequent participant image to the participantdata table 400. The new instance of the participantdata entry 401 stores the participant identifier identifying the participant entry 381 located at block 1086 or added at block 1090 in the participantidentifier field 404, stores a URI identifying the storage location of the subsequent participant image in the image database 152 in the capturedata field 406 and stores“subsequent participant image” in the capturetype field 408.

This new instance of the participantdata entry 401 also stores information contained in the subsequent participant image message received at block 1310 in other fields, and may (1) store the URL of the host web page 1075 in the captureURL field 409, (2) store the user agent information associated with the browser application of the participant device 108 in the useragent field 412, (3) store the browser type of the browser application of the participant device 108 in the browser field 414, (4) store the IP address of the participant device 108 in the IP address field 410, and (5) store the resolution of the web camera of the participant device 108 in the resolution field 416.

This new instance of the participantdata entry 401 also stores a current date and time obtained from the clock 122 (shown in Figure 2) in the created field 418. The participantdata entry 401 added at block 1314 is thus also associated with the participantsession entry 451 added at block 1286 because (a) the participant identifier stored in the participantidentifier field 404 is the same as the participant identifier stored in the participantidentifier field 454 of that instance of the participantsession entry 451 and (b) the date and time stored in the created field 418 is equal to, or after, the date and time stored in the sessionstart field 456 of that instance of the participantsession entry 451.

The participant data collection server codes 1080 then return to block 1296 and cause the assessment server microprocessor 120 to wait for additional participant data. The additional participant data may be receipt of another subsequent participant image message. If the host web page access session of the host web page is ended by the participant via the participant device 108, the participant data collection server codes 1080 may remain at block 1296 and may not receive any subsequent participant image messages or any presence input messages (or any further subsequent participant image messages or any further presence input messages in some embodiments). The participant data collection server codes 1080 may be ended by end session codes 1400 stored in the program memory 128 of the assessment server 102 (shown in Figure 2) described below.

Demonstration Mode

Still referring to Figure 39, if at block 1084 the application entry 311 located at block 1082 has not been activated, the participant data collection server codes 1080 continue at block 1316, which includes codes for configuring demonstration mode browser codes and for transmitting the demonstration mode browser codes to the browser application of the participant device 108.

The participant data collection server codes 1080 continue at block 1322, which includes codes for directing the assessment server microprocessor 120 to add a new instance of the demo entry 371 (shown in Figure 10) to the demo table 370 (shown in Figure 3). This new instance of the demo entry 371 stores the application identifier identifying the application entry 311 located at block 1082 in the applicationidentifier field 374. This new instance of demo entry 371 also stores other information received in the participant assessment request in various fields and may store the URL address of the host web page in the demoURL field 376. This new instance of the demo entry 371 may also store a date and time obtained from the clock 122 (shown in Figure 2) that the demonstration mode browser codes were transmitted to the browser application (obtained from the clock 122 shown in Figure 2) in the created field 378. The participant data collection server codes 1080 then end.

The browser application of the participant device 108 executes the demonstration mode browser codes upon receipt from the assessment server 102. The demonstration mode browser codes are similar to, but different from the participant data collection browser codes. For example, the demonstration mode browser codes may demonstrate the various functionality of the participant assessment application, which may encourage a host to activate the participant assessment application for a host web page, but may not be configured based on values stored in the instance of the application entry 311 located at block 1082 and further may not transmit any participant data to the assessment server 102.

For example, the demonstration mode browser codes include code similar to blocks 1102, 1104, 1106, 1108, 1110, 1112, 1114, 1116, 1118, 1120 of the participant data collection browser codes 1096 (shown in Figure 40A) and may thus direct the browser application of the participant device 108 to display demonstration versions of the privacy policy panel 1160, the collect initial participant image panel 1170, the submit initial participant image panel 1180, the initial participant image capture demonstration panel 1200, the collect reference image panel 1210, the submit reference image panel 1220, and the reference image capture demonstration panel 1240. Flowever, each of these demonstration versions of these panels may include a demonstration mode message indicating to the participant that the participant assessment application is operating in the demonstration mode and the no participant data is being collected and sent to the assessment server 102. Further, the demonstration versions of each panel may not include any customized messages or customized buttons based on the instance of the application entry 311 located at block 1082.

Further, when the participant selects the submit buttons of the demonstration version of submit initial participant image panel or the demonstration version of the submit reference image panel, the demonstration mode browser codes do not include code similar blocks 1110 or 1122 of the participant data collection browser codes 1096 and as such, no initial participant image message and no reference image message is transmitted to the assessment server 102.

The demonstration mode browser codes can also include code similar to block 1124 of the participant data collection browser codes 1096, code similar to blocks 1130, 1132, 1133, 1134, 1135, 1136, and 1138 of the participant tracking codes 1126, as well as code similar to block 1140 of the participant proctoring codes 1128, and may thus direct the browser application of the participant device 108 to display a demonstration version of the participant tracking and proctoring panel 1250. However, the demonstration version of the participant tracking and proctoring panel may also include the demonstration mode message and may not include any customized messages based on the instance of the application entry 311 located at block 1082. Further, the demonstration mode browser codes do not include blocks of code similar block 1137 of the participant tracking codes 1126 or block 1141 of the participant proctoring codes 1128 and as such, no subsequent participant image messages and no presence input messages are transmitted to the assessment server 102.

End Session Codes

Referring back to Figure 2, the program memory 128 of the assessment server 102 further includes the end session codes 1400. In the embodiment shown, the end session codes 1400 execute periodically, such as every 90 seconds. In other embodiments, the end session codes 1400 may execute after a shorter or a longer interval. The end session codes 1400 are illustrated schematically in Figure 52 and generally include codes for directing the assessment server microprocessor 120 to terminate any participant data collection server codes 1080 which are still active (such as waiting at blocks 1092, 1288, or 1296 (shown in Figure 39) for example), but which have not received any further participant data from the browser application of the participant device 108 for a period of time.

Referring to Figure 52, the end session codes 1400 and begin at block 1402, which includes codes for directing the assessment server microprocessor 120 to locate instances of the participantsession entry 451 (shown in Figure 13) in the participantsession table 450 (shown in Figure 3) which store“null” in the sessionend field 458 and store “null” in the sessionreviewed field 470. If no instances of the participantsession entry 451 are located at block 1402, the end session codes 1400 then end.

Flowever, if at least one instance of the participantsession entry 451 is identified at block 1402, the end session codes 1400 continue at block 1404, which include codes for directing the assessment server microprocessor 120 to return a list of all instances of the participantsession entry 451 located at block 1402.

The end session codes 1400 continue at block 1406, which includes codes for directing the assessment server microprocessor 120 to determine whether an instance of the participantsession entry 451 from the list returned at block 1404 can be selected. If an instance of the participantsession entry 451 cannot be selected from the list (such as if all instances of the participantsession entry 451 on the list have already be selected and updated as described below), the end session codes 1400 end.

Flowever, if an instance of the participantsession entry 451 can be selected from the list, the end session codes 1400 continue at block 1408, which includes codes for directing the assessment server microprocessor 120 to select an instance of the participantsession entry 451 from the list and to also remove that instance of the participantsession entry 451 from the list.

Block 1408 also include codes for directing the assessment server microprocessor 120 to locate a most recent instance of the participantdata entry 401 (shown in Figure 12) in the participantdata table 400 (shown in Figure 3) associated with the participantsession entry 451 selected. For example, in the embodiment shown, block 1404 includes codes for directing the assessment server microprocessor 120 to (1) locate all instances of the participantdata entry 401 which store (a) a participant identifier in the participantidentifier field 404 same as the participant identifier stored in the participantidentifier field 454 of that instance of the participantsession entry 451 and (b) a date and time in the created field 418 equal to, or after, the date and time stored in the sessionstart field 456 of that instance of the participantsession entry 451 , (2) read the date and time stored in the created fields 418 of all instances of the participantdata entry 401 identified at step (1) to identify the instance of the participantdata entry 401 having a latest date and time stored in the created field 418.

The end session codes 1400 continue at block 1410, which includes codes for directing the assessment server microprocessor 120 to determine whether the latest date and time is longer than an end session interval (10 minutes in the embodiment shown) from a current date and time obtained from the clock 122 (shown in Figure 2). In the embodiment shown, the end session interval is 10 minutes. In other embodiments, the end session interval may be for a shorter or a longer period of time. If the latest date and time is not longer than the end session interval from the current date and time, the end session codes 1400 then return to block 1406 to determine whether another instance of the participantsession entry 451 can be selected from the list and continue from block 1460 as described above.

However, if latest date and time is longer than the end session interval from the current date and time, the end session codes continue at block 1412, which includes codes for directing the assessment server microprocessor 120 to update the participantsession entry 451 selected at block 1408 by storing the latest date and time in the sessionend field 458. Thus, after block 1408, the sessionstart field 456 of an instance of a participantsession entry 451 stores an earliest date and time stored in the created fields 418 of the instances of the participantdata entry 401 associated with that instance of a participantsession entry 451 (see block 1286 of the participant data collection server codes 1080 shown in Figure 39), while the sessionend field 458 stores a latest date and time stored in the created fields 418 of the instances of the participantdata entry 401 associated with that instance of the participantsession entry 451. The end session codes 1400 then return to block 1406 to determine whether another instance of the participantsession entry 451 can be selected from the list and then continue from block 1406 as described above.

Participant Assessment Codes Referring back to Figure 2, the program memory 128 of the assessment server 102 also includes participant assessment codes 1420. The participant assessment codes 1420 are shown schematically in Figure 53A and 53B, and generally include codes for directing the assessment server microprocessor 120 to determine whether the host web page access session of a host web page can be auto-validated by the assessment server microprocessor 120 or whether the host web page access session should be reviewed by a reviewer.

In the embodiment shown, the participant assessment codes 1420 execute after block 1294 of the participant data collection server codes 1080 (shown in Figure 39). In other embodiments, the participant assessment codes 1420 may execute in response to the end session codes 1400 (shown in Figure 52) storing a date and time in the sessionend field 458 of a particular instance of the participantsession entry 451 (shown in Figure 13).

Referring to Figures 53A and 53B, the participant assessment codes 1420 in the embodiment shown include three groups of codes: (1) previous session validation codes 1422 (shown in Figure 53A), (2) identifier validation codes 1424 (shown in Figure 53B) and (3) image validation codes 1426 (shown in Figure 53B). In the embodiment of Figures 53A and 53B, the participant assessment codes 1420 first attempt to validate the host web page access session using the previous session validation codes 1422 and then attempt to validate the host web page access session using the identifier validation codes 1424 and the image validation codes 1426 in combination. In other embodiments, the participant assessment codes 1420 may attempt to validate the host web page access session using only the identifier validation codes 1424 and the image validation codes 1426 in combination.

As described above, before the participant assessment codes 1420 execute, the participant data collection codes 1080 have already added (or located) a current instance of the participant entry 381 (shown in Figure 11) to (or in) the participant table 380 at block 1086 (or block 1090) (shown in Figure 39). This current instance of the participant entry 381 represents a participant accessing a particular host web page. This current instance of the participant entry 381 also stores the participant first name (received in the participant assessment request sent from the browser application of the participant device 108) as the firstname participant identifier in the firstnameparticiptantidentifier field 388 and stores the participant last name (also received in the participant assessment request) as a lastname participant identifier in the last name field 390.

Further, as described above, the participant assessment codes 1420 execute after block 1294 of the participant data collection server codes 1080 (shown in Figure 39) and thus execute (1) after receipt of both the initial participant image message and the reference image message from the browser application of the participant device 108 (see blocks 1280 and 1290 of the participant data collection server codes 1080 shown in Figure 39), (2) after a current instance of the participantsession entry 451 representing the host web page access session of a host web page has been added to the participantsession table 450 (see block 1286 of the participant data collection server codes 1080 shown in Figure 39) and (3) after this current instance of the participantsession entry 451 is associated with both an instance of the participantdata entry 401 (shown in Figure 12) which stores “initial participant image” in the capturetype field 408 and an instance of the participantdata entry 401 which stores“reference image 1” in the capturetype field 408.

Referring to Figure 53A, the participant assessment codes 1420 begin at block 1430, which includes codes for directing the assessment server microprocessor 120 to locate and render a current initial participant image associated with the current instance of the participantsession entry 451. In the embodiment shown, block 1438 includes codes for directing the assessment server microprocessor 120 to (1) identify the instance of the participantdata entry 401 associated (via an instance of the participant entry 381 and the date and time stored in the created field 418) with the current instance of the participantsession entry 451 which stores“initial participant image” in the capturetype field 408 and to (2) convert the URI stored in the capturedata field 406 of this instance of the participantdata entry 401 into the current initial participant image by drawing the URI onto a canvas object for example.

The participant assessment codes 1420 continue at block 1432, which includes codes for directing the assessment server microprocessor 120 to determine whether a face can be detected in the current initial participant image rendered at block 1430. For example, in the embodiment shown, block 1432 may include codes that direct the assessment server microprocessor 120 to use OpenFace APIs and libraries to return a“TRUE” value if a face is detected in the current initial participant image and to return a“FALSE” value if a face is not detected in the current initial participant image and the reference image.

If a face is not detected in the current initial participant image, the participant assessment codes 1420 then proceed to block 1434, which includes codes for directing the assessment server microprocessor 120 to add an instance of the participantdataflag entry 511 (shown in Figure 18) to the participantdataflag table 510 (shown in Figure 3). This new instance of the participantdataflag entry 511 stores a participantdata identifier identifying the participantdata entry 401 storing the current initial participant image in the participantdataidentifier field 514, stores a flagtype identifier identifying the“clear image of participant not provided” instance of the flagtype entry 481 (shown in Figure 15) in the flagtypeidentifier field 516 (such as flagtype identifier “6” for example), and stores a flagstatus identifier identifying the“initiated” instance of the flagstatus entry 501 (shown in Figure 17) in the flagstatusidentifier field 518. The participant assessment codes 1420 continue at block 1436 to return a“FALSE” value. A“FALSE” value represents that the current instance of the participantsession entry 451 (representing the host web page access session of the host web page) could not be validated by the assessment server microprocessor 120 using the participant assessment codes 1420. The participant assessment codes 1420 continue at block 1437, which includes codes for directing the assessment server microprocessor 120 to load the current instance of the participantsession entry 451 to a reviewer interface 1560 described in greater detail below.

However, if at block 1432 a face is detected in the current initial participant image, the participant assessment codes 1420 then continue at the previous session validation codes 1422.

Previous Session Validation Codes

The previous session validation codes 1422 generally include codes for directing the assessment server microprocessor 120 to validate the current instance of the participantsession entry 451 using a pre-existing (previous) instance of the participantsession entry 451 in the participantsession table 450 (shown in Figure 3).

Still referring to Figure 53A, the previous session validation codes 1422 start at block 1438, which includes codes for directing the assessment server microprocessor 120 to search the participant table 380 (shown in Figure 2) for a previous instance of the participant entry 381 which stores a same firstname participant identifier the firstnameparticiptantidentifier field 388 and a same lastname participant identifier in the lastnameparticiptantidentifier field 390 as that stored in the firstnameparticiptantidentifier field 388 and the lastnameparticiptantidentifier field 390 of the current instance of the participant entry 381. Block 1438 thus examines the participant table 380 for a previous instance of the participant entry 381 which may represent the same individual. This previous instance of the participant entry 381 may identify a participant assessment application (represented by an instance of the application entry 311 shown in Figure 9) embedded in a different host web page and may store an application identifier in the applicationidentifier field 384 different than that stored in the applicationidentifier field 384 of the current instance of the participant entry 381. The assessment server microprocessor 120 is not directed to consider the value in the respective applicationidentifier fields 384 of the two instances of the participant entry 381 at block 1438. If a previous instance of the participant entry 381 is not found, the previous session validation codes 1422 continue at block 1440, which includes codes for directing the assessment server microprocessor 120 to return a“FALSE” value. A“FALSE” value represents that the current instance of the participantsession entry 451 (shown in Figure 13) could not be auto-validated using a previous instance of the participantsession entry 451 , and the participant assessment codes 1420 continue onto the identifier validation codes 1424 and the image validation codes 1426.

However, if a previous instance of the participant entry 381 is found, the previous session validation codes 1422 continue at block 1442. If more than one previous instance of the participant entry 381 is found, block 1438 may include codes for directing the assessment server microprocessor 120 to select the previous instance with a latest date and time stored in the created field 392.

Block 1442 includes codes for directing the assessment server microprocessor 120 to determine whether a previous instance of the participantsession entry 451 (shown in Figure 13) which identifies the previous instance of the participant entry 381 located at block 1438 has been validated or reviewed. For example, in the embodiment shown, block 1431 includes codes for directing the assessment server microprocessor 120 to (1) locate a previous instance of the participantsession entry 451 in the participantsession table 450 (shown in Figure 3) which stores a participant identifier identifying the previous instance of the participant entry 381 in the participantidentifier field 404 and then (2) determine whether the sessionautovalidated field 469 or the sessionreviewed field 470 of the previous instance of the participantsession entry 451 located at step (1) stores a date and time. If the previous instance of the participantsession entry 451 has not been autovalidated or reviewed, the previous session validation codes 1422 continue at block 1440 to return a“FALSE” value and continue from block 1440 as described above.

However, if the previous instance of the participantsession entry 451 has been either autovalidated or reviewed, such as if at least one of the sessionautovalidated field 469 or the sessionreviewed field 470 stores a date and time for example, the previous session validation codes 1422 continue at block 1444. Block 1444 includes codes for directing the assessment server microprocessor 120 to determine if any instances of the participantdata entry 401 (shown in Figure 12) associated (via an instance of the participant entry 381 and the date and time stored in the created field 418) with this previous instance of the participantsession entry 451 are identified by“confirmed” or “initiated” flags. For example, in the embodiment shown, block 1434 includes codes for directing the assessment server microprocessor 120 to (1) locate all instances of the participantdata entry 401 in the participantdata table 400 (shown in Figure 3) which store a participant identifier in the participantidentifier field 404 same as the participant identifier stored in the participantidentifier field 454 of the previous instance of the participantsession entry 451 and stores a date and time in the created field 448 equal to, or after, the date and time stored in the sessionstart field 456 of the previous instance of the participantsession entry 451 , (2) determine if any instances of the participantdataflag entry 511 (shown in Figure 18) in the participantdataflag table 510 (shown in Figure 3) stores a participantdata identifier identifying one of the instances of the participantdata entry 401 located at step (1) in the participantdataidentifier field 514, and (3) if so, determine whether any of the instances of the participantdataflag entry 511 located at step (2) also store a flagstatus identifier identifying the either“confirmed” or the“initiated” instance of the flagstatus entry 501 (shown in Figure 17) in the flagstatusidentifier field 516. If any instance of the participantdata entry 401 is identified by “confirmed” or “initiated” flags, the previous session validation codes 1422 continue at block 1440 to return a“FALSE” value and continue from block 1440 as described above.

However, if no instance of the participantdata entry 401 is identified by“confirmed” or “initiated” flags, the previous session validation codes 1422 continue at block 1445, which includes codes for directing the assessment server microprocessor 120 to locate and render a previous initial participant image. For example, in the embodiment shown, block 1442 includes codes for directing the assessment server microprocessor 120 to (1) identify the instance of the participantdata entry 401 which stores “initial participant image” in the capturetype field 408 and (2) convert the URI stored in the capturedata field 406 of the instance of the participantdata entry 401 identified at step (1) into the previous initial participant image by drawing the URI onto a canvas object.

The previous session validation codes 1422 continue at block 1446, which incudes codes for directing the assessment server microprocessor 120 to determine whether the face detected in the current initial participant image at block 1432 and a face in the previous initial participant image satisfy an image match criterion. Generally, if the two faces satisfy the image match criterion, the two faces are of the same individual. However, if the two faces do not satisfy the image match criterion, the two faces are not of the same individual. In the embodiment shown, block 1446 includes codes that direct the assessment server microprocessor 120 to use OpenFace APIs and libraries for example, to compare the face in the current initial participant image and the face in the previous initial participant image and to return a distance value between 0.00 and 2.00. In the embodiment shown, the image match criterion is a returned distance value of less than 0.99. If the face in the current initial participant image and the face in the previous initial participant image do not satisfy the image match criterion, such as if the distance value returned at block 1446 is greater than, or equal to, 0.99, for example, the previous session validation codes 1422 return to block 1440 to return a “FALSE” value and continue from block 1440 as described above.

If the face in the current initial participant image and the face in the previous initial participant image do satisfy the image match criterion, such as if the distance value returned at block 1446 is less than 0.99, for example, the previous session validation codes 1422 continue at block 1447. Block 1447 includes codes for directing the assessment server microprocessor 120 to return a“TRUE” value for the previous session validation codes 1422. The “TRUE” value represents that the current participant associated with the current instance of the participant entry 381 is the same individual as the previous participant associated with the previous instance of the participant entry 381 , as both participants have a same first and last name (determined at block 1438) and faces which satisfy the image match criterion (determined at block 1446). Further, as the previous instance of the participantsession entry 451 identifying the previous instance of the participant table 381 has already been autovalidated or reviewed (determined at block 1442) and there are no “confirmed” or “initiated” flags associated with this previous instance of the participantsession entry 451 (determined at block 1444), the assessment provider assumes that the face in the previous initial participant image has already been determined to match a face in a previous reference participant image (of a previous reference image representing a participant identification) and that a firstname participant identifier and a lastname participant identifier of this previous instance of the participant entry 381 has already been determined to match a reference identifier (again of a previous reference image representing a participant identification). Thus, a comparison of the current initial participant image, the current firstname participant identifier and the current lastname participant identifier with a reference participant image and reference identifier of a current reference image may not be required. More generally, because the face and name of the previous participant has already been compared (and validated) against a previous piece of participant identification, confirming that the current participant is the same individual as the previous participant may be sufficient to verify an identity of the current participant and comparison of a face and name of the current participant with another piece of participant identification may not be required.

The participant assessment codes 1420 continue at bock 1448, which includes codes for directing the assessment server microprocessor 120 to update the current instance of the participantsession entry 451 to store a current date and time from the clock 122 (shown in Figure 2) in the previoussession autovalidated field 467 and to store a participantsession identifier identifying the previous instance of the participantsession entry 451 in the previoussessionidentifier field 468. A date and time stored in the previoussession autovalidated field 467 of an instance of the participantsession entry 451 generally functions as a previous-session-validated indicator associated with that instance of the participantsession entry 451.

The participant assessment codes 1420 continue at block 1450 to determine whether the instance of the application entry 311 identified by the current instance of the participant entry 381 represents a participant assessment application providing only participant identity verification services or a participant assessment application providing both participant identity verification and participant proctoring services. For example, in the embodiment shown, block 1450 may include codes for directing the assessment server microprocessor 120 to determine if an instance of the orderitem entry 281 (shown in Figure 7) identifying the instance of the application entry 311 stores a participant identity verification indicator representing participant identity verification services in the product field 286 or stores both a participant identity verification indicator and a participant proctoring service indicator in the product field 286.

If the instance of the application entry 311 is a participant assessment application providing only participant identity verification services, the participant assessment codes 1420 continue at block 1452, which includes codes for directing the assessment server microprocessor 120 to store a current date and time obtained from the clock 122 (shown in Figure 2) in the sessionautovalidated field 469 of the current instance of the participantsession entry 451. Generally, a date and time in the sessionautovalidated field 469 in combination with a date and time in the previoussession autovalidated field 467 and a participantsession identifier in the previoussessionidentifier field 468 (see block 1448) indicates that the host web page access session (represented by the current instance of the participantsession entry 451) was autovalidated by the participant assessment codes 1420 using a previous instance of the participantsession entry 451. The participant assessment codes 1420 then end. However, if the instance of the application entry 311 is an assessment application providing both participant identity verification and participant proctoring services, the participant assessment codes 1420 continue at block 1437 to transmit the current instance of participantsession entry 451 to the reviewer interface 1560 described below.

Identifier and Image Validation Codes Still referring to Figure 53A, if the previous session validation codes 1422 continue as described above to block 1440 and return a“FALSE” value, the participant assessment codes 1420 continue at block 1454 (shown in Figure 53B), which includes codes for directing the assessment server microprocessor 120 to locate and render the current reference image associated with the current instance of the participantsession entry 451. For example, in the embodiment shown, block 1438 includes codes for directing the assessment server microprocessor 120 to (1) identify the instance of the participantdata entry 401 (shown in Figure 12) associated (via an instance of the participant entry 381 and the date and time stored in the created field 418) with the current instance of the participantsession entry 451 and which stores“reference image 1” in the capturetype field 408 and to (2) convert the URI stored in the capturedata field 406 of the instance of the participantdata entry 401 located at step (1) into the current reference image by drawing the URI onto a canvas object.

The participant assessment codes 1420 then continue at the identifier validation codes 1424 and the image validation codes 1426. In the embodiment shown, the participant assessment codes 1420 continue at the identifier validation codes 1424 and the image validation codes 1426 concurrently. In other embodiments, the participant assessment codes 1420 may continue at the identifier validation codes 1424 first and the image validation codes 1426 second, or vice versa. Referring to Figure 53B, the identifier validation codes 1424 generally include codes for directing the assessment server microprocessor 120 to (1) extract a reference identifier from the current reference image and (2) determine whether the extracted reference identifier and the firstname participant identifier and lastname participant identifier stored in the current instance of the participant entry 381 (shown in Figure 11) satisfy an identifier match criterion. More generally, the identifier validation codes 1424 determine whether the first and last names of a participant identification (submitted in the reference image by the participant) and the first and last names in the participant assessment request (submitted by the host) satisfy the identifier match criterion.

The identifier validation codes 1424 begin at block 1456, which includes codes for directing the assessment server microprocessor 120 to extract text from the current reference image. For example, in the embodiment shown, block 1462 includes codes for directing the assessment server microprocessor 120 to (1) submit the current reference image to a third party optical character recognition package, and may use tesseract APIs and libraries, for example and (2) receive a returned text string extracted from the reference image by the third party optical character recognition package as a returned reference identifier.

The identifier validation codes 1424 continue at block 1458, which includes codes for directing the assessment server microprocessor 120 to determine whether returned reference identifier and the firstname participant identifier and the lastname participant identifier stored in the firstnameparticiptantidentifier field 388 and the lastnameparticiptantidentifier field 390 of the current instance of the participant entry 381 (shown in Figure 11) satisfy an identifier match criterion. In the embodiment shown, the identifier match criterion requires an exact match between the reference identifier and the firstname participant identifier and lastname participant identifier, such that the reference identifier includes the firstname participant identifier and lastname participant identifier. In other embodiments, the identifier match criterion may only require a partial match. For example, in the embodiment shown, block 1464 includes codes for directing the assessment server microprocessor 120 to use a regular expression match function to query the returned reference identifier for text values corresponding exactly to the firstname participant identifier and the lastname participant identifier. If the returned reference identifier includes both the firstname participant identifier and the lastname participant identifier, the identifier validation codes 1424 continue at block 1460. Block 1466 includes codes for directing the assessment server microprocessor 120 to return a “TRUE” value. The “TRUE” value represents that the reference identifier extracted from the reference image includes the firstname participant identifier and the lastname participant identifier and more generally represents that the name on the participant identification submitted by the participant matches the name of the participant submitted by the host.

The identifier validation codes 1424 continue at block 1462, which includes codes for directing the assessment server microprocessor 120 to update the current instance of the participantsession entry 451 and to store a current date and time obtained from the clock 122 (shown in Figure 2) in the identifierl autovalidated field 462. The participant assessment codes 1420 continue at block 1464, which includes codes for directing the assessment server microprocessor 120 to wait for an output from the image validation codes 1426. A date and time stored in the identifierl autovalidated field 462 of an instance of the participantsession entry 451 generally functions as an identifier-validated indicator associated with that instance of the participantsession entry 451 .

However, if at block 1458 the returned reference identifier does not include both the firstname participant identifier and the lastname participant identifier, the identifier validation codes 1424 continue at block 1466. Block 1466 includes codes for directing the assessment server microprocessor 120 to determine whether there are any character replacements which can be performed on the returned reference identifier. In this respect, in the embodiment shown, original characters in the returned reference identifier may be replaced by the corresponding replacement character as shown in Table 1 below. These character replacements may represent common errors made by the third party optical character recognition package. Other character replacements may be possible. Table 1.

If a character replacement is possible, the identifier validation codes 1424 continue at block 1468, which includes codes for directing the assessment server microprocessor 120 to perform the letter replacements.

Generally, in the embodiment shown, block 1466 includes codes for directing the assessment server microprocessor 120 determine whether there is an original character in Table 1 which has not been replaced with a corresponding replacement character. If so, block 1466 replaces each and every instance of that original character in the returned reference identifier with a corresponding instance of the replacement character. For example, if block 1466 determines that a“h” to“w” replacement is possible, block 1468 replaces each and every instance of the original character“h” in the returned reference identifier with respective instances of the replacement character“w”; block 1466 may then determine that a“i" to . replacement is possible in a second iteration. However, in other embodiments, block 1466 may instead include codes for directing the assessment server microprocessor 120 to determine whether there is specific instance of an original character in Table 1 which has not been replaced with a specific instance of the corresponding replacement character. If so, block 1466 replaces a first instance of that original character in the returned reference identifier with a corresponding first instance of the replacement character. For example, if block 1466 determines that a first“h” to“w” replacement is possible, block 1468 replaces a first original character“h” in the original returned reference identifier with a corresponding instance of the replacement character “w”; block 1466 may then determine that a second“h” to“w” replacement is possible in a second iteration.

The identifier validation codes 1424 continue at block 1470, which includes codes for directing the assessment server microprocessor 120 determine whether the reference identifier having the replacement characters includes both the firstname participant identifier and the lastname participant identifier. If the reference identifier having the replacement characters includes both the firstname participant identifier and the lastname participant identifier, the identifier validation codes 1424 return to block 1460 to return a “TRUE” value and continue from block 1460 as described above.

However, if the reference identifier having the replacement characters does not include both the firstname participant identifier and the lastname participant identifier, the identifier validation codes 1424 continue at optional block 1474, which includes codes for converting the reference identifier having the replacement characters back to the returned reference identifier returned by the third party optical recognition package at block 1456. The identifier validation codes 1424 then return to block 1466 to determine whether another character replacement is possible. In some embodiments, optional block 1474 is omitted, and each successive character replacement is performed on the reference identifier having replacement characters.

If at block 1466 no further character replacement are possible (such as if all the character replacements in Table 1 above have already been performed by bock 1468), the identifier validation codes 1424 continue at block 1476, which includes codes for directing the assessment server microprocessor 120 to determine whether any processing of the current reference image is possible. Processing the current reference image may increase the accuracy of the text string returned by the third party optical character recognition package. In the embodiment shown, there are two reference image processing steps:

1 . Grayscaling and enlarging the current reference image; and

2. Blurring and two-value bitmapping (also known as “binarizing”) the current reference image.

In other embodiments, there may be additional or alternative reference image processing steps. Further, in other embodiments, each processing component may be an independent reference image processing step, such that grayscaling the reference image may be a first reference image processing step, enlarging the reference image may be a second reference image processing step, blurring the reference image may be a third reference image processing step and binarizing the reference image may be a fourth reference image processing step.

If at block 1476, the first reference image processing step is possible, such as if the current reference image has not yet been grayscaled, enlarged, blurred or binarized, the identifier validation codes 1424 continue at block 1478, which includes codes for directing the assessment server microprocessor 120 to perform the first reference image processing step.

In this respect, block 1478 includes codes for directing the assessment server microprocessor 120 to convert the current reference image into a grayscaled reference image. For example, in the embodiment shown, block 1478 includes code for directing the microprocessor to use a canvas object to render the reference image and use a canvas grayscale filter to calculate a brightness value for each pixel in the current reference image and then to set red, green, and blue values of each pixel equal to the calculated brightness value. Block 1478 also includes codes for directing the assessment server microprocessor 120 to enlarge the current reference image. For example, in the embodiment shown, block 1478 includes codes for directing the assessment server microprocessor 120 to use a canvas object to increase a width of the current reference image by three times an initial width and to increase a length of the current reference image by three times an initial length. The identifier validation codes 1424 continue at block 1480, which includes codes for directing the assessment server microprocessor 120 to extract text from the (now) grayscaled and enlarged reference image as a returned reference identifier using the third party optical character package in a manner similar to block 1462 described above. The identifier validation codes 1424 then return to block 1464 to determine whether the returned reference identifier (now returned from block 1480) includes the firstname participant identifier and the lastname participant identifier and continues from block 1464 as described above (including performing another iteration of character replacements by blocks 1466, 1468 and 1470 as described above if required).

If at block 1476 only the second reference image processing step is possible, such as if the current reference image has already been grayscaled and enlarged, but has not yet been blurred or binarized, the identifier validation codes 1426 continue at block 1482, which includes codes for directing the assessment server microprocessor 120 to perform the second reference image processing step.

In this respect, block 1482 incude codes for directing the assessment server microprocessor 120 to apply a generally Gaussian blur to the current reference image. For example, in the embodiment shown, block 1482 includes codes for directing the assessment server microprocessor 120 to use a canvas object to render the current reference image (now grayscaled and enlarged) and to apply a canvas blur filter to convolute each pixel of the current reference image based on a transformation value provided by a Guassian function. Block 1482 also includes codes for directing the microprocessor to convert the current reference image entirely to a bitmap of only two values (such as black and white for example). For example, in the embodiment shown, block 1482 may include codes for directing the assessment server microprocessor 120 to use a canvas object to render the current reference image (now grayscaled, enlarged and blurred) and then to apply a canvas threshold filter to threshold classify each pixel of the current reference image as either black or white on the basis of a threshold. The threshold may be based on the brightness value of each pixel calculated at block 1478 for example, and any pixel having a brightness value greater than or equal to three may be converted to white while each pixel having a value less than three may be converted to black. The identifier validation codes 1424 then return to block 1480 to extract text from the (now) grayscaled, enlarged, blurred and binarized current reference image as a returned reference identifier using the third party optical character package, and continue from block 1480 as described above. Finally, if at block 1476 no further reference image processing steps are possible, the identifier validation codes 1424 continue at block 1486, which includes codes for directing the assessment server microprocessor 120 to return a“FALSE” value. The “FALSE” value represents that the reference identifier of reference image submitted by the participant could not be validated by the assessment server microprocessor 120 using the firstname and lastname participant identifiers submitted by the host, and more generally represents that the name on the participant identification submitted by the participant may not match the name of the participant submitted by the host. The identifier validation codes 1424 continue at block 1464 described above, which includes codes for directing the assessment server microprocessor 120 to wait for an output from the image validation codes 1426.

Still referring to Figure 53B, the image validation codes 1426 generally include codes for directing the assessment server microprocessor 120 to (1) extract a reference participant image from the current reference image and (2) determine whether the reference participant image and the current participant image satisfy an image match criterion. More generally, image validation codes 1426 determine whether a participant identification (submitted by the participant) and the initial participant image (also submitted by the participant) depict a same individual.

The image validation codes 1426 begin at block 1490, which includes codes for directing the assessment server microprocessor 120 to determine whether a face can be detected in the current reference image. For example, in the embodiment shown, block 1490 may include codes that direct the assessment server microprocessor 120 to use OpenFace APIs and libraries to return a“TRUE” value if a face is detected in the current reference image and to return a“FALSE” value if a face is not detected in the current reference image (similar to the codes of block 1432). If a face is not detected in the current reference image, the image validation codes 1426 continue at block 1492, which includes codes for directing the assessment server microprocessor 120 to add an instance of the participantdataflag entry 511 (shown in Figure 18) to the participantdataflag table 510 (shown in Figure 3). This new instance of the participantdataflag entry 511 stores a participantdata identifier identifying the instance of the participantdata entry 401 storing the current reference image in the participantdataidentifier field 514, stores a flagtype identifier identifying the“clear image of participant identification not provided” instance of the flagtype entry 481 (shown in Figure 15) in the flagtypeidentifier field 516 (such as flagtype identifier“5” for example), and stores a flagstatus identifier identifying the“initiated” instance of the flagstatus entry 501 (shown in Figure 17) in the flagstatusidentifier field 518.

The image validation codes 1426 continue at block 1494 to return a“FALSE” value. The “FALSE” value represents that the assessment server microprocessor 120 could not validate the initial participant image using a reference image of the participant identification submitted by the participant, and more generally represents that the photo on the participant identification submitted by the participant may not depict the same individual as depicted in the initial participant image. The image validation codes 1426 continue at block 1464 described above, which includes codes for directing the assessment server microprocessor 120 to wait for an output from the identifier validation codes 1424.

However, if at block 1490 a face is detected in the current reference image, the detected face is defined as a participant reference image of the current reference image and the image validation codes 1426 continue at block 1496. Block 1496 includes codes for directing the assessment server microprocessor 120 to determine whether the face in the reference participant image and the face in the current initial participant image rendered at block 1430 (shown in Figure 53A) satisfy the image match criterion. Generally, as described above, if the two faces satisfy the image match criterion, the two faces are of the same individual. However, if the two faces do not satisfy the image match criterion, the two faces are not of the same individual. In the embodiment shown, the block 1496 includes codes for directing the assessment server microprocessor 120 to use OpenFace APIs and libraries for example, to compare the face in the reference participant image and the face in the current initial participant image and to return a distance value between 0.00 and 2.00. In the embodiment shown, the image match criterion comprises a distance value of less than 0.99.

If the face in the reference participant image and the face in the current initial participant image do satisfy the match criterion, such as if the distance value returned at block 1494 is less than 0.99 for example, the image validation codes 1426 continue at block 1497, which includes codes for directing the assessment server microprocessor 120 to return a “TRUE” value for the image validation codes 1426. The“TRUE” value represents that the individual in the initial participant image is the same individual as the individual in the participant reference image.

The image validation codes 1426 continue at block 1498, which includes codes for directing the assessment server microprocessor 120 to update the current instance of the participantsession entry 451 and to store a current date and time obtained from the clock 122 (shown in Figure 2) in the image_autovalidated field 460. A date and time stored in the image_autovalidated field 460 of an instance of the participantsession entry 451 generally functions as an image-validated indicator associated with that instance of the participantsession entry 451.

The participant assessment codes 1420 continue at block 1464, which includes codes for directing the assessment server microprocessor 120 to wait for an output from the identifier validation codes 1424.

However, if at block 1496 the face in the reference participant image and the face in the current initial participant image do not satisfy the image match criterion, such as if the distance value returned at block 1496 is greater than, or equal to, 0.99 for example, the image validation codes 1426 continue at block 1494 to a“FALSE” value for the image validation codes 1426 and continue from block 1494 as described above.

Still referring to Figure 53B, the participant assessment codes 1420 include codes for directing the assessment server microprocessor 120 to wait, at block 1464 (1) for block 1460 to return a“TRUE” output value or for block 1486 to return a“FALSE” output value for the identifier validation codes 1424 and (2) for block 1494 to return a“FALSE” output value or for block 1496 to return a“TRUE” output value for the image validation codes 1426. Once an output value has been received from both the identifier validation codes 1424 and the image validation codes 1426, the participant assessment codes 1420 continue at block 1500, which includes codes for directing the assessment server microprocessor 120 to determine whether either the identifier validation codes 1424 or the image validation codes 1426 returned a“FALSE” output value.

If either the identifier validation codes 1424 or the image validation codes 1426 returned a “FALSE” output value, the participant assessment codes 1420 continue at block 1437 (shown in Figure 53A) described above to load the current instance of the participantsession entry 451 to the reviewer interface 1560 described below. The participant assessment codes 1420 then end.

However, if both the identifier validation codes 1424 and the image validation codes 1426 returned a“TRUE” output value, the participant assessment server codes return back to block 1450 (shown in Figure 53A) described above to determine whether the instance of the application entry 311 (shown in Figure 9) is a participant assessment application providing only participant identity verification services or a participant assessment application providing both participant identify verification and participant proctoring services, and continue from block 1450 as described above. Briefly, if block 1452 as described above direct the assessment server microprocessor 120 to store a current date and time obtained from the clock 122 (shown in Figure 2) in the sessionautovalidated field 469 of the current instance of the participantsession entry 451 , a date and time in the sessionautovalidated field 469 in combination with a date and time in the image_autovalidated field 460 and a date and time in the identifierl autovalidated field 462 indicates that that the host web page access session (represented by the current instance of the participantsession entry 451) was autovalidated by the participant assessment codes 1420 using a current initial participant image and a current reference image. The participant assessment codes 1420 then end.

Reviewer Account Page

As described above, the participant assessment codes 1420 include codes for directing the assessment server microprocessor 120 to forward certain instances of the participantsession entry 451 (shown in Figure 13) for review by a human reviewer via the reviewer interface 1560. The reviewer interface 1560 allows a human reviewer to review, and validate or invalidate, a host web page access session of a host web page represented by instances of the participantsession entry 451. The reviewer interface 1560 may be accessed by a reviewer by accessing a reviewer account page using a browser application of the reviewer device 110.

In this respect, and referring back to the login page 560 shown in Figure 20, if the electronic mail address entered in the email input field 562 and the password entered in the password input field 564 is an electronic mail address and a password stored in the email field 194 and the password field 196 of an instance of the user entry 191 (shown in Figure 5), and this instance of the user entry 191 is associated with a“reviewer” roletype indicator, the user login codes 610 direct the user interface codes 530 to direct the browser application of the reviewer device 110 to display the reviewer account page shown generally at 1530 in Figure 54. Referring to Figure 54, the reviewer account page 1530 includes a reviewed session region 1532, a user information region 1534, a change password region 1536, and a review button 1538.

The user information region 1534 and the change password region 1536 are similar to the user information region 624 and the change password region 628 of the host account page 620 (shown in Figure 22) and generally allows the reviewer to update the instance of the userdata entry 161 (shown in Figure 4) and the instance of the user entry 191 (shown in Figure 5) representing the reviewer.

Reviewer Interface

If the reviewer selects the review button 1538, the user interface codes 530 direct the browser application of the reviewer device 110 to display the reviewer interface 1560, an embodiment of which is shown generally in Figure 55.

When the reviewer navigates to the reviewer interface 1560, the user interface codes 530 may present a particular instance of the participantsession entry 451 (forward by block 1437 of the participant assessment codes 1420 (shown in Figure 53A) for example) for review by the reviewer. When a particular instance of the participantsession entry 451 is presented at the reviewer interface 1560, the user interface codes 530 further direct the assessment server microprocessor 120 to update that instance of the participantsession entry 451 (shown in Figure 13) to store a user identifier identifying the instance of the user entry 191 (shown in Figure 5) representing the reviewer in the sessionlocked field 476. This prevents the same instance of the participantsession entry 451 being presented to more than one reviewer.

Referring to Figure 55, the reviewer interface 1560 includes a participant indicator 1561 , a rules region 1562, a participant data region 1564, a participant information button 1587, an add flag button 1584, an edit flag button 1582, a complete review button 1586 and an account button 1588. When the host selects the account button 1588, the user interface codes 530 direct the browser application of the reviewer device 110 to re-display the reviewer account page 1530 shown in Figure 54.

The participant indicator 1561 includes both the firstname participant identifier stored in the firstnameparticiptantidentifier field 388 and the lastname participant identifier stored in lastnameparticiptantidentifier field 390 of an instance of the participant entry 381 identified by the instance of the participantsession entry 451 currently presented at the reviewer interface 1560, and thus displays the firstname participant identifier and the lastname participant identifier submitted by the host using the participant assessment request (see block 1086 and 1090 of the participant data collection server codes 1080 shown in Figure 39).

The rules region 1562 displays to the reviewer rules based on which instances of the flagtype entry 481 (shown in Figure 15) are associated (via an instance of the selectedflagtype entry 491 shown in Figure 16) with an instance of the application entry 311 (shown in Figure 9) identified by the instance of the participant entry 381 (shown in Figure 11) currently displayed at the participant indicator 1561 (and thus also associated with the instance of participantsession entry 451 currently presented at the reviewer interface 1560). More generally, the rules region 1562 displays customized rules of the participant assessment application (represented by an instance of the application entry 311) embedded in the host web page which was accessed by the participant during the host web page access session (represented by the instance of the participant session entry 451) currently presented at the reviewer interface 1560.

As described above, which instances of the flagtype entry 481 are associated with an instance of the application entry 311 is ultimately based on which flags were selected by the host using the selection buttons 696, 698 and 700 of the add application page 670 (shown in Figure 23). For example, in the embodiment of Figure 55, the host only selected selection button 696 of the add application page 670 and thus only the “participant not in view” instance of the flagtype entry 481 is associated (via an instance of the selectedflagtype entry 491) with the instance of the application entry 311 embedded in the host web page. The rule region 1562 thus only displays the rule “Participant must remain in view”.

Referring back to Figure 55, the participant data region 1564 generally allows the reviewer to view participant images stored by corresponding instances of the participantdata entry 401 associated (via an instance of the participant entry 381 and the date and time stored in the created fields 418) with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560.

In embodiments where the instance of the participantsession entry 451 represents a host web page access session of a host web page embedded with a participant assessment application providing only participant identity verification services, there may only be two instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 , namely (1) an instance of the participantdata entry 401 storing the initial participant image and (2) an instance of the participantdata entry 401 storing the reference image. However, in embodiments where the instance of the participantsession entry 451 represents a host web page access session of a host web page embedded with a participant assessment application providing both participant identity verification and participant proctoring services, there may be more than two instances of the participantdata entry 401 associated with that instance of the participantsession entry 451 , such as (1) an instance of the participantdata entry 401 storing the initial participant image, (2) an instance of the participantdata entry 401 storing the reference image and (3) at least one instance of the participantdata entry 401 storing a subsequent participant image.

Further, the participant data region 1564 allows the reviewer to view a single participant image stored by a single instance of the participantdata entry 401 at a time, and further allows the reviewer to navigate to a previous or a next participant image stored by another instance of the participantdata entry 401. The order of the participant images displayed in the participant data region 1564 is based on the date and time stored in the created field 418 of each instance of the participantdata entry 401. For example, a participant image stored by an instance of the participantdata entry 401 which stores 1/20/2018 10:03:02AM in the created field 418 will be positioned before a participant image stored by an instance of the participantdata entry 401 which stores 1/20/2018 10:03:32AM in the created field 418.

Referring now to Figure 55, the participant data region 1564 includes a participant data display 1568, a track bar 1578, a frame number indicator 1573, a previous button 1576, a play button 1579 and a next button 1580.

The participant data display 1568 displays a single instance of the participantdata entry 401. In the embodiment shown, the participant data display 1568 uses a canvas object to render the URI stored the capturedata field 406 to display the participant image stored by the instance of the participantdata entry 401. The participant data display 1568 also includes a“mark as initial participant image” button 1570 described below, a date and time indicator 1572 which displays a date and time stored in the created field 418 of the instance of the participantdata entry 401 , and a capture type indicator which displays a capture type stored in the capturetype field 408 of the instance of the participantdata entry 401.

The frame number indicator 1573 identifies how many instances of the participantdata entry 401 are associated (via an instance of the participant entry 381 and the date and time stored in the created field 418) with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560. The frame number indicator 1573 further indicates a position of the instance of the participantdata entry 401 currently displayed at the participant data display 1568 relative to all other instances of the participantdata entry 401 associated with the instance of the participantsession entry 451. For example, in the embodiment of Figure 55, frame number indicator 1573 displays “1/12”, representing that there are a total of 12 instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560 and that the currently displayed instance of the participantdata entry 401 is the first instance (the“1/12” instance of the participantdata entry 401).

The previous button 1576 and the next button 1580 allow the reviewer to select, respectively, a previous and a next instance of the participantdata entry 401 to display in the participant data display 1568. For example, if the frame number indicator 1573 displays“1/12”, when the reviewer selects the next button 1580, the user interface codes 530 direct the browser application of the reviewer device 110 to render a next participant image stored by a next“2/12” instance of the participantdata entry 401 in the participant data display 1568, to display the date and time stored in the created field 418 of that “2/12” instance in the date and time indicator 1572, to display the capture type stored in the capturedata field 406 of that“2/12” instance in the capture type indicator 1574 and to display“2/12” in the frame number indicator 1573.

The track bar 1578 similarly allows the reviewer to select different instances of the participantdata entry 401 to display in the participant data display 1568. Generally, each increment (not shown) of the track bar 1578 corresponds to an instance of the participantdata entry 401 and the number of increments of the track bar 1578 dynamically varies based on the total number of instances of the participantdata entry 401 associated with the participantsession entry 451 currently presented at the reviewer interface 1560. For example, if there are only two instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 , the track bar 1578 would only include two increments, whereas if there are 12 instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 , the track bar 1578 would include 12 increments. The reviewer may drag the track bar 1578 to a particular increment, which causes the user interface codes 530 to direct the browser application to display the instance of the participantdata entry 401 positioned at that particular increment in the participant data display 1568. For example, in the embodiment of Figure 55, if the reviewer dragged the track bar 1578 to the fourth increment, the user interface codes 530 would direct the browser application of the reviewer device 110 to render a participant image stored by a“4/12” instance of the participantdata entry 401 in the participant data display 1568, to display the date and time stored in the created field 418 of that“4/12” instance in the date and time indicator 1572, to display the capture type stored in the capturedata field 406 of that“4/12” instance in the capture type indicator 1574 and to display“4/12” in the frame number indicator 1573.

The play button 1579 allows the reviewer to rapidly cycle through all subsequent instances of the participantdata entry 401. For example, if the frame number indicator 1573 indicates“1/12”, when the reviewer selects the play button 1579, the user interface codes 530 direct the browser application of the reviewer device 110 to display, in the participant data display frame 1568, the participant image and values stored in the“2/12” instance of the participantdata entry 401 for a display duration, then to display the participant image and values stored in a“3/12” instance of the participantdata entry 401 for the display duration, then to display the participant image and values stored in the “4/12” instance of the participantdata entry 401 for the display duration, and so forth. In the embodiment shown, the display duration is 3 seconds, and one of skill in the art would appreciate that a shorter or a longer display duration may be possible for other embodiments. While the subsequent instances of the participantdata entry 401 are being successively displayed in the participant data display 1568, the reviewer may select the play button 1579 again to stop at particular instance of the participantdata entry 401.

The “mark as initial participant image” button 1570 allows a reviewer to change the capture type stored in the capturetype field 408 of the instance of the participantdata entry 401 currently displayed in the participant data display 1568. For example, in certain situations, an original initial participant image may not provide a clear view of the participant’s face, while a subsequent participant image may provide a clearer view of the participant’s face. The reviewer may navigate, using the previous and next buttons 1576 and 1580, the play button 1579 or the track bar 1578, to a subsequent instance of the participantdata entry 401 storing that subsequent participant image and select the“mark as initial participant image” button 1570. When the reviewer selects the“mark as initial participant image” button 1570, the user interface codes 530 direct the assessment server microprocessor 120 to update the subsequent instance of the participantdata entry 401 to replace “subsequent participant image” with “initial participant image” in the capturetype field 408 for example. This subsequent instance of the participantdata entry 401 will then be ignored by clean session codes 1670 (shown in Figure 2) described below. The participant information button 1587 allow the reviewer to view information associated with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560 and the instance of the participantdata entry 451 currently displayed in the participant data display 1568. When the reviewer selects the participant information button 1587, the user interface codes 530 direct the browser of the reviewer device 110 to display a participant information panel shown generally at 1630 in Figure 56.

Referring to Figure 55, the participant information panel 1630 includes a close button 1632, a tracking field 1634, a browser field 1636, a capture type field 1638, a capture URL field 1640, an IP address field 1642, a resolution field 1644 and a user agent field 1646. When the reviewer selects the close button 1632, the user interface codes 530 direct the browser application of the reviewer device 110 to re-display the reviewer interface 1560 shown in Figure 55.

The tracking field 1634 displays a number of instances of the tracking entry 441 (shown in Figure 14) in the tracking table 440 (shown in Figure 3) identifying the instance of the participantsession entry 451 currently presented at the reviewer interface 1560. Thus, more generally, the tracking field 1634 displays a number of times a participant selected the presence input button 1264 of the presence input panel 1260 (shown in Figure 51).

The remaining fields 1636, 1638, 1640, 1644, 1646 display values from the instance of the participantdata entry 401 currently displayed in the participant data display 1568. In this respect, the browser field 1636 displays the browser type information stored in the browser field 414, the capture type field 1638 displays the description of the capture type stored in the capturetype field 408, the capture URL field 1640 displays the host web page URL stored in the captureURL field 409, the IP address field 1642 displays the IP address stored in the IPaddress field 410, the resolution field 1644 stores the web camera resolution stored in the resolution field 416 and the user agent field 1646 stores the user information associated with the browser application of the participant device 108 stored in the useragent field 412.

Referring back to Figure 55, the add flag button 1584 allows the reviewer to add instances of the participantdataflag entry 511 (shown in Figure 18) identifying the instance of the participantdata entry 401 currently displayed in the participant data display 1568. For example, the reviewer may navigate, using the previous and next buttons 1576 and 1580, the play button 1579 or the track bar 1578, to an instance of the participantdata entry 401 storing a participant image, which may be an initial participant image, a reference image, or a subsequent participant images, including a representation of the participant performing an action or other subject matter that satisfy flag criteria and which the reviewer believes would invalidate the host web page access session of the host web page. The reviewer may the select the add flag button 1584, which cause the user interface codes 530 direct the browser application of the reviewer device 110 to display the add flag panel, an embodiment of which is shown generally at 1600 in Figure 57.

Referring to Figure 57, in the embodiment shown, the add flag panel includes a flag selection list 1602, a comment field 1604, a save button 1606 and a close button 1608. The flag selection list 1602 includes selection options which correspond to each instance of the flagtype entry 481 (shown in Figure 15) in the flagtype table 480 (shown in Figure 3) and generally allows the reviewer to select a flag type based on the representation of the participant performing an action or other subject matter that satisfy flag criteria which is depicted in the participant image currently displayed in the participant data display 1568. In the embodiment shown, the flag selection list allows the reviewer to select a “participant not in view” flag for the“participant not in view” instance of the flagtype entry 481 , a“multiple participants” flag for the“multiple participant” instance of the flagtype entry 481 , a “utilised electronic device/headphones” flag for the “utilised electronic device/headphones” instance of the flagtype entry 481 , an “other” flag for the“other” instance of the flagtype entry 481 , an “clear image of participant identification not provided” flag for the“clear image of participant identification not provided” instance of the flagtype entry 481 , an“clear image of participant not provided” flag for the“clear image of participant not provided” instance of the flagtype entry 481 , an “information unclear” flag for the“information unclear” instance of the flagtype entry 481 , an“identifier does not match” flag for the“identifier does not match” instance of the flagtype entry 481 , a“possible un-ethical behaviour” flag for the“possible un-ethical behaviour” instance of the flagtype entry 481 , and a“non-participation” flag for the“non-participation” instance of the flagtype entry 481.

Generally, some flag types relevant to participant identity will be associated with the initial participant image and the reference image when the initial participant image or the reference image satisfies identity flag criteria, while other flag types relevant to participant proctoring will be associated with subsequent participant images when the subsequent participant image satisfies proctoring flag criteria. However, some flag types can be relevant to both participant identity verification and participant proctoring, and can be associated with the initial participant image, the reference image or the subsequent participant images.

With respect to identity flag criteria, the reviewer may associate the“identifier does not match” flag with a reference image if the reference identifier in the reference image and the participant identifier displayed in the participant indicator 1561 (shown in Figure 56) does not satisfy the identifier match criterion (such as if reference identifier and the participant identifier are not the same, for example). Alternatively, the reviewer may also associate the“identifier does not match” flag with an initial participant image if the initial participant image and the reference participant image does satisfy the image match criterion (such as if initial participant image depicts a different individual than the reference participant image of reference image, for example). Further, the reviewer may associate“clear image of participant identification not provided” flag with a reference image if the reviewer could not read the reference identifier from the reference image (such as if the reference image was too blurry and unfocussed, for example), if the reference image does not include a reference participant image (such as if the reference image was of a participant identification without a photograph), or if the reference image is not a representation of a participant identification for example. The reviewer may also associate the“clear image of participant not provided” flag with an initial participant image if the initial participant image does not include a representation of the participant. Further, the reviewer may also associate the“possible un-ethical behaviour” flag with the initial participant image if the initial participant image includes a representation of an individual represented in another initial participant image of another host web page access session (represented by an instance of the participantsession entry 451 shown in Figure 13) which is associated with the same participant assessment application (represented by an instance of the application entry 311 shown in Figure 9) but which identify different participants (represented by instances of the participant entry 381 shown in Figure 11), indicating that a particular participant may be accessing the host web page on behalf of other participants.

With respect to proctoring flag criteria, the reviewer may associate the“participant not in view” flag with a subsequent participant image if the subsequent participant image does not include a representation of the participant. The reviewer may associate the“utilised electronic device/headphones” flag or the “non-participation” flag with a subsequent participant image if the subsequent participant image includes a representation of the participant using an electronic device such a mobile phone or a tablet computer or of the participant wearing headphones. The reviewer may associate the“multiple participants” flag with a subsequent participant image if the subsequent participant image includes a representation of more than one individual, such as another individual aside from the participant. Alternatively, the reviewer may also associate the “possible un-ethical behaviour” flag with a subsequent participant image if the subsequent participant image includes a representation of another individual and it appears that the other individual is helping the participant during the host web page access session. The reviewer may also associate the“possible un-ethical behaviour” flag with a subsequent participant image if the subsequent participant image incudes a representation of an individual different from the participant depicted in the initial participant image, indicating that another individual participant may be accessing the host web page on behalf of the participant.

Still referring to Figure 57, the comment field 1604 allows the reviewer to input a text string further explaining the flag selected using the flag selection list 1602. In the embodiment shown, the reviewer is required to input the text string explaining the flag, however, in other embodiments, the text string may be optional. When the reviewer selects the save button 1606, the user interface codes 530 transmits the values entered in the flag selection list 1602 and the comment field 1604 to the assessment server microprocessor 120. The assessment server microprocessor 120 then first determines whether a flag type has been selected using the flag selection list 1602 and whether a text string has been entered in the comment field 1604. If either the flag type or the text string has not been entered, the assessment server microprocessor 120 may transmit an error message to the browser application of the reviewer device 110 indicating that additional information such as a flag type or a comment is required for example.

However, if both a flag type and a text string has been entered, the assessment server microprocessor 120 then adds a new instance of the participantdataflag entry 511 (shown in Figure 18) to the participantdataflag table 510 (shown in Figure 3). This new instance of the participantdataflag entry 511 stores a participantdata identifier identifying the instance of the participantdata entry 401 currently displayed in the participant data display 1568 in the participantdataidentifier field 514, stores a flagtype identifier which identifies the instance of the flagtype entry 481 selected using the flag selection list 1602 in the flagtypeidentifier field 516, stores the flagstatus identifier identifying the “initiated” instance of the flagstatus entry 501 in the flagstatusidentifier field 518, stores a user identifier identifying the instance of the user entry 191 (shown in Figure 5) representing the reviewer in the createdbyjdentifier field 524 and stores a current date and time obtained from the clock 122 (shown in Figure 2) in the created field 522. More generally, the assessment server microprocessor 120 adds an“initiated” flag to the instance of the participantdata entry 401 currently displayed in the participant data display 1568.

Alternatively, the reviewer may select the close button 1608 instead of the save button 1606, which causes the user interface codes 530 to direct the browser application of the reviewer device 110 to re-display the reviewer interface 1560 shown in Figure 55.

Referring back to Figure 55, the edit flag button 1582 allows the reviewer to edit any instance of the participantdataflag entry 511 (shown in Figure 18) which identify instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560. When the reviewer selects the edit flag button 1582, the user interface codes 530 direct the browser application of the reviewer device 110 to display an edit flag panel, an embodiment of which is shown generally at 1610 in Figure 58.

Referring to Figure 58, in the embodiment shown, the edit flag panel 1610 includes a flag display region 1612 and a close button 1614. In embodiments where no instance of participantdataflag entry 511 identifies any of the instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560, the flag display region 1612 may display a message“no flags for the session” (not shown). The reviewer may then select the close button 1614, which causes the user interface codes 530 to direct the browser application of the reviewer device 110 to re-display the reviewer interface 1560 shown in Figure 55.

Flowever, in embodiments where there is at least one instance of the participantdataflag entry 511 which identifies at least one of the instances of the participantdata entry 401 associated with the instance of the participantsession entry 451 currently presented at the reviewer interface 1560, the flag display region 1612 displays a respective flag panel 1616 for each instance of the participantdataflag entry 511.

The instance of the participantdataflag entry 511 may have been added by the reviewer using the add flag button 1584 on the reviewer interface 1560 shown in Figure 55. The instance of the participantdataflag entry 511 may have also been added automatically by the assessment server microprocessor 120 during execution of the participant assessment codes 1420 (shown in Figures 53A and 53B), such as by block 1434 or block 1492 for example. As described above, block 1434 of the participant assessment codes 1420 (shown in Figure 53A) may add a new instance of the participantdataflag entry 511 which identifies an instance of the participantdata entry 401 storing an initial participant image and the “clear image of participant not provided” instance of the flagtype entry 481 , whereas block 1492 of the participant assessment codes 1420 (shown in Figure 53B) may add a new instance of the participantdataflag entry 511 which identifies an instance of the participantdata entry 401 storing a reference image and the “clear image of participant identification not provided” instance of the flagtype entry 481. Each flag panel 1616 includes a flag type field 1618, a flag status field 1620, a flag comment field 1622, a view image button 1624, a confirm flag button 1626 and a resolve flag button 1628. The flag type field 1618 displays a description of the instance of the flagtype entry 481 identified by the instance of the participantdataflag entry 511 , the flag status field 1620 displays a name stored in the name field 504 of the instance of the flagstatus entry 501 identified by the instance of the participantdataflag entry 511 and the flag comment field 1622 displays the text string stored in the comment field 520 of the instance of the participantdataflag entry 511. In the embodiment shown, the flag type field 1618 displays“clear image of participant identification not provided”, the flag status field 1620 displays“initiated” and the flag comment field 1622 displays“please present a clear and focused image of your photo ID” for example

Further, as described above, each instance of the participantdataflag entry 511 identifies a particular participant image stored by a particular instance of the participantdata entry 401. The reviewer may select the view image button 1624 of the flag panel 1616 to view that particular participant image. This allows the reviewer to re-examine the participant image before either confirming or resolving the flag. For example, in the embodiment shown, when the reviewer selects the view image button 1624, the user interface codes 530 direct the browser application of the reviewer device 110 to render the URI contained in the capturedata field 406 of the instance of the participantdata entry 401 identified by the instance of the participantdataflag entry 511.

If the reviewer determines that the flag should be confirmed, the reviewer may select the confirm flag button 1626, which causes the user interface codes 530 to direct the assessment server microprocessor 120 to update the flagstatusidentifier field 518 of the instance of the participantdataflag entry 511 to store a flagstatus identifier identifying the “confirmed” instance of the flagstatus entry 501. Alternatively, if the reviewer determines that the flag should be resolved, the reviewer can instead select the resolve flag button 1628, which cause the user interface codes 530 to direct the assessment server microprocessor 120 to update flagstatusidentifier field 518 of the instance of the participantdataflag entry 511 to store a flagstatus identifier identifying the “resolved” instance of the flagstatus entry 501. If the reviewer selects either the confirm flag button 1626 or the resolve flag button 1628, the user interface codes 530 also direct the assessment server microprocessor 120 update the instance of the participantdataflag entry 511 to store a user identifier identifying the instance of the user entry 191 (shown in Figure 5) representing the reviewer in the modifiedbyjdentifier field 528 and to store a current date and time from the clock 122 (shown in Figure 2) in the modified field 526. Referring back to Figure 55, if the reviewer selects the complete review button 1586, the user interface codes 530 direct the assessment server microprocessor 120 to update the instance of the participantsession entry 451 currently presented at the reviewer interface 1560 to store a current date and time obtained from the clock 122 (shown in Figure 2) in the sessionreviewed field 470 and to store a user identifier identifying the instance of the user entry 191 (shown in Figure 5) representing the reviewer in the revieweridentifier field 472. The date and time in the sessionreviewed field 470 indicates that the instance of the participantsession entry 451 has been reviewed and the user identifier in the revieweridentifier field 472 indicates who reviewed the instance of the participantsession entry 451. The assessment server microprocessor 120 is also directed to replace the user identifier stored in the sessionlocked field 476 with“null” to unlock the instance of the participantsession entry 451 from the reviewer.

The user interface codes 530 then determine whether there are any other instances of the participantsession entry 451 which have been forwarded to the reviewer interface 1560 by the participant assessment codes 1420, or should otherwise be presented at the reviewer interface 1560. In the embodiment shown, the user interface codes 530 may direct the assessment server microprocessor 120 to query the participantsession table 450 (shown in Figure 3) to locate instances of the participantsession entry 451 (shown in Figure 13) which have a date and time stored in the sessionend field 458, but have“null” stored in the sessionreviewed field 470,“null” stored in the sessionautovalidated field 469 and“null” stored in the sessionlocked field 476.

If another instance of the participantsession entry 451 is located, the user interface codes 530 direct the browser application of the reviewer device 110 to present this other instance of the participantsession entry 451 in the reviewer interface 1560. However, if no other instance of the participantsession entry 451 can be located, the user interface codes 530 direct the browser application of the reviewer device 110 to display a no session page shown generally at 1650 in Figure 59.

Referring to Figure 59, the no-session page 1650 includes a message region 1652, a reload button 1654, and an account button 1658. The account button 1658 is similar to the account button 1588 of the reviewer interface 1560 shown in Figure 55 described above. The message region 1652 generally displays a message which indicates to the reviewer that no instance of the participantsession entry 451 is available for review.

When the reviewer selects the reload button 1654, the user interface codes 530 direct the assessment server microprocessor 120 to again determine whether there are any other instances of the participantsession entry 451 available for review as described above. Further, while the reviewer remains at the no-session page 1650, the user interface codes 530 may direct the assessment server microprocessor 120 to determine whether any other instances of the participantsession entry 451 are available for review after every review interval. In the embodiment shown, the review interval is every thirty seconds, although in other embodiments, the review interval may be for a shorter or a longer period of time.

Referring back to Figure 54, the reviewed session region 1532 of the host account page 1530 includes a query region shown generally at 1802 and a reviewed sessions table shown generally at 1804. The query region 1802 includes date query lists 1810 and 1812 which can be used to query the reviewed sessions table 1804. The reviewed sessions table 1804 includes a participant identifier column 1820, a participant name column 1822, an application name column 1824, a flag column 1826 and a reviewed date column1828.

After the reviewer has reviewed at least one instance of the participantsession entry 451 (shown in Figure 13), such that the revieweridentifier field 472 of at least one instance of the participantsession entry 451 in the participantsession table 450 (shown in Figure 3) identifies the instance of the user entry 191 representing the reviewer, the reviewed sessions table 1804 displays rows representing these instances of the participantsession entry 451 as shown in Figure 60. Referring to Figure 60, each row represents and displays an instance of the participantsession entry 451. In the embodiment shown, each row displays the participant identifier stored in the participantidentifier field 454 of the instance of the participantsession entry 451 in the participant identifier column 1820, the firstname and lastname participant identifiers stored in the firstnameparticiptantidentifier field 388 and lastnameparticiptantidentifier field 390 of an instance of the participant entry 381 identified by the instance of the participantsession entry 451 in the participant name column 1822, an application name stored in the application name field 315 of an instance of the application entry 311 associated (via an instance of the participant entry 381) with the instance of the participantsession entry 451 in the application name column 1824, a number of instances of participantdataflag entry 511 identifying the instance of the participantsession entry 451 in the flag column 1826 and the date and time stored in the sessionreviewed field 470 of the instance of the participantsession entry 451 in the reviewed date column 1828 The reviewer may search the rows of the session reviewed session table 1804 based on the date displayed in the reviewed date column 1828 using the date query lists 1810 and 1812.

Unlock Session Codes

Referring back to Figure 2, the program memory 128 of the assessment server 102 also includes unlock session codes 1660. The unlock session codes 1660 are illustrated schematically in Figure 61 , and generally include codes for unlocking an instance of the participantsession entry 451 from a reviewer when the reviewer has not interacted with reviewer interface 1560 (shown in Figure 54) presenting that instance of the participantsession entry 451 for a set amount of time. The unlock session codes 1660 execute in response to the user interface codes 530 presenting a particular instance of the participantsession entry 451 for review by a reviewer at the reviewer interface 1560 (shown in Figure 55). As described above, once a particular instance of the participantsession entry 451 is presented at the reviewer interface 1560 to a reviewer, the instance is locked to that reviewer and stores the user identifier identifying the instance of the user entry 191 (shown in Figure 5) representing the reviewer in the sessionlocked field 476 (shown in Figure 12).

The unlock session codes 1660 begin at block 1662, which includes codes for directing the assessment server microprocessor 120 to initiate an unlock timer. In the embodiment shown, the unlock timer is for a period of 30 seconds. However, in other embodiments, the unlock timer may be for a longer or a shorter period of time.

The unlock session codes 1660 continue at block 1664, which includes codes for directing the assessment server microprocessor 120 determine whether an input signal from the browser application of the reviewer device 110 indicating that the reviewer is interacting with the reviewer interface 1560 currently presenting the instance of the participantsession entry 451 has been received before the unlock timer expires. The input signal may be transmitted by the browser application of the reviewer device 110 if the reviewer interacts with the reviewer interface 1560 (shown in Figure 55), the participant information panel 1630 (shown in Figure 56), the add flag panel 1600 (shown in Figure 57) or the edit flag panel 1610 (shown in Figure 58). For example, an input signal may be transmitted by the browser application of the reviewer device 110 if the reviewer selects any of the“mark as initial participant image” button 1570, the track bar 1578, the previous button 1576, the play button 1579, the next button 1580, the participant information button 1587, the add flag button 1584 or the add flag button 1584, and if the participant data display 1568 is cycling through different participant images in response to the reviewer selecting the play button 1579 on the reviewer interface 1560 for example.

If an input signal is received at block 1664, the unlock session codes 1660 return to block 1662 to initiate the unlock timer again, such that the unlock timer is refreshed every time an input signal received at block 1664. If an input signal is consistently received at block 1664, the unlock session codes 1660 then end when the reviewer selects the complete review button 1586 (shown in Figure 55) and the instance of the participantsession entry 451 is no longer locked to the reviewer, as the instance of the participantsession entry 451 now stores“null” in the sessionlocked field 476 as described above.

However, if at block 1664 an input signal is not received and the unlock timer expires, the unlock session codes 1660 continue at block 1668, which includes codes for directing the assessment server microprocessor 120 to update the instance of the participantsession entry 451 to store“null” in the sessionlocked field 476, thereby unlocking the instance of the participantsession entry 451 from a particular reviewer. Block 1668 also includes codes for directing the user interface codes 530 to stop displaying the instance of the participantsession entry 451 in the reviewer interface 1560. The unlock session codes 1660 then end.

Clean Session Codes

Referring back to Figure 2, the program memory 128 of the assessment server 102 also includes clean session codes 1670. The clean session codes 1670 are illustrated schematically in Figure 62, and generally include codes for removing instances of the participantdata entry 401 from the participantdata table 400 (shown in Figure 3) to comply with terms of the assessment provider’s privacy policy and also to more efficiently utilize storage of the application database 150 and the image database 152 (shown in Figure 2). In the embodiment shown, clean session codes 1670 execute every 120 seconds. Flowever, in other embodiments, the clean session codes 1670 may execute after a longer or a shorter period of time.

Referring now to Figure 62, the clean session codes 1670 begin at block 1672, which includes codes for directing the assessment server microprocessor 120 to query the application database 150 to determine whether the participantsession table 450 includes any instances of the participantsession entry 451 which store (1) “null” in the sessioncleaned field 474 and (2) either a date and time in the sessionreviewed field 470 which is equal to or greater than 24 hours from a current date and time obtained from the clock 122 (shown in Figure 2) or a date and time in the sessionautovalidated field 469 which is equal to or greater than 24 hours from a current date and time obtained from the clock 122. If no instances of the participantsession entry 451 are identified, the clean session codes 1670 then end.

Flowever, if at least one instance of the participantsession entry 451 is identified, the clean session codes 1670 continue at block 1674, which includes codes for directing the assessment server microprocessor 120 to return a list of all instances of the participantsession entry 451 identified at block 1672. The clean session codes 1670 continue at block 1675, which includes codes for directing the assessment server microprocessor 120 to determine whether one instance of the participantsession entry 451 from the list returned at block 1674 can be selected. If an instance of the participantsession entry 451 cannot be selected from the list (such as if all instances of the participantsession entry 451 on the list have already be selected and updated as described below), the clean session codes 1670 then end.

However, if an instance of the participantsession entry 451 can be selected from the list, the clean session codes 1670 continue at block 1678, which includes codes for directing the assessment server microprocessor 120 to select an instance of the participantsession entry 451 from the list and to remove that selected instance of the participantsession entry 451 from the list returned at block 1674.

Block 1678 also includes codes for directing the assessment server microprocessor 120 to iterate through all instances of the participantdata entry 401 (shown in Figure 12) associated (via an instance of the participant entry 381 and the date and time stored in the created fields 418) with this selected instance participantsession entry 401 to remove all instances of the participantdata entry 401 which store reference images which are not flagged and which store subsequent participant images which are not flagged, leaving those instances of the participantdata entry 401 which store the initial participant image and which store participant images which have been flagged. For example, in the embodiment shown, block 1678 includes codes for directing the assessment server microprocessor 120 to (1) locate all instances of the participantdata entry 401 which store (a) a participant identifier in the participantidentifier field 404 same as the participant identifier stored in the participantidentifier field 454 of the selected instance of the participantsession entry 451 and (b) a date and time in the created field 418 equal to, or after, the date and time stored in the sessionstart field 456 of the selected instance of the participantsession entry 451 , (2) locate all instances of the participantdataflag entry 511 which store participantdata identifiers identifying any of the instances of the participantdata entry 401 located at step (1) in the participantdataidentifier field 514 and then (3) cycle through all instances of the participantdata entry 401 located at step (1) to delete the instances which store“reference image 1”, “reference image 2”,“reference image 3” or“subsequent participant image” in the capturetype field 408 and which are not identified by any of the instances of the participantdataflag entry 511 located at step (2).

The clean session codes 1670 continue at block 1679, which includes codes for directing the assessment server microprocessor 120 to update the selected instance of the participantsession entry 451 to store a current date and time obtained from the clock 122 (shown in Figure 2) in the sessioncleaned field 474.

The clean session codes 1670 then return to block 1676 to determine whether another instance of the participantsession entry 451 on the list returned at block 1674 can be selected and continue from block 1676 as described above. Assessment Results

Referring back to Figure 33, the program memory 958 of the host server 106 further includes assessment result request codes 1690, which includes codes for directing the host server microprocessor 950 of host server 106 to transmit an assessment results request to the assessment server 102 to request results of the participant assessments performed by a particular assessment application embedded in a host web page.

The assessment results request generally includes information which identifies the instance of the application entry 311 (shown in Figure 9) representing the particular assessment application, and may include the “web page embeddable application” identifier stored in the generatedapplicationidentifier field 334 for example. The assessment results request also includes the APIkey stored in the APIkey field 333 to identify the host server 106 to the assessment server 102 as the calling entity.

The assessment results request may also include parameters for retrieving more specific results. For example, the assessment results request may specify a session start time indicator and a session end time indicator, which requests the assessment server 102 to only retrieve participant assessments of host web page access sessions which have occurred between the session start time and the session end time. The assessment results request may also specify participant identifiers, which requests the assessment server 102 to only retrieve participant assessments of participants identified by those participant identifiers. Referring now to Figure 2, the program memory 128 of the assessment server 102 includes assessment request response codes 1700. The assessment request response codes 1700 are illustrated schematically in Figure 63, and generally include codes for directing the assessment server microprocessor 120 to generate an aggregated assessment results report in response to receiving the assessment results request from the host server 106 and to transmit the aggregated assessment results report to the host server 106. In the embodiment shown, the assessment results response codes 1700 are executed by the assessment server microprocessor 120 in response to receiving the assessment results request from the host server 106. However, in other embodiments, certain blocks of the assessment results response codes 1700 may execute automatically after a specified time interval for example.

Referring to Figure 63, the assessment results response codes 1700 and begin at block 1702, which generally includes codes for directing the assessment server microprocessor 120 to determine whether the application table 310 (shown in Figure 3) contains an instance of the application entry 311 (shown in Figure 9) identified by the assessment results request. In the embodiment shown, block 1702 includes codes for directing the assessment server microprocessor 120 to (1) determine whether there is an instance of the application entry 311 which stores the“web page embeddable application” identifier contained in assessment results request in the generatedapplicationidentifier field 334 and (2) if so, determine whether the APIkey contained in the assessment results request is the APIkey stored in the APIkey field 333 of the instance of the application entry 311 located at step (1).

If no instance of the application entry 311 is identified or if the APIkey in the assessment results request is not the APIkey stored in the APIkey field 333, the assessment results response codes 1700 then end.

However, if an instance of the application entry 311 is found and the APIkey in the assessment results request is the APIkey stored in the APIkey field 333, assessment results response codes 1700 continue at block 1704. Block 1704 includes codes for directing the assessment server microprocessor 120 to (1) locate all instances of the participant entry 381 which stores an application identifier identifying the instance of the application entry 311 (located at block 1702) in the applicationidentifier field 384 and (2) return a list of all instances of the participant entry 381 identified at step (1). In embodiments where the assessment results request contain participant identifiers, block 1702 also includes codes for identifying only instances of the participant entry 381 which store the participant identifiers contained in the assessment results request in the identifier field 382.

The assessment results response codes 1700 continue at block 1706, which includes codes for directing the assessment server microprocessor 120 to determine whether it is possible to an instance of the participant entry 381 from the list returned at block 1704. If it is possible to select an instance of the participant entry 381 from the list, block 1704 includes codes for directing the assessment server microprocessor 120 to select an instance of the participant entry 381 and to remove the selected instance from the list.

The assessment results response codes 1700 continue at block 1708, which includes codes for directing the assessment server microprocessor 120 to iterate through and generate a respective assessment results report for each instance of the participantsession entry 451 (shown in Figure 13) associated with the selected instance of the participant entry 381. Further, in embodiments where the assessment results request contains specific session start and session end times, block 1708 may include codes for only generating assessment results reports for instances of the participantsession entry 451 having dates and times stored in the sessionstart field 456 and the sessionend field 458 falling within the session start indicator and session end indicator contained in the assessment results request.

Each assessment results report thus provides a report for a particular instance of the participantsession entry 451. For example, in one illustrative embodiment, each assessment results report includes the hostparticipant identifier stored in the hostparticipantidentifier field 386 of an instance of the participant entry 381 identified by the particular instance of the participantsession entry 451 (such as

“FlostParticipantldentifier”:"participant@youremail.com" or

“HostParticipantldentifier”:”12345” for example). The assessment results report also includes a session start time and a session end time from the sessionstart field 456 and the sessionend field 458 of the particular instance of participantsession entry 451 (such as "StartDate":"2014-11 -3 06:48:32.322" and "EndDate":"2014-11 -3 07:01 :23.111 " for example).

The assessment results report also includes a host web page URL from the captureURL fields 409 of the instances of the participantdata entry 401 associated (via an instance of the participant entry 381 and the date and time stored in the created field 418) with the particular instance of the participantsession entry 451 (such as "CaptureURLs":"http://www.yourdomain.com/yourpath?yourquerystring" for example). Generally, all instances of the participantdata entry 401 associated with an instance of the participantsession entry 451 store the same host web page URL in their respective captureURL fields 409. However, different assessment results reports for different instances of the participant entry 381 may display different host web page URLs if the participant assessment application is embedded into more than one host web page for example. The assessment results report may also include an indication of a number of instances of the tracking entry 441 identifying the particular instance of the participantsession entry 451 , to indicate how many times the participant selected the presence input button 1264 of the presence input panel 1260 (shown in Figure 51 ). For example, the assessment results report may include "DismissedFaceNotFoundWarningCount": 0 if there are not instances of the tracking entry 441 or "DismissedFaceNotFoundWarningCount": 7 if there are seven instances of the tracking entry 441.

The assessment results report may also include the initial participant image, or a link to the initial participant image, and may include the URI stored in the capturedata field 406 of an instance of the participantdata entry 401 associated with the particular instance of the participantsession entry 451 and which stores “initial participant image” in the capturetype field 408. For example, the assessment results report may display "UserPhotoURL": "https://integrityadvocate.com/Home/Getlmage?id=XXXXXX". This may allow the host to view the initial participant image captured and submitted by the participant to further confirm the identity of the participant. Each assessment results report also includes a session validation indicator, to indicate whether the host web page access session represented by the particular instance of the participantsession entry 451 was valid or invalid. The assessment results report may display (1) an in-progress indicator that the host web page access session is still in progress (such as "Status":"ln Progress" for example), (2) a session validated indicator that the host web page access session was valid (such as "Status":"Valid" for example), or (3) a session invalidated indicator that the host web page access session was invalid (such as "Status":"lnvalid" for example).

In this respect, block 1704 includes codes for directing the assessment server microprocessor 120 to generate the an in-progress indicator for the assessment results report if the particular instance of the participantsession entry 451 (shown in Figure 13) stores“null” in the sessionautovalidated field 469 and“null” in the sessionreviewed field 470, indicating that the host web page access session (represented by the particular instance of the participantsession entry 451) has not been (or could not be) validated by the assessment server microprocessor 120 using the participant assessment codes 1420 (shown in Figure 53A and 59B) and has not yet been reviewed by a reviewer using the reviewer interface 1560 (shown in Figure 55).

Block 1704 also includes codes for directing the assessment server microprocessor 120 to generate the session validated indicator if the particular instance of the participantsession entry 451 (shown in Figure 13) stores a date and time in the sessionautovalidated field 469. This indicates that the host web page access session (represented by the particular instance of the participantsession entry 451) was validated automatically by the assessment server microprocessor 120 using the participant assessment codes 1420 (shown in Figure 53A and 53B).

Alternatively, block 1704 also includes codes for directing the assessment server microprocessor 120 to generate the session validated indicator if (a) the particular instance of the participantsession entry 451 stores a date and time in the sessionreviewed field 470 and (b) the instances of the participantdata entry 401 (shown in Figure 12) associated with the instance of the participantsession entry 451 are not identified by any instances of the participantdataflag entry 511 (shown in Figure 18) which identify the“confirmed” instance or the“initiated” instance of the flagstatus entry 501 (shown in Figure 17) in the flagstatusidentifier field 518. This indicates that the particular instance of the participantsession entry 451 has been reviewed by a reviewer using the reviewer interface 1560 (shown in Figure 55) and the reviewer has either not added any flags identifying the instances of the participantdata entry 401 associated with the particular instance of the participantsession entry 451 and/or the reviewer has resolved flags identifying the instances of the participantdata entry 401 associated with the instance of the participantsession entry 451. More generally, block 1704 incudes codes for directing the assessment server microprocessor 120 to generate the session validated indicator when there are no flags associated with the participant images (represented by the instances of the participantdata entry 401) of the host web page access session (represented by the particular instance of the participantsession entry 451), or when only “resolved” flags are associated with the participant images of the host web page access session.

Block 1704 also includes codes for directing the assessment server microprocessor 120 to generate the session invalid indicator if (1) the particular instance of the participantsession entry 451 stores“null” in the sessionautovalidated field 469 and stores a date and time in the sessionreviewed field 470, and (2) at least one instance of the participantdata entry 401 associated with the instance of the participantsession entry 451 is identified by an instance of the participantdataflag entry 511 (shown in Figure 18) which identify the“confirmed” instance or the“initiated” instance of the flagstatus entry 501 (shown in Figure 17) in the flagstatusidentifier field 518. This indicates that the particular instance of the participantsession entry 451 has been reviewed by a reviewer using the reviewer interface 1560 (shown in Figure 55) and the reviewer has either confirmed or failed to resolve flags identifying instances of the participantdata entry 401 associated with the particular instance of the participantsession entry 451. More generally, block 1704 incudes codes for directing the assessment server microprocessor 120 to generate the session invalidated indicator when there are either“confirmed” or“initiated” flags associated with participant images (represented by instances of the participantdata entry 401) of the host web page access session (represented by the particular instance of the participantsession entry 451). If the particular instance of the participantsession entry 451 is associated with instance(s) of the participantdataflag entry 511 representing “confirmed” or “initiated” flags, the assessment results report also includes values stored by the instance(s) of the participantdataflag entry 511. For example, the assessment results report may include a flag portion for each instance of the participantdataflag entry 511. The flag portion may include: a flagtype identifier stored in the flagtypeidentifier field 516 and a flag name stored in the name field 484 of an instance of the flagtype entry 481 (shown in Figure 15) identified the instance of the participantdataflag entry 511 (such as "Flagld": 5, "FlagName": "Participant not in camera view" for example); and a flag comment stored in the comment field 520 of the instance of the participantdataflag entry 511 (such as "FlagDetails": "Participant left computer immediately after ID verification." for example).

The flag portion may also include the participant image, or a link to the participant image, stored by the instance of the participantdata entry 401 identified by the instance of the participantdataflag entry 511. For example, the assessment results report may include the URI stored in the capturedata field 406 of that instance of the participantdata entry 401 (such as "ImageUrl": "https://integrityadvocate.com/Plome/Getlmage?id=XXXXXX" for example). This may allow the host to view the participant image identified by the “confirmed” flag or“initiated” flag to determine whether the flag was warranted and should in fact invalidate the host web page access session.

The assessment results response codes 1700 then return to block 1706 to determine whether another instance of the participant entry 381 can be selected from the list returned at block 1706 and continue from block 1706 as described above.

If at block 1706 another instance of the participant entry 381 cannot be selected from the list returned at block 1704, the assessment results response codes 1700 continue at block 1710, which includes codes for directing the assessment server microprocessor 120 to aggregate all assessment results reports generated at block 1708 into an aggregated assessment results report. The aggregated assessment results report may further include a session number indicator representing a number of the assessment results reports contained in the aggregated assessment results report (such as "SessionCount":15 for example). The aggregated assessment results report may also include a current date and time obtained from the clock 122 (shown in Figure 2) (such "RequestDate":"2014-11-18 14:57:27.850” for example) which represents when the aggregated assessment results report was generated.

The assessment results response codes 1700 continue at block 1712 which includes codes for directing the assessment server microprocessor 120 to transmit the aggregated assessment results report to the host server 106. The assessment results response codes 1700 then end.

Host Account Page

In certain situations, the host may utilize the assessment results region 622 of the host account page 620 (shown in Figure 22) to directly view results of participant assessments rather than making an assessment results request to the assessment server 102 using the host server 106 as described above. Referring back to Figure 22, the assessment results region 622 includes a query region shown generally at 1722, and an assessment results table shown generally at 1724. The query region 1722 includes a number of query fields, including a last name query field 1730, an application query field 1732, a participant identifier query field 1734, a flag query list 1736, and date query lists 1738 and 1740. The assessment results table 1724 includes a participant column 1750, an application name column 1752, a created column 1754, and a flag column 1756. After an instance of the participant entry 381 associated (via an instance of the application entry 311 (shown in Figure 9) for example) with the instance of the user entry 191 representing the host is added to the participant table 380 (shown in Figure 3), the assessment results table 1724 is populated to include a row representing the instance of the participant entry 381. If there is more than instance of the participant entry 381 associated with the instance of the user entry 191 representing the host, the assessment results table 1724 may include a respective row representing each such instance of the participant entry 381. A populated embodiment of the assessment results table 1724 is shown in Figure 64. Referring to Figure 64, a row representing an instance of the participant entry 381 displays: the firstname identifier stored in the firstnameparticiptantidentifier field 388, the lastname identifier stored in the lastnameparticiptantidentifier field 390, the identifier stored in the identifier field 382 and the hostparticipant identifier stored in the hostparticipantidentifier field 386 of that instance of the participant entry 381 in the participant column 1750 (“Smith, John; participant identifier:12345; identifierabcde” in a row 1760 shown); the application name of an instance of the application entry 311 identified by that instance of the participant entry 381 in the application name column 1752 (“Webinar 1 and Webinar2 Participant Assessment” in the row 1760 shown); the date and time stored in the created field 392 of that instance of the participant entry 381 in the created column 1754 , and a number of instances of the participantdataflag entry 511 (shown in Figure 18) which are associated (via an instance of the participantdata entry 401) with that instance of the participant entry 380 in the flags column 1756.

Each row representing an instance of the participant entry 381 also includes a detail button 1762. If the host selects the detail button 1762, the user interface codes 530 direct the browser application of the host device 104 to display an expanded row, an embodiment of which is shown generally in Figure 65.

Referring now to Figure 65, the expanded version of the row 1760 now display further nested rows each representing a respective instance of the participantsession entry 451 which identifies the instance of the participant entry 381 represented by row 1760. In the embodiment shown, there are three nested rows 1770, 1772, and 1774, indicating that three instances of the participantsession entry 451 identifies the instance of the participant entry 381 represented by row 1760. Nested row 1770 will now be described in detail, with the understanding that other nested rows 1772 and 1174 include similar features.

The nested row 1770 includes a session start time and session end time indicator 1780, an initial participant image display 1782, a tracking number indicator 1786, and a flag region 1784. The session start time and session end time indicator 1780 generally displays the date and time stored in the sessionstart field 456 and the sessionend field 458 of the instance of the participantsession entry 451 represented by the nested row

1770.

The initial participant image display 1782 renders the initial participant image stored by an instance of the participantdata entry 401 associated (via the instance of the participant entry 381 and also via the date and time stored in the created field 418) with the participantsession entry 451 represented by the nested row 1770 and which also stores “initial participant image” in the capturedata field 406. For example, the initial participant image display region 1782 may include a canvas object to render the URI stored in the capturedata field 406 of that instance of the participantdata entry 401. This may allow the host to easily visually confirm the identity of the participant.

The tracking number indicator 1786 displays a number of instances of the tracking entry 441 (shown in Figure 14) identifying the instance of the participantsession entry 451 represented by the nested row 1770. Thus, more generally, the tracking number indicator 1768 displays a number of times a participant selected the presence input button 1264 of the presence input panel 1260 (shown in Figure 51)

The flag region 1784 displays instances of the participantdataflag entry 511 which are associated (via an instance of the participantdata entry 401) with the instance of the participantsession entry 451 represented by the nested row 1770. In the embodiment shown, only instances of the participantdataflag entry 511 identifying the“confirmed” or “initiated” instance of the flagstatus entry 501 (shown in Figure 17) in the flagstatusidentifier field 518 are displayed in the flag region 1784.

In the embodiment of Figure 65, there are no instances of the participantdataflag entry 511 associated with the instance of the participantsession entry 451 represented by the nested row 1770, and accordingly, the flag region 1784 does not display any flags. Generally, no flags displayed in the flag region 1784 functions as a session-validated indicator associated with the instance of the participantsession entry 451.

In embodiments where an instance of the participantdataflag entry 511 is associated with the instance of the participantsession entry 451 , the flag region 1784 may display: a flag name stored in the name field 484 of an instance of the flagtype entry 481 identified by the instance of the participantdataflag entry 511 (such as“Flag: clear image of ID not provided” for example); and a flag comment stored in the comment field 520 of the instance of the participantdataflag entry 511 (such as“Details: ID is too blurry to be readable” for example). The flag region 1784 may also render the participant image stored by the instance of the participantdata entry 401 identified by instance of the participantdataflag entry 511 , and may include a canvas object to render the URI stored in the capturedata field 406 of that instance of the participantdata entry 401 for example. This may allow the host to view the specific participant image flagged to determine whether the flag is warranted. Generally, flags displayed in the flag region 1784 functions as a session-invalidated indicator associated with the instance of the participantsession entry 451.

Referring back to Figure 64, the host may filter the rows representing instances of the participant entry 381 displayed in the assessment results table 1724 (1) by lastname participant identifier stored in the lastnameparticiptantidentifier fields 390 of the instances of the participant entry 381 using in the last name query field 1730, (2) by application name of instances of the application entry 311 identified by the instances of the participant entry 381 using the application query field 1732, (3) by participantidentifier stored in the participantidentifier fields 386 of the instances of the participant entry 381 using in participant identifier query field 1734 and (4) by flagtype identifier of the instances of the participantdataflag entry 510 associated (via instances of the participantdata entry 401) with the instances of the participant entry 381 using the flag query list 1736, or (5) by created date stored in the created field 392 of the instances of the participant entry 381 using the date query lists 1738 and 1740.

While specific embodiments have been described and illustrated, such embodiments should be considered illustrative of the subject matter described herein and not as limiting the claims as construed in accordance with the relevant jurisprudence.

Claims

EMBODIMENTS IN WHICH AN EXCLUSIVE PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:

1. A method of assessing a participant taking part in accessing a host web page, the method comprising: causing at least one processor to receive, from a participant device, host identifying information identifying the host web page and a participant identifier identifying the participant when the participant device accesses the host web page; causing the at least one processor to determine whether the host identifying information is associated with an application entry stored in an application table; when the host identifying information is associated with the application entry, causing the at least one processor to at least: receive a reference image and an initial participant image from the participant device, wherein the reference image depicts a reference identifier and a reference participant image; associate the participant identifier, the reference image and the initial participant image with a session entry stored in an session table, the session entry representing a host web page access session associated with the participant; associate an identifier-validated indicator with the session entry when the reference identifier and the participant identifier satisfy an identifier match criterion; and associate an image-validated indicator with the session entry when the reference participant image and the initial participant image satisfy an image match criterion.

2. The method of claim 1 , further comprising causing the at least one processor to: extract the reference identifier from the reference image; and determine whether the reference identifier and the participant identifier satisfy the identifier match criterion.

3. The method of claim 2 further comprising, when the reference identifier and the participant identifier do not satisfy the identifier match criterion, causing the at least one processor to: enlarge the reference image and convert the reference image into a grayscale image; re-extract the reference identifier from the enlarged and converted reference image; and determine whether the re-extracted reference identifier and the participant identifier satisfy the identifier match criterion.

4. The method of claim 2 or 3 further comprising, when the reference identifier and the participant identifier do not satisfy the identifier match criterion, causing the at least one processor to: smooth the reference image and binarize the reference image; re-extract the reference identifier from the smoothed and binarized reference image; and determine whether the re-extracted reference identifier and the participant identifier satisfy the identifier match criterion.

5. The method of any one of claims 1 to 4 further comprising causing the at least one processor to: associate a first flag with the reference image when the reference image satisfies identity flag criteria; and associate a second flag with the initial participant image when the initial participant image satisfies the identity flag criteria.

6. The method of claim 5 wherein the identity flag criteria comprises at least one of: the reference identifier and the participant identifier do not satisfy the identifier match criterion; the reference identifier could not be extracted from the reference image; the reference image does not include the reference participant image; the initial participant image and the reference participant image does not satisfy the image match criterion; and the initial participant image does not include a representation of the participant.

7. The method of claim 5 or 6 further comprising causing the at least one processor to associate a session-validated indicator with the session entry when no flags are associated with the reference image or the initial participant image.

8. The method of claim 5 or 6 further comprising causing the at least one processor to associate a session-validated indicator with the session entry when all flags associated with the reference image and all flags associated with the initial participant image are resolved.

9. The method of claim 7 or 8 further comprising causing the at least one processor to transmit the session-validated indicator associated with the session entry to a host operating the host web page.

10. The method of any one of claims 1 to 9 wherein the application entry is associated with a participant proctoring service indicator.

11. The method of claim 10 further comprising, when the application entry is associated with a participant proctoring service indicator, causing the at least one processor to: periodically receive, from the participant device over a session period of host web page access session associated with the participant, at least one subsequent participant image; and associate the at least one subsequent participant images with the session entry.

12. The method of claim 11 further comprising causing the at least one processor to associate the at least one subsequent participant image with a further image flag if the at least one subsequent participant image satisfies proctoring flag criteria.

13. The method of claim 12, wherein the proctoring flag criteria comprises at least one of: the at least one subsequent participant image does not include a representation of the participant; the at least one subsequent participant image includes a representation of the participant using an electronic device; the at least one subsequent participant image includes a representation of the participant using headphones; the at least one subsequent participant image includes a representation of more than one individual; the at least one subsequent participant image includes a representation of unethical behaviour; and the at least one subsequent participant image includes a representation of lack of participation.

14. The method of any one of claims 10 to 13 further comprising, when the application entry is associated with a participant proctoring service indicator, causing the at least one processor to: transmit to the participant device computer codes which, when executed by the participant device, cause the participant device to detect whether a portion of the participant is within a field of view of a camera associated with the participant device.

15. The method of claim 14 wherein the computer codes, when executed by the participant device, further cause the participant device to prompt the participant for presence input when the portion of the participant is outside the field of view of the camera for a period of time.

16. The method of claim 16 wherein the computer codes, when executed by the participant device, cause the participant device to terminate the host web page access session associated with the participant if the participant does not provide the presence input.

17. The method of any one of claims 1 to 16 further comprising, when the host identifying information is determined to be associated with the application entry causing the at least one processor to: transmit to the participant device, computer codes which, when executed by the participant device, cause the participant device to effect a participant data collection interface on the participant device, the participant data collection interface allowing the participant to capture the reference image and the initial participant image and transmit the captured reference image and the captured initial participant image to the at least one processor.

18. The method of any one of claims 1 to 17, further comprising causing the at least one processor to assess the participant taking part in accessing a second host web page by: causing the at least one processor to receive, from the second host web page when the participant device or another participant device associated with the participant accesses the second host web page, a current participant identifier identifying the participant; causing the at least one processor to determine, using at least the current participant identifier, whether the participant is associated with an previous session entry stored in the session table, wherein the previous session entry includes a validated previous participant identifier and a validated previous initial participant image; when the participant is determined to be associated with the previous session entry, causing the at least one processor to: receive a current initial participant image from the participant device or the another participant device; associate the current participant identifier and the current initial participant image with a current session entry representing a current host web page access session associated with the participant; and associate a previous-session-validated indicator with the current session entry when the current initial participant image and the validated previous initial participant image satisfy the image match criterion.

19. The method of claim 18, wherein causing the at least one processor to determine whether the participant is associated with the previous session entry comprises causing the at least one processor to determine whether the current participant identifier and the validated previous participant identifier satisfy the identifier match criterion.

20. The method of claim 18 or 19 further comprising causing the at least one processor to associate the current session entry with the previous session entry when the current initial participant image and the validated previous initial image satisfy the image match criterion.

21. The method of any one of claims 18 to 20, wherein the validated previous participant identifier and a previous reference identifier of a previous reference image was determined to satisfy the identifier match criterion and the validated previous initial participant image and a previous reference participant image of the previous reference image was determined to satisfy the image match criterion.

22. A method of configuring a host web page, the method comprising: embedding a script element into the host web page, the script element including host identifying information identifying the host web page, a participant identifier identifying a participant taking part in accessing the host web page, and a location of non-transitory instructions which, when executed by at least one processor, directs the at least one processor to perform the method of any one of claims 1 to 21 , the script element further including code for directing a participant device associated with the participant to transmit the host identifying information and the participant identifier to the at least one processor and to cause the at least one processor to execute the non-transitory instructions, such that when the participant device accesses the host web page and processes the script element, the participant device transmits the host identifying information and the participant identifier to the at least one processor and causes the at least one processor to execute the non- transitory instructions.

23. A system comprising a computer readable medium storing non-transitory instructions, which, when executed by the at least one processor, cause the at least one processor to execute the method of any one of claims 1 to 21.