System, method and apparatus for liveness verification using biometric one-time password

Abstract

A system for liveness verification is disclosed, including a liveness verification token, a registered client device, and a liveness verification server. The token includes a biometric sensor, a one-time password (OTP) generator, a clock module, and a token interface, and is configured to obtain a biometric reading from an individual, compare it to a registered biometric reading to verify identity, determine whether the individual is alive at the time of reading, and generate an OTP based in part on the biometric reading and a password key. The server includes an OTP generator, a clock module, and an interface through which the server receives the OTP generated by the token. The server is configured to generate an OTP using information stored in a user file that is associated with the individual and identified with a unique identifier included in the token OTP. The server verifies the liveness of the individual by comparing the OTPs.

Description

[0001] Related applications

[0002] This application claims the benefit of U.S. nonprovisional patent application 17 / 109,734, filed December 2, 2020, entitled “System, Method, and Device for Vitality Verification Using a Biometric One-Time Password,” the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] This document generally deals with vitality verification using biostatistical one-time passwords. Background Technology

[0004] Benefits are typically provided to those most in need, whether due to age, health condition, or other circumstances. Because these needs are so widespread, their provision often occurs on a large scale. Examples include Social Security administrations, retirement plans, pensions, disability programs, and unemployment benefits. The large number of recipients in these programs makes them vulnerable to waste and even fraud, with benefits continuing to be provided even after the intended recipient has died. Traditional methods for verifying whether an intended recipient is still alive are time-consuming and cannot be implemented on the scale required to reduce millions of dollars in losses annually. Summary of the Invention

[0005] According to one aspect, a system for viability verification includes a viability verification token having a processor, memory, a biometric sensor, a first one-time password generator, a first clock module, and a token interface. The viability verification token is configured to obtain a token biometric reading of an individual via the biometric sensor. The token biometric reading includes the individual's fingerprint. The token is also configured to compare the token biometric reading with the individual's registered biometric reading, which is previously obtained via the biometric sensor and stored in memory. The token is further configured to determine whether the individual is alive at the time the token biometric reading is obtained, the determination being at least partially based on the token biometric reading, and also generated using the first OTP generator in response to the token biometric reading matching the registered biometric reading and determining that the individual is alive at the time the token biometric reading is obtained. The token one-time password (OTP) string includes a token OTP generated by applying a one-way function to a token message, the token message including a password key stored in memory, the registered biometric reading, and a first timestamp from the clock module. The system also includes a registration client device communicatively coupled to a vitality verification token. The registration client device is configured to receive, via a biometric sensor, a registration biometric reading of an individual obtained from the vitality verification token, including the individual's fingerprint, and is further configured to receive a unique serial number associated with the vitality verification token. The system also includes a vitality verification server having a second one-time password generator, a second clock module, and at least one server interface, including a server network interface communicatively coupled to the registration client device via a network, and further including an SMS interface. The vitality verification server is configured to receive the serial number and registration biometric reading from the registration client device, retrieve a password key from multiple password keys using the serial number, create a user file associated with the individual, and receive a token OTP string provided by the vitality verification token via a token interface through the SMS interface. The server is also configured to generate a server OTP using the second OTP generator by applying a one-way function to a server message, the server message including a password key stored in the user file, the registration biometric reading stored in the user file, and a second timestamp, the user file being retrieved using at least one of a unique identifier associated with the individual and the start point of the token OTP string. The server is also configured to verify an individual's liveness by comparing the server OTP with the token OTP. The token OTP string begins with the mobile device associated with the individual. The token interface is at least one of a display, speaker, token network interface, and USB interface. The token OTP string is between six and ten characters long.

[0006] Specific embodiments may include one or more of the following features. The at least one server interface may include an SMS interface. The vitality verification server can receive a token OTP string via the SMS interface. The starting point of the token OTP string may be a mobile device associated with the individual. The token OTP string may further include at least a portion of a first timestamp. The token OTP string may further include a unique identifier.

[0007] According to another aspect of this disclosure, a system for viability verification includes a viability verification token having a processor, memory, a biostatistical sensor, a first one-time password generator, a first clock module, and a token interface. The viability verification token is configured to acquire an individual's token biostatistical reading via the biostatistical sensor and compare the token biostatistical reading with the individual's registered biostatistical reading, which was previously acquired via the biostatistical sensor and stored in the memory. The token is also configured to determine whether the individual is alive at the time the token biostatistical reading is acquired, and to generate, using the first OTP generator and in response to the token biostatistical reading matching the registered biostatistical reading and determining that the individual is alive at the time the token biostatistical reading is acquired, a token one-time password (OTP) string comprising a token OTP generated by applying a one-way function to a token message including a password key stored in memory, the registered biostatistical reading, and a first timestamp from the clock module. The system also includes a registration client device communicatively coupled to the viability verification token, the registration client device being configured to receive the individual's registered biostatistical reading acquired by the viability verification token via the biostatistical sensor and to receive a unique serial number for the viability verification token from the viability verification token. The system further includes a vitality verification server having a second one-time password generator, a second clock module, and at least one server interface, said at least one server interface including a server network interface communicatively coupled to a registered client device. The vitality verification server is configured to receive a serial number and registered biometric readings from the registered client device, retrieve a password key from multiple password keys using the serial number, create a user file associated with the individual, and receive a token OTP string provided by a vitality verification token via a token interface through one of the at least one server interfaces. The server is also configured to generate a server OTP using the second OTP generator by applying a one-way function to a server message including a password key stored in the user file, a registered biometric reading stored in the user file, and a second timestamp, the user file being retrieved using at least one of a unique identifier associated with the individual and the start point of the token OTP string, and to verify the individual's vitality by comparing the server OTP with the token OTP.

[0008] Specific embodiments may include one or more of the following features: The token and registration biometric reading may include at least one of fingerprint, retinal scan, and facial scan. The at least one server interface may include an SMS interface, and the token OTP string may be received by the vitality verification server via the SMS interface. The starting point of the token OTP string may be a mobile device associated with the individual. Whether the individual was alive at the time the token biometric reading was obtained may be determined at least in part based on the token biometric reading. The token OTP string may further include at least a portion of a first timestamp. The token OTP string may further include a unique identifier. The at least one server interface may include a voice interface, and the token OTP string may be received by the vitality verification server via the voice interface as a telephone call. The token interface may be at least one of a display, speaker, token network interface, and USB interface. The length of the token OTP string may be between six and ten characters.

[0009] According to another aspect of this disclosure, a method for viability verification includes obtaining a token biometric reading of an individual via a biosensor of a viability verification token, the viability verification token including a processor, a memory, a biosensor, a first one-time password generator, a first clock module, and a token interface. The method further includes comparing the token biometric reading with a registered biometric reading of the individual, which was previously obtained via the biometric sensor and stored in the memory; determining whether the individual was alive at the time the token biometric reading was obtained; and generating a token one-time password (OTP) string using the first OTP generator in response to the token biometric reading matching the registered biometric reading and determining that the individual was alive at the time the token biometric reading was obtained. The token OTP string includes a token OTP generated by applying a one-way function to a token message, the token message including a password key stored in the memory, the registered biometric reading, and a first timestamp from the clock module. The method further includes receiving a token OTP string at the vitality verification server via at least one of its server interfaces, the token OTP string being provided through a token interface, the vitality verification server further having a second one-time password generator and a second clock module, and retrieving an associated user file containing a password key and registered biometric readings using at least one of a unique identifier associated with the individual and the start point of the token OTP string. Finally, the method includes generating a server OTP using the second OTP generator by applying a one-way function to a server message including a password key stored in the user file, registered biometric readings stored in the user file, and a second timestamp, and verifying the individual's vitality by comparing the server OTP with the token OTP.

[0010] Specific embodiments may include one or more of the following features. The method may further include assigning a vitality verification token to an individual; receiving, at a registration client device, a registration biometric reading of the individual obtained by the vitality verification token via a biometric sensor; the registration client device being communicatively coupled to the vitality verification token; receiving a unique serial number for the vitality verification token from the vitality verification token; receiving the serial number and the registration biometric reading from the registration client device at a vitality verification server; retrieving a password key from a plurality of password keys using the serial number; and / or creating a user file associated with the individual, the user file containing the registration biometric reading and the password key. The vitality verification server may receive a token OTP string from the vitality verification token via the registration client device. The at least one server interface may include an SMS interface. The vitality verification server may receive the token OTP string via the SMS interface. The starting point of the token OTP string may be a mobile device associated with the individual. Determining whether the individual is alive at the time the token biometric reading is obtained may be accomplished at least in part using the token biometric reading. The length of the token OTP string may be between six and ten characters. The token and the registration biometric reading may include at least one of fingerprint, retinal scan, and facial scan.

[0011] The aspects and applications of this disclosure presented herein are described below in the accompanying drawings and detailed description. Unless specifically indicated, it is intended that the words and phrases in the specification and claims be given their plain, common, and conventional meanings to those skilled in the art. The inventors are fully aware that they could be their own lexicographers if desired. As their own lexicographers, the inventors explicitly choose to use only the plain and common meanings of terms in the specification and claims, unless they expressly state otherwise, and then further expressly elaborate on the “special” definition of the term and explain how it differs from the plain and common meaning. In the absence of such an explicit statement of intent to apply the “special” definition, the inventors intend and expect that the simple, plain, and common meanings of the terms be applied to the interpretation of the specification and claims.

