BILAG 39

UDVEKSLING AF DNA, FINGERAFTRYK OG OPLYSNINGER FRA KØRETØJSREGISTRE

KAPITEL 0

ALMINDELIGE BESTEMMELSER

Artikel 1 Formål Formålet med dette bilag er at fastlægge de databeskyttelsesbestemmelser og administrative og tekniske bestemmelser, der er nødvendige for gennemførelsen af tredje del, afsnit II, i denne aftale.

Artikel 2 Tekniske specifikationer Staterne overholder de fælles tekniske specifikationer i forbindelse med alle anmodninger og svar vedrørende søgninger og sammenligninger af DNA-profiler, fingeraftryksoplysninger og oplysninger fra køretøjsregistre. Disse tekniske specifikationer er fastsat i kapitel 1-3.

Artikel 3 Kommunikationsnet Elektronisk udveksling mellem staterne af DNA-oplysninger, fingeraftryksoplysninger og oplysninger fra køretøjsregistre finder sted ved anvendelse af kommunikationsnettet Trans European Services for Telematics between Administrations (TESTA II) og senere udviklinger heraf.

Artikel 4 Sikring af elektronisk udveksling af oplysninger Staterne træffer de nødvendige foranstaltninger for at sikre, at elektronisk søgning og sammenligning af DNA-oplysninger, fingeraftryksoplysninger og oplysninger fra køretøjsregistre kan finde sted døgnet rundt alle ugens dage. Hvis der opstår en teknisk fejl, underretter staternes nationale kontaktpunkter omgående hinanden og aftaler midlertidige alternative ordninger til udveksling af oplysninger i henhold til gældende retlige bestemmelser. Den elektroniske udveksling af oplysninger skal genoprettes hurtigst muligt.

Artikel 5 Referencenumre vedrørende DNA- og fingeraftryksoplysninger Referencenumrene i artikel 529 og 533 i denne aftale består af en kombination af følgende: a) en kode, der i tilfælde af overensstemmelse gør det muligt for staterne at finde personoplysninger og andre oplysninger i deres databaser for at levere dem til en, flere eller samtlige stater i henhold til artikel 536 i denne aftale b) en kode til angivelse af DNA-profilens eller fingeraftryksoplysningernes oprindelsesland, og c) med hensyn til DNA-oplysninger en kode til angivelse af DNA-profilens type.

Artikel 6 Principper for udveksling af DNA-oplysninger 1. Staterne anvender eksisterende standarder for udveksling af DNA-oplysninger, som for eksempel det Europæiske standardsæt (ESS) eller INTERPOL's standardsæt af loci (ISSOL). 2. I forbindelse med elektronisk søgning og sammenligning af DNA-profiler finder overførselsproceduren sted inden for en decentraliseret struktur. 3. Der træffes passende foranstaltninger for at garantere oplysningers fortrolighed og integritet under overførsel til andre stater, herunder kryptering af oplysningerne. 4. Staterne træffer de fornødne foranstaltninger til at sikre integriteten af de DNA-profiler, der er stillet til rådighed for eller fremsendt til de andre stater med henblik på sammenligning, og for at sikre, at disse foranstaltninger overholder internationale standarder som f.eks. ISO 17025. 5. Staterne anvender landekoder i overensstemmelse med ISO 3166-1 alpha-2-standarden.

Artikel 7 Regler for anmodninger og svar vedrørende DNA-oplysninger 1. Anmodninger om elektronisk søgning eller sammenligning, jf. artikel 530 eller 531 i denne aftale, må kun indeholde følgende oplysninger: a) den anmodende stats landekode b) anmodningens dato, tidspunkt og indikationsnummer c) DNA-profilerne og disses referencenumre d) de fremsendte DNA-profilers typer (uidentificerede DNA-profiler eller reference-DNA-profiler) og e) oplysninger, der er nødvendige for styring af databasesystemerne og kvalitetskontrol i forbindelse med de elektroniske søgeprocesser. 2. Svaret (overensstemmelsesrapporten) på anmodningen i stk. 1 må kun indeholde følgende oplysninger: a) angivelse af, hvorvidt der er konstateret overensstemmelse med én eller flere DNA-profiler eller ej b) anmodningens dato, tidspunkt og indikationsnummer c) svarets dato, tidspunkt og indikationsnummer d) den anmodende og den anmodede stats landekode e) den anmodende og den anmodede stats referencenummer f) de fremsendte DNA-profilers typer (uidentificerede DNA-profiler eller reference-DNA-profiler) g) de ønskede og de matchende DNA-profiler og h) oplysninger, der er nødvendige for styring af databasesystemerne og kvalitetskontrol i forbindelse med de elektroniske søgeprocesser. 3. Der gives kun elektronisk meddelelse om overensstemmelse, hvis den elektroniske søgning eller sammenligning har resulteret i overensstemmelse mellem et mindste antal loci. Dette mindste antal er anført i kapitel 1. 4. Staterne sikrer, at anmodninger overholder de erklæringer, der er fremsat i overensstemmelse med artikel 529, stk. 3, i denne aftale.

Artikel 8 Procedure for overførsel af elektronisk søgning af uidentificerede DNA-profiler i henhold til artikel 530 1. Hvis der i forbindelse med en søgning med en uidentificeret DNA-profil ikke er fundet overensstemmelse i den nationale database, eller hvis der er fundet overensstemmelse med en uidentificeret DNA-profil, kan denne uidentificerede DNA-profil overføres til alle andre staters databaser, og hvis der i forbindelse med en søgning med denne uidentificerede DNA-profil findes overensstemmelse med reference-DNA-profiler og/eller uidentificerede DNA-profiler i andre staters databaser, meddeles disse tilfælde automatisk, og DNA-referenceoplysningerne overføres til den anmodende stat; hvis der ikke findes overensstemmelse i andre staters databaser, meddeles dette automatisk til den anmodende stat. 2. Hvis der i forbindelse med en søgning med en uidentificeret DNA-profil findes overensstemmelse i andre staters database, kan de berørte stater indsætte en note herom i deres nationale databaser.

Artikel 9 Procedure for overførsel af elektronisk søgning af reference-DNA-profiler i henhold til artikel 530 Hvis der i forbindelse med en søgning med en reference-DNA-profil ikke er fundet overensstemmelse i den nationale database med en reference-DNA-profil, eller der er fundet overensstemmelse med en uidentificeret DNA-profil, kan denne reference-DNA-profil overføres til alle andre staters databaser, og hvis der i forbindelse med en søgning med denne reference-DNA-profil findes overensstemmelse med reference-DNA-profiler og/eller uidentificerede DNA-profiler i andre staters database, meddeles disse tilfælde automatisk, og DNA-referenceoplysningerne overføres til den anmodende stat; hvis der ikke findes overensstemmelse i andre staters databaser, meddeles dette automatisk til den anmodende stat.

Artikel 10 Procedure for overførsel af elektronisk sammenligning af uidentificerede DNA-profiler i henhold til artikel 531 1. Hvis der i forbindelse med en sammenligning med uidentificerede DNA-profiler findes overensstemmelse i andre staters databaser med reference-DNA-profiler og/eller uidentificerede DNA-profiler, meddeles disse tilfælde automatisk, og DNA-referenceoplysningerne overføres til den anmodende stat. 2. Hvis der i forbindelse med en sammenligning med uidentificerede DNA-profiler findes overensstemmelse i andre staters databaser med uidentificerede DNA-profiler eller reference-DNA-profiler, kan de berørte stater indsætte en note herom i deres nationale databaser.

Artikel 11 Principper for udveksling af fingeraftryksoplysninger 1. Digitalisering af fingeraftryksoplysninger og overførsel heraf til de øvrige stater finder sted ved anvendelse af det ensartede dataformat, der er anført i kapitel 2. 2. Staterne sikrer, at kvaliteten af de fingeraftryksoplysninger, som de overfører, er tilstrækkelig høj til, at oplysningerne kan behandles i det elektroniske fingeraftryksidentifikationssystem (AFIS). 3. Overførselsproceduren for udveksling af fingeraftryksoplysninger finder sted inden for en decentraliseret struktur. 4. Der træffes passende foranstaltninger for at garantere fingeraftryksoplysningers fortrolighed og integritet under fremsendelse til andre stater, herunder kryptering af disse. 5. Staterne anvender landekoder i overensstemmelse med ISO 3166-1 alpha-2-standarden.

Artikel 12 Søgekapacitet for fingeraftryksoplysninger 1. Staterne sikrer, at deres søgningsanmodninger ikke overstiger den søgekapacitet, den anmodede stat har anført. Det Forenede Kongerige afgiver en erklæring om den maksimale søgekapacitet pr. dag for fingeraftryksoplysninger vedrørende identificerede personer og for fingeraftryksoplysninger vedrørende ikkeidentificerede personer. 2. Det maksimale antal personer, der accepteres med henblik på kontrol pr. overførsel, er fastsat i kapitel 2.

Artikel 13 Regler for anmodninger og svar i forbindelse med fingeraftryksoplysninger 1. Den anmodede stat kontrollerer omgående kvaliteten af de fremsendte fingeraftryksoplysninger ved en fuldautomatisk procedure. Hvis oplysningerne er uegnede til elektronisk sammenligning, underretter den anmodede stat omgående den anmodende stat herom. 2. Den anmodede stat foretager søgninger i den rækkefølge, hvori anmodninger modtages. Anmodninger behandles inden for 24 timer ved en fuldautomatisk procedure. Den anmodende stat kan anmode om fremskyndet behandling af sine anmodninger, hvis dens nationale lovgivning foreskriver det, og den anmodede stat foretager disse søgninger omgående. Hvis tidsfristerne på grund af force majeure ikke kan overholdes, foretages sammenligningen umiddelbart efter, at hindringerne er fjernet.

Artikel 14 Principper for elektronisk søgning af oplysninger i køretøjsregistre 1. Til elektronisk søgning af oplysninger i køretøjsregistre anvender staterne en version af softwareprogrammet til det Europæiske informationssystem vedrørende køretøjer og kørekort (Eucaris), der er udformet specielt med henblik på artikel 537 i denne aftale, og ændrede versioner af dette softwareprogram. 2. Elektronisk søgning af oplysninger i køretøjsregistre finder sted inden for en decentraliseret struktur. 3. Oplysninger, der udveksles via Eucarissystemet, overføres i krypteret form. 4. Det angives i kapitel 3, hvilke oplysninger fra køretøjsregistrene der skal udveksles. 5. Ved gennemførelsen af artikel 537 i denne aftale kan staterne give førsteprioritet til søgninger, der vedrører bekæmpelse af alvorlig kriminalitet.

Artikel 15 Omkostninger Staterne afholder alle omkostninger i forbindelse med forvaltning, anvendelse og vedligeholdelse af det i artikel 14, stk. 1, nævnte Eucarissoftwareprogram.

Artikel 16 Formål 1. Den modtagende stat må kun behandle personoplysninger til de formål, hvortil oplysningerne er leveret i henhold til tredje del, afsnit II, i denne aftale. Behandling til andre formål er kun tilladt efter forudgående samtykke fra den stat, der forvalter databasen, og kun under overholdelse af den modtagende stats nationale lovgivning. Samtykke kan gives, hvis behandling til sådanne andre formål er tilladt i henhold til den nationale lovgivning i den stat, der forvalter databasen. 2. Den stat, der søger eller sammenligner oplysninger, må kun behandle oplysninger, der er leveret i henhold til artikel 530, 531 og 534 i denne aftale, med henblik på a) at fastslå, om de sammenlignede DNA-profiler eller fingeraftryksoplysninger stemmer overens b) at udarbejde og indgive en politi- eller retsanmodning om retshjælp i overensstemmelse med den nationale lovgivning, hvis disse oplysninger stemmer overens c) at foretage registrering som omhandlet i dette kapitels artikel 19. 3. Den stat, der forvalter databasen, må kun behandle oplysninger, som den har fået leveret i henhold til artikel 530, 531 og 534 i denne aftale, hvis dette er nødvendigt for at foretage en sammenligning, en elektronisk besvarelse af søgningen eller en registrering som omhandlet i dette kapitels artikel 19. Når oplysningerne er sammenlignet, eller søgningen er besvaret elektronisk, skal de leverede oplysninger straks slettes, medmindre der er behov for yderligere behandling til de formål, der er anført i denne artikels stk. 2, litra b) og c). 4. Oplysninger, der er leveret i henhold til artikel 537 i denne aftale, må kun bruges af den stat, der forvalter databasen, hvis det er nødvendigt for at foretage en elektronisk besvarelse af søgning eller en registrering i henhold til dette kapitels artikel 19. Når søgning er besvaret elektronisk, skal de leverede oplysninger straks slettes, medmindre der er behov for yderligere behandling med henblik på registrering som omhandlet i dette kapitels artikel 19. Den søgende stat må kun anvende de oplysninger, der er fundet ved søgningen, til den procedure, på grundlag af hvilken søgningen er foretaget.

