Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
  • G06F16/58—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
  • G06F16/583—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually using metadata automatically derived from the content
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
  • G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
  • G06V40/10—Human or animal bodies, e.g. vehicle occupants or pedestrians; Body parts, e.g. hands
  • G06V40/18—Eye characteristics, e.g. of the iris
  • G06V40/197—Matching; Classification
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
  • G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
  • G06V40/50—Maintenance of biometric data or enrolment thereof

Definitions

• the invention relates to the field of database systems.
• it relates to a method and system for improving the speed with which a candidate record may reliably be fuzzily matched against a record within the database.
• biometrics in which the requirement is to determine whether or not the individual who has provided a particular biometric sample is already in the database.
• Databases of the type described can be extremely large, and it may be impractical to attempt a full match analysis between the sample record and every one of the records within the database.
• a variety of pre-screening processes are in use, but many of these have very restricted fields of application since they often rely upon specific peculiarities of the matching algorithm or of the data that are to be matched.
• biometric matching normally relies upon the concept of an approximate or "fuzzy" match, rather than on an exact match.
• a typical scenario is the need to determine whether a particular individual exists within a large database of individuals. For example, we may have an iris scan of an individual and want to know whether a national security database already contains one or more iris scans of the same individual. Because the sample iris scan and the stored iris scans are unlikely to be identical in all respects, one way of achieving the necessary "fuzzy" match is to search over a region. Having converted both the sample and the stored records into codes, according to some predefined protocol, we can attempt to find a match between a stored record and any code within a region which we consider to be sufficiently close to the sample code. Alternatively, we may attempt a match between the sample code and any code within a search region which is sufficiently close to one of the stored codes. In either case, the need to search over a region of codes when doing the fuzzy match may significantly slow down the matching process.
• a method of identifying possible matches between a sample record and a plurality of stored records comprising:
• a system for identifying possible matches between a sample record and a plurality of stored records using a plurality of characteristics within a characteristic space comprising:
• Such a method provides very fast candidate-matching at the expense of some additional effort when registering a new record within the database.
• the trade-off is well worth while when matching is done frequently in comparison with the frequency of registration of new records.
• separate processors may be used for matching characteristics against sample records, and for identifying stored records as possible matches. These processors may be on separate computers, and may be remote from each other. In one particular embodiment, the main data list including the full collection of stored records may be held separately from the characteristic list. That allows a local processor, to carry out the initial analysis on a sample record such as a locally - obtained iris scan. Once a list of possible matches has been identified, that list can then be passed to a remote server, where a more detailed analysis can be carried out by comparing the sample with the full encoded iris scans of each of the possible matches.
• This approach has the further advantage that the designer of the system does not need to distribute to a large number of users full copies of the entire database of encoded iris scans. Instead, each user simply receives a list of characteristics, which is enough for the initial analysis to be carried locally. Where one or more possible matches are found, the system may then be automatically report to a central location where further analysis can be carried out against the full records.
• Figure 1 shows the database structure according to an embodiment of the invention
• Figure 2 is a histogram exemplifying the matching process
• Figure 3 is another exemplary histogram; and Figure 4 shows some exemplary hardware.
• Figure 3 is another exemplary histogram; and Figure 4 shows some exemplary hardware.
• an iris scan has been taken of a particular individual, and the need is to determine whether another iris scan of the same individual already exists within a large database such as a national security database.
• the database structure of the exemplary embodiment is shown schematically in Figure 1. Details of particular individuals are held within a case list or table 16, each row 17 of which represents a specific iris scan of a specific individual. Ideally, each individual will be represented by a single iris scan, but of course in a typical national security database, there will in practice be multiple scans of at least some individuals.
• Each row or iris scan record include columns 18, 20, 22, which respectively hold a unique iris scan reference number for use within the system, the name of the individual, where known, and an external identifier such as a national security or social security code.
• the full iris scan for each record is held within a separate data list or table 10, each row 11 of which represents an individual scan.
• This table consists of two columns, the first 12 being the unique reference number, mentioned above, and the second 14 holding the complete scan in some suitable encoded form. Where necessary, the original raw scan, as imaged, may also be stored as well. More generally, the column 14 may be considered to hold some encoded representation which uniquely identifies a specific scan or other biometric record of a particular individual.
• Each registered case is classified according to a plurality of attributes, characteristics or codes, these being extracted or derived either from the raw iris scans or more typically from the encoded scan data 14.
• the codes may, but need not, be representative of human-identifiable characteristics of the scan.
• some of the codes could be representative of eye colour, with others being representative of such characteristics as the amount of colour and intensity variation within the iris.
• the encoded scans 14 may be treated as a pure data stream, with the codes simply resulting from some function or functions applied to the data stream. Apart from the hash function already mentioned, a further possibility would be to search for the presence or absence of specific groups of bits within the data stream. In any event, it will be understood that multiple codes will typically be extracted from each individual record 11.
• the codes are typically constrained to be numeric, and to lie within a particular predefined range.
• the codes might for example be defined by 16 binary bits, allowing 65536 possible codes to occur.
• the functions or operations which generate these codes from the raw or encoded data are limited in their possible range of outputs so that only the desired codes are possible.
• the actual range of outputs is remapped to a list of numeric codes within the desired range.
• a mapping table (not shown) may be used if required.
• the list 40 for the code value 1 contains just a single row, indicating that only name A generates this code.
• the list 41 representing code value 2 contains no data since in the present example none of the registered iris scans generates that code.
• the lists 42, 43 representing respectively code values 3 and 4, each relate just to a single scan.
• the table 44 indicates that iris scans for names A and B each generate code value 5.
• each of the tables or lists 28 contains in each row 29 simply the unique reference 18 to a single record which corresponds to the relevant code.
• each of these lists relating not simply to an individual code but rather to those codes which are a given distance from the corresponding base code, according to some desired metric such as the Hamming distance.
• the Hamming distances between the codes 1 to 5 are given in Table 1.
• the Hamming distance is the number of bits that are different between two codes. For example the Hamming distance between codes 1 and 2 is 2, because 2 bits are changed between the code for 1 (001) and the code for 2 (010).
• the tables 30 contain data relating to those cases which resolve to a code having a Hamming distance of exactly 1 from the corresponding base code of the tables 28.
• the Hamming distance has been used to illustrate the embodiment and that any other convenient metric may be used.
• the required metric eg Hamming distance
• the codes may be multidimensional, with the required metric being measured within a corresponding multidimensional space.
• a new iris scan is to be registered within the database, its details are added to the case and data lists 16, 10 and the corresponding codes for the new scan are calculated and/or determined.
• the scan's unique reference number 18 is then added, as appropriate, to one or more of the individual lists
• one or more new codes may be added to the code list 24, in which case the individual tables 28 are automatically created, and each iris scan within the database is checked to determine whether its reference number needs to be added to one or more of the newly created tables.
• each code n is used as an index 70 to a look-up table 25, this table containing pointers Pl, P2, P3 ... which point to the respective areas in memory which hold the code value 1, 2 and 3 lists. If each of the lists centred on a particular nominal code value follow one another in memory, only a single pointer (plus an offset) will be required. Alternatively, separate pointers could be provided for the respective lists within the series 28, the series 30 and the series 32. Another possibility would be for each of the lists 28 to have a pointer which looks to the corresponding list in 30, and so on.
• the system then proceeds to identify candidate matches by building up a histogram of the number of occurrences of each case across all of the tables of a particular
• a threshold is applied to the count, and any record which scores at least the threshold value is considered to be a candidate match.
• the threshold is taken as 1
• the candidate matches are scans A, B and D.
• the candidates are A and D.
• Figure 3 shows the histogram for the same sample, generating codes 1 and 3, but this time tested against a Hamming distance of up to 2
• the hits from the base tables 40, 42 are A and D
• Applying a threshold of 1 gives us A, B, C and D as candidate matches, whereas applying a higher threshold of 2 returns A, B, and D as candidates.
• the output response of the system may be tuned, according to the application, by selecting suitable values for the threshold and/or Hamming distance. Either or both of these values could be fixed, programmatically varied, or user varied. In some applications it may be convenient for the user to be able to select appropriate values of either or both of these parameters at run time.
• more complex matching algorithms may be envisaged. For example, different threshold values may be used for different Hamming distances.
• the system could also automatically select candidates at a variety of Hamming distances, and compare or combine the respective selections at different distances to generate an improved composite list of candidate matches.
• the threshold and/or Hamming distance selections may be determined, where necessary according to the extent to which the pre-selection process needs to remove a large number of cases from consideration in order to speed up the overall matching process.
• a simple count and a fixed threshold is a convenient way of dividing possible matches from non- matches, other algorithms could equally well be used.
• the sample scan may be compared against the candidates within the database using some more sophisticated but slower algorithm.
• the database itself may be held on the same computer or at the same location where the preliminary and/or the final matching takes place.
• the process may be distributed, with the preliminary matching being carried out according to a code list held at a local computer, and the preliminary matches being passed on to a remote computer for the detailed matching to take place.
• the primary data list 10 (which includes the full data representing all the stored scans) to be held at a central location, with a local machine needing to hold just the individual case occurrence lists 28, 30, 32.
• the process of the present invention may further be speeded up by using multiple computers or processors operating in parallel.
• a user computer 32 forwards a matching task to a controller 34 which splits it up and distributes it between a plurality of computers or processors 36.
• Each processor 36 may be instructed to handle a particular code or group of codes; alternatively, the controller 34 may split up the work in some other way.
• the processors 36 pass their results onto a consolidator 38, which finalises the selection of possible matches (for example using the procedure illustrated in Figures 2 and 3).
• the list of possibilities is then forwarded as required, either to a computer or processor 42 which carries out the detailed matching or as shown by reference numeral 40 back to the user 32 for further analysis.
• one embodiment may be in hardware, such as implemented to operate on a device or combination of devices, for example, whereas another embodiment may be in software.
• an embodiment may be implemented in firmware, or as any combination of hardware, software, and/or firmware, for example.
• one embodiment may comprise one or more articles, such as a storage medium or storage media.
• This storage media such as, one or more CD-ROMs and/or disks, for example, may have stored thereon instructions, that when executed by a system, such as a computer system, computing platform, or other system, for example, may result in an embodiment of a method in accordance with claimed subject matter being executed, such as one of the embodiments previously described, for example.
• a computing platform may include one or more processing units or processors, one or more input/output devices, such as a display, a keyboard and/or a mouse, and/or one or more memories, such as static random access memory, dynamic random access memory, flash memory, and/or a hard drive.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Library & Information Science (AREA)
• Multimedia (AREA)
• Human Computer Interaction (AREA)
• Data Mining & Analysis (AREA)
• Databases & Information Systems (AREA)
• General Engineering & Computer Science (AREA)
• Health & Medical Sciences (AREA)
• General Health & Medical Sciences (AREA)
• Ophthalmology & Optometry (AREA)
• Collating Specific Patterns (AREA)
• Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=38895629

Family Applications (1)

Country Status (4)

Cited By (2)

Families Citing this family (9)

Citations (4)

Family Cites Families (62)

• 2006
  • 2006-10-23 US US11/585,358 patent/US7809747B2/en active Active
• 2007
  • 2007-10-23 EP EP07824283.1A patent/EP2095277B1/en active Active
  • 2007-10-23 JP JP2009533936A patent/JP5394245B2/ja active Active
  • 2007-10-23 WO PCT/GB2007/004035 patent/WO2008050107A1/en not_active Ceased
• 2010
  • 2010-07-16 US US12/838,109 patent/US20100281043A1/en not_active Abandoned

Patent Citations (4)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events