Developing Distributed Biometric Applications for Mobile Wireless Devices

HP deserves recognition for developing a cost effective device which brings biometrics and the ability to develop applications with them to the public. A company named Cogent (http://www.cogentsystems.com) based out of California developed the core fingerprint recognition technology. HP partnered with them to provide this functionality on the 275X, 2790, 5450, and 5555 Pocket PCs.

Biometrics can measure facial features, voice, fingerprint, iris, retina, hand geometry, signature dynamics, keystroke dynamics, lip movements, thermal head image, thermal hand image and gait. In fact if you look at the header file for the API set you will see all of these defined. Only fingerprint input is supported on the current CE devices. However, we should see handheld applications dealing with the other biometrics within the next several years. The recent 5.0 version of Windows Mobile has been released with voice synthesis and voice recognition via the Speech APIs. SAPI provides developer access via C, C++ or COM programming.

Another use for fingers

I decided to test out the Biometric APIs by developing an application which would collect some basic biographic information like name, and then collect both a photo as well as a fingerprint scan. To do this I used an iPAQ 5555 device since it has the biometric fingerprint reader and has 802.11 wireless capabilities already integrated. I selected the Photosmart SDIO camera to collect snapshots.

(Note: HP used to provide the SDKs free to the developer community for all of their iPAQ devices. You now have to join and pay a yearly membership fee. See http://h71018.www7.hp.com/hp_ids/login.aspx.)

Most fingerprint recognition works by comparing the minutiae from within fingerprint scans. Minutia is simply the ridges of fingerprint lines in which they converge, diverge or end. The FP collection API will capture a fingerprint and return both an image suitable for displaying as a bitmap and a wad of biometric data containing all those minutiae. The API termed the minutiae data, a Biometric Input Record (BIR).

Here's where trouble started. Finger print collectors are engineered using optical, capacitance, ultrasound, pressure based, or thermal technologies. They all have their limitations. HP utilized a thermal collector and we found it operates OK, but on one out of ten people it could not acquire a BIR. I am not sure why or if the failures were because the person's fingerprint had too few minutiae. The bulk of the problems occurred due to thermal issues. If the person's hands are cold you are out of luck. Picture this for plant floor access control: you have a shift change, 50 people show up, and it is 23 degrees outside in the middle of winter. Thermal scans just will not work here. Capacitance technology can run in low power and in small form factors like PDAs, and is more applicable here. (See Biometrics—Identity Verification in a Networked World, Wiley Press, 2002.)

The BIR API documentation recommended that you collect several complete scans. To give this a fair trial I collected five complete BIRs per individual. The test group and I then discovered why they have come up with the terms Enrollment and Verification for FP scanning. Enrollment is the time spent registering a person, which can be quite time-consuming and (at times) frustrating. With improvements in this technology for mobile devices the enrollment stage should decrease to perhaps a few minutes. This would open the path for many applications, such as instant conference security complete with selective access control.

One-to-one and one-to-many

A nice feature of the APIs is the ability to match one BIR to an array of BIRs. In our case having previously recorded five separate FP scans per individual gave us more data points to match. To obtain a match compare the candidate's single new BIR with an array of BIRs which you may load from a local or remote database.

 

Syndicate content
 

Flash®