[0012] The inventors also understand the general rules of English grammar. Therefore, if a noun, term, or phrase is intended to be further characterized, specified, or narrowed in some way, then such a noun, term, or phrase will explicitly include additional adjectives, descriptive terms, or other modifiers according to the general rules of English grammar. In the absence of such adjectives, descriptive terms, or modifiers, the intention is that such a noun, term, or phrase will be given a plain and common English meaning to a person skilled in the art in the applicable field described above.

[0013] Furthermore, the inventors were fully informed of the application of the standard and specific provisions of 35 USC §112(f). Therefore, the use of the terms “function,” “component,” or “step” in the description of the detailed description, drawings, or claims is not intended to indicate a desire to invoke the specific provisions of 35 USC §112(f) to define the invention. Rather, if an invocation of 35 USC §112(f) were sought to define the invention, the claims would specifically and explicitly state the exact phrases “component for…” or “step for…” and would also state the word “function” (i.e., “component for performing the function of [insertion function]”), without listing any structure, material, or action supporting that function in such phrases. Therefore, even when a claim lists “component for performing the function of…” or “step for performing the function of…”, if the claim also lists any structure, material, or action supporting that component or step, or any structure, material, or action performing the listed function, the inventors’ explicit intention is not to invoke the provisions of 35 USC §112(f). Furthermore, even when the claimed aspects are defined by reference to 35 USC §112(f), it is intended that these aspects are not limited to the specific structures, materials, or actions described in the preferred embodiments, but additionally include any and all structures, materials, or actions that perform the claimed functions as described in alternative embodiments or forms of this disclosure, or equivalent structures, materials, or actions that are well known and currently or later developed for performing the claimed functions.

[0014] The foregoing and other aspects, features and advantages will be apparent to those skilled in the art from the description, drawings and claims. Attached Figure Description

[0015] The present disclosure will now be described in conjunction with the accompanying drawings, wherein similar designations denote similar elements, and:

[0016] Figure 1A This is a schematic view of the vitality verification system;

[0017] Figure 1B yes Figure 1A A schematic view of the system's vitality verification token;

[0018] Figure 2 This is a schematic view of the user files;

[0019] Figure 3 This is a process view of a method for performing viability verification using a one-time biometric password in a viability verification system; and

[0020] Figure 4 It is a schematic diagram of a specific computing device that can be used to implement the methods and systems disclosed herein, according to one or more embodiments. Detailed Implementation

[0021] This disclosure, its aspects, and implementations are not limited to the specific material types, components, methods, or other examples disclosed herein. Many additional material types, compositions, methods, and procedures known in the art are contemplated for use in specific implementations of this disclosure. Thus, for example, although a specific implementation is disclosed, such implementations and implementation components may include any components, models, types, materials, versions, quantities, and / or like thereof known in the art for such systems and implementation components, consistent with the intended operation.

[0022] The terms “exemplary,” “example,” or their various forms, as used herein, are intended to serve as examples, instances, or illustrations. Any aspect or design described herein as “exemplary” or “example” is not necessarily to be construed as preferred or superior to any other aspect or design. Furthermore, examples are provided for clarity and understanding only and are not intended to limit or constrain the disclosed subject matter or relevant parts of this disclosure in any way. It will be appreciated that numerous additional or alternative examples of varying scope may have been presented, but these examples have been omitted for the sake of brevity.

[0023] While this disclosure includes many different embodiments, specific embodiments are illustrated in the accompanying drawings and will be described in detail herein. It should be understood that this disclosure is intended to be considered as an illustration of the principles of the disclosed methods and systems, and is not intended to limit the broad aspects of the disclosed concepts to the illustrated embodiments.

[0024] Benefits are typically provided to those most in need, whether due to age, health condition, or other circumstances. Because these needs are so widespread, their provision often occurs on a large scale. Examples include Social Security administrations, retirement plans, pensions, disability programs, and unemployment benefits. The large number of recipients in these programs makes them vulnerable to waste and even fraud, with benefits continuing to be provided even after the intended recipient has died. Traditional methods for verifying whether an intended recipient is still alive are time-consuming and cannot be implemented on the scale required to reduce millions of dollars in losses annually.

[0025] This paper envisions a system, method, and apparatus for vitality verification using a biometric one-time password. The envisioned system and method rely on a vitality verification token that generates the one-time password in part based on a biometric reading performed by the token, rather than relying on conventional methods for determining whether a grant recipient is still alive. Upon reading, the token also determines the vitality of the biometric source. A one-time password (hereinafter referred to as OTP) is generated when it is determined that the reading comes from a living individual and matches the reading made when the individual registered. Presenting the OTP to a vitality verification server verifies that the individual is still alive, thereby authorizing the disbursement of the grant for an additional time period.

[0026] For a number of reasons, the systems, methods, and devices envisioned in this paper are superior to traditional methods for reducing waste and fraud in allowance systems. The technology is proven and inexpensive. It is far more accurate than traditional telephone methods, in which individual identity can be difficult to verify. It is also far more efficient than in-person visits. The devices themselves are not expensive, especially considering the savings they will provide by reducing waste and fraud.

[0027] It should be noted that although the following discussion takes place in the context of verifying an individual’s vitality to authorize continued receipt of allowances, the system, method, and device can be adapted for us in other contexts that require proof of life, or as an additional security layer (i.e., biostatistics) to OTP tokens used in the conventional way.

[0028] Figure 1A This is a schematic view of a non-limiting example of a vitality verification system 100. As shown, the vitality verification system 100 (hereinafter referred to as "System 100") includes a vitality verification server 106 (hereinafter referred to as "Server 106") and a vitality verification token 102 (hereinafter referred to as "Token 102"). Some embodiments may also include a registration client device 104. According to various embodiments, Token 102 performs a biometric scan on an individual 108, generates a one-time password based at least in part on the biometric scan, and sends the password to Server 106 for comparison with a password generated by Server 106. If they match, the vitality has been verified by the allowance provider, and the allowance is authorized for another period of time.

[0029] In the context of this specification and the following claims, the vitality verification token 102 (hereinafter “token 102”) is a device capable of detecting biometric signals or inherent attributes of an individual, and further capable of generating a one-time password in part based on such biometric readings. Unlike conventional OTP tokens used to provide access or login credentials, the token 102 contemplated herein is not designed as a security device. It operates independently and is used to verify whether the individual 108 associated with the token 102 is alive, and a biometric scan has already been provided.

[0030] As shown, according to various embodiments, token 102 includes a processor 112, a memory 114, a first clock module 122ab, at least one token interface 124, at least one biostatistical sensor 118, and a first OTP generator 120. Each of these elements will be discussed below. In some embodiments, token 102 may be battery-powered and may use a rechargeable battery. In other embodiments, token 102 may be powered by an external power source.

[0031] Token 102 includes at least one biosensor 118. In the context of this specification and the following claims, biostatistical sensor 118 is a sensor capable of detecting, measuring, or capturing one or more characteristics inherent to and unique to individual 108. In some embodiments, biostatistical sensor 118 may capture behavioral characteristics of individual 108, meaning they observe how individual 108 does something. Examples include, but are not limited to, gait, signature, keystroke patterns and rhythms when typing on a keyboard, and the like. While behavioral characteristics are not as obviously unique to a person as physiological characteristics, they can be readily captured and, when used in combination with other characteristics, can provide sufficient accuracy to reliably identify individual 108.

[0032] In other embodiments, the biostatistical sensor 118 can capture one or more physiological characteristics of an individual. These characteristics are fundamental to the individual. Examples include, but are not limited to, fingerprints, retinal vascular distribution shown in a retinal scan, ear shape, vein patterns, facial features shown in a facial scan, iris fibers and color, heart rhythm, and the like. Exemplary biostatistical sensors 118 include, but are not limited to, infrared thermography (e.g., detecting veins under the skin of the hands, face, or other body parts), cameras (e.g., images of ear shape, face, iris), 3D scanners or depth-sensitive cameras (e.g., geometry of the face, hands, etc.), retinal scanners (e.g., for retinal vascular distribution), heart rate monitors (e.g., for observing heart rhythm), and fingerprint readers (e.g., optical, ultrasonic, etc.).

[0033] In some embodiments, token 102 may capture a single biostatistical reading, while in other embodiments, token 102 may measure multiple biostatistical characteristics, which may be combined into a single value or a set of values ​​for generating an OTP. Combining multiple biostatistical signals allows for the use of less expensive hardware while still consistently distinguishing individuals 108.

[0034] A key function of the vitality verification system 100 is to determine that the individual 108 associated with the token 102 is actually alive. In some embodiments, vitality determination may be performed as a separate function. However, in other embodiments, vitality determination may be performed when biostatistical readings are obtained, and the same biostatistical sensor 118, or even the same data, may be used.