Artikel 17 Oplysningernes rigtighed, aktualitet og lagringstid 1. Staterne sikrer personoplysningers rigtighed og aktualitet. Hvis det uden videre eller efter meddelelse fra den registrerede viser sig, at der er leveret urigtige oplysninger eller oplysninger, der ikke skulle have været leveret, skal dette straks meddeles den modtagende stat. De(n) har pligt til at rette eller slette oplysningerne. Desuden skal leverede personoplysninger rettes, hvis det viser sig, at de er urigtige. Hvis den modtagende myndighed har grund til at antage, at de leverede oplysninger er urigtige eller bør slettes, underretter den straks den leverende myndighed herom. 2. Oplysninger, hvis rigtighed den registrerede anfægter, og hvis rigtighed eller urigtighed ikke kan fastslås, skal under overholdelse af staternes nationale lovgivning forsynes med en påtegning efter anmodning fra den registrerede. Hvis der er foretaget en påtegning, kan denne under overholdelse af staternes nationale lovgivning kun fjernes med den registreredes samtykke eller på grundlag af en afgørelse truffet af den kompetente domstol eller det kompetente uafhængige databeskyttelsesorgan. 3. Leverede personoplysninger slettes, hvis de ikke skulle have været leveret eller modtaget. Retmæssigt leverede og modtagne oplysninger slettes, a) hvis de ikke eller ikke længere er nødvendige til det formål, hvortil de er leveret; hvis personoplysninger leveres uden anmodning, skal det modtagende organ straks kontrollere, om de er nødvendige til de formål, hvortil de er leveret b) efter udløbet af den maksimumsperiode for opbevaring af oplysningerne, som er fastsat i den leverende stats nationale lovgivning, hvis det leverende organ har oplyst det modtagende organ om denne maksimumsperiode ved leveringen. 4. I stedet for at blive slettet blokeres oplysningerne under overholdelse af den nationale lovgivning, hvis der er grund til at antage, at sletning vil skade den registreredes interesser. Blokerede oplysninger må kun leveres eller bruges til det formål, af hensyn til hvilket sletning er undladt.

Artikel 18 Tekniske og organisatoriske foranstaltninger med henblik på databeskyttelse og datasikkerhed 1. Det leverende og det modtagende organ har pligt til effektivt at beskytte personoplysninger mod hændelig eller uautoriseret tilintetgørelse, hændeligt tab, uautoriseret adgang, uautoriseret eller hændelig ændring og uautoriseret videregivelse. 2. Enkelthederne i den tekniske udformning af den elektroniske søgeprocedure fastsættes i gennemførelsesforanstaltningerne, jf. artikel 539 i denne aftale, der sikrer, a) at der træffes foranstaltninger til ved hjælp af den mest avancerede teknik at garantere databeskyttelse og datasikkerhed, især oplysningernes fortrolighed og integritet b) at der anvendes anerkendte krypterings- og autoriseringsprocedurer, når de kompetente organer benytter almindeligt tilgængelige net, og c) at det i overensstemmelse med dette kapitels artikel 19, stk. 2, 5 og 6, kan kontrolleres, om søgninger er tilladt.

Artikel 19 Logning og registrering: særlige forskrifter vedrørende elektronisk og ikkeelektronisk levering 1. Hver stat sikrer, at enhver ikkeelektronisk levering og enhver ikkeelektronisk modtagelse af personoplysninger i det organ, der forvalter databasen, og i det søgende organ, logges med henblik på at kontrollere, om leveringen er tilladt. Logningen omfatter følgende oplysninger: a) grunden til leveringen b) de leverede oplysninger c) datoen for leveringen, og d) navnet eller referencekoden på det søgende organ og det organ, der forvalter databasen. 2. For elektronisk søgning af oplysninger i henhold til artikel 530, 534 og 537 i denne aftale og elektronisk sammenligning i henhold til artikel 531 i denne aftale gælder følgende: a) elektronisk søgning eller sammenligning må kun foretages af særligt bemyndigede embedsmænd fra de nationale kontaktpunkter; efter anmodning forelægges en liste over embedsmænd, der er bemyndigede til at foretage elektronisk søgning eller sammenligning, for de tilsynsførende myndigheder, der er nævnt i stk. 6, og for de andre stater b) hver stat sikrer, at enhver levering og modtagelse af personoplysninger i det organ, der forvalter databasen, og i det søgende organ registreres, herunder meddelelse om, hvorvidt der er fundet et HIT registreringen omfatter følgende oplysninger: i) de leverede oplysninger ii) datoen og det nøjagtige tidspunkt for leveringen og iii) navnet eller referencekoden på det søgende organ og det organ, der forvalter databasen. 3. Det søgende organ registrerer desuden grunden til søgningen eller leveringen og referencen på den embedsmand, der har foretaget søgningen, og den embedsmand, der har givet ordre til søgningen eller leveringen. 4. Det registrerende organ meddeler efter anmodning de registrerede oplysninger til den pågældende stats kompetente databeskyttelsesmyndigheder senest fire uger efter modtagelsen af anmodningen; registrerede oplysninger må kun bruges til følgende formål: a) kontrol af databeskyttelse b) sikring af datasikkerhed. 5. De registrerede oplysninger skal med passende midler beskyttes mod uretmæssig brug og andre former for misbrug og opbevares i to år. Efter opbevaringsperiodens udløb skal de registrerede oplysninger straks slettes. 6. Den juridiske kontrol af leveringen eller modtagelsen af personoplysninger ligger hos de respektive staters uafhængige databeskyttelsesmyndigheder eller, hvor det er relevant, judicielle myndigheder. Under overholdelse af den nationale lovgivning kan enhver anmode disse myndigheder om at kontrollere, om behandlingen af oplysninger om den pågældende er retmæssig. Disse myndigheder og de organer, der er ansvarlige for registrering, skal også uden anmodning foretage stikprøvekontrol af leveringernes retmæssighed på grundlag af de sagsakter, der ligger til grund herfor. 7. Resultaterne af denne kontrol opbevares af de uafhængige databeskyttelsesmyndigheder i 18 måneder. Efter denne periodes udløb skal de straks slettes. Hver databeskyttelsesmyndighed kan anmodes af en anden stats uafhængige databeskyttelsesmyndighed om at udøve sine beføjelser under overholdelse af den nationale lovgivning. Staternes uafhængige databeskyttelsesmyndigheder gennemfører det samarbejde, der er nødvendigt for deres kontrolopgaver, navnlig gennem udveksling af relevante oplysninger.

Artikel 20 Registreredes ret til skadeserstatning Når den ene stats organ har leveret personoplysninger i henhold til tredje del, afsnit II, i denne aftale, kan den anden stats modtagende organ ikke unddrage sig sit ansvar over for skadelidte i henhold til national lovgivning med den begrundelse, at de leverede oplysninger var urigtige. Hvis det modtagende organ yder erstatning for en skade, der skyldes brug af urigtige videregivne oplysninger, godtgør det leverende organ det modtagende organ hele det udbetalte erstatningsbeløb.

Artikel 21 Oplysninger efter anmodning fra staterne Den modtagende stat underretter efter anmodning den leverende stat om behandlingen af de leverede oplysninger og resultatet heraf.

Artikel 22 Erklæringer og udpegelser 1. Det Forenede Kongerige meddeler sine erklæringer i henhold til artikel 529, stk. 3, i denne aftale og artikel 12, stk. 1, i dette kapitel samt sine udpegelser i henhold til artikel 535, stk. 1, og artikel 537, stk. 3, i denne aftale til specialudvalget om retshåndhævelse og retligt samarbejde. 2. De faktuelle oplysninger, som forelægges af Det Forenede Kongerige i form af disse erklæringer og udpegelser og af medlemsstaterne i overensstemmelse med artikel 539, stk. 3, i denne aftale, findes i håndbogen som omhandlet i artikel 18, stk. 2, i afgørelse 2008/616/RIA. 3. Stater kan til enhver tid ændre de erklæringer og udpegelser, der er forelagt i henhold til stk. 1, ved hjælp af en meddelelse til specialudvalget om retshåndhævelse og retligt samarbejde. Specialudvalget om retshåndhævelse og retligt samarbejde videresender alle modtagne erklæringer til Generalsekretariatet for Rådet. 4. Generalsekretariatet for Rådet meddeler eventuelle ændringer i den i stk. 2 omhandlede håndbog til specialudvalget om retshåndhævelse og retligt samarbejde.

Artikel 23 Forberedelse af afgørelser som omhandlet i artikel 540 1. Rådet træffer afgørelse som omhandlet i artikel 540 i denne aftale på grundlag af en evalueringsrapport, der baseres på et spørgeskema. 2. Med hensyn til den elektroniske dataudveksling i overensstemmelse med tredje del, afsnit II, i denne aftale baseres evalueringsrapporten ligeledes på et evalueringsbesøg og en forsøgsfase, der gennemføres, når Det Forenede Kongerige har underrettet specialudvalget om retshåndhævelse og retligt samarbejde om, at det har opfyldt de forpligtelser, som det er pålagt i henhold til tredje del, afsnit II, i denne aftale, og afgiver de erklæringer, der er fastsat i dette kapitels artikel 22. Yderligere enkeltheder vedrørende proceduren er fastsat i dette bilags kapitel 4.

Artikel 24 Statistik og rapporter 1. Den administrative, tekniske og finansielle anvendelse af dataudvekslingen i henhold til tredje del, afsnit II, i denne aftale evalueres regelmæssigt. Evalueringen gennemføres for de kategorier af data, for hvilke dataudvekslingen er påbegyndt for de berørte staters vedkommende. Evalueringen baseres på rapporter fra de respektive stater. 2. Hver stat indsamler statistikker om resultaterne af den elektroniske dataudveksling. For at sikre, at statistikkerne er sammenlignelige, vil den relevante arbejdsgruppe i Rådet udarbejde statistikmodellen. Disse statistikker sendes hvert år til specialudvalget om retshåndhævelse og retligt samarbejde. 3. Staterne vil desuden regelmæssigt, men højst én gang hvert år, blive anmodet om at forelægge yderligere oplysninger om den administrative, tekniske og finansielle gennemførelse af elektronisk dataudveksling, som er nødvendig for at analysere og forbedre processen. 4. I forbindelse med denne artikel finder statistikker og rapportering fra medlemsstaterne i overensstemmelse med afgørelse 2008/615/RIA og 2008/616/RIA anvendelse.

KAPITEL 1

UDVEKSLING AF DNA-OPLYSNINGER

1. DNA-relaterede retsmedicinske spørgsmål, overensstemmelsesregler og algoritmer

1.1. Egenskaber ved DNA-profilerne

DNA-profilen kan indeholde 24 talpar, der repræsenterer allelerne af 24 loci, der også benyttes i INTERPOL's DNA-procedurer. Navnene på disse loci er anført i følgende skema:

VWA TH01 D21S11 FGA D8S1179 D3S1358 D18S51 Amelogenin TPOX CSF1P0 D13S317 D7S820 D5S818 D16S539 D2S1338 D19S433 Penta D Penta E FES F13A1 F13B SE33 CD4 GABA

De syv grå loci i øverste række er det nuværende ESS og ISSOL.

Medtagelsesregler:

De DNA-profiler, som staterne stiller til rådighed for eller udsender med henblik på søgning og sammenligning, skal indeholde mindst seks fulde udpegede (1) loci og kan indeholde yderligere loci eller blanke felter alt efter, hvad der er tilgængeligt. Reference-DNA-profilerne skal indeholde mindst 6 af de 7 ESS-loci. For at højne overensstemmelsespræcisionen opbevares alle de tilgængelige alleler i den indekserede DNA-profildatabase og benyttes til søgning og sammenligning. Hver stat bør, så hurtigt som det er praktisk gennemførligt, implementere enhver ny ESS for loci, som vedtages af EU.

Blandede profiler er ikke tilladt, hvilket vil sige, at allelværdien for hvert locus kun består af to tal, der kan være ens i tilfælde af homozygositet i et givet locus.

Jokere og mikrovarianter behandles efter følgende regler:

— Enhver ikkenumerisk værdi bortset fra amelogenin i profilen (f.eks. "o", "f", "r", "na", "nr" eller "un") skal ved eksport automatisk konverteres til en joker (*) og søges på i forhold til alle.

— Numeriske værdier "0", "1" eller "99" i profilen skal ved eksport automatisk konverteres til en joker (*) og søges på i forhold til alle.

— Hvis der forekommer tre alleler for en og samme locus, vil den første allel blive accepteret, og de to andre alleler skal ved eksport automatisk konverteres til en joker (*) og søges på i forhold til alle.

— Når der forekommer jokerværdier for allel 1 eller 2, vil der blive søgt på begge permutationer af den numeriske værdi for den pågældende locus (f.eks. vil 12, * give overensstemmelse med 12,14 eller 9,12).

— Pentanucleotide (Penta D, Penta E & CD4) mikrovarianter vil give overensstemmelse efter følgende model: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x.4 — x.4 = x.3, x.4, x + 1,

— Tetranucleotide (alle andre loci er tetranucleotide) mikrovarianter vil give overensstemmelse efter følgende model: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x + 1.

1.2. Overensstemmelsesregler

