SYSTEMS AND METHODS FOR DYNAMIC MONITORING OF TEST TAKING

Abstract

A system and process for dynamic security monitoring of test taking. The system combines historical information about the test taker or relevant conditions, and includes sensors which objectively monitor test taker's actions, inactions, and involuntary response to the test given before and during the test, and at a specific test location. The information collected from the sensors is compared to a plurality of predetermined individual risk factors, which indicate a possibility of test fraud by the individual test taker to create a test event risk profile. The individual risk profile is combined with non-individual specific risk factors to create a holistic test event security profile. Security resources are then dynamically assigned to or removed from the test event based on the unique test event security profile.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application claims the priority and benefit of U.S. Provisional Patent Application Ser. No. 62/660,563, titled “Systems and Methods for Dynamic Monitoring of Test Taking,” filed on Apr. 20, 2018, the entirety of which is incorporated herein by reference.

FIELD OF THE INVENTION

The present disclosure relates to a system and device to verify identity, verify presence, and verify compliance with rules of behavior in a test session or a remote test session.

BACKGROUND

Today, high-stakes or low-stakes test are delivered, presented or administered to test takers, whether students, prospective students, workers or prospective workers, usually using computers (laptops, desktops, tablets, smartphones, and others). Some tests, however, are still administered by paper and pencil. This invention would apply to those tests as well, but, due to its dynamic nature, the invention is better suited for administering computerized exams. This invention applies to all tests, however designed, created, administered or used.

The dominant requirement of such testing, particularly high-stakes tests (e.g., MCATs, SATs, college course exams, certification exams, employment and pre-employment tests, personality tests, and others), is to make sure there is enough security in place so that the risk associated with test fraud—cheating and test theft—is greatly reduced. If such test fraud is allowed, then the test scores cannot be used for the purposes designed (e.g., certification of skills, academic achievement, academic potential, etc.). Security can take many forms, but the one used ubiquitously is proctoring, or monitoring of test takers during a test session. The purpose of such monitoring is to detect cheating and/or test theft, or to deter such behavior. However, other security measures are possible. For example, the design of items and tests can reduce exposure and increase unpredictability so that test takers will be less motivated to harvest or steal content, or to use such information to cheat. Other security measures are used to deter test takers from such fraud by informing them of security rules and punishments, and by having them sign non-disclosure agreements, oaths or honor codes.

A test event is defined as a test taker taking or sitting for a test. One established fact about the current test administration process is that proctoring or monitoring security procedures are applied to all test events more or less equally. Test administration rules are usually clear as to the number of human monitors to be used based on the number of test takers in the room. This applies to testing centers and other locations (for example, gymnasiums for Saturday SAT testing) and to online monitoring. No effort is ever made to evaluate the risk of a specific test event, meaning the risk individual test takers and their circumstances pose to test security. This is because, before and during test administration, no data about the test event (including information about the tests, locations, test takers, testing history, new threats, and many more) is gathered or used. Heightened security procedures, designed for the group of test takers, are used almost by default and are universally deployed for all types of test events. Another way to state this is all test takers are monitored the same way whether individual test takers commit or intend to commit, or are even able to commit different types of test fraud (cheating or test theft). It is clear that such gross and universal security deployment is more expensive than it should be and is not the best allocation of resources.

Security is expensive, usually involving the labor of humans, as previously mentioned. Proctors are humans tasked with: (1) monitoring test takers during test administration, and (2) also authenticating each test taker to make sure he or she is the person who is supposed to take the test. For the latter, official ID's are checked, or some other biometric may be used. It is accepted that the cost of proctoring is the major expense of virtually all test administrations. Test administration costs (not pricing or fees for a test) per test event typically range from $20 to $50 depending on several factors (e.g., proctor wages, number of simultaneous test events, the cost of location, etc.). Personal cost factors such as the time/cost for test taker travel, parking costs, etc., are not considered in these estimates, they are add-on costs. Pricing for such tests is then applied providing a margin covering costs for the development of the tests, sales and marketing, profit, and other incidentals. Test administration is considered to be expensive today, and human-based security efforts are a large part of that expense.

If the labor costs of proctors can be reduced, then test administration becomes more affordable to all and accessible to those currently unable to afford tests. If the costs can be reduced while at the same time increasing the effectiveness of test security, then tests can be administered in homes, workplaces, and in countries where test security risks are currently too high or where test administration costs are too prohibitive. With such flexibility in testing locations, personal costs of travel time/cost, parking, etc., will be reduced as well.

Currently, test administration models have at least three significant and recognized security flaws.

First, current test administration models, whether physical or online, rely heavily on engaged human proctors. The number of test takers that a proctor may reasonably oversee is limited. As a result, such proctoring may unnecessarily inflate the cost and pricing of the test event as the proctors are used to oversee a large number of test takers, many or most of which have no intention of cheating or stealing the test content. For that likely majority, the cost of human proctors is completely wasted, and unnecessary for security or other reasons. Furthermore, as the proctors are human, they may be: (1) susceptible to bribery and conflicts of interest, (2) disinclined to monitor closely or well, (3) may shy away from confronting a person when fraud is actually observed, or (4) may have discriminatory biases towards one race, sex, gender, nationality, etc.

Second, test administration is unreasonably tied to set locations, such as an established testing center, a school classroom, or gymnasium. These testing locations are often themselves a source of security problems, as they do not support objective, un-biased monitoring. Indeed, proctors are rarely able to reasonably observe all the test takers all the time. Additionally, for some disabled test takers, anchoring the test to a single location may add an unreasonable burden (e.g., the location may not be ADA accessible). In addition, test takers who live in remote locations may not be able to travel to a designated testing center. Citizens of some countries cannot afford test administration fees of current systems let alone travel and parking expenses. Indeed, a test administration services vendor, in order to make a profit, especially in a difficult-to-service country, may have to charge as much as double or triple the retail price of a test. However, in those countries, often third-world countries, the most that a test taker may be able to afford would be a small fraction of the test price. Such financial pressures make it difficult to currently provide the highest quality security offered today in the United States worldwide.