[0035] Vital activity determination can be hardware-based or software-based. In some embodiments, hardware-based methods may utilize additional sensors to observe aspects not captured by one or more biostatistical sensors 118. These observations include, but are not limited to, pulse, pulse oximetry, blood pressure (e.g., fingertip), electrical impedance, temperature, subtle movements of the fingertip surface, and multi-wavelength optical properties. Hardware-based methods for determining vital activity can be expensive because they require additional hardware. They are often inherently invasive and can be circumvented or fooled. For example, the additional hardware may be tricked into providing the desired reading. Once circumvention methods are identified, hardware-based methods become worthless.

[0036] Compared to hardware-based methods, software-based methods for determining the viability of an individual 108 providing biostatistical readings present several advantages, the primary one being that they require no additional sensing hardware beyond the hardware used to acquire the biostatistical readings. These methods analyze biostatistical data to determine the viability of the data source. Some of these methods may be dynamic, meaning they observe changes in the signal across multiple readings (although sometimes this may be performed within seconds). Examples include observing elastic deformation of fingerprint surface features and observing sweating when a finger is pressed against the biostatistical sensor 118.

[0037] Other software-based methods for determining viability can be static, utilizing a single biostatistical reading. Examples include, but are not limited to, observing fingerprint morphology, examining fingerprint images in the frequency domain via Fourier analysis, determining ridge widths in fingerprints, and other methods for accurately determining the viability of fingerprint sources.

[0038] Another advantage of software-based methods for vitality determination is that they can be refined over time through software updates. For example, machine learning models can continue to improve accuracy as they are trained on datasets that were not available when System 100 was first launched. New and improved detection methods can be implemented without replacing token 102 or educating users on new procedures.

[0039] It should be noted that while these examples of viability determination methods all focus on using fingerprints as biometric data, those skilled in the art will recognize that viability can be determined based on biometric data other than fingerprints, and software-based methods for other biometric measurements are possible. For example, a video feed from a facial scan can be used to detect an individual's pulse through barely perceptible fluctuations in facial color.

[0040] As a specific example, in one embodiment, the biometric sensor 118 may be a capacitive fingerprint reader capable of distinguishing the valleys and ridges of an individual's fingerprint 108 by observing voltage fluctuations detected on a metal plate as the individual drags their finger. Living biological tissue is charged; after death, the skin loses that charge within a few days. This ensures that, in the event of the death of an individual receiving allowance, others can only falsely provide proof of life for a maximum of a single allowance period (such as one month).

[0041] If a biostatistical reading is obtained, but token 102 determines that the source is not a living organism, token 102 may present an incorrect indication to individual 108. In other embodiments, such readings may be transmitted back to vitality verification server 106 for further observation of signs of fraud (e.g., multiple vitality failures for various reasons).

[0042] The token 102 also includes a processor 112 and a memory 114. According to various embodiments, the memory 114 may store various data fragments that play a role in the generation of the biometric one-time password. As shown, this information includes at least one registered biometric reading 144, a password key 146a, a unique serial number 156 for that particular token 102, and a unique identifier 158.

[0043] In the context of this specification and the following claims, the registered biostatistical reading 144 is a biostatistical reading obtained from individual 108 when individual 108 begins participation in a program using system 100. According to various embodiments, the registered biostatistical reading 144 is obtained in the same manner and using the same methods and hardware as subsequent readings obtained using the biostatistical sensor 118 with token 102. As will be discussed below, in some embodiments, one or more biostatistical sensors 118 with token 102 may be used to obtain one or more registered biostatistical readings 144. In other embodiments, the registered biostatistical reading 144 may be obtained in a different manner, still reconcilable with the data subsequently obtained using the biostatistical sensor 118 with token 102.

[0044] The cryptographic key 146a is a value known in the art for generating an OTP. In the context of this specification and the following claims, the unique identifier 158 is a unique value or data associated with a specific individual 108, and it can be used to distinguish them from other individuals utilizing system 100.

[0045] As shown, token 102 also includes a first one-time password generator 120 (hereinafter referred to as "first OTP generator 120"). It should be noted that this generator is referred to as first OTP generator 120 to distinguish it from the second OTP generator 130 found in server 106. While their ability to generate the same OTP given the same input is crucial for the operation of the system 100 envisioned herein, in some embodiments they may be implemented differently, which will be discussed further below.

[0046] OTP generator 120 is configured to obtain biometric data from sensor 118, secret password key 146a (stored in memory 114 of token 102), and in some embodiments, additional data (such as the serial number 156 of token 102 or GPS coordinates), and then apply one-way function 148 to present a one-time password that can only be derived from that particular set of values, but cannot be recovered from them. This seed information passed through one-way function 148 will be referred to as the token message and will be referenced below. Figure 3 Let's discuss this in more detail.

[0047] Some embodiments may be time-synchronized, meaning the input data includes a timestamp from the first clock module 122. In such cases, the OTP is valid only for a very short period, after which it expires and will not be verified. In other embodiments where the token 102 is communicatively coupled to the server 106, the OTP may be challenge-based, meaning it incorporates a value sent by the server 106. The actual generation of the OTP typically relies on the application of a one-way function 148 (such as a cryptographic hash function), which is impractical (e.g., the computational and time costs far outweigh the value obtained by reversing the hash) or even computationally difficult to reverse. Those skilled in the art will recognize that other methods can be used to generate one-time passwords based on seed data. The systems, methods, and apparatuses envisioned herein differ from conventional OTP implementations in that biometric data is incorporated into password generation.

[0048] The OTP generated by token 102 contains information that server 106 can use to identify the individual 108 that generated the OTP or token 102 (and thus indicate the individual 108 associated with token 102). In some embodiments, the first OTP generator 120 may incorporate a value unique to token 102, such as a serial number 156, which server 106 can extract and use to look up associated information to perform verification. This approach may be advantageous in embodiments where communication between token 102 and server 106 may require a human to transcribe the OTP. In other embodiments, the first OTP generator 120 may add a unique identifier 158 to the beginning of the sent password (e.g., “214-908703”, where 214 is the unique identifier 158). This unique identifier 158 serves as an index directly pointing to a user file 128 stored by server 106, or at least allows the server to distinguish user files 128 that may be associated with that individual 108. Alternatively, in some embodiments, the unique identifier 158 may be used in combination with a telephone number.

[0049] In some embodiments, the unique identifier 158 may be used in conjunction with a phone number associated with individual 108. As a specific example, in one embodiment, the unique identifier 158 may be a three-digit sequence, which on its own would limit the system to 1,000 unique user files. However, when used in conjunction with a phone number associated with a user file, and that number is visible to server 106, a three-digit unique identifier 158 is sufficient. Using a short unique identifier 158 reduces the length of the OTP, making it easier for users to manually submit it to server 106.

[0050] In some embodiments, the first OTP generator 120 may be configured to generate a password short enough that the individual 108 will not be overwhelmed if they must type the password, read it aloud, or send it via text message or SMS. In other embodiments in which the token 102 is communicatively coupled to the server 106, the token OTP may be longer and / or more difficult (e.g., including punctuation marks that are difficult to read aloud).

[0051] Once token 102 has generated an OTP, it needs to be transmitted to server 106 so that it can be verified. Token interface 124 facilitates this communication. In the context of this specification and the following claims, token interface 124 is a hardware element that presents the OTP generated by token 102 in a manner suitable for further use beyond token 102. In some embodiments, token interface 124 may be configured for human reception. For example, in some embodiments, token interface 124 may include display 150 or a screen to visually communicate the OTP to individual 108, who then (e.g., using mobile device 142) reports the OTP to vitality verification server 106. This will be referenced below. Figure 3 Further discussion. Other embodiments may employ speaker 152 for relaying OTP to individual 108 or via voice interface 140 of server 106. Still other embodiments may implement other output devices known in the art, such as token interface 124.

[0052] According to various embodiments, the token interface 124 can be configured for machine-to-machine communication, either directly or via a network 110 (e.g., the Internet, a cellular network, etc.). In one embodiment, the token interface 124 can be a conventional network interface 136, such as a Wi-Fi or cellular modem, or a wired connection. In other embodiments, the token interface 124 can be configured to connect to a network-enabled intermediate device (e.g., a Bluetooth connection to a mobile device 142 communicating with server 106, a USB interface 154 for sending OTPs to server 106 when a network-enabled computer is plugged in, etc.). Some embodiments may have more than one token interface 124, such as... Figure 1B As shown in the image.

[0053] As shown, some embodiments of token 102 may further include a GPS receiver 162. Incorporating GPS location into the generation of the token OTP, in addition to biometric data, adds another layer of easily collected data, which will further complicate any fraudulent attempts, especially on a scale larger than a single beneficiary. For example, if an individual or group acquires the technical sophistication required to forge biometric signals from a living person, they will also have to spoof GPS signals or determine which portion or subset of the GPS location is being fed into the one-way function of each token 102, further reducing the scalability of any fraudulent activity.

[0054] Furthermore, in some embodiments, the GPS location can be used to determine the location of the token 102 when the OTP is generated, to verify that location-specific allowances (e.g., disaster relief, economic recovery relief, etc.) are paid to individuals located in the necessary area. Additionally, in some embodiments, the token 102 can be configured such that it will generate the OTP only if the GPS location has been determined to be within a designated area or geofence.