Sammenligningen af to DNA-profiler sker på grundlag af de loci, for hvilke et allelværdipar er til stede i begge DNA-profiler. Mindst 6 fulde udpegede loci (ekskl. amelogenin) skal være sammenfaldende i de to DNA-profiler, før der gives overensstemmelsessvar.

Fuld overensstemmelse (kvalitet 1) defineres som en overensstemmelse, hvor alle allelværdier for de sammenlignede loci, der er almindeligt forekommende i de anmodende og anmodede DNA-profiler, er ens. Næsten-overensstemmelse defineres som en overensstemmelse, hvor kun værdien af en enkelt af alle de sammenlignede alleler er forskellig i de to DNA-profiler (kvalitet 2, 3 og 4). En næsten-overensstemmelse accepteres kun, hvis der er mindst 6 fulde udpegede overensstemmende loci i de to sammenlignede DNA-profiler.

En næsten-overensstemmelse kan skyldes:

— en menneskelig slåfejl i en af DNA-profilerne i søgningen eller DNA-databasen ved indrejsestedet

— en allelbestemmelses- eller allelfremkaldelsesfejl under genereringen af DNA-profilen.

1.3. Indberetningsregler

Fuld overensstemmelse, næsten-overensstemmelse og "ingen overensstemmelse" vil alle blive indberettet.

Overensstemmelsesrapporten vil blive sendt til det anmodende nationale kontaktpunkt og gøres også tilgængelig for det anmodede nationale kontaktpunkt (så det kan danne sig et overblik over, hvilken art og hvor mange opfølgende anmodninger der vil kunne komme om yderligere tilgængelige personoplysninger og andre oplysninger vedrørende den DNA-profil, der svarer til den fundne overensstemmelse, jf. artikel 536 i denne aftale.

2. Skema over landekoder

I overensstemmelse med tredje del, afsnit II, i denne aftale benyttes ISO 3166-1-alpha-2-koderne til domænenavne og andre konfigurationsparametre, der er krævet i Prümaftalens DNA-udvekslingsprogrammer via et lukket netværk.

ISO 3166-1-alpha-2-koderne for staterne er nedenstående landekoder med to bogstaver.

Staternes navne Kode Staternes navne Kode Belgien BE Litauen LT Bulgarien BG Luxembourg LU Den Tjekkiske Republik CZ Ungarn HU Danmark DK Malta MT Tyskland DE Nederlandene NL Estland EE Østrig AT Irland IE Polen PL Grækenland EL Portugal PT Spanien ES Rumænien RO Frankrig FR Slovakiet SK Kroatien HR Slovenien SI Italien IT Finland FI Cypern CY Sverige SE Letland LV Det Forenede Kongerige UK

3. Funktionsanalyse

3.1. Systemets tilgængelighed

Anmodninger i henhold til artikel 530 i denne aftale bør nå frem til den søgte database i kronologisk orden efter de enkelte anmodningers afsendelsestidspunkt, og svar bør afsendes, så de når frem til den anmodende stat senest 15 minutter efter, at anmodningen er modtaget.

3.2. Anden etape

Når en stat modtager en indberetning om en overensstemmelse er dens nationale kontaktpunkt ansvarlig for at sammenligne værdierne i den profil, der blev indsendt som en forespørgsel, med værdierne i den eller de profiler, der blev modtaget som svar, med henblik på at validere og kontrollere profilens beviskraft. De nationale kontaktpunkter kan kontakte hinanden direkte om spørgsmål, der vedrører validering.

Procedurer for juridisk bistand begynder efter validering af en konstateret overensstemmelse mellem to profiler på grundlag af en "fuld overensstemmelse" eller en "næsten-overensstemmelse", der er fremkommet i den automatiske konsultationsfase.

4. DNA-grænsefladekontroldokument (ICD)

4.1. Indledning

4.1.1. Formål

I dette kapitel defineres kravene vedrørende udveksling af DNA-profiloplysninger mellem alle staternes DNA-databasesystemer. Headerfelterne er defineret specielt med henblik på Prümudvekslingen af DNA-oplysninger, og datadelen er baseret på DNA-profildatadelen i det XML-skema, der er defineret til INTERPOL's DNA-udvekslingsgateway.

Oplysningerne udveksles med Simple Mail Transfer Protocol (SMTP) og andre avancerede teknologier og benytter en central relaymailserver, som netudbyderen stiller til rådighed. XML-filen sendes som mail body.

4.1.2. Anvendelsesområde

Dette ICD definerer kun indholdet af meddelelsen (eller mailen). Alle netværksspecifikke og mailspecifikke elementer er defineret ens, så der opnås et fælles teknisk grundlag for udveksling af DNA-oplysninger.

Dette omfatter:

— formatet af meddelelsens emnefelt, så det bliver muligt at edb-behandle meddelelserne

— overvejelser om behovet for kryptering, og i bekræftende fald hvilke metoder der bør vælges

— meddelelsernes maksimale længde.

4.1.3. XML-struktur og principper

XML-meddelelsen er opdelt i:

— headerdelen, der indeholder oplysninger om transmissionen, og

— datadelen, der indeholder profilspecifikke oplysninger samt selve profilen.

Det samme XML-skema benyttes til anmodning og til svar.

Når det drejer sig om komplette verifikationer af uidentificerede DNA-profiler, jf. artikel 531 i denne aftale, skal det være muligt at sende flere profiler i samme meddelelse. Der skal fastsættes et maksimalt antal profiler, der kan være indeholdt i en enkelt meddelelse. Antallet afhænger af den maksimale størrelse, som en mail må have, og skal fastlægges, når valget af mailserver er foretaget.

XML-eksempel:

<?version="1.0" standalone="yes"?>

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> datastrukturen gentages, hvis flere profiler sendes i (….) samme SMTP-meddelelse, hvilket kun er tilladt i tilfælde i henhold til artikel 531 i denne aftale

</datas>]

</PRUEMDNA>

4.2. Definition af XML-strukturen

Definitionerne i det følgende tjener kun dokumentationsformål og til at forbedre læsbarheden. De egentlige bindende oplysninger findes i en XML-skema-fil (PRUEM DNA.xsd).

4.2.1. Skemaet PRUEMDNAx

Den indeholder følgende felter:

Fields Type Description header PRUEM_header Occurs: 1 data PRUEM_data Occurs: 1 … 500

4.2.2. Indholdet af headerstrukturen

4.2.2.1. PRUEM header Denne struktur beskriver XML-filens header. Den indeholder følgende felter: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting State info requested PRUEM_header_info Requesting State info

4.2.2.2. PRUEM_header dir Typer af data i meddelelsen. Værdien kan være: Value Description R Request A Answer

4.2.2.3. PRUEM header info Denne struktur beskriver staten samt dato og tidspunkt. Den indeholder følgende felter: Fields Type Description source_isocode String ISO 3166-2 code of the requesting State destination_isocode String ISO 3166-2 code of the requested State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message

4.2.3. Indholdet af PRUEM-profilens data

4.2.3.1. PRUEM_datas Denne struktur beskriver XML-profilens datadel. Den indeholder følgende felter: Fields Type Description reqtype PRUEM request type Type of request (Article 530 or 531) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (HIT) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of HIT hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality!=0 (the original requested profile), then empty.

4.2.3.2. PRUEM_request_type Typer af data i meddelelsen. Værdien kan være: Value Description 3 Requests pursuant to Article 530 4 Requests pursuant to Article 531

4.2.3.3. PRUEM_hitquality_type Value Description 0 Referring original requesting profile: Case "No-HIT": original requesting profile sent back only; Case "HIT": original requesting profile and matched profiles sent back. 1 Equal in all available alleles without wildcards 2 Equal in all available alleles with wildcards 3 HIT with Deviation (Microvariant) 4 HIT with mismatch

4.2.3.4. PRUEM_data_type Typer af data i meddelelsen. Værdien kan være: Value Description P Person profile S Stain

4.2.3.5. PRUEM_data_result Typer af data i meddelelsen. Værdien kan være: Value Description U Undefined, If direction = R (request) H HIT n No-HIT E Error

4.2.3.6. IPSG_DNA_profile Denne struktur beskriver en DNA-profil. Den indeholder følgende felter: Fields Type Description ess_issol IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of INTERPOL) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile

4.2.3.7. IPSG_DNA_ISSOL Denne struktur indeholder ISSOL-loci (Standard Group of INTERPOL loci). Den indeholder følgende felter: Fields Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amelogin

4.2.3.8. IPSG_DNA_additional_loci Denne struktur indeholder de øvrige loci. Den indeholder følgende felter: Fields Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba

4.2.3.9. IPSG_DNA_locus Denne struktur beskriver en locus. Den indeholder følgende felter: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele

5. Program, sikkerhed og kommunikationsarkitektur

5.1. Oversigt

Når der implementeres programmer til DNA-udveksling inden for rammerne af tredje del, afsnit II, i denne aftale, skal der benyttes et fælles kommunikationsnetværk, der vil blive logisk lukket til staternes kreds. For at udnytte denne fælles kommunikationsinfrastruktur til afsendelse af anmodninger og modtagelse af svar så effektivt som muligt, anvendes en asynkron mekanisme til transmission af anmodninger om DNA-oplysninger og fingeraftryksoplysninger i en "wrapped" SMTP-e-mail. Af hensyn til sikkerheden vil SMTP-funktionen blive suppleret med S/MIME-mekanismen for at skabe en veritabel sikker ende-til-ende tunnel via netværket.

De operationelle Trans European Services for Telematics between Administrations (TESTA) anvendes som kommunikationsnet for udvekslingen af oplysninger mellem staterne. TESTA fungerer under Europa-Kommissionens ansvar. I betragtning af at de nationale DNA-databaser og det nuværende nationale TESTA-tilkoblingspunkt kan befinde sig på forskellige operationssteder i staterne, kan adgangen til TESTA etableres enten ved at:

1. benytte det nuværende nationale tilkoblingspunkt eller oprette et nyt nationalt tilkoblingspunkt til TESTA eller

2. oprette et sikkert lokalt link fra det operationssted, hvor DNA-databasen befinder sig og forvaltes af det kompetente nationale agentur, til det nuværende nationale tilkoblingspunkt til TESTA.

Protokollerne og standarderne i de programmer, der benyttes ved gennemførelsen af tredje del, afsnit II, i denne aftale, er i overensstemmelse med de åbne standarder og opfylder de krav, som staternes nationale sikkerhedspolitiske beslutningstagere har opstillet.

5.2. Den overordnede arkitektur

I medfør af tredje del, afsnit II, i denne aftale stiller hver stat sine DNA-oplysninger til rådighed for udveksling med andre stater og/eller for andre staters søgning i dem under overholdelse af det standardiserede fælles dataformat. Arkitekturen er baseret på en alle-til-alle-kommunikationsmodel. Der findes hverken en central computerserver eller en centraliseret database, hvor DNA-profiler opbevares.

Foruden at opfylde de nationale juridiske krav på staternes operationssteder kan hver stat beslutte, hvilken type hardware og software der skal benyttes til konfigurationen på operationsstedet, med henblik på at opfylde kravene i tredje del, afsnit II, i denne aftale.

5.3. Sikkerhedsstandarder og databeskyttelse

Der er blevet drøftet og indført sikkerhedsforanstaltninger på tre niveauer.

5.3.1. Dataniveauet

De DNA-profildata, som de enkelte stater leverer, skal forberedes i overensstemmelse med en fælles databeskyttelsesstandard, så de anmodende stater modtager et svar, der først og fremmest angiver, om der er overensstemmelse eller ej, samt i tilfælde af overensstemmelse et identifikationsnummer, der ikke indeholder nogen personoplysninger. Den videre efterforskning efter meddelelsen om en overensstemmelse sker på bilateralt plan efter de respektive staters operationssteders gældende nationale juridiske og organisatoriske regler.

5.3.2. Kommunikationsniveauet

Meddelelser, der indeholder DNA-profiloplysninger (anmodninger og svar) krypteres ved hjælp af en avanceret mekanisme efter åbne standarder, såsom S/MIME, inden de sendes til de andre staters operationssteder.

5.3.3. Transmissionsniveauet

Alle krypterede meddelelser, der indeholder DNA-profiloplysninger, sendes til andre staters operationssteder via et virtuelt, privat tunnelsystem, der administreres af en betroet netværksudbyder i international kontekst og via de sikre forbindelser til dette tunnelsystem, der er underlagt statens nationale ansvar. Dette virtuelle private tunnelsystem har ingen kontaktflader med det åbne internet.

5.4. Protokoller og standarder, der skal benyttes til krypteringsmekanismen: S/MIME og dertil hørende pakker

De facto e-mailstandarden SMTP vil blive suppleret med open standard-programmet S/MIME med henblik på krypteringen af meddelelser, der indeholder DNA-profiloplysninger. S/MIME-protokollen (V3) muliggør signerede kvitteringer, sikkerhedsmærkninger og sikre mailinglister og er baseret på Cryptographic Message Syntax (CMS), en Internet Engineering Task Force-specifikation (IETF) for kryptografisk beskyttede meddelelser. Den kan benyttes til digital underskrift, digitalt fingeraftryk, autentificering eller kryptering af enhver form for digitale data.

