The kernel implements the BioID business logic, that is divided into client processing, the BioID Client, and server processing, the BioID Server. Communication between these services is done via proxies, which define the protocol that is used for the communication. Currently the DCOM protocol is implemented, a SOAP protocol proxy is in process. The server also builds the abstraction layer between the business logic and the data service that is provided by a structured Data Store such as the Microsoft SQL server or an Oracle database. An implementation using the Microsoft Active Directory Services is planned.
The BioID Client is responsible for accessing and managing capture devices (e.g. sound card, camera, fingerprint, etc.), recording audio, video and other raw data (we call these data Recordings), preprocessing the data and extracting the biometric features (just called Features). The Patterns, the combination of Recordings and Features, are sent to the ClientPeer and API client attached to it (e.g. a BioID API object) or to the server for a classification. In live mode the ClientPeer also receives live frames, e.g. a single image or an audio frame of 100ms length, and/or the processed live features.
A new feature within the client is the Local Classifier, which enables the client to perform a verification of a single user without the needs of a BioID Server connection. But note that the client is not able to store any data. To use the local classifier, an application has to provide the needed data itself. The local classifier can be accessed via the DataPeer. The DataPeer also provides access to user specific data on a BioID Server. Communication with a BioID Server is always performed by using a ServerProxy object, which implements the protocol, needed to communicate with the server.
The server receives the Features from the client and performs the classification or verification for the different biometric traits. The results of the single Classifiers are combined by the Fusion component and sent back to the client. The server also builds the abstraction layer to the data store, this means that any access to the BioID database is rooted through the Data Server component.
When the server receives new Patterns for a user, the Classifiers have to be (re-) trained. The training process creates the biometric Template for the user, which is stored in the database, together with the Patterns. As soon as a user is trained, he can be classified by the server.
Other tasks of the server are monitoring services that are used to keep the database clean, build statistics about the performed classifications and make proposals how to improve the quality of the classifiers.
Any server access has to be done by using the ServerPeers. The ServerPeer is used to perform classifications and the DataServerPeer is used to access user specific data. For an enhanced data access there is another object that is not public yet, but will be released together with the Server API.
The BioID Database contains the data of all BioID users including general information about a user, account information associated with this user and the biometric Template, as well as the Patterns of this user. Any classification performed at the server is recorded in the database including classification results and the Patterns that have been classified. Additionally, all settings needed by the server are stored in the database.