[0055] In some embodiments, token 102 may be a dedicated single-purpose device, such as a conventional OTP token device. In such embodiments, token 102 may resemble a key card or other small device. In other embodiments, token 102 may act as a computer peripheral, such as a USB drive, which can directly input OTP into a network interface or transmit OTP directly over network 110 via a socket when plugged into a computer. Alternatively, in some embodiments, token 102 may be reusable or otherwise erasable, allowing user-specific information to be removed and the device to be reset to pre-registration conditions.

[0056] In other embodiments, token 102 can be implemented in a non-single-purpose hardware environment. For example, token 102 can be implemented on mobile device 142 such as a smartphone, and can utilize sensors common to many smartphones (e.g., fingerprint scanners, cameras, depth-sensing cameras, etc.) to perform biometric scanning and viability determination. The OTP generated by this virtual token 102 can be transmitted directly to server 106 via network 110. Alternatively, in cases where network connectivity via mobile device 142 is unavailable, the generated OTP can be presented to individual 108 for transmission in a conventional manner (e.g., telephone call, etc.). Implementing token 102 on mobile device 142 is advantageous because it reduces the cost of implementing and deploying system 100. Individual 108 is less likely to lose mobile device 142, which is used regularly, than a small keycard device used only once a month, for example. Furthermore, the computing power of mobile device 142 can facilitate OTP generation, which might be computationally too intensive for an affordable single-purpose device.

[0057] As shown, the registration client device 104 includes a processor 112, a memory 114, and a client network interface 136; some embodiments also include one or more biostatistical sensors 118. The registration client device 104 (hereinafter referred to as "client device 104") is used to register an individual 108 in the vitality verification system 100, such that a token 102 can be associated with and issued to that individual. The client device 104 receives information from the individual 108 and can also initialize the token 102 for use by a specific individual. References will follow below. Figure 3 Let's discuss the registration process in more detail.

[0058] In some embodiments, the registration client device 104 may include a biostatistical sensor 118 to capture and build registration biostatistics 144, which will be used by the token 102 for verification. In other embodiments, the client device 104 may instead rely on the token 102, which is communicatively coupled to it, thereby allowing the use of the token sensor 118 to build the registration biostatistics 144. This would advantageously account for variations in readings obtained from different sensors and could reduce the error rate in performing verification and registration. Furthermore, in some embodiments, the client device 104 also receives its unique serial number 156 from the token 102, which will be transmitted to the server 106 along with other identifying information required to create a user file 128 for the individual 108.

[0059] According to various embodiments, client device 104 can communicatively couple with token 102 to obtain desired information or to send information, such as password key 146a, to token 102. Network interface 136 of client device 104 can allow such communication, as well as communication with server 106. For example, in one embodiment, client device 104 may be able to communicate using Bluetooth and via Wi-Fi connection to network 110. In some embodiments, client device 104 can communicate with token 102 via a wired connection (such as a USB interface) to reduce the cost of token 102.

[0060] In some embodiments, the client device 104 may be a dedicated piece of hardware. In other embodiments, it may be implemented as software in a multi-purpose hardware environment. For example, in some embodiments, the registered client device 104 may be a smartphone, a desk, a laptop computer, or a desktop computer. The advantage of this implementation is that it eliminates the need to issue new hardware to the grant provider as part of launching the system 100 envisioned herein; instead, only one piece of software needs to be installed, thereby reducing both the time and monetary costs of implementation.

[0061] The vitality verification server 106 (hereinafter referred to as "server 106") is responsible for maintaining records of each individual 108 and token 102 used by system 100, and verifying the vitality of individual 108 by generating a server OTP and comparing it with the token OTP received by server 106. As shown, server 106 includes a processor 112 and a memory 114, as well as a second clock module 132 and a second OTP generator 130.

[0062] According to various embodiments, the second clock module 132 produces substantially the same output as the first clock module 122. However, implementing system 100 using tokens 102 that are always synchronized with the second clock module 132 of server 106 would unnecessarily increase the cost of each token 102. Instead, some embodiments of the system 100 and methods envisioned herein are capable of handling potentially out-of-sync clock modules. This will be explained below. Figure 3 Discussed in the context of [the relevant context].

[0063] As previously mentioned, the first OTP generator 120 of token 102 and the second OTP generator 130 of server 106 are identical in the extent to which they apply the same one-way function 148 and produce the same OTP given the same input. In some embodiments, they may be literally identical in software and / or hardware implementation. However, in other embodiments, the second OTP generator 130 may be implemented in a different manner than the first OTP generator 120 of token 102. While token 102 only needs to generate a single OTP for each period of time in which it will be valid, server 106 may receive hundreds or thousands of authentication requests simultaneously and may need to generate one-time passwords many orders of magnitude faster than token 102. In some embodiments, the second OTP generator 130 may be implemented on special hardware that is too expensive to implement in every token 102, such as FPGA or ASIC solutions, or GPUs suitable for evaluating the one-way function 148 faster than the general-purpose CPU or microcontroller used by token 102.

[0064] Server 106 verifies an OTP by matching the OTP received through server interface 134 with an OTP generated by server 106 using information stored in user file 128. According to various embodiments, user file 128 may be stored in a database 116 communicatively coupled to server 106, while in other embodiments, user file 128 may be stored within server 106. In some embodiments, database 116 may be located locally on server 106, while in other embodiments, database 116 may be discrete, remote, or even cloud-based. Reference will be made below. Figure 2 Let's discuss user file 128 in more detail.

[0065] In addition to user file 128, in some embodiments, server 106 may also store multiple password keys 146, each password key being paired with a sequence number 156 assigned to it by token 102. Reference will be made below. Figure 3 The use of these keys will be discussed further.

[0066] Server 106 also includes at least one server interface 134. Similar to token interface 124, server interface 134 facilitates the reception of an OTP generated by token 102. In some embodiments, server interface 134 may include network interface 136 for machine-to-machine communication over network 110. For example, in some embodiments, server 106 communicates with registered client device 104 over network 110 through such an interface. In other embodiments, server interface 134 may also allow people to provide the OTP using communication device 142 (e.g., telephone, smartphone, web portal, text messaging, etc.). Example interfaces include, but are not limited to, SMS 138, USSD, web portal, voice recognition or other voice interface 140, VoIP, direct communication via app, and the like.

[0067] Server interface 134 is also capable of communicating with other devices, such as third-party server 160. In some embodiments, system 100 may be implemented by the agency or entity providing the allowance, and the release of the allowance may be internalized to server 106. In other embodiments, instructions to release funds in response to verified vitality may be sent to different servers 160 (e.g., a pre-existing or legacy system used by the agency to release funds). In still other embodiments, system 100 may be implemented across multiple agencies or departments; receipt of the OTP results in the identification of individual 108 and the party that should be notified upon successful vitality verification (e.g., the IP address of server 160, network hooks, etc.).

[0068] In some embodiments, server 106 may be a single machine. In other embodiments, server 106 may be implemented across multiple machines, operate as a single machine, or be implemented in a load-sharing environment. In still other embodiments, server 106 may be implemented in a shared computing environment via virtualization.

[0069] Figure 2 This is a schematic view of a non-limiting example of a user file 128 stored in a database 116 on server 106. User file 128 contains information unique to token 102 and information unique to the individual 108 associated with that token 102. This information allows server 106 to generate OTPs that match the OTPs provided by token 102.

[0070] As shown, user file 128 may include a unique identifier 158, which can be used to locate user file 128 associated with an OTP received by server 106. User file 128 also includes data required to generate a password, such as a password key 146a, a serial number 156, and biometric data 144 obtained during registration (hereinafter referred to as "registration biometric data 144"). According to various embodiments, user file 128 may also include a telephone number 200 that is being verified and is unique to individual 108, as well as multiple second telephone numbers 200 associated with that individual. In embodiments where individual 108 can provide their OTP via SMS or voice call, system 100 can use the identity of the starting point, in this case, the telephone number, to identify the correct user file 128. In cases where multiple user files 128 are associated with the same telephone number 200 (e.g., more than one allowance recipient uses the same telephone line), the unique identifier 158 can be used to focus on the correct user file 128. In such cases, the unique identifier 158 will only need to be long enough to distinguish the maximum possible number of individuals 108 using the same telephone line.

[0071] In some embodiments, this information can be used to quickly identify the correct user file 128 upon receiving a voice call reporting an OTP via server interface 134. User file 128 may also include a history of both successful and failed previous verification attempts. In embodiments of system 100 that provides services to multiple agencies or entities, as previously discussed, user file 128 may also identify who and how to contact them when verifying an individual's vitality.

[0072] In some embodiments, user file 128 may also instruct allowance provider 202. Where the vitality verification system 100 is being used to verify the vitality of an individual receiving allowances from more than one institution, user file 128 may indicate which institution successfully delivered the verification, and in some embodiments, which failed, allowing for the release of funds (or initiation of an investigation). In some embodiments, user file 128 may indicate the identity of the allowance provider, while in other embodiments, it may simply instruct server 106 to send it a message identifying individual 108 and an IP address or domain name containing information about their vitality.