Det underliggende certifikat, som S/MIME benytter, skal være i overensstemmelse med X.509-standarden. Med henblik på at sikre, at de samme standarder og procedurer også gælder for andre Prümprogrammer, er behandlingsreglerne for S/MIME-krypteringsoperationer eller behandlingsreglerne i forbindelse med diverse Commercial Product of the Shelves-miljøer (COTS) som følger:

— Operationernes rækkefølge er: først kryptering og derefter signatur.

— Krypteringsalgoritmen AES (Advanced Encryption Standard) med en nøglestørrelse på 256 bit og RSA med en nøglestørrelse på 1024 bit skal benyttes ved henholdsvis symmetrisk og asymmetrisk kryptering.

— Hash-algoritmen SHA-1 skal benyttes.

S/MIME-funktionaliteten er indbygget i de langt de fleste moderne e-mailprogrammer, herunder Outlook, Mozilla Mail og Netscape Communicator 4.x, og den kan kombineres med alle de mest fremtrædende e-mailsoftwarepakker.

Fordi S/MIME er så let at integrere i de nationale IT-infrastrukturer på alle staternes operationssteder, er den valgt som en brugbar mekanisme til at implementere kommunikationssikkerhedsniveauet. For at opnå målsætningen "Proof of Concept" på en mere effektiv måde og reducere omkostningerne er open standard-programmet JavaMail API imidlertid valgt til prototypen for udveksling af DNA-oplysninger. JavaMail API foretager en simpel kryptering og afkryptering af e-mails ved hjælp af S/MIME og/eller OpenPGP. Hensigten er at stille en enkel, brugervenlig API til rådighed for e-mailbrugere, der ønsker at sende og modtage krypteret e-mail i et af de to mest populære e-mailkrypteringsformater. Derfor vil en hvilken som helst avanceret implementering til JavaMail API være tilstrækkelig til at opfylde kravene i tredje del, afsnit II, i denne aftale, f.eks. Bouncy Castle JCE's produkt Java Cryptographic Extension, som vil blive benyttet til at indføre S/MIME i prototypen for udveksling af DNA-oplysninger mellem alle staterne.

5.5. Programarkitektur

Hver af staterne sender de øvrige stater et sæt standardiserede DNA-profiloplysninger, der er i overensstemmelse med det nuværende fælles ICD. Det kan enten ske ved at give en logisk oversigt over den enkelte nationale database eller ved at oprette en fysisk eksporteret database (indekserede databaser).

De fire hovedkomponenter: E-mailserver/S/MIME, programserver, datastrukturområde til hentning/fødning af data og registrering af indkommende og udgående meddelelser og overensstemmelsesmekanismen udmønter hele programmets logik i praksis på en produktuafhængig måde.

For at gøre det lettere for alle staterne at integrere komponenterne på deres respektive nationale operationssteder er den specificerede fælles mekanisme blevet indført ved hjælp af open source-komponenter, som de enkelte stater kan vælge afhængigt af deres nationale IT-politik og IT-forskrifter. Som følge af de uafhængige faciliteter, der skal indføres for at få adgang til de indekserede databaser, som indeholder de DNA-profiler, der er omfattet af tredje del, afsnit II, i denne aftale, kan hver stat frit vælge sin hardware- og sin softwareplatform, herunder databasesystem og styresystem.

En prototype for udveksling af DNA-oplysninger er blevet udviklet og testet med gode resultater via det eksisterende fælles netværk. Version 1.0 er blevet installeret i det aktive miljø og benyttes til de daglige operationer. Staterne kan anvende det produkt, der er udarbejdet i fællesskab, men også udvikle deres egne produkter. De fælles produktelementer vil blive vedligeholdt, tilpasset og videreudviklet i takt med IT-udviklingen og udviklingen inden for retsmedicin og/eller politiets funktionelle behov.

5.6. Protokoller og standarder, der skal benyttes i programarkitekturen

5.6.1. XML

Udvekslingen af DNA-oplysninger vil fuldt ud udnytte XML-schema som attachment til SMTP-e-mailmeddelelser. eXtensible Markup Language (XML) er et W3C-anbefalet multifunktionelt opmærkningssprog til udformning af formålsspecifikke opmærkningssprog, som kan beskrive mange forskellige former for data. En DNA-profilbeskrivelse, der egner sig til udveksling mellem alle staterne, er blevet udarbejdet ved hjælp af XML og XML-schema i ICD-dokumentet.

5.6.2. ODBC

Open DataBase Connectivity giver en standardsoftware API-metode til søgning i databaseforvaltningssystemer og til at gøre søgningen uafhængig af programmeringssprog og af database- og styresystemer. ODBC har imidlertid visse ulemper. Hvis man administrerer et stort antal klientmaskiner, kan der forekomme mange forskellige drivere og DLL-filer. Denne komplekse struktur kan blive en belastning for systemadministrationskapaciteten.

5.6.3. JDBC

Java DataBase Connectivity (JDBC) er et API til Java-programmeringssproget, der definerer, hvordan en klient får adgang til en database. I modsætning til ODBC forudsætter JDBC ikke, at der bruges et bestemt sæt lokale DLL'er på arbejdsstationen.

Arbejdsgangen for behandling af anmodninger og svar vedrørende DNA-profiler på de enkelte staters operationssteder beskrives i nedenstående diagram. Såvel anmodnings- som svarstrømme passerer via et neutralt dataområde, der omfatter forskellige datalagre med en fælles datastruktur.

5.7. Kommunikationsmiljøet

5.7.1. Det fælles kommunikationsnet: TESTA og dets opfølgningsinfrastruktur

Programmet for udveksling af DNA-oplysninger benytter e-mail, en asynkron mekanisme, til at sende anmodninger og modtage svar staterne imellem. Da alle staterne har mindst ét nationalt tilkoblingspunkt til TESTA-nettet, vil udvekslingen af DNA-oplysninger komme til at foregå via TESTA-nettet. TESTA indeholder en række tillægstjenester via sin e-mailrelayserver. Foruden at være vært for de specifikke TESTA-e-mailbrevkasser gør infrastrukturen det muligt at anvende maildistributionslister og routingpolitikker. Dermed kan TESTA benyttes som clearingorgan for meddelelser, der er stilet til administrationer, som er tilkoblet domænerne for hele EU. Der kan også installeres antivirusmekanismer.

TESTA-e-mailrelaysystemet er baseret på en "high availability hardware"-platform, der befinder sig på det centrale TESTA-programcenter, og som er beskyttet af en firewall. TESTA's Domain Name Systems (DNS) står for tildeling af URL til IP-adresser og skjuler adresseringsoplysninger for brugeren og for programmerne.

5.7.2. Sikkerhedsspørgsmål

Begrebet virtuelt privat netværk (VPN) er indarbejdet i TESTA. Den Tag Switching Technology, der er benyttet til at opbygge dette VPN, vil blive udviklet til at understøtte en Multi-Protocol Label Switching (MPLS) standard, som er udviklet af IETF.

MPLS er en IETF-standardteknologi, der accelererer nettrafikken ved at undgå, at pakkerne analyseres af de mellemliggende routere (hop). Dette sker på grundlag af de såkaldte "labels", som edge-routerne i udkanten af backbonestrukturen knytter til pakken på grundlag af oplysninger, der er lagret i en speciel labeltabel kaldet forwarding information base (FIB). Labels benyttes ligeledes ved oprettelsen af VPN'er.

MPLS kombinerer fordelene ved lag 3-routing med fordelene ved lag 2-switching. Eftersom IP-adresserne ikke tjekkes under transmissionen gennem nettets backbone, sætter MPLS ikke nogen begrænsninger med hensyn til IP-adresserne.

Hertil kommer, at e-mailmeddelelser, der sendes via TESTA, vil være beskyttet af S/MIME's krypteringsmekanisme. Ingen kan uden at kende nøglen og uden at være i besiddelse af det rigtige certifikat dekryptere meddelelser, der sendes via nettet.

5.7.3. Protokoller og standarder, der skal benyttes på kommunikationsnettet

5.7.3.1. SMTP SMTP er i praksis den gældende standard for e-mailforsendelse på internettet. SMTP er en forholdsvis enkel tekstbaseret protokol, hvor man angiver en eller flere modtagere af en meddelelse og derefter sender den. SMTP benytter TCP port 25 som specificeret af IETF. Til bestemmelse af SMTP-serveren for et givet domænenavn, benyttes "MX (Mail eXchange) DNS (Domain Name Systems)"-registret. Da denne protokol oprindelig udelukkende var baseret på ASCII-tekst, havde den problemer med at klare binære data. Der blev indført standarder som MIME til indkodning af binære data, som skulle transporteres via SMTP. I dag understøtter de fleste SMTP-servere 8BITMIME and S/MIME, der gør det næsten lige så let at sende binære data som almindelig tekst. Reglerne for behandling af S/MIME-operationer er beskrevet i afsnittet om S/MIME (jf. afdeling 5.4). SMTP er en "push"-protokol, der ikke gør det muligt selv at hente ("pull") meddelelser fra en fjernserver. For at kunne gøre dette skal mailklienten benytte POP3 eller IMAP. Med henblik på udveksling af DNA-oplysninger er det blevet besluttet at benytte POP3-protokollen.

5.7.3.2. POP Lokale e-mailklienter benytter Post Office Protocol version 3 (POP3), som er en standardprogramlagsprotokol til brug på internettet, til at hente e-mail fra en fjernserver via en TCP/IP-forbindelse. Ved at benytte SMTP-protokollens Submit-profil kan e-mailklienter sende meddelelser via internettet eller via en virksomheds netværk. MIME fungerer som standard for vedhæftede filer og ikke-ASCII-tekst i e-mails. Selv om hverken POP3 eller SMTP kræver MIME-formaterede e-mails, kommer de fleste e-mails på internettet i MIME-format, så POP-klienter er også nødt til at kunne forstå og benytte MIME. Hele kommunikationsmiljøet i tredje del, afsnit II, i denne aftale vil derfor indeholde POP-komponenterne.

5.7.4. Tildeling af netværksadresser

Det operative miljø

En særskilt klasse halv B subnetblok er indtil videre blevet tildelt til TESTA af den Europæiske IP-registreringsmyndighed (RIPE). IP-adresser tildeles til staterne på grundlag af en geografisk opdeling af Europa. Staternes indbyrdes udveksling af oplysninger inden for rammerne af tredje del, afsnit II, i denne aftale sker via et logisk lukket IP-netværk, der dækker hele Europa.

Testmiljø

Med henblik på at skabe et velfungerende miljø for den daglige drift mellem alle de tilkoblede stater er det nødvendigt at indrette et testmiljø via det lukkede netværk for nye stater, der forbereder sig til at komme med i systemet. Der er fastsat et sæt parametre, inkl. IP-adresser, netværksindstillinger, e-maildomæner samt programbrugerkonti, som skal installeres på den pågældende stats operationssted. Der er desuden oprettet et sæt pseudo-DNA-profiler til testformål.

5.7.5. Konfigurationsparametre

Der er etableret et sikret e-mailsystem på eu-admin.net-domænet. Dette domæne og de dertil hørende adresser vil ikke være tilgængelige fra steder, der ikke ligger på TESTA's EU-dækkende domæne, eftersom navnene kun er kendt på TESTA's centrale DNS-server, der er afskærmet fra internettet.

Mappingen af disse TESTA-site-adresser (host names) til deres IP-adresser foretages af TESTA's DNS-tjeneste. For hvert lokalt domæne vil der blive tilføjet en mailregistrering i TESTA's centrale DNS-server, som videresender alle e-mailmeddelelser, der sendes til TESTA's lokale domæner, til TESTA's centrale mailrelayserver. Herfra sendes de så videre til det specifikke lokale domænes e-mailserver under anvendelse af e-mailadresser på det lokale domæne. Ved at videresende e-mail på denne måde transporteres de eventuelle kritiske oplysninger i e-mailene kun på den EU-dækkende lukkede netværksinfrastruktur og ikke på det usikre internet.

Der skal oprettes underdomæner (fede typer og kursiv) på alle staternes operationssteder med følgende syntaks:

"application-type.State-code.pruem.testa.eu", hvor: "State-code" antager værdien af en af landekoderne med to bogstaver (dvs. AT, BE osv.);

"application-type" antager en af følgende værdier: DNA, FP og CAR.

Efter ovennævnte syntaks kommer staternes underdomæner til at se ud som angivet i følgende skema:

