TITLE OF THE INVENTION
METHOD OF AUTOMATED SIGNATURE VERIFICATION
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to signature verification.
2. Description of Related Art
In a variety of applications, methods for verifying that a person seeking access is in fact authorized are often required. For example, keys are commonly used to require some form of authentication before entry to a building or a vehicle is permitted. Where access is desired to software programs or to software-controlled devices (such as an automated bank teller or credit card account) access is often verified by requiring that
the person seeking access enter a password or personal identifier number ("PIN") , or by requiring that such information be recorded on a magnetic stripe or in the memory of a "smart" card.
While these methods of the prior art achieve the goal of limiting access, they are subject to several drawbacks. (1) Passwords and PINs may be forgotten, leading to persons who are authorized but cannot achieve access. (2) Passwords and PINs are often chosen without security considerations in mind (they are often chosen to be easily remembered) , or are too short, leading security systems which depend upon them to be subject to attack by testing likely keys. (3) Magnetic cards or "smart" cards may be lost or stolen, leading to persons who can achieve access but are not authorized.
It would be advantageous to have a method of authorization which allows verification in response to the signature of the person seeking access. However, known methods of signature matching generally require costly human review of the signature. Accordingly, it is an object of the invention to provide a method of automated signature verification.
SUMMARY OF THE INVENTION
The invention provides a method of automated signature verification, in which a test signature, e.g., a signature entered by an operator, may be preprocessed and examined for test features. The test features may be compared against features of
a set of template signatures, and verified in response to the presence or absence of the test features in the template signatures. In a preferred embodiment, the test signature may be preprocessed, so as to normalize it and remove artifacts which are irrelevant to verification. In a preferred embodiment, the features of the template signatures may be determined and stored in an associative memory or a data structure with associative memory capabilities, e.g., a discrete Hopfield artificial neural network. In a preferred embodiment, the method of verification may be adjusted to greater or lesser sensitivity in response to external conditions.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows an example system in which automated signature verification is used to control entry.
Figure 2 shows a process flow chart of a method of automated signature verifica ion.
Figure 3 shows a process flow chart of a method of signature smoothing.
Figures 4A and 4B show a process flow chart of a method I of signature rotation.
I Figure 5 shows a process flow chart of a method of signature resizing.
Figure 6 shows a process flow chart of a method of signature feature extraction.
Figure 6A shows a process flow chart of the step of identifying the pen movement feature.
Figure 6B shows a process flow chart of the step of identifying the pen speed feature.
Figure 6C shows a process flow chart of the step of identifying the pen status feature.
Figure 6D shows a process flow chart of the step of identifying the pixel dispersion feature.
Figure 6E shows a process flow chart of the step of identifying the euclidean coordinate feature.
Figure 6F shows a process flow chart of the step of identifying the polar coordinate feature.
Figure 6G shows a process flow chart of the step of identifying the stroke turning feature.
Figure 7 shows a process flow chart of a method of signature feature storage (generation of a Hopfield weight matrix) .
Figures 8A and 8B show a process flow chart of a method of unweighted Levenshtein distance measure.
Figures 9A and 9B show a process flow chart of a method of signature comparison with template signatures.
Figure 10 shows a process flow chart of a method of signature accept/reject decision.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Figure 1 shows an example system in which automated signature verification is used to control entry.
A automated signature verification system 101 may comprise an input device 102 for receipt of an input signature 103, such as a writing implement 104 and a pressure plate 105, coupled to a processor 106 for receiving data relating to the input signature 103. In a preferred embodiment, the writing implement 104 and pressure plate 105 may comprise a stylus and graphics tablet for freehand computer input, in which the location of the stylus on the tablet and the pressure then exerted are periodically transmitted to the processor 106, as are known in the art (such as the "Acecat" graphics tablet made by ACECAD of Monterey, California) . However, it would be clear to those skilled in the art, after perusal of this application, that other types of input device would also be workable, and are within the scope and spirit of the invention.
In a preferred embodiment, the processor 106 may comprise a system having a processor, memory comprising a stored program, memory comprising data, and input/output devices 107, as is well known in the art. The operation and software structures of this system are described herein in terms of their functions and at a level of detail which would be clear to those of ordinary skill in the art. It would be clear to anyone of ordinary skill in the art, after perusal of this application, that modification and/or programming (using known programming techniques) of a processor of known design to achieve these functions would be a straightforward task and would not require undue experimentation. It would also be clear to those skilled in the art, after perusal of this application, that processors of other types could be adapted to methods shown herein without undue experimentation, and that such other types of processor are within the scope and spirit of the invention.
In response to the input signature 103, the processor 106-may generate a verification signal 108, which may be used to verify the identity of the person writing the input signature 103. This verification signal 108 may be viewed by an operator, may be coupled directly to a locking device 109, or may be coupled to software within the processor 106 (or within another processor) . In a preferred embodiment, the verification signal 108 may be combined with other methods for verifying the identity of the person, such as methods which are already known in the art.
SIGNATURE INPUT, STORAGE AND LATER VERIFICATION
Figure 2 shows a process flow chart of a method of automated signature verification.
A method of automated signature verification may comprise a template input step 201, a template normalization step 202, a template storage step 203, a test input step 204, a test normalization step 205, a comparison step 206, and an accept/- reject decision step 207.
As shown herein, the method may use a system as described with reference to figure 1, and may proceed by recording a set of template signatures, which are known to be valid signatures, and may be used later for comparison with a test signature. In a preferred embodiment, the set of template signatures may comprise at least five individual signatures. These template signatures are each input and normalized, and stored for later comparison. The method may then proceed, when verification of a person's identity is desired, to verify a test signature. The test signature is input and normalized, compared with the template signatures, and accepted or rejected in response to that comparison.
In the template input step 201, the person whose identity is to be verified later may write a set of template input signatures 103 on the input device 102, e.g., by handwriting the input signature 103 with the writing implement
104 on the pressure plate 105. The template input signatures 103 are known to be valid signatures, and may be used later for comparison with the test input signature 103.
At the template input step 201, the identity of the person may be explicitly identified to the system, e.g., by means of an additional input device 107, e.g., a text input device such as a keyboard, or by means of other input devices such as a mouse or other pointing device, voice input, photographic or other graphic input, or by other means of data input which are known in the art. However, it is not required that the identity of the person be explicitly identified, e.g., the system may compare a test input signature 103 with all recorded template signatures, and generate the verification signal 108 if there is a match with any stored set of template signatures.
In a preferred embodiment, data transmitted by the input device 107 to the processor 106 may be periodically retrieved by the processor 106, as is well known in the art, and stored in a data structure associated with the template input signature 103. In a preferred embodiment, the data may comprise a set of pixels, each of which may comprise a set of pixel data, organized into a data structure as shown in the following table. However, those skilled in the art would recognize, after perusal of this application, that other sets of data elements would be workable, and are within the scope and spirit of the invention.
P- = { X. , Y, , T- , S- , PR- } P2 = { X2 , Y2 , T2 , S2 , PR2 } P3 = { X3 , Y3 , T3 , S3 , PR3 } * * *
P„ - { Tn' Sn' PRn >
where X^ = X-coordinate of pixel, = Y-coordinate of pixel, T,. = time when pixel captured, S{ = pen-up/pen-down status of the writing implement 104 at that time, PR,- = pressure of the writing implement 104 at that time
In the template normalization step 202, the processor 106 may convert the template input signature 103 into a normalized form. Use of a normalized form allows the processor 106 to remove features of the template input signature 103 which are deemed irrelevant to comparison with other signatures. Such irrelevant features may include noise introduced by the input device 102, orientation, and size.
In the template storage step 203, the template input signatures 103 may be stored for later comparison with a test signature. In a preferred embodiment, features of the template input signatures 103 may be determined in response to the template input signatures 103 and stored in a manner which allows associative memory retrieval.
In the test input step 204, the person whose identity is to be verified may write a test input signature 103 on the
input device 102, in similar manner as the template input step 201. At the test input step 204, the identity of the person may be explicitly identified to the system in similar manner as in the template input step 108. At the test input step 204, the processor 106 may capture similar data as in the template input step 201.
In the test normalization step 205, the processor 106 may normalize the test input signature 103 in similar manner as the template normalization step 202 is performed for the template input signature 103.
In the comparison step 206, the processor 106 may compare the test input signature 103 with the stored template input signatures 103. In a preferred embodiment, features of the test input signature 103 may be determined with reference to the test input signature 103 and compared with the stored template input signatures 103 using associative memory retrieval.
In the accept/reject decision step 207, the processor 106 may determine whether to verify the person entering the test input signature 103 in response to the comparison step 206.
/ / /
SIGNATURE NORMALIZATION
In a preferred embodiment, the template normalization step 202 and the test normalization step 205 may each include a smoothing step, a rotation step, and a resizing step.
Figure 3 shows a process flow chart of a method of signature smoothing.
It may occur that data captured by the graphics tablet has a higher resolution than data which is transmitted to the processor 106, e.g., because the graphics tablet has a higher resolution than a graphics adapter used to transmit that data. This may result in two pixels being mapped to the same location on the graphics adapter, which in turn may cause the input signature 103 to appear not to be smooth, and may even cause strokes of the input signature 103 to appear to zigzag. Additionally, the manner in which the input signature 103 was written may cause it not to be smooth.
At an initialization step 301, a set of weights w2 and w3, and a threshold df, may be determined. A preferred value for wn may be 1, a preferred value for w2 may be 2, a preferred value for w3 may be 1, and a preferred value for df may be 4.
At a smooth-once step 302, each pixel value for X
{ and Y
j may be smoothed by computing a weighted average of that pixel, J its predecessor pixel, and its successor pixel, as follows:
At a distance-threshold step 305, the maximum distance ύ
maχ is compared with the threshold df. If Λ
maχ is not greater than df, the method of smoothing is complete. Otherwise, the method repeatedly assigns each pixel its new X
j and Y
{ values, and then continues with the smooth-once step 302. Because the smooth-once step 302 causes the distance
f between a new pixel value and its previous value to become smaller, the value ά
mgχ computed at the maximum-distance step 304 also becomes smaller, until it becomes smaller than the threshold df. Accordingly, the comparison at the distance-threshold step 305 will eventually show ύ
tmχ to be less than df, and the method of signature smoothing will eventually terminate (i.e., it will not proceed in an "infinite loop") .
Figures 4A and 4B show a process flow chart of a method of signature rotation.
It may occur that the input signature 103 is written at an angle from what would normally be expected, either due to positioning of the graphics tablet, position of the person making the input signature 103, or the manner in which the input signature 103 was written. In a preferred embodiment, the angle of the input signature 103 is detected and the input signature 103 is rotated to align it with a horizontal or vertical axis.
At an orientation step 401, the orientation of the input signature 103 may be determined. In a preferred embodiment, the horizontal extent Lχ of the input signature 103
may be compared with the vertical extent of the input signature 103. If Lx >= Ly, the input signature 103 is determined to be horizontal, otherwise the input signature 103 is determined to be vertical. The remainder of the method of signature rotation is described with reference to a horizontal input signature 103, but treatment of a vertical input signature 103 would be clear to those skilled in the art after perusal of this application.
At a partition step 402, the input signature 103 may be partitioned into equal intervals along the X axis. A preferred value for m may be 64. The smallest and largest X coordinates may be determined and the X interval for input signature 103 may be divided into m equal intervals. Each pixel may be assigned to one of these intervals.
At an interval-statistics step 403, the mean X- and standard deviation S. of the pixels in each interval j may be computed, using known statistical formulae. The median T of the standard deviations s, may be computed at step 404, using known statistical formulae. The median absolute deviation MAD of the standard deviations 8, from T may be computed at step 405, using known statistical formulae.
At an outlier-detection step 406, outlying pixels are removed. Those intervals for which (Sj - T)/MAD exceeds a threshold C are determined to be outliers. A preferred value for C may be 2.5.
At.a regression step 407, a regression line may be
At a scaling step 503, each pixel of the input signature 103 may be scaled to a new X coordinate and Y coordinate position, using known geometric formulae.
| At a time-reset step 504, each pixel of the input signature 103 may have its time Tj adjusted by subtracting the | start time of the input signature 103
FEATURE EXTRACTION AND TEMPLATE STORAGE
One aspect of the invention is the identification of relatively constant features in signatures, which remain present in the signature of a person even though that person's signature may be rewritten on differing occasions. One valuable indicator of the source of a person's signature is the strength of those features identifiable in that person's template signatures.
One class of features may include time series data, e.g-, pen-up/pen-down status, pen position, writing pressure, or writing speed or acceleration, each expressed as a function of time. Another class of features may include parameters derived from the input signature 103, e.g., number of strokes, total time duration or duration of each stroke, number of pixels in each interval (e.g., each interval identified in the partition step 402) , centroid of all pixels, higher order moments, minimum and maximum X and Y extent of the signature, or of an interval, peak curvatures and locations thereof, starting location or direction, and other aggregate values known in the art of statistics.
In.a preferred embodiment, each identified feature may be expressed as a vector of binary values, each equalling "0" or "1", i.e., a binary vector or bit string. This has the advantage of reducing storage requirements.
Figure 6 shows a process flow chart of a method of signature feature identification and representation.
In a preferred embodiment of the invention, seven specific features of the input signature 103 may be identified. These features may include time series data, such as (1) movement of the writing implement 104 as a function of time, (2) speed of the writing implement 104 as a function of time, (3) pen-up/pen- down status of the writing implement 104 as a function of time, and (4) pixel dispersion as a function of time. These features may also include time-independent features, such as (5) a euclidean coordinate map, (6) a polar coordinate map, and (7) a set of stroke turning positions in a euclidean coordinate map.
At a step 601, a pen movement feature, comprising movement of the writing implement 104 as a function of time, may be identified and represented as a bit vector.
At a step 602, a pen speed feature, comprising speed of the writing implement 104 as a function of time, may be identified and represented as a vector of integers.
At a step 603, a pen status feature, comprising pen- up/pen-down status of the writing implement 104 as a function of time, may be identified and represented as a bit vector,
At a step 604, a pixel dispersion feature, comprising pixel dispersion as a function of time, may be identified and represented as a bit vector.
At a step 605, a euclidean coordinate feature, comprising a euclidean coordinate map of the input signature 103, may be identified and represented as an array of integers.
At a step 606, a polar coordinate feature, comprising a polar coordinate map of the input signature 103, may be identified and represented as a vector of integers,
At a step 607, a stroke turning feature, comprising a set of stroke turning positions in a euclidean coordinate map, may.be identified and represented as a bit vector.
Figure 6A shows a process flow chart of the step of identifying the pen movement feature.
At a partition step 611, the input signature 103 may be partitioned into a set of M bins of equal time duration. A preferred value for M may be 32.
At a movement determination step 6 2 , the total movement of the writing implement 104 may be determined. In a preferred embodiment, the sum 8 of the differences (Xj+, - Xj) may be computed for each bin, where both pixels Xj and Xi+, belong to the same bin.
I At a quantization step 613, the sum is quantized by setting a quantized result R to 1 if the sum 8 is negative, and by setting a quantized result R to 0 if the sum 8 is nonnegative.
The feature may be represented by a vector of M bits of the quantized result R.
Figure 6B shows a process flow chart of the step of identifying the pen speed feature.
At a partition step 621, the input signature 103 may be partitioned into a set of M bins of equal time duration. A preferred value for M may be 32.
At a distance summing step 622, a sum of Euclidean distances of successive pixels in each bin may be determined, e.g., a value for the each bin b[i] is set to a sum of square- root ( (Xj+1 - Xj ) 2 + (Yj+1 - Yj ) 2 ) , summed over all pixels <Xj , Yj> in that bin.
At a normalizing step 623, each b[i] may be divided by the total of all b[i].
The feature may be represented by a vector of M integers.
Figure 6C shows a process flow chart of the step of identifying the pen status feature.
At a partition step 631, the input signature 103 may be partitioned into a set of M bins of equal time duration. A preferred value for M may be 32
At a pen-up step 632, a status bit b[i] for each bin may be set to "1" if any pixel in that bin has pen-up status. Otherwise, the status bit b[i] for that bin may be set to "0".
The feature may be represented by a vector of M bits.
Figure 6D shows a process flow chart of the step of identifying the pixel dispersion feature.
At a partition step 641, the input signature 103 may be partitioned into a set of M bins of equal time duration. A preferred value for M may be 32.
At a dispersion step 642, a standard deviation of X coordinates sigma(Xj) and a standard deviation of Y coordinates sigma (Yj) may be determined, using known statistical formulae.
At.an orientation step 643, a pixel dispersion bit b[i] for each bin may be set to "0" if εigma(Xj) > sigma(Yj) and the signature is horizontal, and may be set to "1" if sigma(Xj) < sigma(Yj) and the signature is determined to be horizontal. If the signature is determined to be vertical, these "0" and "1" bit 1 values may be inverted.
I The feature may be represented by a vector of M bits,
1 Figure 6E shows a process flow chart of the step of J identifying the euclidean coordinate feature.
I For this feature, the input signature 103 may be mapped onto an M x N matrix of bins b[x,y]. A preferred value for M may be 16; a preferred value for H may be 16.
At a centroid step 651, a coordinate <Xmean,Ymean > may be mapped onto bin b[M/2,N/2].
At a mapping-ratio step 652, a farthest coordinate from the center Xf for horizontal signatures (Yf for vertical signatures) may be determined. A ratio r for mapping pixels may be determined:
r =
M/2 j
At . a mapping step 653 , each pixel <Xk , Yk> may be mapped onto a bin b [ i , j ] , where
I Xk ~ ^an I i = ! ,
! !
I x k ^rnean I , j = ! i
I r I
At a pixel-count step 654, the number of pixels mapped onto each bin b[i,j] may be counted.
At a normalizing step 655, the number of pixels for each bin b[i,j] may be divided by the total number of pixels in the signature. In a preferred embodiment, the normalized value may be rounded up to the nearest integer if it comprises a fractional value.
The feature may be represented by an M x N array of integers. In a preferred embodiment, each integer may be represented by six bits in unsigned binary format, with values greater than 63 represented by the bit string for 63, i.e., "111111". When retrieved for Levenshtein distance comparison, the binary data may be unpacked into the M x H array of integers.
Figure 6F shows a process flow chart of the step of identifying the polar coordinate feature.
For this feature, the input signature 103 may be mapped onto a polar coordinate structure with M equidistant concentric
rings and N etjuiangular sectors in each ring. A preferred value for M may be 24; a preferred value for K may be 24.
At a centroid step 661, a coordinate <X|nean,Ymean > maY >e mapped onto the origin of the polar coordinate system.
At a translation step 662, each pixel <Xk,Yk> may be translated by subtraction of <Xroean»V mean >•
At a mapping-ratio step 663, a farthest radius from the center Rf may be determined. A ratio r for mapping pixels may be determined:
r = -f- !
M j
At a ring-mapping step 664, each pixel <Xk,Yk> may be mapped onto a ring, where
square-root ( Xk 2 + Yk 2 ) ring = r At a sector-mapping step 665, each pixel <Xk,Yk> may be mapped onto a sector within its ring, where
theta = arctan (Yk/Xk) , +2π if needed to bring within (0,2π)
sector = theta * (180/π) / (360/N)
At. pixel-count step 666, the number of pixels mapped onto each <ring,εector> tuple may be counted.
At a ring-summing step 667, the number of pixels for each ring may be summed, i.e., the number of pixels for all the sectors in each ring are summed and placed in M bins b[i].
At a normalizing step 668, the number of pixels for each bin b[i] may be divided by the total number of pixels in the signature. In a preferred embodiment, the normalized value may be rounded up to the nearest integer if it comprises a fractional value.
The feature may be represented by an M x N array of integers for bins b[ring,sector] ; the value for the origin of the polar coordinate may be discarded for this feature. In a preferred embodiment, each integer may be represented by six bits in unsigned binary format, with values greater than 63 represented by the bit string for 63, i.e., "111111". When retrieved for Levenshtein distance comparison, the binary data may be unpacked into the M x N array of integers.
Figure 6G shows a process flow chart of the step of identifying the stroke turning feature.
For this feature, the input signature 103 may be mapped onto an M x N matrix of bins b[x,y] . A preferred value for M may be 16; a preferred value for N may be 16.
A centroid step 671 and a mapping-ratio step 672 may be performed in like manner as the centroid step 651 and mapping- ratio step 652.
At a mapping step 673, each pixel <Xk,Yk> which may comprise a stroke-turning point may be mapped onto a bin b[i,j], in like manner as pixels are mapped onto a bin b[i,j] in the mapping step 653. As used herein, a stroke-turning point is a point where there is a change in stroke direction.
In a preferred embodiment, stroke-turning points may be recognized by examining each set of five consecutive pixels for a change of direction as the middle point. A change of direction may be recognized in a variety of ways, e.g., by determining if the middle point is a minimum, maximum, or inflection point using known methods of elementary calculus, applied to discrete points.
A pixel-count step 674 and a normalizing step 675 may be performed in like manner as the pixel-count step 654 and the normalizing step 655.
The feature may be represented by an M x N array of integers. In a preferred embodiment, each integer may be represented by six bits in unsigned binary format, with values greater than 63 represented by the bit string for 63, i.e., "111111". When retrieved for Levenshtein distance comparison, the binary data may be unpacked into the M x N array of integers.
FEATURE RETRIEVAL AND SIGNATURE COMPARISON
Once a feature has been identified and represented as a template feature bit string, a weight matrix may be generated according to the discrete Hopfield asynchronous network paradigm. The discrete Hopfield asynchronous network is known in the art and so is not disclosed in detail here. A more complete discussion may be found in "Neural Networks and Physical Systems with Emergent Collective Computational Abilities", by John J. Hopfield, published 1982 in "Proceedings of the National Academy of Sciences, U.S.A. 1979", pages 2554—2558, hereby incorporated by reference as if fully set forth herein.
Figure 7 shows a process flow chart of a method of signature feature storage (generation of a Hopfield weight matrix)
At a bipolar-conversion step 701, each binary value (0 or 1) may be converted to a bipolar value (-1 or +1) , by replacing all "0" values with -1 values.
At an outer-product step 702, an outer product may be computed for each binary vector with its transpose. Where the binary vector is length m, the product M will be an m x m bipolar matrix.
At a summation step 703, the outer products for the selected feature of all (five) of the template signatures are added to generate a summed matrix M'
At a zero-diagonal step 704, the main diagonal of the summed matrix M' is set to zero. The resulting matrix M' is herein called a weight matrix or a memory matrix.
Once a feature in the test input signature 103 has been identified and represented as a test feature bit string, differences between the test feature bit string and the template feature bit strings may be determined according to the asynchronous update paradigm of the discrete Hopfield network. String distance may be computed according to the Levenshtein distance. The Levenshtein distance is known in the art and so is not disclosed in detail here. A more complete discussion may be found in "Binary Codes Capable of Correcting Deletions, Insertions, and Reversals", by V.J. Levenshtein, published 1965 in "Doklady Akademii Nauk SSR" 163(4), pages 845—848, hereby incorporated by reference as if fully set forth herein.
Figures 8A and 8B show a process flow chart of a method of unweighted Levenshtein distance measure.
Briefly, the Levenshtein distance between two strings of symbols may be computed by determining how many symbols must be added, how many deleted, and how many substituted, from a first string A to a second string B.
At an initialization step 801, the length La of string A, the length Lb of string B, the deletion cost D, the insertion cost I, and the substitution cost 8 may be determined. A preferred value for D may be 1, a preferred value for I may be 1, and a preferred value for 8 may be 1. A distance matrix M may be allocated with an initial value for M(0,0) of zero.
In a deletion-loop 802, the value for M(i,0) may be set to M(i-1,0) + D, for each value of i < La. The variable i may be a counter.
In an insertion-loop 803, the value for M(0,j) may be set to M(0,j-1) + I, for each value of j < Lb. The variable j may be a counter.
In a substitution-loop 804, the counter variables i and j may be allowed to range over each value i <= La and j <= Lb. At step 805, the ith position of string A may be compared with the .jth position of string B. For each location in M, the value for M(i,j) may be set to M(i-l,j-l) (at step 806), plus 8 if the values of the strings differ in their ith and jth positions (at step 807). At step 808, the value for M(i,j) may be computed for achieving the substitution by deletion or insertion instead. At step 809, the value for M(i,j) may be set to a lower value if one could be achieved by deletion or insertion instead.
Figures 9A and 9B show a process flow chart of a method of signature comparison with template signatures.
At.an initialization-step 901, the weight matrix M' and a feature bit string b are known. An altered feature bit string b' may be set equal to b.
In an update-loop 902, a vector c may be computed as the product M' x b'. Each bit of b' may be altered to equal "1" if that element of c is >= 0, and otherwise may be altered to equal "0".
At a loop-complete step 903, the updated bit string b' may be compared with the original bit string b. If they are different, the updated bit string b' may be assigned to the original bit string b at step 904 and the update-loop 902 may be re-entered. Otherwise, the update-loop 902 is complete and the method may continue with step 905.
At a measurement step 905, the Levenshtein distance of the updated bit string b' from the template feature bit strings may.be computed.
At a minimum-distance step 906, the minimum Levenshtein distance computed may be determined to be the distance of the test feature bit string from the template feature bit strings.
In a preferred embodiment, the pen movement feature data may comprise 32 bits, and may be packed into 4 bytes at 8 bits per byte. The pen speed feature data may comprise 32 integers, encoded with six bits per integer, thus 192 bits, and
I may be packed into 24 bytes at 8 bits per byte. The pen status feature data may comprise 32 bits, and may be packed into 4 bytes at 8 bits per byte. The pixel dispersion feature data may comprise 32 bits, and may be packed into 4 bytes at 8 bits per byte. The euclidean coordinate feature data may comprise 16 x 16 = 256 integers, encoded with six bits per integer, thus 1536 bits, and may be packed into 192 bytes at 8 bits per byte. The polar coordinate feature data may comprise 24 integers, encoded with six bits per integer, thus 144 bits, and may be packed into 18 bytes at 8 bits per byte. The stroke turning feature data may comprise 16 x 16 = 256 bits, and may be packed into 32 bytes at 8 bits per byte.
In a preferred embodiment, a packed data structure for feature data may be expressed as follows in the C programming language:
typedef struct
{ char movement[5]; char speed[25]; char status[5]; char dispersion[5] ; char euclidean_map[193] ; char polar_map[19] ; char turning_position[33] } PACKED_FEATURE
In a preferred embodiment, a packed data structure of five template signatures may be expressed as follows in the C programming language:
PACKED_FEATURE packed_template_feature[5] ;
In a preferred embodiment, this data structure may be stored in a database of signatures.
In a preferred embodiment, an unpacked data structure for feature data may be expressed as follows in the C programming language:
typedef struct
{ char movement[33]; short speed[32]; char status[33]; char dispersion[33] ; short euclidean_map[256] ; short polar_map[24] ; char turning_position[257] } UNPACKED_FEATURE
In a preferred embodiment, an unpacked data structure of five template signatures may be expressed as follows in the C programming language:
UNPACKED_FEATURE unpacked_template_feature[5] ;
In a preferred embodiment, this data structure may be used for storing features which are determined for template signatures and unpacked from a database of signatures,
An example Levenshtein distance comparison is shown in I the following table for two 20-bit bitstrings:
Let a test feature vector of 20 bits be defined as follows: "11000 10110 11101 10101"
Let a template feature vector of 20 bits be defined as follows: "01101 01011 OHIO 11010"
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 1 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 2 2 1 1 2 3 4 5 6 7 9 10 11 12 i3 14 15 16 17 18 3 2 2 2 1 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 4 3 3 3 2 2 2 3 4 5 7 8 9 10 11 12 13 14 15 16 5 4 4 4 3 3 2 3 3 4 6 7 8 9 10 11 12 13 14 15 6 5 4 4 4 3 3 2 3 3 5 6 7 8 9 10 11 12 13 14 7 6 5 5 4 4 3 3 2 3 4 5 6 7 8 9 10 11 12 13 8 7 6 5 5 4 4 3 3 2 4 4 5 6 7 8 9 10 11 12 9 8 7 6 6 5 5 4 4 3 3 4 4 5 6 7 8 9 10 11 10 9 8 7 6 6 5 5 4 4 2 3 4 5 5 6 7 8 9 10
11 10 9 8 7 6 6 5 5 4 3 2 3 4 5 5 6 7 8 9
12 11 10 9 8 7 7 6 6 5 4 3 2 3 4 5 5 6 7 8
13 12 11 10 9 8 8 7 7 6 5 4 3 2 3 4 5 6 6 7
14 13 12 11 10 9 8 8 7 7 5 5 4 3 2 3 4 5 6 6
15 14 13 12 11 10 9 8 8 7 6 5 5 4 3 2 3 4 5 6
16 15 14 13 12 11 10 9 9 8 7 6 5 5 4 3 2 3 4 5
17 16 15 14 13 12 11 10 9 9 7 7 6 6 5 4 3 2 3 4
18 17 16 15 14 13 12 11 10 9 8 7 7 6 6 5 4 3 2 3
19 18 17 16 15 14 13 12 11 10 10 9 8 8 7 6 6 5 4 3 2
20 19 18 17 16 15 14 13 12 11 10 10 9 8 8 7 6 6 5 4 3
The Levenshtein distance between the two feature vectors is the last element, i.e., the lower right corner element, which is 3.
Figure 10 shows a process flow chart of a method of signature accept/reject decision.
At a threshold step 1001, an acceptance threshold for each feature is determined.
In a preferred embodiment, the acceptance threshold may be determined in response to the distances between pairs of the template input signatures 103. In a preferred embodiment with
five template input signatures 103, there will be ten such pairwise distances, as shown in the following table:
1 0 dl d2 d3 d4
2 dl 0 d5 d6 d7
3 d2 d5 0 d8 d9
4 d3 d6 d8 0 dlO
5 d4 d7 d9 dlO 0
In a preferred embodiment, these ten pairwise distances may be arranged in decreasing order, and the kth distance may be selected as an acceptance threshold. A preferred value for k may be 7, i.e., the 7th greatest distance may be selected as an acceptance threshold. The greater k is, the tighter the acceptance threshold; i.e., when k is 9, the 9th greatest distance may be selected as an acceptance threshold.
At an averaging step 1002, an average acceptance threshold a and an average distance d may be computed.
At a comparison step 1003, the average acceptance threshold a and an average distance d may be compared. If the average acceptance threshold a is less than the average distance ύ, the test input signature 103 may l>e accepted and the rification signal 108 may be generated. Otherwise, the test
input signature 103 may be rejected and the verification signal 108 may be absent.
Alternative Embodiments
While preferred embodiments are disclosed herein, many [ variations are possible which remain within the concept and scope of the invention, and these variations would become clear to one of ordinary skill in the art after perusal of the specification, drawings and claims herein.