[0073] Figure 3This is a non-limiting network view of a process flow for a method of viability verification using biostatistical OTPs. Individual 108 must register in system 100 before token 102 can begin verifying viability and generating an OTP. Registration begins with capturing registration biostatistics 144. See circle "1". In some embodiments, the registration client device 104 may use its own sensor 118 to capture this data 144, while in other embodiments, token 102 may be used as part of initialization to capture the data 144, and then it may be transmitted to the registration client device 104.

[0074] In some embodiments, fragments or instances of multiple biometric data 144 can be captured from individual 108. For example, in one embodiment utilizing a fingerprint scanner, fingerprints of multiple fingers can be captured during registration, allowing individual 108 to use any of their fingers to confirm their viability. Such flexibility may be advantageous when individual 108 is elderly, and conditions such as arthritis may develop, making it difficult or painful to place one or more fingers on sensor 118 after registration.

[0075] If the registration biometrics 144 are captured using the biometric sensor 118 on the client device 104, the data is then sent to the token 102 to be assigned to the individual. See circle “2”. The biometrics 144 captured at registration will be used to determine whether the person scanned by the token 102 is the registered individual 108.

[0076] Next, token 102 sends to client device 104 the information that server 106 will need to generate the OTP for verification. See circle "3". This information may include the token 102's serial number 156 and unique identifier 158 (or this may be assigned by client device 104). In some embodiments, this information may also include a password key 146a inherent to (or defined by) token 102. In other embodiments, where password key 146a is assigned to token 102 at manufacturing time, server 106 can retrieve password key 146a from a list local to server 106 using serial number 156. This list contains the serial number 156 and password key 146a defined for token 102 at manufacturing time. In embodiments where biostatistical sensor 118 using token 102 obtains registration biostatistics data 144, this data is also sent to client device 104.

[0077] Other communications between the registration client device 104 and the token 102 may include, but are not limited to, software updates, key updates (e.g., in case the password key is compromised, etc.), modifications to biometric matching thresholds (e.g., how close the biometric data needs to be to be considered a match, etc.), the length of the OTP validity period, and clock synchronization. In some embodiments, some of this information may also be transmitted to the token 102 after registration using the mobile device 142 associated with the individual 108.

[0078] In some embodiments, registration is performed using a mobile device 142 as a client device 104, operating in provisioning mode. A token 102 is used to capture registration biometrics 144 of an individual 108, whose information (e.g., name, phone number, etc.) is captured by an application running on the mobile device 142 or input via a network interface connected to the server 106. In some embodiments, the application facilitates a direct connection between the token 102 and the server 106, bridging the two with a network connection and a Bluetooth connection. The token 102 sends the registration biometrics 144 (or template) to the server 106 via the client device 104. According to various embodiments, the server 106 sends information to the token 102 via the client device 104, which may include, but is not limited to, a password key 146a, a matching threshold for the biometrics, the OTP validity period, the duration of the OTP as shown on the token 102 display 150, and the like. In the case of re-registration (e.g., individual 108 has lost their token 102, token 102 has been corrupted, etc.), server 106 can provide registration data 144 to token 102 without rescanning individual 108.

[0079] Registration data (e.g., registration biometrics 144, serial number 158, etc.) is packaged by client device 104 and sent to server 106. See circle "4". It should be noted that in some embodiments, the role of client device 104 can be played by server 106 itself, either locally on token 102 or remotely via network 110.

[0080] After receiving the information from the client device 104, the server 106 creates a user file 128 and stores it in the database 116. See circle "5". This completes the registration process.

[0081] Regarding the password key 146, in some embodiments, key 146a is assigned to token 102 during manufacturing. In some embodiments, token 102 provides this key as part of the registration process; in other embodiments, server 106 may be able to access a list of password keys 146 that match token serial number 158, ensuring that the password keys are never publicly sent over the network (assuming server 106 obtains the list securely).

[0082] In other embodiments, as part of the registration process, server 106 may generate a password key 146 itself and issue it to token 102. In still other embodiments, token 102 may have the capability to automatically generate a password key 146a during registration and share that password key 146a with server 106 via registration client 104 or via network 110 through a direct connection, as previously discussed.

[0083] Now, once the payment or allowance supply period begins, individual 108 will need to generate a token OTP302a using their token 102 so that server 106 can verify that they are still alive and that the funds should be released. This process begins with individual 108 being scanned by the biometric sensor 118 of token 102. See circle “6”. Token 102 then compares the token biometric reading 300 with the registration biometric data 144 stored in memory 114. As previously mentioned, in some embodiments, registration may capture multiple instances of biometric data 144, such as fingerprints of more than one finger of the individual. The token biometric reading 300 will then be compared with all registration data 144 to see if any captured instances match the current scan (e.g., individual 108).

[0084] In some embodiments, if the comparison result is within a predefined tolerance (e.g., 70%, etc.), then reading 300 and registration data 144 will be considered a match. The predefined tolerance will depend on the specific type or model of the biostatistical sensor 118 used. A sensor 118 capable of providing highly consistent readings can be implemented with a higher tolerance than a less reliable sensor 118. In some embodiments, if the registration and current data do not match, an error can be indicated to individual 108, who needs to try again.

[0085] While capturing biometric data 300, token 102 also determines whether the source of the biometric data 300 was alive at the time of scanning. According to various embodiments, the determination of liveness can be performed using the scanned data. For example, in cases where biometric data includes facial recognition using a depth-sensing camera, subtle movements and eye gaze can be used to distinguish between a living person and a photograph or mask. In other embodiments, the determination of liveness can be performed using sensor 118 for capturing data 300 instead of data 300 itself. For example, in embodiments utilizing a capacitive fingerprint scanner, the scanned fingerprint must belong to a living individual to have the specific type of surface charge required to register on the capacitive sensor. A dead or artificial individual would not be likely to have such a charge. Other methods include, but are not limited to, detecting pulse and / or respiration via video capture and the like.

[0086] If the scanned biostatistics match registered biostatistics 144, an OTP 302a is generated. See circle “7”. According to various embodiments, the token OTP 302a is generated by applying a one-way function to the token message 306a. The token message 306a includes a cryptographic key 146a specific to the token 102 and individual 108, registered biostatistics readings 144 (e.g., registered biostatistics readings 144 that fully match biostatistics readings 300 obtained for the vitality verification instance, standard biostatistics readings 144 that will also be used by the server 106 for OTP generation, etc.), and a first timestamp 308a from the first clock module 122, indicating the time when the OTP 302a was generated. In other embodiments, additional data may be included in the token message 306a before it is passed through the one-way function 148 to generate the token OTP 302a.

[0087] It should be noted that in some embodiments, the registered biostatistics data 144 converts the raw data obtained from the biostatistics sensor 118 into a “template” that preserves unique features in a more concise form, thereby allowing for easier storage and processing for comparison and application of the one-way function 148.

[0088] According to various embodiments, OTP 302a is sent to server 106 by itself. However, in other embodiments, it includes... Figure 3In the non-limiting example shown, OTP 302a is encapsulated as part of a token one-time password string 304. In the context of this specification and the following claims, the token OTP string 304 is a string that includes the token OTP 302a and additional information that the auxiliary server 106 identifies the correct user file 128 and correctly verifies the OTP 302a. Exemplary data that may be part of the OTP string 304 may include, but is not limited to, a first timestamp 308a, a portion of the first timestamp 308a (e.g., multiple numbers taken from a specific position within the timestamp), a unique identifier 158, and the like. Alternatively, these additional pieces of information may be mixed with the characters constituting the OTP 302a for additional obfuscation.

[0089] In some embodiments, particularly where OTP 302a is transmitted directly from token 102 to server 106 or via another device as part of a machine-to-machine interface, the OTP string 304 may be long. In other embodiments, the OTP string 304 may need to be provided to server 106 with the assistance of individual 108 or another person (e.g., typing an SMS message, reading it aloud over a telephone, etc.). Limiting the OTP string 304 to a feasible length, or limiting it to easily distinguishable characters (e.g., no punctuation characters, no mix of zeros and the letter O, etc.), is beneficial. According to some embodiments, the length of the OTP string 304 may be limited to between six and ten characters. In other embodiments, the length of the OTP string 304 may be between ten and 14 characters. In still other embodiments, the OTP string 304 may be longer than 14 characters.

[0090] When generating OTP 302a and subsequently forming OTP string 304, token OTP string 304 is sent to server 106 via at least one token interface 124. See circle "8". In some embodiments, this can be done directly via a connection to network 110, while in other embodiments, OTP string 304 can be relayed to individual 108 (e.g., via display 150, speaker 152, etc.) and then provided to server 106 via mobile device 142 which is not token 102.

[0091] In some embodiments, this can be accomplished by making a telephone call 312 to the voice interface 140 of server 106. As a particular example, the voice interface 140 may be an automated system with voice prompts and voice recognition that requires the caller to read the OTP string 304 (with an option to provide instructions if needed), and reads back the received string to verify that it was heard correctly. Alternatively, the voice interface 140 may indicate to the caller whether the provided OTP string 304 has been verified by server 106 or if there is a problem.