Syntaks for staters underdomæner Stat Underdomæner Bemærkninger BE dna.be.pruem.testa.eu fp.be.pruem.testa.eu car.be.pruem.testa.eu test.dna.be.pruem.testa.eu test.fp.be.pruem.testa.eu test.car.be.pruem.testa.eu BG dna.bg.pruem.testa.eu fp.bg.pruem.testa.eu car.bg.pruem.testa.eu test.dna.bg.pruem.testa.eu test.fp.bg.pruem.testa.eu test.car.bg.pruem.testa.eu CZ dna.cz.pruem.testa.eu fp.cz.pruem.testa.eu car.cz.pruem.testa.eu test.dna.cz.pruem.testa.eu test.fp.cz.pruem.testa.eu test.car.cz.pruem.testa.eu DK dna.dk.pruem.testa.eu fp.dk.pruem.testa.eu car.dk.pruem.testa.eu test.dna.dk.pruem.testa.eu test.fp.dk.pruem.testa.eu test.car.dk.pruem.testa.eu DE dna.de.pruem.testa.eu fp.de.pruem.testa.eu car.de.pruem.testa.eu test.dna.de.pruem.testa.eu test.fp.de.pruem.testa.eu test.car.de.pruem.testa.eu EE dna.ee.pruem.testa.eu fp.ee.pruem.testa.eu car.ee.pruem.testa.eu test.dna.ee.pruem.testa.eu test.fp.ee.pruem.testa.eu test.car.ee.pruem.testa.eu IE dna.ie.pruem.testa.eu fp.ie.pruem.testa.eu car.ie.pruem.testa.eu test.dna.ie.pruem.testa.eu test.fp.ie.pruem.testa.eu test.car.ie.pruem.testa.eu EL dna.el.pruem.testa.eu fp.el.pruem.testa.eu car.el.pruem.testa.eu test.dna.el.pruem.testa.eu test.fp.el.pruem.testa.eu test.car.el.pruem.testa.eu ES dna.es.pruem.testa.eu fp.es.pruem.testa.eu car.es.pruem.testa.eu test.dna.es.pruem.testa.eu test.fp.es.pruem.testa.eu test.car.es.pruem.testa.eu FR dna.fr.pruem.testa.eu fp.fr.pruem.testa.eu car.fr.pruem.testa.eu test.dna.fr.pruem.testa.eu test.fp.fr.pruem.testa.eu test.car.fr.pruem.testa.eu HR dna.hr.pruem.testa.eu fp.hr.pruem.testa.eu car.hr.pruem.testa.eu test.dna.hr.pruem.testa.eu test.fp.hr.pruem.testa.eu test.car.hr.pruem.testa.eu IT dna.it.pruem.testa.eu fp.it.pruem.testa.eu car.it.pruem.testa.eu test.dna.it.pruem.testa.eu test.fp.it.pruem.testa.eu test.car.it.pruem.testa.eu CY dna.cy.pruem.testa.eu fp.cy.pruem.testa.eu car.cy.pruem.testa.eu test.dna.cy.pruem.testa.eu test.fp.cy.pruem.testa.eu test.car.cy.pruem.testa.eu LV dna.lv.pruem.testa.eu fp.lv.pruem.testa.eu car.lv.pruem.testa.eu test.dna.lv.pruem.testa.eu test.fp.lv.pruem.testa.eu test.car.lv.pruem.testa.eu LT dna.lt.pruem.testa.eu fp.lt.pruem.testa.eu car.lt.pruem.testa.eu test.dna.lt.pruem.testa.eu test.fp.lt.pruem.testa.eu test.car.lt.pruem.testa.eu LU dna.lu.pruem.testa.eu fp.lu.pruem.testa.eu car.lu.pruem.testa.eu test.dna.lu.pruem.testa.eu test.fp.lu.pruem.testa.eu test.car.lu.pruem.testa.eu HU dna.hu.pruem.testa.eu fp.hu.pruem.testa.eu car.hu.pruem.testa.eu test.dna.hu.pruem.testa.eu test.fp.hu.pruem.testa.eu test.car.hu.pruem.testa.eu MT dna.mt.pruem.testa.eu fp.mt.pruem.testa.eu car.mt.pruem.testa.eu test.dna.mt.pruem.testa.eu test.fp.mt.pruem.testa.eu test.car.mt.pruem.testa.eu NL dna.nl.pruem.nl.testa.eu fp.nl.pruem.testa.eu car.nl.pruem.testa.eu test.dna.nl.pruem.testa.eu test.fp.nl.pruem.testa.eu test.car.nl.pruem.testa.eu AT dna.at.pruem.testa.eu fp.at.pruem.testa.eu car.at.pruem.testa.eu test.dna.at.pruem.testa.eu test.fp.at.pruem.testa.eu test.car.at.pruem.testa.eu PL dna.pl.pruem.testa.eu fp.pl.pruem.testa.eu car.pl.pruem.testa.eu test.dna.pl.pruem.testa.eu test.fp.pl.pruem.testa.eu test.car.pl.pruem.testa.eu PT dna.pt.pruem.testa.eu fp.pt.pruem.testa.eu car.pt.pruem.testa.eu test.dna.pt.pruem.testa.eu test.fp.pt.pruem.testa.eu test.car.pt.pruem.testa.eu RO dna.ro.pruem.testa.eu fp.ro.pruem.testa.eu car.ro.pruem.testa.eu test.dna.ro.pruem.testa.eu test.fp.ro.pruem.testa.eu test.car.ro.pruem.testa.eu SI dna.si.pruem.testa.eu fp.si.pruem.testa.eu car.si.pruem.testa.eu test.dna.si.pruem.testa.eu test.fp.si.pruem.testa.eu test.car.si.pruem.testa.eu SK dna.sk.pruem.testa.eu fp.sk.pruem.testa.eu car.sk.pruem.testa.eu test.dna.sk.pruem.testa.eu test.fp.sk.pruem.testa.eu test.car.sk.pruem.testa.eu FI dna.fi.pruem.testa.eu fp.fi.pruem.testa.eu car.fi.pruem.testa.eu test.dna.fi.pruem.testa.eu test.fp.fi.pruem.testa.eu test.car.fi.pruem.testa.eu SE dna.se.pruem.testa.eu fp.se.pruem.testa.eu car.se.pruem.testa.eu test.dna.se.pruem.testa.eu test.fp.se.pruem.testa.eu test.car.se.pruem.testa.eu UK dna.uk.pruem.testa.eu fp.uk.pruem.testa.eu car.uk.pruem.testa.eu test.dna.uk.pruem.testa.eu test.fp.uk.pruem.testa.eu test.car.uk.pruem.testa.eu

KAPITEL 2

UDVEKSLING AF FINGERAFTRYKSOPLYSNINGER (GRÆNSEFLADEKONTROLDOKUMENT)

Formålet med dette "grænsefladekontroldokument" er at fastsætte, hvilke krav der skal være opfyldt i forbindelse med udveksling af fingeraftryksoplysninger mellem staternes automatiske fingeraftryksidentifikationssystemer (AFIS). Det er baseret på INTERPOL's implementering af ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b).

Denne version skal dække alle de grundlæggende definitioner for logiske records af type-1, type-2, type-4, type-9, type-13 og type-15, som er nødvendige for behandling af fingeraftryk på grundlag af billeder eller minutiæ.

1. Oversigt over filens indhold

En fingeraftryksfil består af flere logiske records. I den oprindelige ANSI/NIST-ITL 1-2000 standard var der defineret seksten recordtyper. Der indsættes passende ASCII-adskillelsestegn mellem de enkelte records og felterne og subfelterne inde i de enkelte records.

Til udvekslingen af oplysninger mellem oprindelsesagenturet og modtageragenturet benyttes kun 6 recordtyper:

Type-1 → Transaction information (Transaktionsoplysninger) Type-2 → Alphanumeric persons/case data (Alfanumeriske data om personer eller sager) Type-4 → High resolution grayscale dactyloscopic images (Gråtonebilleder med høj opløsning af fingeraftryk) Type-9 → Minutiæ Record (Minutiae) Type-13 → Variable resolution latent image record (Latent billede med variabel opløsning) Type-15 → Variable resolution palmprint image record (Håndfladeaftryksbillede med variabel opløsning)

1.1. Type-1 — File header

Denne record indeholder routingoplysninger og oplysninger, der beskriver resten af filens struktur. Denne recordtype definerer også de typer af transaktioner, der henhører under følgende brede kategorier:

1.2. Type-2 — Descriptive text

Denne record indeholder tekstoplysninger af interesse for de afsendende og modtagende agenturer.

1.3. Type-4 — High resolution gray-scale image

Denne record benyttes til udveksling af gråtonebilleder (otte bit) af fingeraftryk med høj opløsning (500 DPI). Fingeraftryksbillederne komprimeres efter WSQ-algoritmen i et forhold på højst 15:1. Andre komprimeringsalgoritmer eller ukomprimerede billeder må ikke benyttes.

1.4. Type-9 — Minutiæ record

Type-9-records benyttes til udveksling af linjekarakteristika eller minutiæ-data. Formålet er dels at undgå unødig dobbelt udførelse af AFIS-indkodningen og dels at gøre det muligt at sende AFIS-koderne, der indeholder færre data end de tilsvarende billeder.

1.5. Type-13 — Variable-Resolution Latent Image Record

Denne record benyttes til udveksling af latente fingeraftryksbilleder og latente håndfladeaftryksbilleder med variabel opløsning ledsaget af alfanumeriske teksturoplysninger. Billederne skannes med en opløsning på 500 DPI og med 256 gråtoner. Hvis det latente billedes kvalitet er tilstrækkelig god, komprimeres det efter WSQ-algoritmen. Om nødvendigt kan billedopløsningen øges til mere end 500 DPI og mere end 256 gråtoner efter fælles aftale. I så tilfælde anbefales det kraftigt at benytte JPEG 2000 (jf. tillæg 39-7).

1.6. Variable-Resolution Palmprint Image Record

Type-15-billedrecords med mærkede felter benyttes til udveksling af håndfladeaftryksbilleder med variabel opløsning sammen med alfanumeriske teksturoplysninger. Billederne skannes med en opløsning på 500 DPI og med 256 gråtoner. For at begrænse datamængden bør alle håndfladeaftryksbilleder komprimeres efter WSQ-algoritmen. Om nødvendigt kan billedopløsningen øges til mere end 500 DPI og mere end 256 gråtoner efter fælles aftale. I så tilfælde anbefales det kraftigt at benytte JPEG 2000 (jf. tillæg 39-7).

2. Record-formatet

En transaktionsfil består af en eller flere logiske records. For hver logisk record, som filen indeholder, skal der være en række informationsfelter, der passer til den pågældende recordtype. Hvert af informationsfelterne kan indeholde et eller flere grundlæggende informationselementer, der hver især består af en enkelt værdi. Tilsammen benyttes disse elementer til at angive forskellige aspekter af oplysningerne i feltet. Et informationsfelt kan også bestå af et eller flere informationselementer, der grupperes og gentages flere gange i et felt. En sådan gruppe af informationselementer kaldes et subfelt. Et informationsfelt kan således bestå af et eller flere subfelter med informationselementer.

2.1. Information separators

I de logiske records med mærkede felter er der indsat mekanismer til adskillelse af oplysningerne, som benytter fire ASCII-informationsseparatorer. De adskilte oplysninger kan være elementer i et felt eller subfelt, felter inden for en logisk record eller subfelter, der forekommer flere gange. De benyttede informationsseparatorer er defineret i standarden ANSI X3.4. Disse tegn benyttes til at adskille og karakterisere information på en logisk måde. Set ud fra en hierarkisk synsvinkel er filseparatortegnet "FS" det mest inklusive og derefter følger gruppeseparatortegnet "GS", recordseparatortegnet "RS" og endelig enhedsseparatortegnet "US". Tabel 1 viser disse ASCII-separatorer og giver en beskrivelse af deres brug i forbindelse med denne standard.

Informationsseparatorer bør funktionelt set betragtes som en angivelse af, hvilken type data der følger efter. "US"-tegnet adskiller individuelle informationselementer inde i et felt eller subfelt. Dette signalerer, at det efterfølgende informationselement vedrører det pågældende felt eller subfelt. En række subfelter i et felt, som er adskilt af "RS"-tegnet, angiver begyndelsen af den næste gruppe af gentagne informationselementer. "GS"-separatortegnet, der benyttes mellem informationsfelter, angiver begyndelsen af et nyt felt, som efterfølges af det angivne feltidentificeringsnummer. På tilsvarende vis markeres begyndelsen af en ny logisk record med angivelse af tegnet "FS".

De fire tegn giver kun mening, når de benyttes som separatorer mellem dataelementer i felter i ASCII-tekstrecords. Tegnene har ingen specifik betydning, når de forekommer i binære billedrecords og binære felter — de indgår blot som en del af de udvekslede oplysninger.

Normalt bør der ikke være nogen tomme felter eller informationselementer, så der bør derfor kun være ét separatortegn mellem to givne dataelementer. Undtagelsen fra denne regel indtræder, når data i felterne eller informationselementer i en transaktion ikke er tilgængelige, ikke findes eller er fakultative, og behandlingen af transaktionen ikke er afhængig af, at de pågældende data er til stede. I sådanne tilfælde skal man angive flere separatortegn i træk snarere end at indsætte fylddata mellem separatortegnene.

Med henblik på definitionen af et felt, der består af tre informationselementer, gælder følgende. Hvis oplysningerne i andet informationselement mangler, anføres to "US"-informationsseparatortegn ved siden af hinanden mellem første og tredje informationselement. Hvis både andet og tredje informationselement mangler, anføres tre separatortegn — to "US"-tegn samt det afsluttende separatortegn for feltet eller subfeltet. Som hovedregel bør det korrekte antal separatortegn indsættes, hvis et eller flere obligatoriske eller fakultative informationselementer ikke er tilgængelige for et felt eller subfelt.

