Interfacing with Biometric Devices from POS applications

Question

A new blog has been posted to help people who want to interface with biometric devices (such as fingerprint readers).  It is on the team blog site here:

http://blogs.msdn.com/pointofservice/archive/2009/09/23/interfacing-with-biometric-devices-from-pos-applications.aspx

Answer 1

Sylvester,
thanks again for the code samples.  Not to diminish your efforts, but I have been trying with earnest for several months to locate a UPOS fingerprint reader.  Today a colleague informed me that DigitalPersona responded that they previously had a UPOS (POS .NET) service object for their fingerprint readers but they no longer support UPOS due to lack of demand. 

Honestly, this is not a good sign.  I have repeatedly said Microsoft needs to do more to stoke the channels.  I'm not sure if the message is getting through or not.  When a developer cannot by any means obtain a UPOS driver for a fingerprint reader, it makes me question to some extent the value proposition of POS for .NET. 

I guess its  a chicken and egg scenario.  If the IHVs dont promote what they have, then its hard to generate demand.  And if there is no demand, its hard to justify supporting the device. But  I can only speak for myself.  I am quite frustrated for having adopted POS for .NET and now have no drivers with which to integrate to our application.  And Im not blaming Microsoft really...digitalpersona claims they had a UPOS driver... i haven't seen it and I really strongly doubt they ever promoted it in the WePOS usenet forums so it makes me question their marketing efforts.
 
Dont mistake me for a basher.  I'm just giving honest feedback and hoping that things improve.
I've done my part by pushing the IHVs to write UPOS service objects...now i either wait or just use a different platform for fingerprint readers.

Answer 2

Hi Sylvester,

Thanks for the blog post, unfortunately there are still some area's that are confusing and neither your post, the Pos .Net documentation or the UPOS specification seem to help.

One primary area of concern is 'enrolment'. The Pos .Net documentation and I think the UPOS specification say that enrolment usually takes an 'average' of a users biometric data to be stored for comparison later. Your post mentions 'aggregating' BIR records into a final one.. but nowhere does it explain how to actually get an 'average' or aggregate the records, and it is not clear from the interface spec.

There is some mention of 'adapting' BIR records but the SDK documentation isn't clear on when or why you'd want to do this. It just says you do it to update a users bio-records over time... how would you know when you should do that ? Does it also apply to enrolment ? Is this is what we should do to get an average ?. If this IS the way to get the 'average' for enrolment, then it appears the process has to be;

1. Call BeginErollCapture
2. Wait for data to be captured
3. When data is captured store it and call EndCapture
4. After calling EndCapture call BeginEnrollCapture passing the data from the last capture as the record to be adapted.
5. Repeat from step 2 until you've had enough captures to satisfy your 'average' requirements (i.e 5 captures).

That seems to be a farily complicated process and isn't described anywhere.

If we are NOT meant to use adapation for enrolment, then I'm not sure what we do. If we simply store multiple BIR records against a users account, what do we do when the Identify method returns a rank ordered array that looks like this;

BIR #1 for User A
BIR #2 for User B
BIR #1 for User B
BIR #3 for User A
BIR#4 for User A
etc..

In that case do we have to reject the scan as being inconclusive, do we say there are more records for user A in the top 5 items so we identify user A, or do we say the first record in the list was user A and since it's the first entry it's the closest match, and if that's the case how did storing multiple BIR records to get an average help ?

Could you please write another blog post, or update your existing one to explain the correct process ? An update to the programming model in the Pos .Net SDK documentation would also be great.

Thanks.

Answer 3

Woodchux,

We do appreciate the honest feedback and I can assure you that it does not fall on deaf ears.  I agree that all providers of the UPOS implementations have a part to play, but it cannot be interpreted as a replacement for ecosystem demand.  The current design of UPOS requires IHVs to develop service objects for three different platforms and they are forced to prioritze which platforms they support by the amout of demand they hear from ISVs.  I encourage you to communicate the business case to the vendors of your choice.  If they understand that it presents a desireable market opportunity for them they will respond.

Terry Warwick
Microsoft

Answer 4

Yort,

The Biometric Information Record (BIR) referenced in the UPOS specification is based on the original definition published by the BioAPI Consortium (http://www.bioapi.org).  For additional detail about the BIR it may be useful to reference the BioAPI specification as well.

Terry Warwick
Microsoft

Answer 5

Hi Terry,

I've checked out www.bioapi.org, downloaded and read their specification etc. but I have still not found the answer I'm after. Their spec does mention adaptation during enrolment, but only from the point of view that some devices may not support it and an app may need to detect that functionality and rollback to doing 're-enrollments'... there is no mention of how to actually perform an enrolment or why adaptation is easier, or how to average/aggregate multiple enrolment BIR's in a way they can be easily used with the verification methods. The working of the document also suggests/implies that adaptation is not part of the normal enrolment process, but again it's not explicit.

As part of the team who wrote the Pos .Net library, are you or one of your colleagures not able to explain how to use it effectively ?

Thanks.

Answer 6

Yort,
There are two big problems with POS for .NET.

1.  The standards are vague and imprecisely defined in many cases.
2.  And a related problem, because the standards are vague and imprecise, the implementation of service objects by IHVs is inconsistent.


I pulled a list of the technical committe for NRF/ Arts who bears nearly full responsibility for both these problems.  The  Technical Committee, composed of both vendors and retailers, modifies the UnifiedPOS specification based on guidance of the Administrative Committee.  The Technical Committee provides support by resolving implementation issues or issues arising from the standard.

Frank May of Microsoft is one the persons responsible for the technical oversight of the POS for .NET standards (UPOS).  The buck stops with this committee. There is nothing to say that Microsoft cannot supplement its explanation of teh UPOS standard in its own POS for .NET documentation.  And because Microsoft is one of  ten people on the committee its a bit of a copout to say that NRF Arts is the problem for the poorly documentated and implemented standards.

Maybe its time that Frank May be removed from this committee and someone who can relate to the problems of IHV and ISVs be put on the board.  Its one thing to write a standard, and its quite another to be the one having to implement a poorly written standard.

I understand that this committee may have little or no control over the old OPOS standards which are perhaps 20 years old, but the newer standards such as Biometrics there is no excuse for why these should not be clear and precise.

Committee Chair:

Paul Gay

Seiko Epson

Committee Members:

Chuck Atwater	DataLogic
Michael Webb	DataLogic
Harry McKinlay	Fujitsu Transaction Solutions
Richard Kairis	IBM Corporation
Frank May	Microsoft Corporation
John Evans	Motorola Corporation
Brian Spohn	NCR Corporation
Curtiss Monroe	NCR Corporation
Tadashi Furuhata	OPOS-J
Thomas Heinrich	Wincor Nixdorf

Answer 7

For most applications, I've found that all anyone really needs is an SDK alternative that's done all the work for you pretty much. I mean the UPOS implementation, from my experience with it, is a great idea in theory but is really not user friendly (saying a lot for developer), difficult, confusing, and the end result is still pretty unstable at best. My favorite part about this SDK alternative (besides how amazingly easy it is to use) is IF you have a problem, you actually get tech SUPPORT.

Here is a really great comparison: bio plugin SDK alternative

There's also a free trial version to get your juices flowing.