[0092] In some embodiments, the OTP string 304 can be transmitted to the server 106 via the SMS interface 138. Individual 108 can send an SMS message 314 to the SMS interface 138 containing the OTP string 304 and receive a returned message indicating whether it has been successfully verified by the server 106 or if there is a problem. In some embodiments, individual 108 can transcribe the OTP string 304, read it from the display 150 of the token 102, and input it into the mobile device 142. In other embodiments, the token 102 can be communicatively coupled to the mobile device 142 via a network interface 136 (e.g., Bluetooth, self-organizing Wi-Fi, local Wi-Fi, etc.) and the OTP string 304 can be directly input into the mobile device 142 for transmission via SMS (e.g., as part of an application, etc.).

[0093] In other embodiments, token 102 can send OTP string 304 to server 106 on network 110 by registering client device 104, regardless of whether device 104 is an application running on a multi-purpose computing device (e.g., laptop computer, mobile device 142, desktop computer, etc.) or a dedicated piece of hardware.

[0094] In some embodiments, where the registration client device 104 exists as an application running on a mobile device 142 associated with individual 108, the client device 104 (again, the application on the mobile device) can operate in an operational mode. After a connection with the token 102 is established via network interface 136 (e.g., Bluetooth, self-organizing Wi-Fi, local Wi-Fi, etc.), the token 102 passes the OTP string 304 to the client device 104 for delivery to the server 106. Alternatively, in some embodiments, the token 102 sends the OTP string 304 directly to the server 106 via a secure connection through the client device 104, and the client device 104 never sees the plaintext form of the OTP string 304.

[0095] In some embodiments, client device 104 (again, running as an application on mobile device 142) can send OTP string 304 to server 106 via SMS interface 138 by activating a local SMS application on mobile device 142, entering the number of SMS interface 138 of server 106, and adding OTP string 304 to the message field.

[0096] Furthermore, in some of these embodiments where the token 102 communicates with client device 104 or mobile device 142 (or, in some cases, the same device), the token 102 can resynchronize the first clock module 122 with a time server on the Internet to avoid errors due to clock drift. This allows the use of a clock module to construct the token 102, which is allowed to drift within an OTP window (discussed below) typically for a one-month allowance period. This means that the token 102 can be constructed using the less expensive clock module 122, thereby reducing costs without sacrificing functionality.

[0097] After receiving the OTP string 304 through one of the server interfaces 134, server 106 extracts the additional information added to OTP 302a by token 102 (e.g., unique identifier 158, serial number 156, timecode, a portion of the timecode, etc.) and uses it to retrieve the appropriate user file 128. See circle "9". Using the retrieved information, server 106 then uses the user's data (e.g., registration biometrics 144, password key 146a, etc.) to generate server OTP 302b in the same way that token 102 generated token OTP 302a. As previously discussed, although the second OTP generator 130 can be implemented in a different hardware environment, it applies the same one-way function 148 used by the first OTP generator 120 of token 102.

[0098] In some embodiments, the server interface 134 receiving the OTP string 304 may be able to determine the starting point 310 (e.g., the phone number sending the SMS or voice data, the IP address of the network connection, the MAC address of the device, etc.). In some embodiments, the starting point 310 may be used to locate the appropriate user file 128. Alternatively, the starting point 310 may be used in conjunction with a unique identifier 158 included as part of the OTP string 304 in the token OTP 302a.

[0099] According to various embodiments, a server OTP 302b is generated using a second OTP generator 130, and a one-way function 148 is applied to a server message 306b. Similar to the token message 306a, the server message 306b includes a password key taken from the user file 128, registration biometric data 144 taken from the user file 128 and indicated by the OTP string 304 (in the case where there are multiple registration data samples, a simple numeric indicator will be sufficient to indicate which sample is used in the OTP generation), and a second timestamp 308b from the second clock module 132 of the server 106.

[0100] According to various embodiments, if the biometric data used to generate the OTP string 304 (i.e., registration data 144 that is sufficiently similar to the input received by the biometric sensor 118 during verification) matches the biometric data 144 of the user file 128, and the password key 146a also matches, then the two generated OTPs will be identical if the timestamps are the same. In some embodiments, the timestamp is rounded to the increment of the OTP period (also referred to as the computational basis), and the time window in which the individual 108 needs to submit the OTP string 304 generated by the token 102 to the server 106 for verification can be equivalent to one or more computational bases. In some embodiments where the time window consists of multiple computational bases (e.g., X computational bases), the server 106 can store the last X generated OTPs for comparison with incoming OTPs. OTPs generated within the same computational base will be identical, and OTPs received within the time window can be verified by the last X OTPs generated by the server, which represent the X computational bases constituting the time window. Once the time window has passed, the earliest OTP within that window is no longer valid, and another OTP needs to be generated.

[0101] A common problem with time-based one-time cryptographic devices is clock drift. In some embodiments, server 106 may also generate OTP 302b for multiple consecutive time periods to account for the delay in the arrival of token OTP 302a at server 106 and / or from clock drift.

[0102] According to various embodiments, the system 100 and method envisioned herein utilize its unique approach, employing OTP technology, to address the issues of clock synchronization and clock drift. Traditional OTP applications typically target two-factor authentication solutions, where the generated one-time password expires within minutes, if not within seconds. In such implementations, clock drift and clock synchronization with server 106 can quickly become problematic.

[0103] In the system 100 envisioned in this paper, the verification of OTP 302a occurs on the timescale of allowance distribution, typically monthly or bi-weekly. Verification can occur at any time during that payment period. In many instances, individual 108 may not be able to send the OTP string 304 from their location. As a specific example, in remote areas of Africa, individual 108 can scan their fingerprint with token 102 to verify their vitality and receive the OTP string 304. However, due to the lack of cellular signal in their area, they may have to wait one or two days to travel to the city or wait for a family member to travel there and send an SMS message. In such cases, the ability to verify the OTP even 2 or 3 days after its generation is highly beneficial.

[0104] This can be achieved in embodiments where the computational basis is measured in days, rather than seconds as done in traditional OTP systems. For example, if the computational basis is a day starting at midnight, then every OTP generated by individual 108 during that day will be identical. In some embodiments, the token and server can use the same biometrics (e.g., index finger) to generate their OTPs, and the token can register multiple biometric readings for comparison with sensor data obtained upon verification. As a specific example, in one embodiment, the token can register all ten fingers of an individual, so they can scan any finger that facilitates vitality verification and identity determination. Once the token has been verified for identity and vitality, it generates an OTP to be sent to the server using the same biometrics used by the server for each OTP generated.

[0105] Furthermore, in some embodiments, OTP generators 120 and 130 may operate using a reference time instead of the current time. The first clock module 122 and the second clock module 132 are synchronized such that they are simultaneously within the same verification window (or computational basis). This means that any time within this window is considered the same time, chosen by any method but agreed upon by both modules (e.g., both use the beginning of the window, both use the middle of the window, etc.). Since the computational basis is much longer than typically used in time-based OTP systems, using a reference time means that any clock drift will be swallowed up by the size of the time window. Furthermore, as described above, periodic resynchronization with an internet time source will further mitigate the clock drift problem.

[0106] Some embodiments utilize some of these methods. Other embodiments combine a longer computational basis (e.g., ordered by days, etc.) using a reference time and calculations of the OTP prior to the current reference time to ensure that no false negatives are issued when verifying an individual's OTP string 304.

[0107] The server then compares the token OTP 302a with the server OTP. See circle "10". If they do not match, the server 106 can communicate with the individual, indicating that secondary authentication is required. This can be done using traditional methods (e.g., live phone calls, visits, etc.) or alternative electronic methods.

[0108] If they do match, then individual 108 has been verified as alive. This is then forwarded to the appropriate party (e.g., third-party server 160) so that the funds can be released. See circle "11".

[0109] Figure 4 These are schematic diagrams of a particular computing device 400 and a particular mobile computing device 450 that can be used to perform and / or implement any of the embodiments disclosed herein. In one or more embodiments, Figure 1A The vitality verification server 106, the registration client device 104, the database 116 and / or the third-party server 160 may be a specific computing device 400, while the mobile device 142 and the vitality verification token 102 may be a mobile device 450.

[0110] A particular computing device 400 may represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and / or other suitable computers. A particular mobile computing device 450 may represent various forms of mobile devices, such as smartphones, camera phones, personal digital assistants, cellular phones, tablets, and other similar mobile devices. According to one embodiment, the components shown herein, their connections, couplings, and relationships, as well as their functions, are meant to be exemplary only and are not intended to limit the described and / or claimed embodiments.

[0111] A particular computing device 400 may include a processor 402, a memory 404, a storage device 406, a high-speed interface 408 coupled to the memory 406 and a plurality of high-speed expansion ports 410, and a low-speed interface 412 coupled to a low-speed bus 414 and the storage device 406. In one embodiment, each of the components to date may be coupled to each other using various buses and may be mounted on a common motherboard and / or otherwise suitably mounted. According to one embodiment, the processor 402 may process instructions for execution in the particular computing device 400, including instructions stored in the memory 404 and / or the storage device 406, to display graphical information of a GUI on an external input / output device, such as a display unit 416 coupled to the high-speed interface 408.