Det er muligt at have kombinationer af to eller flere af de fire separatortegn lige efter hinanden. Hvis dataene ikke foreligger eller ikke er tilgængelige til informationselementer, subfelter eller felter, skal der være et separatortegn mindre end det fornødne antal informationselementer, subfelter eller felter.

Tabel 1

Benyttede separatorer

Code Type Description Hexadecimal Value Decimal Value US Unit Separator Separates information items 1F 31 RS Record Separator Separates subfields 1E 30 GS Group Separator Separates fields 1D 29 FS File Separator Separates logical records 1C 28

2.2. Record layout

I logiske records med mærkede felter, skal hvert af de benyttede informationsfelter nummereres i overensstemmelse med denne standard. Formatet for hvert felt skal bestå af den logiske records typenummer efterfulgt af et punktum ".", et feltnummer efterfulgt af et kolon ":" efterfulgt af de oplysninger, der skal stå i feltet. Det mærkede felts nummer er et etcifret tal fra 1 til 9, som anføres mellem punktummet "." og kolonet ":". Det skal fortolkes som et nummer i et usigneret talfelt. Det vil sige, at feltnummeret "2.123:" svarer til og skal fortolkes på samme måde som feltnummeret "2.000000123:".

I eksemplerne i resten af dette dokument benyttes et trecifret tal til angivelse af felterne i hver af de logiske records med mærkede felter, der beskrives heri. Feltnumrene udformes således: "TT.xxx:", hvor "TT" repræsenterer recordtypen med et eller to tegn efterfulgt af et punktum. De næste tre tegn angiver det pågældende feltnummer efterfulgt af et kolon. Efter kolonet følger der beskrivende ASCII-oplysninger eller billeddata.

Logiske type-1- og type-2-records indeholder kun ASCII-tekstdatafelter. Recordens samlede længde (inkl. feltnumre, koloner og separatortegn) skal angives som det første ASCII-felt i hver af disse recordtyper. ASCII-filseparatorkontroltegnet "FS" (der angiver afslutningen af den logiske record eller transaktion) skal følge umiddelbart efter sidste byte i ASCII-oplysningerne og skal medregnes i recordens længde.

Modsat hvad der gælder for mærkede felter, indeholder en type-4-record kun binære data, der er registreret som ordnede binære felter med fast længde. Recordens samlede længde skal angives i det første binære firebytefelt i hver record. For denne binære record skal hverken recordnummeret med dets punktum eller det første feltidentificeringsnummer og dets følgende kolon angives. Hertil kommer, at da alle felterne i denne record enten har fast eller specificeret længde, skal ingen af de fire separatortegn ("US", "RS", "GS" eller "FS") fortolkes som andet end binære data. I den binære record skal tegnet "FS" ikke benyttes som recordseparator eller som transaktionsafslutningstegn.

3. Logisk record af type 1: filens header

Denne record beskriver filens struktur og type og andre vigtige oplysninger. Det tegnsæt, der anvendes i type 1-felter, må kun indeholde 7-bit-ANSI-koden for udveksling af oplysninger.

3.1. Felter i logiske records af Type-1

3.1.1. Field 1.001: Logical Record Length (LEN)

Dette felt angiver det samlede antal bytes i hele den logiske record af type-1. Feltet begynder med "1.001:" efterfulgt af recordens samlede længde, hvori medtages samtlige tegn i hvert eneste felt og informationsseparatorerne.

3.1.2. Field 1.002: Version Number (VER)

For at sikre, at brugerne er opmærksomme på, hvilken version af ANSI/NIST-standarden der benyttes, angiver dette fire-byte-felt nummeret på den version af standarden, der benyttes af softwaren eller af det system, der har genereret filen. De første to bytes specificerer hovedversionens referencenummer og de næste to nummeret på det sekundære revisionsnummer. Eksempelvis anses den oprindelige 1986-standard for at være den første version, der angives som "0100", mens den nuværende ANSI/NIST-ITL 1-2000-standard angives som "0300".

3.1.3. Field 1.003: File Content (CNT)

Dette felt angiver hver eneste record i filen efter recordtype og den rækkefølge, som disse records optræder i den logiske fil. Det består af et eller flere subfelter, der hvert især indeholder to informationselementer, der beskriver en enkelt logisk record, der forekommer i den pågældende fil. Subfelterne angives i den rækkefølge, som de pågældende records er registreret og sendt i.

Det første informationselement i det første subfelt er "1", som henviser til denne type-1-record. Det efterfølges af et andet informationselement, der angiver, hvor mange andre records filen indeholder. Dette nummer er også lig med antallet af resterende subfelter under felt 1.003.

Hvert af de øvrige subfelter associeres med en record i filen, og subfeltsekvensen svarer til recordsekvensen. Hvert subfelt indeholder to informationselementer. Det første identificerer recordtypen. Det andet er recordens IDC. "US"-tegnet benyttes til at adskille de to informationselementer.

3.1.4. Field 1.004: Type of Transaction (TOT)

Dette felt indeholder et mnemoteknisk hjælpemiddel på tre bogstaver, som angiver transaktionstypen. Disse koder kan være forskellige fra dem, der benyttes af andre implementeringer af ANSI/NIST-standarden.

CPS: Criminal Print-to-Print Search. Denne transaktion er en anmodning om en søgning i en aftryksdatabase på en record vedrørende en lovovertrædelse. Personens aftryk medsendes som WSQ-komprimerede billeder i filen.