Third, technology used for cheating is becoming harder to detect by human observation. For example, the new technology behind hideable, wearable, high-resolution, so-called “spy” cameras, makes it difficult, even impossible for a proctor to prevent or even detect the accurate theft of any test's entire content. Likewise, wireless ear pieces permitting the test taker to communicate with a third party outside the testing center continue to shrink to the point that the presence of such ear pieces could only be identified with the assistance of visually-enhanced images and invasive searches.

The description of the prior art provided in this disclosure highlights the unmet needs for a test monitoring system and method that: (a) evaluates the amount and type of security risk for individual test events; (b) allows the monitoring to be targeted, competent, remote and objective; (c) is flexible so as to permit the test event to occur in additional hard-to-reach and hard-to-service remote locations; (d) includes additional capability to assist in detecting and preventing the use of technology to cheat or steal test content; and (e) is affordable for all.

SUMMARY

The invention provides solutions to meet the needs in the industry for test monitoring systems and methods. Generally, the solutions include, but are not limited to, the following benefits: (i) the ability to take a variety of factors before and during an exam, and use the factors to calculate initial risk, continuously evaluate risk in real-time, and then act on that risk in real-time; (ii) the use of cloud-based computer system(s) to send and receive risk-related information continuously in real time; (iii) implementation of statistically-based risk analytics, or any formal risk analytics; (iv) the ability to dynamically allocate security resources, depending on a current risk analysis level; (v) validate security of an exam event following conclusion of the test; and (vi) use item and test design features as factors to modify the risk analysis. These and other solutions are provided by the invention.

Illustrative and alternative embodiments of a computer-based test monitoring platform are described in detail with reference made to the figures of this application. The platform is configured to evaluate test security risk and to provide a competent, efficient, and secure monitoring system. The system includes additional detection and prevention tools to assist in monitoring or proctoring, as well as to identify and prevent cheating and theft. The platform is adaptable so that a test can be administered through a telecommunications network to a computer in a remote location.

In an exemplary, non-limiting embodiment, the system of the invention comprises a computer processor, at least one storage device configured to store collected data and to recall the stored data, one or more sensors configured to monitor specific risks, a risk analysis and management tool, an applicant file, and a location file. The system is configured to permit a test taker to sign into his/her account using unique identifying credentials, which provide access to the system so that the system can electronically administer a test that the test taker will be taking. The system can include at least one authentication sensor used to verify the identity of the test taker before and during test administration. The system is configured for risk analysis management to determine the test-taker's security profile for the initial level of monitoring, which can include proctors and automated sensors. Then, test administration begins. During the test, one or more sensors used for security detection continuously monitor the test taker and record the occurrence of any threats in the files of the system. All testing events are managed by the risk analysis tool that creates the test taker's unique security profile, evaluates known risks and indicates a security threat (e.g., cheating). The test-taker's security profile can change at any time during testing, depending on the specific threats detected. The test taker's security profile is continuously compared to threshold risk profiles stored in the system. Security resources are then allocated based on the comparison of the test-taker's security profile to the threshold risk profiles. In one non-limiting embodiment, when the test-taker's security profile risk is higher than the threshold risk profile, the test taker may be required to be instantly monitored one-on-one by a proctor. Conversely, if the test-taker's security profile is below the threshold risk profile, the test taker can be monitored by automated monitoring sensors or by human proctors who may also be monitoring other test takers.

The test-taker's security profile can be constructed from a plurality of events that occur during testing. For each characteristic of the test event captured by one or more sensors of the system, the processor calls up predetermined individual risk factors, previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author, and current security profile, to update the test-taker's security profile. The adjusted profile may indicate a higher risk of test fraud by the individual test taker. The processor then compares the adjusted profile of the individual to the security thresholds to determine if there is a match within a range of tolerance. This comparison can be noted in the applicant's file and/or the test file. The processor, at set intervals or continuously, uses the result of the comparison of the applicant's file to previously uploaded threshold levels to dynamically allocate changes in security directed towards the test-taker. For low-risk test taker security profiles, the system can indicate continued automatic monitoring by the sensors. If the profile indicates the highest-risk situation, the system can transmit a notification to a human proctor who can review the event, intervene if necessary and closely monitor the test taker one-on-one. The system can have multiple monitoring levels available, which can be applied to various levels of test-taker security risk profiles.

The method and non-transitory computer readable medium integrated within the system comprises the steps of confirming that a test taker is authenticated to take a test, creating an initial security risk profile from available data for the test taker, and then assigning a security monitoring level, ranging from minimal and automated monitoring to one-on-one human monitoring. The method and non-transitory computer readable medium integrated within the system comprises further the steps of monitoring actions of the test taker at set intervals or continuously to identify relevant test security occurrences during testing. The method and non-transitory computer readable medium comprises the step of comparing identified security events to a plurality of predetermined individual risk factors, which are used to indicate a (1) risk of test fraud, cheating or theft, by the individual test taker, (2) a location risk factor based on the test location, and (3) an overall individual risk level. The method and non-transitory computer readable medium comprises the step of comparing the individual security risk profile to the threshold risk levels to dynamically assign the security measures to be assigned to the test taker (e.g., computer monitoring, additional forensics analysis, stopping/pausing the test, in person monitoring, etc.). Finally, if the individual's security profile is above or below the current threshold risk level, the method and non-transitory computer readable medium comprises the step of creating, with a software application, a log, and then tracking and storing the information that comprises and is used to determine changes in the security profile. A proctor can review the information generated by the method and non-transitory computer readable medium execute remedial action, as necessary.

