PSBio Flows

This document briefly describes the processing flows of Search, Enroll, Update and Delete in PSBio.

Search

Search Flow in PSBio

1. Upon receiving a search request (Search), PSBio returns an initial status of SEARCH_IN_PROGRESS.

2. Two flows are triggered in parallel: the local search (local database and cache) and the remote search on the other PSBios. If the IDN is found (either in the local search or the remote search), the response will be SEARCH_MATCH or SEARCH_NOT_MATCH depending on the result of the biometric 1:1 match between the query and the existing record with the provided IDN. If the provided IDN is not found (absent from the local database, the local cache, and the other PSBios), the response will be SEARCH_FAILED.

Enroll

Enroll Flow in PSBio

1. Upon receiving a registration request (Enroll), PSBio returns an initial status of ENROLL_IN_PROGRESS.

2. The registration data are searched in the Blacklist. In case of a biometric match, the transaction is completed with the registration refused and status ENROLL_ANOMALY_BLACKLIST.

3. The registration's IDN is queried on the other PSBios with an IDN_Query call. If the IDN is found, the transaction is completed with the registration refused and status ENROLL_FAILED.

4. The biometrics are searched in the local database and cache. If found, the transaction will have response ENROLL_ANOMALY and PSBio will wait for the exception to be handled to complete the transaction. If the match occurs in the cache, an IDE packet is sent to update the other PSBios.

5. An IDE packet is sent to the other PSBios to synchronize caches and the status is changed to ENROLL_CACHE_OK. When the VRE responses are received, the status changes to ENROLL_OK and the transaction is completed.

Update

Update Flow in PSBio

1. Upon receiving an update request (Update), PSBio returns an initial status of UPDATE_IN_PROGRESS.

2. The registration data are searched in the Blacklist. In case of a biometric match, the transaction is completed with the update refused and status UPDATE_ANOMALY_BLACKLIST.

3. The registration's IDN is queried in the local database and cache, and also on the other PSBios with an IDN_Query call. If the IDN is not found, the transaction is completed with the update refused and status UDPATE_FAILED.

4. It is checked which PSBio holds the original registration. If it is another PSBio, the update is refused with status UPDATE_REFUSED.

5. If the registration belongs to this PSBio, the transaction continues to be processed: it is checked whether there is a pending exception for the original registration. If there is, the status is changed to UPDATE_REFUSED, the update is refused and the transaction is completed.

6. A biometric verification is performed between the update biometric data and the original registration. If there is no match, the status is changed to UPDATE_ANOMALY, and the transaction will remain pending until the exception is handled.

7. If it matches, it is checked whether there are new fingerprints. If there are none, the update is performed as a TRUSTED_ENROLL, the status is changed to UPDATE_OK and the transaction is completed.

8. If there are new fingerprints: they are searched in the blacklist. If found, the update is refused with status UPDATE_ANOMALY_BLACKLIST and the transaction is completed.

9. The new fingerprints are searched in the local database and cache. If they are not found, or are found with swapped positions (indices) of the same individual, the update is performed. An IDE packet is sent to the other PSBios (to update their caches). The status is temporarily changed to CACHE_OK, depending on whether there are unavailable PSBios or not. The update is performed, the status changed to UPDATE_OK and the transaction is completed.

10. If the new fingerprints are found in a different individual, the update is not performed, the status is changed to UPDATE_ANOMALY and the transaction will remain pending until the exception is handled.

Delete

Delete Flow in PSBio

1. Upon receiving a removal request (Delete), PSBio checks whether the original registration belongs to this PSBio. If not, the removal is refused with status DELETE_NOT_OK.

2. If the registration belongs to this PSBio, the status is changed to DELETE_PENDING and it is removed from the local database and the local cache.

3. PSBio notifies the removal to all other PSBios, which must remove the registration from the cache and revoke its validity. PSBio waits for the receipt confirmation from all the other PSBios. After receiving all confirmations, it changes the status to DELETE_OK and finalizes the flow.