I tilfælde af No-HIT (ingen overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record

I tilfælde af HIT (overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record

— 1-14 type-4-record

CPS TOT er sammenfattet i tabel A.6.1 (tillæg 39-6).

PMS: Print-to-Latent Search. Denne transaktion benyttes, når der søges efter overensstemmelse med et sæt aftryk i en database over uidentificerede latente aftryk. Svaret vil indeholde HIT/No-HIT-afgørelsen af destinationens søgning i fingeraftryksidentifikationssystemet. Hvis der forekommer flere uidentificerede latente aftryk, vil der blive tilbagesendt flere SRE-transaktioner med et latent aftryk pr. transaktion. Personens aftryk medsendes som WSQ-komprimerede billeder i filen.

I tilfælde af No-HIT (ingen overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record

I tilfælde af HIT (overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record

— 1 type-13-record.

PMS TOT er sammenfattet i tabel A.6.1 (tillæg 39-6).

MPS: Latent-to-Print Search. Denne transaktion benyttes, når der skal søges efter overensstemmelse med et latent aftryk i en fingeraftryksdatabase. Minutiæ om det latente aftryk og billedet (WSQ-komprimeret) medsendes i filen.

I tilfælde af No-HIT (ingen overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record.

I tilfælde af HIT (overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record

— 1 type-4- eller type-15-record.

MPS TOT er sammenfattet i tabel A.6.4 (tillæg 39-6).

MMS: Latent-to-Latent Search. I denne transaktion indeholder filen et latent aftryk, som der skal søges på i en database over uidentificerede latente aftryk for at etablere forbindelser mellem forskellige gerningssteder. Minutiæ om det latente aftryk og billedet (WSQ-komprimeret) skal medsendes i filen.

I tilfælde af No-HIT (ingen overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record.

I tilfælde af HIT (overensstemmelse) vil følgende logiske records blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record

— 1 type-13-record.

MMS TOT er sammenfattet i tabel A.6.4 (tillæg 39-6).

SRE: Denne transaktion sendes tilbage af det anmodede agentur som svar på fingeraftryksforespørgsler. Svaret vil indeholde HIT/No-HIT-afgørelsen af destinationens søgning i fingeraftryksidentifikationssystemet. Hvis der forekommer flere kandidater, vil der blive tilbagesendt flere SRE-transaktioner med én kandidat pr. transaktion.

SRE TOT er sammenfattet i tabel A.6.2 (tillæg 39-6).

ERR: Denne transaktion sendes tilbage af det anmodede fingeraftryksidentifikationssystem for at angive en fejl i forbindelse med transaktionen. Den indeholder et meddelelsesfelt (ERM), der angiver, hvilken fejl der er konstateret. Følgende logiske records vil blive sendt tilbage:

— 1 type-1-record

— 1 type-2-record.

ERR TOT er sammenfattet i tabel A.6.3 (tillæg 39-6).

Tabel 2

Tilladte koder i transaktionerne

Transaction Type Logical Record Type 1 2 4 9 13 15 CPS M M M — — — SRE M M C — (C in case of latent HITs) C C MPS M M — M (1*) M — MMS M M — M (1*) M — PMS M M M* — — M* ERR M M — — — —

Key:

M = Mandatory (obligatorisk) M* = Kun én af de to recordtyper kan medtages O = Optional (fakultativ) C = Conditional (afhængigt af, om oplysningerne er tilgængelige) — = Ikke tilladt 1* = Afhængigt af legacysystemerne

3.1.5. Field 1.005: Date of Transaction (DAT)

Dette felt angiver den dato, hvor transaktionen blev indledt, og følger ISO-standardformatet: YYYYMMDD

hvor YYYY er året, MM er måneden, og DD er dagen. Der sættes et nul foran étcifrede tal. For eksempel svarer "19931004" til den 4. oktober 1993.

3.1.6. Field 1.006: Priority (PRY)

Dette fakultative felt definerer den prioritet, på en skala fra 1 til 9, som tillægges søgningen. "1" er højeste prioritet og "9" laveste prioritet. Transaktioner med prioritet "1" skal behandles omgående.

3.1.7. Field 1.007: Destination Agency Identifier (DAI)

Dette felt angiver det agentur, som transaktionen er rettet til.

Det består af to informationselementer i følgende format: CC/agency.

Det første informationselement indeholder landekoden (Country Code), som er defineret i ISO 3166, og som består af to alfanumeriske tegn. Det andet element, agenturet (agency), er en fritekstidentificering af agenturet på højst 32 alfanumeriske tegn.

3.1.8. Field 1.008: Originating Agency Identifier (ORI)

Dette felt angiver det agentur, der har afsendt filen, og det er i samme format som DAI (Felt 1.007).

3.1.9. Field 1.009: Transaction Control Number (TCN)

Dette er et kontrolnummer til henvisningsbrug. Det genereres af computeren og har følgende format: YYSSSSSSSSA,

hvor YY er transaktionsåret, SSSSSSSS er et ottecifret serienummer, og A er et kontrolbogstav, der genereres efter proceduren i tillæg 39-2.

Når TCN ikke er til rådighed, udfyldes feltet YYSSSSSSSS med nuller, og kontrolbogstavet genereres som angivet ovenfor.

3.1.10. Field 1.010: Transaction Control Response (TCR)

Når en søgning er sendt af sted, og dette svar kommer tilbage, vil dette fakultative felt indeholde søgningsmeddelelsens transaktionskontrolnummer. Det har derfor samme format som TCN (felt 1.009).

3.1.11. Field 1.011: Native Scanning Resolution (NSR)

Dette felt angiver den normale scanningsopløsning i det system, som transaktionsafsenderen understøtter. Opløsningen angives som et tocifret tal, efterfulgt af et decimalkomma og derefter endnu to cifre.

For alle transaktioner i henhold til artikel 533 og 534 i denne aftale skal opløsningen være 500 DPI (= pixel/tomme) eller 19,68 pixel/mm.

3.1.12. Field 1.012: Nominal Transmitting Resolution (NTR)

Dette felt på fem byte angiver den nominelle overførselsopløsning for de billeder, der overføres. Opløsningen angives i pixel/mm i samme format som NSR (Felt 1.011).

3.1.13. Field 1.013: Domain name (DOM)

Dette obligatoriske felt angiver domænenavnet for implementeringen af den brugerdefinerede logiske type-2-record. Det består af to informationselementer og skrives således: "INT-I{}{US}}4.22{}{GS}}".

3.1.14. Field 1.014: Greenwich mean time (GMT)

Dette obligatoriske felt tilvejebringer en mekanisme til at udtrykke dato og klokkeslæt udtrykt i universelle Greenwich Mean Time-enheder (GMT-enheder). Når det benyttes, indeholder GMT-feltet den universelle dato, som supplerer den lokale dato i felt 1.005 (DAT). Brugen af GMT-feltet fjerner det problem med lokal tid, der opstår, når en transaktion og svaret herpå sendes mellem to steder, der er adskilt af flere tidszoner. GMT angiver den universelle dato og klokkeslæt døgnet rundt uafhængig af tidszoner. Den angives som "CCYYMMDDHHMMSSZ", en sekvens på 15 tegn, der kæder datoen sammen med GMT og slutter med "Z". Tegnene "CCYY" angiver transaktionsåret, "MM" angiver måneden med to cifre, og "DD" angiver dagen med to cifre, "HH" står for timetallet, "MM" for minuttallet og "SS" for sekundtallet. Den fulde dato må ikke være senere end dags dato.

4. Type-2-logisk record: beskrivende tekst

Strukturen i det meste af denne record er ikke defineret efter den oprindelige ANSI/NIST-standard. Den indeholder oplysninger af specifik interesse for de agenturer, der afsender eller modtager filen. For at sikre kompatibiliteten mellem fingeraftrykssystemer, der skal kommunikere med hinanden, er det nødvendigt, at recorden kun indeholder de felter, der er angivet nedenfor. Dette dokument angiver, hvilke felter der er obligatoriske, og hvilke der er fakultative, og definerer desuden de enkelte felters struktur.

4.1. Felter i logiske records af Type-2

4.1.1. Field 2.001: Logical Record Length (LEN)

Dette felt angiver den samlede længde af denne type-2-record og angiver det samlede antal bytes, inkl. samtlige tegn i hvert enkelt felt og informationsseparatorerne.

4.1.2. Field 2.002: Image Designation Character (IDC)

Den IDC, der anføres i dette obligatoriske felt, er en ASCII-repræsentation af IDC som defineret i filindholdsfeltet (CNT) for type-1-recorden (felt 1.003).

4.1.3. Field 2.003: System Information (SYS)

Dette felt er obligatorisk og indeholder fire bytes, der angiver, hvilken version af INT-I denne specifikke type-2-record er forenelig med.

De første to bytes specificerer hovedversionens nummer og de næste to nummeret på det sekundære revisionsnummer. Eksempelvis er denne implementering baseret på INT-I version 4 revision 22 og skal derfor angives som "0422".

4.1.4. Field 2.007: Case Number (CNO)

Dette nummer tildeles af det lokale fingeraftrykskontor til en række latente aftryk, der er fundet på et gerningssted. Det angives i følgende format: CC/number

hvor CC er INTERPOL's landekode på to alfanumeriske tegn, og "number" afhænger af de relevante lokale retningslinjer og kan være op til 32 alfanumeriske tegn langt.

Dette felt gør det muligt for systemet at identificere latente aftryk med tilknytning til en bestemt lovovertrædelse.

4.1.5. Field 2.008: Sequence Number (SQN)

Dette felt angiver hver sekvens af latente aftryk i en sag. Det kan være op til fire numeriske tegn langt. En sekvens er et latent aftryk eller en række latente aftryk, der er grupperet med henblik på lagring og/eller søgning. Definitionen indebærer, at selv individuelle latente aftryk også skal have tildelt et sekvensnummer.

Dette felt kan sammen med MID (felt 2.009) medtages med henblik på at identificere et bestemt latent aftryk i en sekvens.

4.1.6. Field 2.009: Latent Identifier (MID)

Dette felt angiver det enkelte latente aftryk i en sekvens. Værdien er et eller to bogstaver, hvor "A" betegner det første latente aftryk, "B" det andet og så videre op til "ZZ". Dette felt benyttes på samme måde som det latente sekvensnummer, der er omhandlet i beskrivelsen af SQN (felt 2.008).

4.1.7. Field 2.010: Criminal Reference Number (CRN)

Dette er et unikt referencenummer, som et nationalt agentur tildeler en person, der for første gang tiltales for en lovovertrædelse. I det enkelte land har den enkelte aldrig mere end ét CRN og har det heller ikke til fælles med nogen anden person. Men den samme person kan have strafferetlige referencenumre i flere lande, som skelnes fra hinanden ved hjælp af landekoderne.

Følgende format benyttes for CRN-feltet: CC/number

hvor CC er den landekode på to alfanumeriske tegn, som er defineret i ISO 3166, og "number" afhænger af det udstedende agenturs relevante lokale retningslinjer og kan være op til 32 alfanumeriske tegn langt.

For transaktioner i henhold til artikel 533 og 534 i denne aftale vil dette felt blive benyttet til det anmodende agenturs nationale strafferetlige referencenummer, som er knyttet til billederne i records af type-4 eller type-15.

4.1.8. Field 2.012: Miscellaneous Identification Number (MN1)

Dette felt indeholder CRN (felt 2.010), som er overført ved en CPS- eller PMS-transaktion uden landekode foran.

4.1.9. Field 2.013: Miscellaneous Identification Number (MN2)

Dette felt indeholder CNO (felt 2.007), som er overført ved en MPS- eller MMS-transaktion uden landekode foran.

4.1.10. Field 2.014: Miscellaneous Identification Number (MN3)

Dette felt indeholder SQN (felt 2.008), som er overført ved en MPS- eller MMS-transaktion.

4.1.11. Field 2.015: Miscellaneous Identification Number (MN4)

Dette felt indeholder MID (felt 2.009), som er overført ved en MPS- eller MMS-transaktion.

4.1.12. Field 2.063: Additional Information (INF)

I tilfælde af en SRE-transaktion i forbindelse med en PMS-anmodning indeholder dette felt oplysninger om, hvilken finger der gav den eventuelle overensstemmelse. Feltets format er som følger:

NN, hvor NN er den fingerpositionskode, der er defineret i tabel 5, på to tegns længde.

I alle andre tilfælde er feltet fakultativt. Det består af op til 32 alfanumeriske tegn og kan give supplerende information om anmodningen.

4.1.13. Field 2.064: Respondents List (RLS)

Dette felt indeholder mindst to subfelter. Det første subfelt beskriver, hvilken type søgning der er foretaget, ved hjælp af et mnemoteknisk hjælpemiddel på tre bogstaver, som angiver transaktionstypen i TOT (felt 1.004). Det andet subfelt er kun på ét tegn. Et "I" angiver, at der er fundet en overensstemmelse (HIT), og "N" angiver, at der ikke er fundet nogen overensstemmelse (No-HIT). Det tredje subfelt indeholder sekvensidentifikatoren for kandidatresultatet og det samlede antal kandidater, adskilt af en skråstreg. Hvis der findes flere kandidater, vil der blive sendt flere meddelelser tilbage.

I tilfælde af en mulig overensstemmelse vil det fjerde subfelt indeholde resultatet i form af et tal med op til seks cifre. Er overensstemmelsen bekræftet, angives værdien i subfeltet som "999999".

Eksempel: "CPS{}{RS}}I{}{RS}}001/001{}{RS}}999999{}{GS}}".

Hvis AFIS-fjernserveren ikke sætter tal på resultatet, bør resultatet nul benyttes på det pågældende punkt.

4.1.14. Field 2.074: Status/Error Message Field (ERM)

Dette felt indeholder fejlmeddelelser i tilknytning til transaktioner, som vil blive sendt tilbage til anmoderen, når der opstår en fejl.

Tabel 3

Fejlmeddelelser

Numeric Code (1-3) Meaning (5-128) 003 ERROR: UNAUTHORISED ACCESS 101 Mandatory field missing 102 Invalid record type 103 Undefined field 104 Exceed the maximum occurrence 105 Invalid number of subfields 106 Field length too short 107 Field length too long 108 Field is not a number as expected 109 Field number value too small 110 Field number value too big 111 Invalid character 112 Invalid date 115 Invalid item value 116 Invalid type of transaction 117 Invalid record data 201 ERROR: INVALID TCN 501 ERROR: INSUFFICIENT FINGERPRINT QUALITY 502 ERROR: MISSING FINGERPRINTS 503 ERROR: FINGERPRINT SEQUENCE CHECK FAILED 999 ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY.

Fejlmeddelelse 100-199:

Disse fejlmeddelelser vedrører valideringen af ANSI/NIST-records og defineres som: <error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF <error_code 2>: IDC <idc_number 2> FIELD <field_id 2> <dynamic text 2>… hvor — error_code er en kode, der entydigt angiver en specifik årsag (jf. tabel 3) — field_id er ANSI/NIST-feltnummeret for det felt, som fejlen vedrører (e.g. 1.001, 2.001, …) i formatet <record_type>.<field_id>.<sub_field_id> — dynamisk tekst er en mere detaljeret dynamisk beskrivelse af fejlen — LF betegner et linjeskift (Line Feed), der adskiller fejlene, hvis der konstateres mere end én fejl — for type-1-records er ICD defineret som "-1".

Eksempel:

201: IDC - 1 FIELD 1.009 WRONG CONTROL CHARACTER {}{LF}} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION

Dette felt er obligatorisk for fejltransaktioner.

4.1.15. Field 2.320: Expected Number of Candidates (ENC)

Dette felt indeholder det maksimale antal kandidater, som det anmodende agentur forventer at skulle kontrollere. ENC-værdien må ikke overstige de værdier, der er fastsat i tabel 11.

5. Type-4-logisk record: gråtonebillede med høj opløsning

Det skal bemærkes, at type-4-records i sagens natur er binære og ikke ASCII-baserede. Derfor har hvert enkelt felt fået anvist en bestemt position i recorden, hvilket indebærer, at alle felterne er obligatoriske.

Standarden gør det muligt at angive såvel billedets størrelse som opløsningen i recorden. Kun logiske records af type-4 kan indeholde fingeraftryksbilleddata, der overføres med en nominel pixeltæthed på 500-520 DPI. Den foretrukne pixeltæthed for nye miljøer er 500 DPI (pixel/tomme) eller 19,68 pixel/mm. 500 DPI er den tæthed, der anbefales af INT-I, men tilsvarende systemer kan kommunikere med hinanden ved en anden tæthed end den foretrukne, beliggende mellem 500 og 520 DPI.

5.1. Felter i logisk record af type-4

5.1.1. Field 4.001: Logical Record Length (LEN)

Dette felt på fire bytes angiver længden af denne type-4-record og angiver det samlede antal bytes, inkl. samtlige bytes i hvert enkelt felt i recorden.

5.1.2. Field 4.002: Image Designation Character (IDC)

Dette er den 1 byte store binære repræsentation af det IDC-nummer, der er angivet i headerfilen.

5.1.3. Field 4.003: Impression Type (IMP)

Aftrykstypen er et 1 byte stort felt, der optræder som den sjette byte i recorden.

Tabel 4

Fingeraftrykstype

Code Description 0 Live-scan of plain fingerprint 1 Live-scan of rolled fingerprint 2 Non-live scan impression of plain fingerprint captured from paper 3 Non-live scan impression of rolled fingerprint captured from paper 4 Latent impression captured directly 5 Latent tracing 6 Latent photo 7 Latent lift 8 Swipe 9 Unknown

5.1.4. Field 4.004: Finger Position (FGP)

Dette felt, der har en fast længde på seks bytes, optræder som bytes nr. 7-12 i en type-4-record. Det angiver mulige fingerpositioner begyndende i den byte, der er længst til venstre (byte nr. 7 i recorden). Den kendte eller mest sandsynlige fingerposition hentes i tabel 5. Der kan registreres yderligere fem fingre ved at indlæse de øvrige fingerpositioner i de resterende fem bytes efter samme model. Hvis der benyttes færre end fem registrerede fingerpositioner, udfyldes de ubenyttede bytes med det binære 255. Til registrering af alle fingerpositionerne benyttes koden 0 for ukendt.

Tabel 5

Fingerpositionskode og maksimal størrelse

Finger position Finger code Width (mm) Length (mm) Unknown 0 40,0 40,0 Right thumb 1 45,0 40,0 Right index finger 2 40,0 40,0 Right middle finger 3 40,0 40,0 Right ring finger 4 40,0 40,0 Right little finger 5 33,0 40,0 Left thumb 6 45,0 40,0 Left index finger 7 40,0 40,0 Left middle finger 8 40,0 40,0 Left ring finger 9 40,0 40,0 Left little finger 10 33,0 40,0 Plain right thumb 11 30,0 55,0 Plain left thumb 12 30,0 55,0 Plain right four fingers 13 70,0 65,0 Plain left four fingers 14 70,0 65,0

For latente aftryk fra gerningssteder benytter man kun koderne 0 til 10.

5.1.5. Field 4.005: Image Scanning Resolution (ISR)

Dette 1 byte store felt optræder som byte nr. 13 i en type-4-record. Hvis værdien er "0", er billedet taget med den foretrukne scanningsopløsning på 19,68 pixel/mm (500 pixel/tomme). Hvis værdien er "1", er billedet taget med en anden scanningsopløsning som angivet i type-1-recorden.

5.1.6. Field 4.006: Horizontal Line Length (HLL)

Dette felt optræder som byte nr. 14 og 15 i en type-4-record. Det angiver antal pixel i hver scannet linje. Den første byte er den vigtigste.

5.1.7. Field 4.007: Vertical Line Length (VLL)

Dette felt angiver i byte nr. 16 og 17 antallet af scannede linjer i billedet. Den første byte er den vigtigste.

5.1.8. Field 4.008: Gray-scale Compression Algorithm (GCA)

Dette 1 byte store felt angiver, hvilken gråtonekomprimeringsalgoritme der er benyttet ved kodningen af billeddataene. I denne implementering angiver en binær kode 1, at WSQ-komprimeringsalgoritmen (tillæg 39-7) er benyttet.

5.1.9. Field 4.009: The Image

Dette felt indeholder en byte-strøm, der repræsenterer billedet. Strukturen vil naturligvis afhænge af den benyttede komprimeringsalgoritme.

6. Type-9-logisk record: Minutiæ Record

Type-9-records indeholder ASCII-tekst, der beskriver minutiæ og dertil knyttede oplysninger, som er indkodet fra et latent aftryk. For en søgetransaktion på et latent aftryk er der ingen begrænsning for, hvor mange af disse type-9-records en fil kan indeholde, og som hver især skal svare til et særskilt view eller latent aftryk.

6.1. Minutiæ extraction

6.1.1. Minutia type identification

Denne standard definerer tre identifikationsnumre, der benyttes til at beskrive, hvilken type minutia der er tale om. De er anført i tabel 6. En linjeafslutning (ridge ending) betegnes som type-1. En bifurcation betegnes som type-2. Hvis en minutia ikke klart kan kategoriseres som en af disse typer, betegnes den som "andet", type-0.

Tabel 6

Minutia types

Type Description 0 Other 1 Ridge ending 2 Bifurcation

6.1.2. Minutia placement and type

For at modellerne kan være i overensstemmelse med afsnit 5 i ANSI INCITS 378-2004-standarden, skal følgende metode, der er en udbygning af den nuværende INCITS 378-2004-standard, benyttes til at bestemme de enkelte minutiæs position (lokalisering og retning).

Den position eller lokalisering, som en minutia, der repræsenterer en linjeafslutning, har, bliver forgreningspunktet for midterskelettet i fordybningen foran linjeforhøjningens afslutning. Hvis man reducerer de tre udløbere i fordybningen til et skelet af kun én pixels bredde, vil krydspunktet være minutiaens lokalisering. Tilsvarende er en bifurcations lokalisering forgreningspunktet for linjeforhøjningens midterskelet. Hvis forhøjningens tre udløbere hver især blev reduceret til et skelet af kun én pixels bredde, ville de tre udløberes krydspunkt være minutiaens lokalisering.

Når alle linjeafslutningerne er blevet konverteret til bifurcationer, repræsenteres alle fingeraftrykkets minutiæ som bifurcationer. X- og Y-pixelkoordinaterne i krydspunktet for de tre udløbere af hver minutia kan formateres direkte. Fastsættelsen af minutiaernes retning kan udledes af hver af skelettets bifurcationer. De tre udløbere af hvert af skelettets bifurcationer skal undersøges, og endepunktet for hver udløber lokaliseres. Figur 6.1.2 illustrerer de tre metoder, der benyttes til at lokalisere endepunktet for en udløber på grundlag af en scanningsopløsning på 500 DPI.

Endepunktet lokaliseres ud fra den begivenhed, der indtræder først. Pixeltællingen er baseret på en scanningsopløsning på 500 DPI. Men andre scanningsopløsninger vil pixeltællingen give andre resultater.

— En afstand på 0,064" (den 32. pixel)

— Endepunktet for skeletudløberen befinder sig i en afstand af mellem 0,02" og 0,064" (fra den 10. til den 32. pixel); kortere udløbere benyttes ikke

— En anden bifurcation optræder inden for en afstand af 0,064" (før den 32. pixel).

Minutiævinklen bestemmes ved at konstruere tre virtuelle stråler, der udgår fra bifurcationspunktet og når ud til enden af hver udløber. Medianlinjen i den mindste af de tre vinkler, som disse stråler danner, angiver minutiæns retning.

6.1.3. Koordinatsystem

Det koordinatsystem, der benyttes til at anskueliggøre et fingeraftryks minutiæ, er et kartesisk koordinatsystem. Lokaliseringen af de enkelte minutiæer repræsenteres af deres x- og y-koordinater. Koordinatsystemets origo placeres i det oprindelige billedes øverste venstre hjørne, således at x-værdierne stiger mod højre og y-værdierne stiger i nedadgående retning. Både x- og y-koordinaterne for et minutæ angives i pixelenheder fra origo. Det skal bemærkes, at placeringen af origo og måleenhederne ikke er i overensstemmelse med den konvention, der anvendes i definitionerne af type-9 i ANSI/NIST-ITL 1-2000.

6.1.4. Minutiæernes retning

Vinklerne udtrykkes i matematisk standardformat, med 0 grader til højre og vinkler, der bliver større mod uret. De registrerede vinkler åbner bagud langs forhøjningen for en forhøjningsafslutning og i retning mod fordybningens midte for en bifurcation. Denne konvention er 180 grader modsat den konventionelle vinkel, der beskrives i definitionerne af type-9 i ANSI/NIST-ITL 1-2000.

6.2. Felter i type-9-logisk record INCITS-378 format

Alle felter i type-9-recorden registreres som ASCII-tekst. Der må ikke være nogen binære felter i denne record med mærkede felter.

6.2.1. Field 9.001: Logical record length (LEN)

Dette obligatoriske ASCII-felt skal angive længden af den logiske record og præcisere det samlede antal bytes, herunder hvert tegn i hvert felt i recorden.

6.2.2. Field 9.002: Image designation character (IDC)

Dette obligatoriske to-byte felt anvendes til identificering og placering af minutiædata. IDC i dette felt skal matche IDC i feltet for filindhold i type-1-recorden.

6.2.3. Field 9.003: Impression type (IMP)

Dette obligatoriske en-byte felt beskriver, hvor informationen om fingeraftryksbilledet blev indsamlet. ASCII-værdien af den korrekte kode som valgt fra tabel 4 indlæses i dette felt for at angive aftrykstypen.

6.2.4. Field 9.004: Minutiæ format (FMT)

Dette felt indeholder et "U" for at angive, at minutiæ er formateret efter M1-378 standard. Selv om informationer kan kodes i overensstemmelse med M1-378-standarden, skal alle data i felter i type-9-recorden fortsat være ASCII-tekstfelter.

6.2.5. Field 9.126: CBEFF information

Dette felt indeholder tre informationselementer. Det første informationselement skal indeholde værdien "27" (0x1B). Det er for at identificere ejeren af CBEFF-formatet, der af International Biometric Industry Association (IBIA) er udpeget til INCITS Technical Committee M1. <US>-tegnet skal adskille dette element fra CBEFF-formattypen, der har en værdi på "513" (0x0201) for at angive, at denne record kun indeholder data om placering og angulærretning uden nogen udvidet datablokinformation. <US>-tegnet skal adskille dette element fra CBEFF Product Identifier (PID), der identificerer "ejeren" af kodningsudstyret. Det er sælger, der fastsætter denne værdi. Det kan fås på IBIA's websted (www.ibia.org), hvis det er indlæst.

6.2.6. Field 9.127: Capture equipment identification

Dette felt indeholder to informationselementer, der er adskilt af <US>-tegnet. Det første skal indeholde "APPF", hvis det udstyr, der oprindeligt blev anvendt til at tage billedet, var certificeret i overensstemmelse med tillæg F (IAFIS Image Quality Specification af 29. januar 1999) i CJIS-RS-0010, Federal Bureau of Investigation's Electronic Fingerprint Transmission Specification. Hvis udstyret ikke var i overensstemmelse hermed, indeholder det værdien "NONE". Andet informationselement skal indeholde optagelsesudstyrets ID, som er sælgers produktnummer på optagelsesudstyret. Værdien "0" angiver, at optagelsesudstyrets ID ikke er registreret.

6.2.7. Field 9.128: Horizontal line length (HLL)

Dette obligatoriske ASCII-felt angiver antallet af pixel i en enkelt horisontal linje af det overførte billede. Den maksimale horisontale størrelse er begrænset til 65534 pixel.

6.2.8. Field 9.129: Vertical line length (VLL)

Dette obligatoriske ASCII-felt angiver antallet af horisontale linjer i det overførte billede. Den maksimale vertikale størrelse er begrænset til 65534 pixel.

6.2.9. Field 9.130: Scale units (SLC)

Dette obligatoriske ASCII-felt angiver de enheder, der anvendes til at beskrive pixeltætheden. Et "1" i dette felt angiver pixel pr. tomme og et "2" angiver pixel pr. centimeter. Et "0" i dette felt angiver, at der ikke er angivet nogen skala. I dette tilfælde angiver kvotienten af HPS/VPS pixelaspektratioen.

6.2.10. Field 9.131: Horizontal pixel scale (HPS)

Dette obligatoriske ASCII-felt angiver den horisontale pixeltæthed i hele tal, når SLC indeholder et "1" eller et "2". Ellers angiver det den horisontale komponent af pixelaspektratioen.

6.2.11. Field 9.132: Vertical pixel scale (VPS)

Dette obligatoriske ASCII-felt angiver den vertikale pixeltæthed i hele tal, når SLC indeholder et "1" eller et "2". Ellers angiver det den vertikale komponent af pixelaspektratioen.

6.2.12. Field 9.133: Finger view

Dette obligatoriske felt angiver viewnummeret på den finger, der er knyttet til denne records data. Nummeret begynder med "0" og stiger med én ad gangen til "15".

6.2.13. Field 9.134: Finger Position (FGP)

Dette felt angiver koden for den fingerposition, der leverede oplysningen til denne type-9-record. En kode mellem 1 og 10 fra tabel 5 eller den relevante håndfladekode fra tabel 10 skal anvendes til at angive finger- eller håndfladepositionen.

6.2.14. Field 9.135: Finger quality

Dette felt angiver kvaliteten af de samlede minutiædata for fingeren og angives mellem 0 og 100. Tallet giver et samlet overblik over kvaliteten af fingerrecorden og repræsenterer kvaliteten af det oprindelige billede, af minutiaene og andre yderligere operationer, der kan berøre minutiærecorden.

6.2.15. Field 9.136: Number of minutiæ

Dette obligatoriske felt indeholder en opregning af antallet af minutiæ, der er registreret i denne logiske record.

6.2.16. Field 9.137: Finger minutiæ data

Dette obligatoriske felt har seks informationselementer adskilt af <US>-tegnet. Det består af flere subfelter, som hver indeholder detaljer af de enkelte minutiae. Det samlede antal minutiaesubfelter skal svare til antallet i felt 136. Det første informationselement er indeksnummeret for minutiæ, der indledes med "1" og øges med "1" for hver yderligere minutia i fingeraftrykket. Andet og tredje informationselement er x-koordinaten og y-koordinaterne i minutiæ angivet i pixelenheder. Fjerde informationselement er minutiae-vinklen angivet i enheder på to grader. Denne værdi skal være ikkenegativ mellem 0 og 179. Femte informationselement er minutiætypen. "0" angiver minutiæ af typen "OTHER", "1" en linjeafslutning (ridge ending) og "2" en linjebifurcation. Sjette informationselement angiver kvaliteten af hver minutiae. Denne værdi går fra 1 som minimum til 100 som maksimum. "0" angiver, at der ikke er nogen kvalitetsværdi. Hvert subfelt adskilles fra det næste ved at anvende <RS>-separatortegnet.

6.2.17. Field 9.138: Ridge count information

Dette felt består af en række subfelter, der hver især indeholder tre informationselementer. Det første element i første subfelt angiver metoden til ekstraktion af linjeantallet. "0" angiver, at det ikke vides, hvilken metode der er brugt til ekstraktion af linjeantallet eller deres rækkefølge i recorden. "1" angiver, at der for hver central minutia blev ekstraheret data om linjeantal til nærmeste minutia i fire kvadranter, og linjeantal for hver centrale minutia opgives samlet. "2" angiver, at der for hver centrale minutia blev ekstraheret data om linjeantal til nærmeste minutia i otte oktanter, og linjeantal for hver centrale minutia opgives samlet. De resterende to informationselementer i første subfelt skal begge indeholde "0". Informationselementer adskilles med <US>-separatortegnet. Efterfølgende subfelter vil indeholde indeksnummeret for den centrale minutiæ som første informationselement, indeksnummeret for nærliggende minutiæ som andet informationselement og antallet af linjer, der krydses, som tredje informationselement. Subfelter adskilles af <RS>-separatortegnet.

6.2.18. Field 9.139: Core information

Dette felt består af et subfelt for hver kerne i det oprindelige billede. Hvert subfelt består af tre informationselementer. De første to elementer indeholder x- og y-koordinatpositionerne i pixelenheder. Det tredje element indeholder kernens vinkel registreret i enheder på 2 grader. Værdien skal være en ikkenegativ værdi mellem 0 og 179. Flere kerner adskilles af <RS>-separatortegnet.

6.2.19. Field 9.140: Delta information (deltainformation)

Dette felt består af et subfelt for hvert delta i det oprindelige billede. Hvert subfelt består af tre informationselementer. De første to elementer indeholder x- og y-koordinatpositionerne i pixelenheder. Det tredje element indeholder deltaets vinkel registreret i enheder på 2 grader. Værdien skal være en ikkenegativ værdi mellem 0 og 179. Flere kerner adskilles af <RS>-separatortegnet.

7. Type-13-record: latent billede med variabel løsning

Type-13-logiske records med mærkede felter indeholder billeddata fra latente billeder. Disse billeder er beregnet på at blive overført til agenturer, der automatisk eller ved menneskelig indgriben og behandling vil ekstrahere de ønskede informationer om tegnene fra billederne.

Information vedrørende scanningsopløsning, billedstørrelse og andre parametre, der kræves til at behandle billedet, registreres som mærkede felter i recorden.

Tabel 7:

Type-13-record: latent billede med variabel opløsning

Ident Cond. code Field Number Field Name Char type Field size per occurrence Occur count Max byte cou