BRIEF DESCRIPTION OF THE FIGURES

Additional aspects, features and advantages of the invention, as to its method and system, structure, components, configuration, functionality, and operability will be understood and become more readily apparent when the invention is considered in light of the following description of figures made in conjunction with the accompanying drawings, wherein:

FIG. 1 shows an illustration of the flow of information between components of the system of the invention.

FIG. 2 shows an illustration of the hardware components of the system of the invention.

FIG. 3 shows a flow chart of an embodiment of the functionality of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention provides solutions to the present need in the art for systems and methods for dynamically monitoring test taking. The invention solves the prior art problems using a computer-based test platform that is specially programmed to monitor and to catalog all testing events, such as actions or reactions, or the lack of an actions or reactions, taken by a test taker sitting for a particular test at a particular day and time, and at a specific location, and then to determine whether the testing events warrant changes to testing security. The invention can include a computerized test administration system that functions with a test security risk analysis management system in order to allocate security resources intelligently. Various embodiments of the invention are described in detail below.

In an embodiment, the system collects and uses available information to assess risk, prior or ongoing, associated with a test event. The data collection and real-time use of that information for continuous assessment of risk for a test event has never been performed during test administration. Prior art systems collect very little information about a test event before, or even while the test is in progress, and do not use that information to make security decisions (e.g., whether or not to halt the test because of a detected security breach; whether to change the levels of monitoring; etc.).

The invention provides for identifying risk levels for a test event so that security resources can be applied intelligently and dynamically. Human resources are best applied to high-risk events. For example, the detection of a test taker's use of a two-way radio (i.e., a high-risk event) should be allocated greater security resources than a low-risk or no-risk circumstance, such as the test taker stretching or shifting in their seat. Indeed, low-risk events may only be allocated automated security monitoring resources. This dynamic resource allocation is an improvement over current resource management methods, which currently results in using the same resources regardless of whether the security risk is low or high. This type of dynamic resource allocation provided by the invention has not been performed and can significantly reduce the expense of using humans as proctors. In some cases, the costs may be reduced by an estimate of 80% to 90%, due to the reliance on automated monitoring resources for low-risk test events, which generally comprise the majority of risk events. The drastically lower costs of such test administration encourages testing in these areas where the typical fees for testing are significantly high for the market. This embodiment of the invention provides security for high-risk events, more accessibility to testing, and value to areas of the world where testing has been economically hindered.

With dynamic resource allocation provided by this invention, a test administrator can provide an exam with premium security to a test taker at any location and at any time. This flexibility to take exams anywhere and anytime provides significant benefits for test administrators and test takers. For example, testing can occur in places convenient to test takers, such as homes, community centers, and workplaces. Furthermore, an individual with disabilities that restrict his/her travel could take tests in his/her home where he/she may use his/her own assistive devices.

A detailed discussion of the methods and systems of the invention is provided below. First, a system overview is discussed. Next, a step-by-step approach to dynamic resource allocation of test security is outlined. Third, the system components are identified. A description of a cloud computing system follows. The collection and retention of relevant data is outlined. Finally, incorporation of additional parameters to the system is then delineated.

System Overview

The system is provided for creating and administering a secure, dynamically-monitored test to measure an individual's knowledge or skills, the system comprises:

• • a software application operating on a mobile computer device or on a computer device, which is synced with at least one sensor for monitoring the individual test taker, the software application is configured to receive information related to the individual test taker from historical databases of the system and at least one sensor and to communicate the information through a wired and/or wireless communication network to a risk analysis management server located at a location remote from the test location, and
  • a processor that is in communication through the wired and/or wireless communication network with the software application, as well as the risk analysis management server, the processor is configured to call up from a database of the system upon communication of the information to the risk analysis management server: (1) a plurality of historical individual risk factors, which may indicate a possibility of test fraud by the individual test taker and have been previously uploaded to the system from a public sources or made available by an owner or author of the test or an employee, contractor, or agent of the owner or author, (2) a non-individual risk factor, such as a location risk factor, or other risk factors not tied to the individual test taker, which has/have been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author, and (3) threshold risk levels which have been previously determined and uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author;
  • whereby the processor is configured to actively monitor the information related to the individual test taker and the test event;
  • whereby the processor is configured to determine an individual risk profile by adding the information received from the sensor(s) to the test event and individual risk factors to create a modifiable risk profile for the test event;
  • whereby the processor is configured to determine a security profile for the test taker by combining the individual risk profile and other test event risk factors, including the location risk factor and then to create a security profile to compare to the threshold risk levels; and
  • whereby, when the processor determines that the security profile is different from the initial threshold risk level, within a range of tolerance, the processor is configured to notify the software application.

FIG. 1 illustrates the system that includes a server comprising a processor aided by memory that communicates with sensor(s) and database(s). The database(s) contains: (1) a plurality of historical and current individual risk factors, which indicate a possibility of test fraud by the individual test taker and have been previously determined and uploaded to the database by an owner or author of the test or an employee, contractor, or agent of the owner or author, (2) a test event risk factor, including a location risk factor, which has been previously uploaded to the database by an owner or author of the test or an employee, contractor, or agent of the owner or author, and (3) threshold risk levels which have been previously uploaded to the database by an owner or author of the test or an employee, contractor, or agent of the owner or author.

Creation of Individual Risk Profile

