1. Controle de Qualidade e Sequência¶

Quando o GBDS recebe uma nova transação, uma checagem de controle de qualidade e sequência é realizada. Essa verificação tem o propósito de evitar que transações ruins de serem inseridas no banco de dados.

Qualquer transação rejeitada pela controle de qualidade e sequência é enviada ao MIR para revisão manual.

1.1. Passos de Verificação¶

1.1.1. Checagem de Qualidade¶

O primeiro passo quando se recebe uma nova transação é a realização de uma verificação de qualidade pelo GBDS de cada template de biometria submetido.

Se a qualidade de qualquer template não alcançar o limiar configurado [1], toda a transação é enviada para o MIR para verificação manual.

[1]	Veja o Manual de Configuração do GBDS ou contate o time de suporte da Griaule para mais informações.

Qualquer problema identificado por esse passo de verificação será retornado como "QualityIssue" pela API.

1.1.2. Checagem de Duplicidade¶

Nesse passo, o GBDS compara cada digital contra as outras para checar duplicidade.

Se alguma duplicata for identificada, a transação é enviada para o MIR para verificação manual.

Qualquer problema identificado nesse passo será retornado como "DuplicationIssue" pela API.

1.1.3. Checagem de Sequência¶

Para realizar esse passo, o GBDS requer imagens de digitais pousadas capturadas simultaneamente (4-slap fingerprint) (índices 940 e 941)

O GBDS tentará segmentar essas imagens e extrair um número predeterminado de biometrias [2]. Então, irá comparar as imagens segmentadas contra as digitais capturadas individualmente (usualmente, capturas roladas).

Se qualquer comparação identificar um não-casamento, o GBDS tentará corrigir o índice dos dedos que não casam e fará uma autocorreção.

Se houver qualquer problema identificado que o GBDS não possa autocorrigir, ou que o número de autocorreções seja maior que o máximo configurado [3], nenhuma correção será feita e a transação será enviada para o MIR.

Qualquer problema identificado nesse passo de verificação será retornado como "SequenceControlIssue" pela API.

[2]	Em casos de amputação ou deficiência temporária, a imagem pode conter menos que quatro dedos.

[3]	Veja o manual de configuração do GBDS ou contate o time de suporte da Griaule para mais informações. O fluxo de comparação para checagem de sequência será o seguinte:

1.1.3.1. Fluxo de Trabalho de Comparação¶

As imagens individuais das digitais (roladas ou planas), com índices entre 0 e 3 [4] serão comparadas contra as imagens segmentadas do índice 940.

Então, as imagens de digitais individuais dos índices entre 6 e 9 serão comparadas contra as imagens segmentadas do índice 941.

[4]	Os índices para as imagens de digitais individuais são:

Índice	Digital	Índice	Digital
0	Mínimo Esquerdo	5	Polegar Direito
1	Anelar Esquerdo	6	Indicador Direito
2	Médio Esquerdo	7	Médio Direito
3	Indicador Esquerdo	8	Anelar Direito
4	Polegar Esquerdo	9	Mínimo Direito

1.2. Tratando Anomalias¶

Para saber mais informações sobre o MIR e os processos de tratamento de anomalias, veja o manual do MIR, como mencionado acima.

Nessa seção, os processos de análise de qualidade realizados pelo servidor serão detalhados, desde o momento GBDS recebe a decisão fornecida pelo MIR.

1.2.1. Transação Aprovada Sem Mudanças¶

Dada essa decisão, o GBDS manterá a transação original sem mudanças e continuará o processo de cadastro. O GUID (Global Unique IDentifier) da transação (TGUID), irá permanecer o mesmo para ambas operações (QUALITY_ANALYSIS and ENROLL).

O fluxo de notificação será o seguinte:

1.2.1.1. Análise de Qualidade - Aprovado¶

A primeira notificação conterá o status "APPROVED" para a operação de "QUALITY_ANALYSIS".

{
    "operation": "QUALITY_ANALYSIS",
    "tguid": "<tguid>",
    "status": "APPROVED"
}

1.2.1.2. Cadastro - Cadastrado¶

A segunda notificação conterá o status "ENROLLED" para a seguinte operação de "ENROLL".

{
    "operation": "ENROLL",
    "tguid": "<tguid>",
    "status": "ENROLLED"
}

1.2.2. Transação Aprovada com Mudanças¶

Dada essa decisão, o GBDS irá manter as mudanças feitas pelo examinador (imagens deletadas ou editadas) e irá gerar um novo TGUID para o cadastro.

O fluxo de notificação para essa decisão é similar ao gerado pela “Transação Aprovada sem Mudanças”, adicionando o novo TGUID:

1.2.2.1. Análise de Qualidade - Aprovado¶

A primeira notificação conterá o status "APPROVED" para operação de "QUALITY_ANALYSIS" e incluirá o novo campo "newTransactionGUID" denotando que a transação foi aceita com mudanças e apontando para o novo TGUID.

{
    "newTransactionGUID": "<new_tguid>",
    "operation": "QUALITY_ANALYSIS",
    "tguid": "<original_tguid>",
    "status": "APPROVED"
}

1.2.2.2. Cadastro - Cadastrado¶

A segunda notificação conterá o status "ENROLLED" para a seguinte operação de "ENROLL".

Note

A operação de ENROLL será realizada para a transação alterada, então o TGUID mencionado será o novo que foi gerado pela operação de QUALITY_ANALYSIS.

{
    "operation": "ENROLL",
    "tguid": "<new_tguid>",
    "status": "ENROLLED"
}

1.2.3. Transação Rejeitada¶

Dada a decisão, o GBDS não continuará o processo de cadastro e descartará [5] toda a transação. O TGUID continuará o mesmo.

[5]	O histórico da transação será mantido, mas o perfil não será inserido no banco de dados como um registro de pessoa ativa.

O fluxo de notificação será o seguinte:

1.2.3.1. Análise de Qualidade - Rejeitado¶

A primeira notificação conterá o status "REJECTED" pela operação de "QUALITY_ANALYSIS".

{
    "operation": "QUALITY_ANALYSIS",
    "tguid": "<tguid>",
    "status": "REJECTED"
}

1.2.3.2. Cadastro - Falha¶

O resultado da operação de QUALITY_ANALYSIS será seguido de uma notificação de cadastro apontando para o status "FAILED" para a operação de "ENROLL".

{
    "operation": "ENROLL",
    "tguid": "tguid",
    "status": "FAILED"
}