[0112] In other embodiments, multiple processors and / or multiple buses may be suitably used, along with multiple memories and / or memory types. Furthermore, multiple specific computing devices 400 may be coupled together, with each device providing a portion of the necessary operation (e.g., as a server group, a set of blade servers, and / or a multiprocessor system).

[0113] Memory 404 may be coupled to a particular computing device 400. In one embodiment, memory 404 may be volatile memory. In another embodiment, memory 404 may be non-volatile memory. Memory 404 may also be another form of computer-readable medium, such as a disk and / or optical disk. Storage device 406 may be capable of providing mass storage for a particular computing device 400. In one embodiment, storage device 406 may include a floppy disk device, a hard disk device, an optical disk device, a magnetic tape device, flash memory, and / or other similar solid-state memory devices. In another embodiment, storage device 406 may be an array of devices among the aforementioned computer-readable media, such as computer-readable media, and / or an array of devices including devices in a storage area network and / or other configurations.

[0114] A computer program may consist of instructions that, when executed, perform one or more methods, such as those described above. The instructions may be stored in memory 404, storage device 406, memory coupled to processor 402, and / or propagating signals.

[0115] High-speed interface 408 can manage bandwidth-intensive operations of a specific computing device 400, while low-speed interface 412 can manage lower bandwidth-intensive operations. Such a functional allocation is merely exemplary. In one embodiment, high-speed interface 408 may be coupled to memory 404, display unit 416 (e.g., via a graphics processor and / or accelerator), and to multiple high-speed expansion ports 410 that can accept various expansion cards.

[0116] In this embodiment, the low-speed interface 412 can be coupled to the storage device 406 and the low-speed bus 414. The low-speed bus 414 can be a wired and / or wireless communication port (e.g., a Universal Serial Bus (“USB”), Bluetooth port, Ethernet port, and / or wireless Ethernet port). The low-speed bus 414 can also be coupled to the scanning unit 428, printer 426, keyboard, mouse 424, and networking devices (e.g., switches and / or routers) via a network adapter.

[0117] The specific computing device 400 can be implemented in a variety of different forms, as shown in the figures. In one embodiment, the specific computing device 400 can be implemented as a standard server 418 and / or a group of such servers. In another embodiment, the specific computing device 400 can be implemented as part of a rack-mount server system 422. In yet another embodiment, the specific computing device 400 can be implemented as a general-purpose computer 420, such as a laptop or desktop computer. Alternatively, components from the specific computing device 400 can be combined with another component in the specific mobile computing device 450. In one or more embodiments, the entire system can consist of a plurality of specific computing devices 400 and / or a plurality of specific computing devices 400 coupled to a plurality of specific mobile computing devices 450.

[0118] In one embodiment, a particular mobile computing device 450 may include a mobile-compatible processor 452, a mobile-compatible memory 454, and input / output devices, among other components, particularly such as a mobile display 466, a communication interface 472, and a transceiver 458. The particular mobile computing device 450 may also provide storage devices, such as microdrives or other devices, to provide additional storage. In one embodiment, the components indicated so far are coupled to each other using various buses, and several components may be mounted on a common motherboard.

[0119] The mobile-compatible processor 452 can execute instructions in a specific mobile computing device 450, including instructions stored in the mobile-compatible memory 454. The mobile-compatible processor 452 can be implemented as a chip set including individual and multiple analog and digital processors. The mobile-compatible processor 452 can provide, for example, coordination of other components of the specific mobile computing device 450, such as control of the user interface, applications running on the specific mobile computing device 450, and wireless communications of the specific mobile computing device 450.

[0120] The mobile-compatible processor 452 can communicate with the user via a control interface 456 and a display interface 464 coupled to a mobile display 466. In one embodiment, the mobile display 466 may be a thin-film transistor liquid crystal display (“TFTLCD”), an organic light-emitting diode (“OLED”) display, or another suitable display technology. The display interface 464 may include appropriate circuitry for driving the mobile display 466 to present graphics and other information to the user. The control interface 456 can receive commands from the user and translate them for submission to the mobile-compatible processor 452.

[0121] In addition, an external interface 462 may be provided to communicate with the mobile-compatible processor 452, enabling short-range communication between the specific mobile computing device 450 and other devices. The external interface 462 may provide wired communication in some embodiments, or wireless communication in others, and multiple interfaces may be used.

[0122] Mobile-compatible memory 454 can be coupled to a specific mobile computing device 450. Mobile-compatible memory 454 can be implemented as volatile or non-volatile memory. Expansion memory 478 can also be coupled to a specific mobile computing device 450 via expansion interface 476, which may include, for example, a single in-line memory module (“SIMM”) card interface. Expansion memory 478 can provide additional storage space for a specific mobile computing device 450, or it can store applications or other information for the specific mobile computing device 450.

[0123] Specifically, the extended memory 478 may include instructions for performing the processes described above. The extended memory 478 may also include security information. For example, the extended memory 478 may be provided as a security module for a specific mobile computing device 450 and may be programmed with instructions that authorize the secure use of that specific mobile computing device 450. Furthermore, security applications along with additional information, such as placing identification information on the SIMM card in an unbreakable manner, may be provided on the SIMM card.

[0124] Mobile-compatible memory 454 may include volatile memory (e.g., flash memory) and non-volatile memory (e.g., non-volatile random access memory (“NVRAM”). In one embodiment, a computer program includes a set of instructions that, when executed, perform one or more methods. The instruction set may be stored in mobile-compatible memory 454, extended memory 478, memory coupled to mobile-compatible processor 452, and propagated signals that may be received, for example, via transceiver 458 and / or external interface 462.

[0125] A specific mobile computing device 450 can wirelessly communicate via a communication interface 472, which may consist of digital signal processing circuitry. The communication interface 472 can provide communication using various modes and / or protocols, such as the Global System for Mobile Communications (“GSM”) protocol, Short Message Service (“SMS”) protocol, Enhanced Messaging System (“EMS”) protocol, Multimedia Messaging Service (“MMS”) protocol, Code Division Multiple Access (“CDMA”) protocol, Time Division Multiple Access (“TDMA”) protocol, Personal Digital Cellular (“PDC”) protocol, Wideband Code Division Multiple Access (“WCDMA”) protocol, CDMA2000 protocol, and General Packet Radio Service (“GPRS”) protocol.

[0126] Such communication can be performed via transceiver 458 (e.g., an RF transceiver). Additionally, short-range communication can be performed using transceivers such as Bluetooth, Wi-Fi, and / or others. Furthermore, the GPS (“Global Positioning System”) receiver module 474 can provide additional navigation-related and location-related wireless data to a specific mobile computing device 450, which can be appropriately used by software applications running on the specific mobile computing device 450.

[0127] The specific mobile computing device 450 can also use an audio codec 460 for audible communication, which receives voice information from a user and converts it into usable digital information. The audio codec 460 can also generate audible sounds for the user, such as through a speaker (e.g., in a handheld smartphone of the specific mobile computing device 450). Such sounds can include sounds from voice call, recorded sounds (e.g., voice messages, music files, etc.), and may also include sounds generated by applications operating on the specific mobile computing device 450.

[0128] The specific mobile computing device 450 can be implemented in a variety of different forms, as shown in the figure. In one embodiment, the specific mobile computing device 450 can be implemented as a smartphone 468. In another embodiment, the specific mobile computing device 450 can be implemented as a personal digital assistant (“PDA”). In yet another embodiment, the specific mobile computing device 450 can be implemented as a tablet device 470.

[0129] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuits, integrated circuits, application-specific integrated circuits (“ASICs”), computer hardware, firmware, software applications, and combinations thereof. These various embodiments may include embodiments in one or more computer programs executable and / or interpretable on a programmable system, which includes a programmable processor, which may be dedicated or general-purpose, coupled to receive and transmit data and instructions from a storage system, an input device, and at least one output device.

[0130] These computer programs (also referred to as programs, software, software applications, and / or code) include machine-readable instructions for a programmable processor and can be implemented in high-level programming and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and / or “computer-readable medium” refer to any computer program product, apparatus, and / or device (e.g., disk, optical disk, memory, and / or programmable logic device (“PLD”) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0131] To provide interaction with the user, the systems and techniques described herein can be implemented on a computing device having a display device (e.g., a cathode ray tube (“CRT”) and / or liquid crystal (“LCD”) monitor) for displaying information to the user, and a keyboard and mouse for the user to provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, and / or tactile feedback), and input from the user can be received in any form, including acoustic, speech, and / or tactile input.

[0132] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), middleware components (e.g., application servers), frontend components (e.g., client computers with graphical user interfaces and / or web browsers through which users can interact with embodiments of the systems and technologies described herein) and combinations thereof. The components of the system can also be coupled via communication networks.

[0133] The communication network may include a local area network (“LAN”) and a wide area network (“WAN”) (e.g., the Internet). The computing system may include clients and servers. In one embodiment, the client and server are geographically separated but interact through the communication network.