The system receives information related to prior or current testing event(s) from the sensors and communicates such information to the processor when a test taker accesses the system. The sensors can transmit the information at set intervals, when triggers happen, or continuously to the processor related to testing events. The testing event may allow for the sensing of a number of forms such as actions and/or inactions by the test taker, or simply gathering information stored in databases from previous test events. For example, the sensor(s) for a current test event can measure the movement or lack of movement of the eyes of the test taker, whether or not the test taker's breathing or heart rate increases or decreases, or the speed at which the test taker reviews the question or submits an answer. In other embodiments, the sensors can detect involuntary reactions such as biological responses in a current test event. For example, sensors can be used to take a test taker's heart rate, breathing rate, temperature, or level of perspiration. The system can also be used to detect more gross behaviors such as leaving the room where the test is taking place, and returning some time later, both of which could be considered to be an infraction of test taking rules.

The processor can then determine if the information collected by one or more sensor(s) is a match to an individual risk factor within a range of tolerance. In certain embodiments, the individual risk factors can be set at levels that, once exceeded, indicate a likelihood of cheating or other types of test fraud. For example, a test taker's eyes focusing on another test taker's test for more than a tenth (0.1) of a second can indicate a possibility of copying/cheating by the individual test taker. Conversely, the individual risk factors can be the change in certain readings within a certain defined timeframe whose occurrence indicates a likelihood of cheating. For example, an increase of the test taker's heart rate by 20 beats per minute within a thirty second period can indicate a possibility of cheating. In another example, the speed or pattern of answering questions can also indicate cheating with pre-knowledge or harvesting questions.

In the event the processor correlates data within a range of tolerance obtained from sensor(s) with individual risk factors, the system is notified and/or the correlation noted in the individual risk profile. In one embodiment, such relationship can be assigned a numeric value that can be added together to create a dynamic individual risk profile of the test taker or the test event.

The system calculates individual risk profiles based on time passing, correlation with test fraud, data forensics analyses, hardiness of preventative test protections, history of the test taker, trustworthiness of the test site, and many more pertinent data points. The system can use algebraic models to combine these factors and their differential weighting in order to calculate a current individual risk profile. The system can dynamically determine the risk profile as these various risk factors are continuously monitored and evaluated and changes identified.

Incorporation of Non-Individual Risk Factors

The system can be configured to assess other factors not tied to the individual taking the test, while creating a holistic security profile for a test taker. For example, location risk factors can be used. In one embodiment, the location in which the test is administered and/or the timing of the administration can be taken into consideration or used to assign different weights to individual risk factors. By way of example, a test such as the MCAT can be administered in the United States and Australia. Because those locations are on opposite ends of the planet, the individual tests may be administered at different times. With the speed of the Internet, individuals who take the test earlier may be able to steal questions and sell them to those individuals who are taking the test later, thereby compromising test security. In order to combat security breaches in this example, the individual risk factors can be assigned different weights depending on the location where the tests are administered. For example, the system can be configured to place greater weight on individual risk factors related to question theft (e.g., taking unnecessary notes, identification of a photographic lens, etc.) in the location hosting the earlier test. For the location hosting the later test, question theft may not be as great a concern, therefore greater weight can be assigned to individual risk factors related to having prior question knowledge (e.g., not reading the entire question before submitting the answer).

The system can be configured to provide a static value for the location risk factor. For example, more cheating may have previously been observed in the United States than in Australia. Consequently, test takers in the United States can immediately be assigned a higher individual risk profile than the test takers in Australia. Conversely, the location risk factor can be used as a multiplier for identified individual risk factors. Again, if more cheating was observed in the United States than Australia, the United States can be assigned a location risk factor multiple of 2 with Australia assigned a location risk factor multiple of 1. As a result, while wandering eyes can be initially credited as 2 on the individual risk profile, regardless of location, the multiplier in the United States will result in the infraction being recorded as a 4 on the test taker's individual holistic security profile (i.e., 2 for individual risk profile multiplied by 2 from the location risk factor equals 4).

Creation of a Security Profile

The system can be configured to create an individual risk profile from many other risk factors, including the location risk factor to establish a holistic security profile for the individual test taker. The security profile is then compared to predetermined threshold risk levels to dynamically allocate security resources.

Dynamic Security Resource Assignment

The system can be configured to use the individual security profile to intelligently allocate test security resources as needed. Knowing risk levels for a test event allows the system to apply security resources intelligently and differentially in real time. As a result, high-risk events can be allocated greater security resources. Those with low or no risk can only be allocated automated security resources, i.e., fewer and less expensive security resources, but just as effective for the risk level.

Furthermore, as the security profile for each test taker is dynamically evaluated, re-evaluated and adjusted by the system, the system can assign security dynamically with adjustments to compensate for changing levels of risk. For example, a test taker that is originally categorized as low-risk based on his/her initial, pre-testing security profile can engage in a high-risk testing event (e.g., looking at a neighbor's answers for more than a designated period of time). In that case, the system notifies the software application of such an event, the risk analysis management software re-evaluates the individual's security profile, and the system can automatically assign added security resources to that test-taker. Likewise, if the test taker has not engaged in even a low-risk behavior for a period of time, the risk can be re-assessed as lower, and security resources could be re-assigned elsewhere.

Step-by-Step Approach

This section describes a non-limiting, exemplary embodiment that includes the steps of the process of the invention.

Step 1. When a test event is scheduled, the system calls up all prior testing events that occurred at the testing location or at other locations. Furthermore, as individual test takers register for the test, the system calls up all prior testing events that each test taker was part of. The system checks to see if external risks are current, e.g., the test has been disclosed on the Internet or cheating has been discovered on that test with a cluster of other test takers. The system then provides an initial starting risk level for that test event. The scheduling process can also include such information as test start time and other test-related information and the payment of fees.

Step 2. The system analyzes all available data using a multivariate statistical model and assigns a risk factor(s) based on prior testing events which may have occurred at the testing location and initial individual risk factors based on prior testing events which each test taker may have been part of.

Step 3. Based on the non-individual risk factor and initial individual risk factors, the system assigns security resources to the event. The resources can include a stricter authentication step, a combination of human monitoring in differing degrees, and additional advanced technology monitoring. For the highest risk level, maximum security resources can be applied during the entire testing session. For lower risk levels, fewer security resources are applied. In some embodiments, resources will not be required for lower risk levels including no risk and human security. Sophisticated automated monitoring, because it is inexpensive, would remain as the default security level for the minimum risk levels.

Step 4. The system maintains logs of data collected and decisions made at all steps of the risk analysis and management process for later review, in an applicant file or a test file or a system file. The collected data can include, but not be limited to, records of the behaviors of test takers such as responses and latencies answering test questions, audio and video behavior, communications with the system/proctors, calculations of risk by the system, scores, appeals, or assignment of proctor and security resources. The logs can be used for research, to respond to a challenge against any decisions, or for the tuning of the adjustment process of future risk factors in the future.

Step 5. When the test concludes, the system can provide an evaluation of the security applied to each test score. This step may provide evidence that the test score was produced without interference from security threats, that the test score can be trusted from at least that security perspective. The system can then provide a link for the test taker or other user of the test score (university admissions officer, teacher, parent, employer, etc.) so that the score can be accessed and independently used, if necessary.

System Components

A non-limiting embodiment of the system includes a general-purpose computing device, including a processing unit (CPU or processor), and a system bus that couples various system components including the system memory such as read only memory (ROM) and random access memory (RAM) to the processor. The system can include a storage device connected to the processor by the system bus. The system can include interfaces connected to the processor by the system bus. The system can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor. The system can copy data from the memory and/or a storage device to the cache for quick access by the processor. In this way, the cache provides a performance boost that avoids processor delays while waiting for data. These and other modules stored in the memory, storage device or cache can control or be configured to control the processor to perform various actions. Other system memory can be available for use as well. The memory can include multiple different types of memory with different performance characteristics.

Computer Processor

The invention can operate on a computing device with more than one processor or on a group or cluster of computing devices networked together to provide greater processing capability. The processor can include any general purpose processor and a hardware module or software module, stored in an external or internal storage device, configured to control the processor, as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor can essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor can be symmetric or asymmetric.

For clarity purposes, an illustrative embodiment of the system is shown as including individual functional blocks including certain functional blocks labeled as a “processor”. The functions the blocks represent can be provided through the use of either shared or dedicated hardware, including, but not limited to, hardware capable of executing software and hardware, such as a processor that is purpose-built to operate as an equivalent to software executing on a general purpose processor. For example, the functions of one or more processors can be provided by a single shared processor or multiple processors. The use of the term “processor” should not be construed to refer exclusively to hardware capable of executing software. Illustrative embodiments may include microprocessor and/or digital signal processor (DSP) hardware, read-only memory (ROM) for storing software performing the operations discussed below, and random access memory (RAM) for storing results. Very large scale integration (VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with a general purpose DSP circuit, can also be provided.

System Bus

The system bus can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM or the like, can provide the basic routine that helps to transfer information between elements within the computing device, such as during start-up.

Storage Device

The computing device can also include a storage device such as a hard disk drive, a magnetic disk drive, an optical disk drive, a solid state drive, a tape drive or the like. Similar to the system memory, a storage device can be used to store data files, such as location information, menus, software, wired and wireless connection information (e.g., information that enables the mobile device to establish a wired or wireless connection, such as a USB, Bluetooth or wireless network connection), and any other suitable data. Specifically, the storage device and/or the system memory can store code and/or data for carrying out the disclosed techniques among other data.

In one aspect, a hardware module that performs a particular function includes the software component stored in a non-transitory computer-readable medium in connection with the necessary hardware components, such as the processor, bus, display, and so forth, to carry out the function. The basic components are known to those of skill in the art and appropriate variations are contemplated depending on the type of device, such as whether the device is a small, handheld computing device, a desktop computer, or a computer server.

Although the preferred embodiment described herein employs cloud computing and cloud storage, other types of computer readable media that can store data and that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMS), read only memory (ROM), a cable or wireless signal containing a bit stream and the like, can also be used in the operating environment. Furthermore, non-transitory computer-readable storage media as used herein can include all computer-readable media, with the sole exception being a transitory propagating signal per se.

Interface

To enable user interaction with the computing device, an input device represents any number of input mechanisms, such as a microphone for speech, a web camera for video, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device can also be one or more of a number of output mechanisms, such as, a display screen, speaker, alarm, and so forth. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device. The communications interface generally governs and manages the user input and system output. Furthermore, one interface, such as a touch screen, can act as an input, output and/or communication interface.

There is no restriction on operating on any particular hardware arrangement. Here, the basic features can be easily substituted for improved hardware or firmware arrangements as they are developed.

Sensors

The system includes at least one sensor for monitoring the test taker. The sensor can take many forms. For example, the sensor can be an auditory sensor (e.g., microphone), a video sensor (e.g., camera), a biometric sensor (e.g., pulse detector, keyboard patterns, voiceprint, facial recognition), a motion detector, a proximity sensor, or a combination thereof (e.g., a camera which is configured to also measure the temperature of the test taker). In one non-limiting embodiment, the proximity sensor can be configured to monitor and confirm that the test taker remains in a dictated location or within a range of the testing location. In another embodiment, the sensor can be a motion sensor configured to monitor the test taker's eyes. The sensor can also monitor less obvious behaviors, such as response patterns answering questions that reveal the use of pre-knowledge, for example.

In one non-limiting embodiment, the sensor can be mounted on a wearable device, such as a headset or glasses. The wearable device can, again, include biometric sensors, such as a pulse detection sensor, eye direction sensors, a three-axis accelerometer, a GPS module, an RF sensor, an RFID or NFC chip, a galvanic skin response sensor, or other sensor to detect stress or continued presence or proximity to the testing location. Such a wearable sensor can be configured to alarm or vibrate if the sensor is moved out of a proximity to the testing location, within a range of tolerance. The wearable sensor can also record the field of view which is seen by the eyes of the test taker. Such a configuration can capture information about any visual aids viewed or utilized by the test taker. In order to assure that the sensor is properly worn, a second visual sensor, such as a camera can be used to monitor the test taker for the presence and proper use of the sensor.

In one embodiment, the sensor includes electronic components for wired or wireless communication with the system. As a result, the sensor can avoid interference with the administration of the test. In one embodiment, the sensor is replaceable or added to, such that different sensors can be removed, which can allow the sensor to be cleaned.

In another embodiment, the sensor can include embedded monitoring components that are configured to verify the identity of the user and monitor the remote session environment for a duration of an entire session. For example, the sensor can employ facial recognition software or finger print analysis to confirm the identity of the test taker at set intervals or continuously.

In another embodiment, a sensor detects the security design features of the test. A test that prevents the theft of the questions or different methods of cheating would provide critical information for the assessment of risk by the risk analysis and management system.

The system can include more than one sensor. Indeed, the system can include 2, 3, 4, 5, 6, 7, 8, 9, or 10 sensors, each of a different type and different purpose. For example, the system may include two cameras, a microphone, a biometric sensor and a statistical response pattern sensor. In one embodiment, the sensors cannot be easily tampered with.

Software Operations

The logical operations of the various embodiments disclosed are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a general use computer, (2) a sequence of computer implemented steps, operations, or procedures running on a specific-use programmable circuit; and/or (3) interconnected machine modules or program engines within the programmable circuits. The system can practice all or part of the recited methods, can be a part of the recited systems, and/or can operate according to instructions in the recited non-transitory computer-readable storage media. Such logical operations can be implemented as modules configured to control the processor to perform particular functions according to the programming of the module. For example, if a storage device contains modules configured to control the processor. These modules can be loaded into RAM or memory at runtime or can be stored as would be known in the art in other computer-readable memory locations. Having disclosed some components of a computing system, the disclosure now turns to a description of cloud computing, which is the preferred environment of the invention.

Cloud System

Cloud computing is a type of Internet-based computing in which a variety of resources are hosted and/or controlled by an entity and made available by the entity to authorized users via the Internet. A cloud computing system can be configured, wherein a variety of electronic devices can communicate via a network for purposes of exchanging content and other data. The system can be configured for use on a wide variety of network configurations that facilitate the intercommunication of electronic devices. For example, each of the components of a cloud computing system can be implemented in a localized or distributed fashion in a network.

Cloud Resources

The cloud computing system can be configured to include cloud computing resources (i.e., “the cloud”). The cloud resources can include a variety of hardware and/or software resources, such as cloud servers, cloud databases, cloud storage, cloud networks, cloud applications, cloud platforms, and/or any other cloud-based resources. In some cases, the cloud resources are distributed. For example, cloud storage can include multiple storage devices. In some cases, cloud resources can be distributed across multiple cloud computing systems and/or individual network enabled computing devices. For example, cloud computing resources can communicate with a server, a database, and/or any other network enabled computing device to provide the cloud resources.

In some cases, the cloud resources can be redundant. For example, if cloud computing resources are configured to provide data backup services, multiple copies of the data can be stored such that the data is still available to the user even if a storage resource is offline, busy, or otherwise unavailable to process a request. In another example, if a cloud computing resource is configured to provide software, the software can be available from different cloud servers so that the software can be served from any of the different cloud servers. Algorithms can be applied such that the closest server or the server with the lowest current load is selected to process a given request.

User Terminal

A user interacts with cloud computing resources through user terminals or testing devices connected to a network by direct and/or indirect communication. Cloud computing resources can support connections from a variety of different electronic devices, such as servers, desktop computers, mobile computers, handheld communications devices (e.g., mobile phones, smart phones, tablets), set top boxes, network-enabled hard drives, and/or any other network-enabled computing devices. Furthermore, cloud computing resources can concurrently accept connections from and interact with multiple electronic devices. Interaction with the multiple electronic devices can be prioritized or occur simultaneously.

Cloud computing resources can provide cloud resources through a variety of deployment models, such as public, private, community, hybrid, and/or any other cloud deployment models. In some cases, cloud computing resources can support multiple deployment models. For example, cloud computing resources can provide one set of resources through a public deployment model and another set of resources through a private deployment model.

In some configurations, a user terminal can access cloud computing resources from any location where an Internet connection is available. However, in other cases, cloud computing resources can be configured to restrict access to certain resources such that a resource can only be accessed from certain locations. For example, if a cloud computing resource is configured to provide a resource using a private deployment model, then a cloud computing resource can restrict access to the resource, such as by requiring that a user terminal access the resource from behind a firewall.

Service Models

Cloud computing resources can provide cloud resources to user terminals through a variety of service models, such as Software as a Service (SaaS), Platforms as a service (PaaS), Infrastructure as a Service (IaaS), and/or any other cloud service models. In some cases, cloud computing resources can provide multiple service models to a user terminal. For example, cloud computing resources can provide both SaaS and IaaS to a user terminal. In some cases, cloud computing resources can provide different service models to different user terminals. For example, cloud computing resources can provide SaaS to one user terminal and PaaS to another user terminal.

User Interaction

In some cases, cloud computing resources can maintain an account database. The account database can store profile information for registered users. The profile information can include resource access rights, such as software the user is permitted to use, maximum storage space, etc. The profile information can also include usage information, such as computing resources consumed, data storage location, security settings, personal configuration settings, etc. In some cases, the account database can reside on a database or server remote to cloud computing resources such as servers or database.

Cloud computing resources can provide a variety of functionality that requires user interaction. Accordingly, a user interface (UI) can be provided for communicating with cloud computing resources and/or performing tasks associated with the cloud resources. The UI can be accessed via an end user terminal in communication with cloud computing resources. The UI can be configured to operate in a variety of client modes, including a fat client mode, a thin client mode, or a hybrid client mode, depending on the storage and processing capabilities of cloud computing resources and/or the user terminal. Therefore, a UI can be implemented as a standalone application operating at the user terminal in some embodiments. In other embodiments, a web browser-based portal can be used to provide the UI. Any other configuration to access cloud computing resources can also be used in the various embodiments.

Collection of Data

In some configurations, during the testing described above, a storage device or resource can be used to store relevant data transmitted from the sensor(s) or the test taker's device to a database over a wired or wireless communication network. For example, how long it takes to read and process the question or the number of identified incidents of cheating may be captured. Such data may be used to dynamically adjust risk factors or the calculations based on those risk factors.

The data stored can also be incorporated into the disclosed system and methods to refine the testing experience or evaluate security. For example, if a location experiences an increase in cheating incidents in the first part of the test, the location risk factor can be increased during the test which can result in the allocation of additional security resources with relation to all the test takers at that site. As a result, the information collected can serve more than one purpose (quality of measurement, better security, more fairness, and others). Those purposes can also be routinely evaluated.

Incorporation of Additional Parameters

Identity Verification

In a non-limiting embodiment, the sensors can be used to authenticate the test taker before the administration of the test. In one example, the system can be linked to a public or private database that includes photo or biometric information of the test taker (e.g., finger prints). Before the test can be presented to the test taker, the system can be required to authenticate the right of the test taker to take the test. Such verification and confirmation can be accomplished in many ways, for example, the use of facial recognition, keystroke pattern analysis, voice recognition software or fingerprint scanners, or many others, which can be hardware or non-hardware dependent.

Corrective Actions

In a non-limiting embodiment, when the security profile exceeds a threshold risk level, the entire system can be alerted. The system can then allow a proctor monitoring the system and assigned to the test event to: (1) review the security profile and/or the testing events identified in the security profile; and/or (2) pause the test to discuss the issues with the test taker, and (3) other reasonable actions given the circumstances. Such review and/or communication can occur in person or remotely (i.e., the proctor remoting into the device on which the test being administered or calling the person on a phone). To the extent a security breach is identified, the proctor can seize control of the testing session. For example, if a threat is detected, the proctor can pause the test and deal with the test taker via a live or remote chat session. When a test is paused, the current test item can be “covered” and the test timing can be suspended. If the problem is resolved to the satisfaction of the proctor, he or she can “un-pause” the test allowing it to continue as if nothing had happened. If the problem cannot be resolved, the proctor has the options of (1) suspending the test, which allows it to continue at another scheduled time, or (2) cancelling the test event altogether. Such control provides a very effective tool in the hands of the proctor to motivate compliance or to address the risk directly, one that is missing in the offerings of many online and some on-site proctoring service vendors today.

Example

FIG. 3 shows an exemplary embodiment of the disclosed system. At least one database 310 feeds information to a processors 320, which may also be referred to as a Risk Analysis Management System (RAMS). The information may be fed at set intervals or continuously.

In certain embodiments there are two or more databases 310. Such databases can be segregated based on the type of information stored. For example, one database can hold information uploaded before a testing event, such as: (1) prior incidents at the testing center, (2) test designs (e.g., multiple choice tests versus short answer or essay tests), (3) location of the testing event, (4) web monitoring reports (e.g., review of social media chatter prior to the test to see if potential cheating is being discussed), (5) data forensic reports, (6) system security, (7) examinee history, and (8) ability to authenticate examinee. Conversely, another database may include information obtained during the testing event, such as: (1) test taker movement, (2) audio of the test taking environment, (3) real-time biometrics of the test taker, (4) proctor location, actions, and the test takers response thereto, (5) unauthorized communications by the test taker, and (6) the test taker's adherence to the rules of the testing environment. The RAMS 320 takes the information from the database(s) 310, combines the information and statistically determines the level of risk associated with a test event. The risk is then assigned a classification 330.

In one embodiment, the classifications 330 are broken down as: (1) No Risk, (2) Low Risk, (3) Medium Risk, (4) Medium High Risk and (5) High Risk. Increased security measures are assigned to higher risk events. The classifications 330 are not static. Indeed, additional information may change the risk level dynamically. For example, an incident occurring in real-time during testing may elevate a risk level from Low Risk to High Risk almost instantaneously.

While this subject matter has been disclosed with reference to specific embodiments, it is apparent that other embodiments and variations can be devised by others skilled in the art without departing from the true spirit and scope of the subject matter described herein. The appended claims include all such embodiments and equivalent variations.

Claims

1. A system for monitoring an individual test taker and verifying compliance with rules of behavior with regard to a test event, during a test session administered to an individual at a test location, the system comprising:

a software application operating on a mobile computer device or on a computer device, which are in communication with at least one sensor for monitoring the test event, the software application configured to receive information related to the individual test taker from the sensor and to communicate the information through a wired and/or wireless communication network to a risk analysis management server located at the test location or at a location remote from the test location, and

a processor that is in communication through the wired and/or wireless communication network with the software application, as well as the risk analysis management server, the processor is configured to call up from a database of the system upon communication of the information to the risk analysis management server: (1) a plurality of predetermined individual risk factors, which indicate a possibility of test fraud, cheating, or test theft, by the individual test taker or others at the location, and have been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author, (2) a non-individual risk factor, which has been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author, and (3) a set of threshold risk levels which have been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author;

whereby the processor is configured to actively monitor the information related to the test event;

whereby the processor is configured to determine an individual risk profile by comparing the information received from the sensor(s) against the individual risk factors to identify whether the risk profile needs to be adjusted;

whereby the processor is configured to determine a security profile for the test taker by combining the individual risk profile and the non-individual risk factor into the test event risk security profile, and compare that security profile to the threshold risk level; and

whereby when the processor determines that the security profile is above or below specific threshold risk levels, within a range of tolerance, the processor is configured to notify the software application.

2. The system of claim 1 wherein, the software application allocates greater security resources if the security profile is above more of the threshold risk levels, and the software application allocates less security resources if the security profile is below less of the threshold risk levels.

3. The system of claim 1 wherein, based on active monitoring of the test event by the sensor, the system is configured to dynamically increase or decrease the allocation of security resources based on how many threshold risk levels the security profile is above.

4. The system of claim 3 wherein, based on active monitoring of the test event by the sensor, the system is configured to increase the allocation of security resources when the security profile traverses the threshold risk level, within a range of tolerance, from below an individual threshold risk level to above the individual threshold risk level.

5. The system of claim 3 wherein, based on active monitoring of the test event by the sensor, the system is configured to decrease the allocation of security resources when the security profile traverses the threshold risk level, within a range of tolerance, from above an individual threshold risk level to below the individual threshold risk level.

6. The system of claim 1 wherein, the non-individual risk factor is a location risk factor.

7. A system for monitoring an individual test taker and verifying compliance with rules of behavior with regard to a test event administered at a test location, the system comprising:

a software application operating on a website accessible through a wired or wireless communications network by a unique mobile computer device or a unique computer device which are synced with at least one sensor for monitoring the test event, the software application configured to receive information related to the individual test taker and testing location from the sensor and to communicate the information through a wired and/or wireless communication network to a risk analysis management server located at the test location or at a location remote from the test location; and

a processor that is in communication through the wired and/or wireless communication network with the software application, as well as the risk analysis management server, the processor is configured to call up from a database of the system upon communication of the information to the risk analysis management server: (1) a plurality of predetermined individual risk factors, which indicate a possibility of cheating or other types of fraud by the individual test taker and have been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author, (2) a plurality of non-individual risk factors, which have been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author, and (3) a set of threshold risk levels which has been previously uploaded by an owner or author of the test or an employee, contractor, or agent of the owner or author;

whereby the processor is configured to actively monitor the information related to the test event;

whereby the processor is configured to determine an individual risk profile by comparing the information received from the sensor against the individual risk factors to identify any that might require the risk factor to be adjusted;

whereby the processor is configured to determine a security profile for the test event by combining the individual risk profile and the non-individual risk factors, and compare the current security profile to the threshold risk level; and

whereby when the processor determines that the security profile is above or below specific threshold risk levels, within a range of tolerance, the processor is configured to notify the software application.

8. The system of claim 7 wherein, the software application allocates greater security resources if the security risk profile is above more threshold risk levels, and the software application allocates less security resources if the security risk profile is below less threshold risk levels.

9. The system of claim 7 wherein, based on active monitoring of the test event by the sensor, the system is configured to dynamically increase or decrease the allocation of security resources based on whether the security profile is above or below the threshold risk level.

10. The system of claim 8 wherein, based on active monitoring of the test event by the sensor, the system is configured to increase the allocation of security resources when the security profile traverses the threshold risk level, within a range of tolerance, from below the threshold risk level to above the threshold risk level.

11. The system of claim 9 wherein, based on active monitoring of the test event by the sensor, the system is configured to decrease the allocation of security resources when the security profile traverses the threshold risk level, within a range of tolerance, from above the threshold risk level to below the threshold risk level.

12. The system of claim 7 wherein, the non-individual risk factor is a location risk factor.

13. A method for monitoring an individual test taker and verifying compliance with rules of behavior with regard to a test event, the method comprising:

receiving information related to the individual test taker from a sensor for monitoring the individual test taker and test taking environment synced through a wired and/or wireless communication network with a software application operating on a mobile computer device or on a computer device;

upon receiving the information, using a processor to verify the identity of the individual test taker and call up: (1) a plurality of predetermined individual risk factors, which indicate a possibility of cheating or test theft by the individual test taker, (2) non-individual risk factors, and (3) a set of threshold risk levels;

creating an individual risk profile by comparing the information received from the sensor against the individual and non-individual risk factors;

combining the individual risk profile with the non-individual risk factors, creating a security profile for the test event;

comparing the security risk profile of the test event to the threshold risk levels; and

notifying the software application if the security risk profile is above or below a specified threshold risk level.

14. The method of claim 13, further comprising:

assigning security resources based on whether the security profile is above or below the specified threshold risk level.

15. The method of claim 13 further comprising:

dynamically increasing or decreasing the allocation of security resources based on active monitoring of the test event by the sensor.

16. The method of claim 15, wherein, increased security resources are allocated if the security profile crosses the specified threshold risk level, within a range of tolerance, from below the specified threshold risk level to above the specified threshold risk level.

17. The method of claim 15, wherein, decreased security resources are allocated if the security profile crosses the specified threshold risk level, within a range of tolerance, from above the specified threshold risk level to below the specified threshold risk level.

18. The method of claim 13, wherein, the non-individual risk factor is a location risk factor.