[0134] Several embodiments have been described. However, it will be understood that various modifications can be made without departing from the spirit and scope of the claimed invention. Furthermore, the logical flow depicted in the figures does not require the specific order or sequential order shown to achieve the desired results. Additionally, other steps may be provided, or steps may be removed from the described flow, and other components may be added to or removed from the described system. Therefore, other embodiments are within the scope of the following claims.

[0135] It will be understood that the various systems, methods and apparatuses disclosed herein may be embodied in a machine-readable and / or machine-accessible medium compatible with a data processing system (e.g., a computer system), and / or may be executed in any order.

[0136] The structures and modules in the figures may be shown as distinct and may communicate only with a few specific structures, not with other structures. These structures may be combined with each other, may perform overlapping functions, and may communicate with other structures not shown in the figures. Therefore, the description and / or figures should be considered illustrative rather than restrictive.

[0137] In the examples, embodiments, and implementations described above, those skilled in the art will understand that other biostatistical sensors and interfaces can be combined with or substituted for the provided sensors and interfaces. Where the above description relates to specific embodiments of systems and methods for vitality verification, it should be readily apparent that various modifications can be made without departing from the spirit of the work, and that these embodiments and implementations can also be applied to other vitality and / or authentication technologies. Therefore, the disclosed subject matter is intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of this disclosure and the knowledge of those skilled in the art.

Claims

1. A system for viability verification, comprising: A vitality verification token comprising a processor, memory, a biostatistical sensor, a first one-time password generator, a first clock module, and a token interface, wherein the vitality verification token is configured to: An individual's token biostatistical readings are obtained using a biostatistical sensor, and the token biostatistical readings include the individual's fingerprints; The token biostatistical readings are compared with the individual's registered biostatistical readings, which were previously obtained by a biostatistical sensor and stored in memory; Determine whether an individual is alive at the time the token biostatistical reading is obtained, and determine this at least in part based on the token biostatistical reading; and Using a first OTP generator and in response to a token biostatistic reading matching a registered biostatistic reading and determining that the individual was alive when the token biostatistic reading was obtained, a token one-time password (OTP) string is generated, the token one-time password string including the token OTP generated by applying a one-way function to a token message, the token message including a password key stored in memory, a registered biostatistic reading, and a first timestamp from a clock module; A registration client device communicatively coupled to a liveness verification token, the registration client device being configured to: The biostatistical sensor receives an individual's registered biostatistical readings obtained from a vitality verification token, the registered biostatistical readings including the individual's fingerprint; and Receive a unique serial number for the vitality verification token from the vitality verification token; A vitality verification server includes a second one-time password generator, a second clock module, and at least one server interface, said at least one server interface including a server network interface communicatively coupled to a registered client device via a network, and further including an SMS interface, said vitality verification server being configured to: Receive serial number and registration biometric readings from the registered client device; Retrieve a cryptographic key from multiple cryptographic keys using a serial number; Create user files associated with an individual; Receive the token OTP string provided by the vitality verification token through the token interface via the SMS interface; A second OTP generator is used to generate a server OTP by applying a one-way function to a server message, the server message including a password key stored in a user file, a registration biometric reading stored in a user file, and a second timestamp, and the user file is retrieved using at least one of a unique identifier associated with an individual and the start point of a token OTP string; and The vitality of an individual is verified by comparing the server OTP with the token OTP; The starting point of the token OTP string is the mobile device associated with the individual; The token interface is at least one of a display, a speaker, a token network interface, and a USB interface; The OTP token string is between six and ten characters long.

2. The system of claim 1, wherein the at least one server interface includes an SMS interface, and wherein the token OTP string is received by the vitality verification server via the SMS interface, and wherein the starting point of the token OTP string is a mobile device associated with the individual.

3. The system of claim 1, wherein the token OTP string further includes at least a portion of a first timestamp.

4. The system of claim 1, wherein the token OTP string further includes a unique identifier.

5. A system for viability verification, comprising: A vitality verification token comprising a processor, memory, a biostatistical sensor, a first one-time password generator, a first clock module, and a token interface, wherein the vitality verification token is configured to: Token biostatistic readings of individuals are obtained through biostatistic sensors; The token biostatistical readings are compared with the individual's registered biostatistical readings, which were previously obtained by a biostatistical sensor and stored in memory; Determine whether an individual is alive at the time the token biostatistical reading is obtained; and Using a first OTP generator and in response to a token biostatistic reading matching a registered biostatistic reading and determining that the individual was alive when the token biostatistic reading was obtained, a token one-time password (OTP) string is generated, the token one-time password string including the token OTP generated by applying a one-way function to a token message, the token message including a password key stored in memory, a registered biostatistic reading, and a first timestamp from a clock module; A registration client device communicatively coupled to a liveness verification token, the registration client device being configured to: The biostatistical sensor receives the individual's registered biostatistical readings obtained from the vitality verification token; and Receive a unique serial number for the vitality verification token from the vitality verification token; A vitality verification server includes a second one-time password generator, a second clock module, and at least one server interface, said at least one server interface including a server network interface coupled to a registered client device via a network communication. The vitality verification server is configured to: Receive serial number and registration biometric readings from the registered client device; Retrieve a cryptographic key from multiple cryptographic keys using a serial number; Create user files associated with an individual; Receive the token OTP string provided by the vitality verification token through the token interface via one of the at least one server interfaces; A second OTP generator is used to generate a server OTP by applying a one-way function to a server message, the server message including a password key stored in a user file, a registration biometric reading stored in a user file, and a second timestamp, and the user file is retrieved using at least one of a unique identifier associated with an individual and the start point of a token OTP string; and The vitality of an individual is verified by comparing the server OTP with the token OTP.

6. The system of claim 5, wherein the token and registration biometric readings include at least one of fingerprint, retinal scan, and facial scan.

7. The system of claim 5, wherein the at least one server interface includes an SMS interface, and wherein the token OTP string is received by the vitality verification server via the SMS interface, and wherein the starting point of the token OTP string is a mobile device associated with the individual.

8. The system of claim 5, wherein the determination of whether an individual was alive at the time the token biostatistical reading was obtained is based at least in part on token biostatistical readings.

9. The system of claim 5, wherein the token OTP string further includes at least a portion of a first timestamp.

10. The system of claim 5, wherein the token OTP string further includes a unique identifier.

11. The system of claim 5, wherein the at least one server interface includes a voice interface, and wherein the token OTP string is received by the vitality verification server via the voice interface as a telephone call.

12. The system of claim 5, wherein the token interface is at least one of a display, a speaker, a token network interface, and a USB interface.

13. The system of claim 5, wherein the length of the token OTP string is between six and ten characters.

14. A method for viability verification, comprising: An individual's token biostatistic readings are obtained through a biostatistic sensor of a vitality verification token, the vitality verification token including a processor, memory, biostatistic sensor, first one-time password generator, first clock module and token interface; The token biostatistical readings are compared with the individual's registered biostatistical readings, which were previously obtained by a biostatistical sensor and stored in memory; Determine whether an individual is alive at the time the token biostatistical reading is obtained; Using a first OTP generator and in response to a token biostatistic reading matching a registered biostatistic reading and determining that the individual was alive when the token biostatistic reading was obtained, a token one-time password (OTP) string is generated, the token one-time password string including the token OTP generated by applying a one-way function to a token message, the token message including a password key stored in memory, a registered biostatistic reading, and a first timestamp from a clock module; The token OTP string is received at the vitality verification server through at least one of the server interfaces of the vitality verification server, the token OTP string being provided through the token interface, the vitality verification server further comprising a second one-time password generator and a second clock module. The associated user file is retrieved using at least one of a unique identifier associated with the individual and the starting point of a token OTP string, the user file including a password key and registered biometric readings; A second OTP generator is used to generate a server OTP by applying a one-way function to a server message, the server message including a password key stored in a user file, a registration biometric reading stored in a user file, and a second timestamp; The vitality of an individual is verified by comparing the server OTP with the token OTP.

15. The method of claim 14, further comprising: Assign vitality verification tokens to individuals; The registration client device receives the individual's registration biostatistical readings obtained by the vitality verification token via a biostatistical sensor at the registration client device, which is communicatively coupled to the vitality verification token; Receive a unique serial number for the vitality verification token from the vitality verification token; The vitality verification server receives the serial number and registration biostatistics reading from the registered client device. Retrieve a cryptographic key from multiple cryptographic keys using a serial number; and Create a user profile associated with the individual, which includes registered biostatistical readings and password keys.

16. The method of claim 14, wherein the vitality verification server receives a token OTP string from the vitality verification token via a registered client device.

17. The method of claim 14, wherein the at least one server interface includes an SMS interface, and wherein the token OTP string is received by the vitality verification server via the SMS interface, and wherein the starting point of the token OTP string is a mobile device associated with the individual.

18. The method of claim 14, wherein determining whether an individual is alive at the time the token biometric reading is obtained is accomplished at least in part using token biometric readings.

19. The method of claim 14, wherein the length of the token OTP string is between six and ten characters.

20. The method of claim 14, wherein the token and registration biometric readings include at least one of fingerprint, retinal scan, and facial scan.

Images