text:
efterfulgt af et punktum. De næste tre tegn angiver det på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, må 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 på, hvilken version af ANSI/NIST-standarden der benyttes, angiver dette fire-byte-felt nummeret på 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 på 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 består af et eller flere subfelter, der hvert især indeholder to informationselementer, der beskriver en enkelt logisk record, der forekommer i den pågældende fil. Subfelterne angives i den rækkefølge, som de på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 også 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 på tre bogstaver, som angiver


text:
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 på 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, nå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, nå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 på 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 på 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 é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
 —

type: contracts

jurisdiction: EU


text:
(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 é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 året, MM er måneden, og DD er dagen. Der sættes et nul foran é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, på 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 omgående.
 3.1.7. Field 1.007: Destination Agency Identifier (DAI)
 Dette felt angiver det agentur, som transaktionen er rettet til.
 Det bestå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 består af to alfanumeriske tegn. Det andet element, agenturet (agency), er en fritekstidentificering af agenturet på 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 transaktionsåret, SSSSSSSS er et ottecifret serienummer, og A er et kontrolbogstav, der genereres efter proceduren i tillæg 39-2.
 Når TCN ikke er til rådighed, udfyldes feltet YYSSSSSSSS med nuller, og kontrolbogstavet genereres som angivet ovenfor.
 3.1.10. Field 1.010: Transaction Control Response (TCR)
 Nå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 på 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 består af to informationselementer og skrives så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). Når det benyttes, indeholder GMT-feltet den universelle dato, som supplerer den lokale dato i felt 1.005 (DAT). Brugen


text:
af GMT-feltet fjerner det problem med lokal tid, der opstår, når en transaktion og svaret herpå 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 på 15 tegn, der kæder datoen sammen med GMT og slutter med "Z". Tegnene "CCYY" angiver transaktionsåret, "MM" angiver måneden med to cifre, og "DD" angiver dagen med to cifre, "HH" står for timetallet, "MM" for minuttallet og "SS" for sekundtallet. Den fulde dato må 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 på det sekundære revisionsnummer. Eksempelvis er denne implementering baseret på 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 på et gerningssted. Det angives i følgende format: CC/number
 hvor CC er INTERPOL's landekode på 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 på lagring og/eller søgning. Definitionen indebærer, at selv individuelle latente aftryk også skal have tildelt et sekvensnummer.
 Dette felt kan sammen med MID (felt 2.009) medtages med henblik på 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 så videre op til "ZZ". Dette felt benyttes på samme måde som det latente sekvensnummer, der


text:
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 é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 på 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, på to tegns længde.
 I alle andre tilfælde er feltet fakultativt. Det bestå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 på tre bogstaver, som angiver transaktionstypen i TOT (felt 1.004). Det andet subfelt er kun på é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 skrå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 på resultatet, bør resultatet nul benyttes på det på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, når der opstår en fejl.
 Tabel 3
 Fejlmeddelelser
 Numeric Code (1-3)
 Meaning (5-128)
 003
 ERROR: UNAUTHORISED ACCESS
 101
 Mandatory field missing
 102


text:
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 å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 é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 må ikke overstige de værdier, der er fastsat i tabel 11.
 5. Type-4-logisk record: grå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 fået anvist en bestemt position i recorden, hvilket indebærer, at alle felterne er obligatoriske.
 Standarden gør det muligt at angive så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 på 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 på 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


text:
8
 Swipe
 9
 Unknown
 5.1.4. Field 4.004: Finger Position (FGP)
 Dette felt, der har en fast længde på 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 på 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 grå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 på 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.


text:
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 é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 én pixels bredde, ville de tre udløberes krydspunkt være minutiaens lokalisering.
 Nå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 på grundlag af en scanningsopløsning på 500 DPI.
 Endepunktet lokaliseres ud fra den begivenhed, der indtræder først. Pixeltællingen er baseret på en scanningsopløsning på 500 DPI. Men andre scanningsopløsninger vil pixeltællingen give andre resultater.
 —
 En afstand på 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 stråler, der udgår fra bifurcationspunktet og når ud til enden af hver udløber. Medianlinjen i den mindste af de tre vinkler, som disse strå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, således at x-værdierne stiger mod højre og y-værdierne stiger i nedadgående retning. Både x- og y-koordinaterne for et minutæ angives i pixelenheder fra origo. Det skal bemærkes, at placeringen af origo og må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 å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 må 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


text:
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 på "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 fås på 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 på 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, nå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, når SLC indeholder et "1" eller et "2". Ellers angiver det den vertikale komponent af pixelaspektratioen.
 6.2.12.


text:
Field 9.133: Finger view
 Dette obligatoriske felt angiver viewnummeret på den finger, der er knyttet til denne records data. Nummeret begynder med "0" og stiger med é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 håndfladekode fra tabel 10 skal anvendes til at angive finger- eller hå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 bestå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 på 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 gå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 bestå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 består af et subfelt for hver kerne i det oprindelige billede. Hvert subfelt bestå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 på 2 grader. Værdien skal være en ikkenegativ værdi mellem 0 og 179. Flere


text:
kerner adskilles af <RS>-separatortegnet.
 6.2.19. Field 9.140: Delta information (deltainformation)
 Dette felt består af et subfelt for hvert delta i det oprindelige billede. Hvert subfelt bestå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 på 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 på 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 count
 min.
 max.
 min
 max
 LEN
 M
 13.001
 LOGICAL RECORD LENGTH
 n
 4
 8
 1
 1
 15
 IDC
 M
 13.002
 IMAGE DESIGNATION CHARACTER
 n
 2
 5
 1
 1
 12
 IMP
 M
 13.003
 IMPRESSION TYPE
 A
 2
 2
 1
 1
 9
 SRC
 M
 13.004
 SOURCE AGENCY/ORI
 AN
 6
 35
 1
 1
 42
 LCD
 M
 13.005
 LATENT CAPTURE DATE
 n
 9
 9
 1
 1
 16
 HLL
 M
 13.006
 HORIZONTAL LINE LENGTH
 n
 4
 5
 1
 1
 12
 VLL
 M
 13.007
 VERTICAL LINE LENGTH
 n
 4
 5
 1
 1
 12
 SLC
 M
 13.008
 SCALE UNITS
 n
 2
 2
 1
 1
 9
 HPS
 M
 13.009
 HORIZONTAL PIXEL SCALE
 n
 2
 5
 1
 1
 12
 VPS
 M
 13.010
 VERTICAL PIXEL SCALE
 n
 2
 5
 1
 1
 12
 CGA
 M
 13,011
 COMPRESSION ALGORITHM
 A
 5
 7
 1
 1
 14
 BPX
 M
 13.012
 BITS PER PIXEL
 n
 2
 3
 1
 1
 10
 FGP
 M
 13.013
 FINGER POSITION
 n
 2
 3
 1
 6
 25
 RSV
 13.014
 RESERVED FOR FUTURE DEFINITION
 —
 —
 —
 —
 —
 —
 13.019
 COM
 O
 13.020
 COMMENT
 A
 2
 128
 0
 1
 135
 RSV
 13.021
 RESERVED FOR FUTURE DEFINITION
 —
 —
 —
 —
 —
 —
 13.199
 UDF
 O
 13.200
 USER-DEFINED FIELDS
 —
 —
 —
 —
 —
 —
 13.998
 DAT
 M
 13.999
 IMAGE DATA
 B
 2
 —
 1
 1
 —
 Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary
 7.1. Felter i type-13-logisk record
 Følgende afsnit beskriver de data, der er indeholdt i hvert af felterne i type-13-logiske records.
 I type-13-logiske records skal indlæsninger foretages i nummererede felter. Det er nødvendigt, at de to første felter i recorden står i samme rækkefølge, og feltet med billeddata skal være angivet i recordens sidste fysiske felt. For hvert felt i type-13-recorden indeholder tabel 7 feltet "condition code" som "mandatory" (obligatorisk) "M" eller "optional" (fakultativ) "O", feltnummer, feltnavn, tegntype, feltstørrelse og grænser for forekomst. Baseret på et trecifret feltnummer er det maksimale antal bytes angivet i sidste kolonne. Da der anvendes flere cifre til feltnummeret, vil det maksimale antal bytes også stige. De to felter i "field


text:
size per occurence" omfatter alle separatortegn, der anvendes i feltet. "Maximum byte count" omfatter feltnummer, oplysninger og alle separatortegn, herunder tegnet "GS".
 7.1.1. Field 13.001: Logical record length (LEN)
 Dette obligatoriske ASCII-felt skal indeholde det samlede antal bytes i den logiske type-13-record. Felt 13.001 skal angive recordens længde og omfatte samtlige tegn i hvert felt samt informationsseparatorerne.
 7.1.2. Field 13.002: Image designation character (IDC)
 Dette obligatoriske ASCII-felt anvendes til at identificere de latente billeddata, der er indeholdt i recorden. Dette IDC skal matche det IDC, der blev fundet i filindholdsfeltet (CNT) i type-1-recorden.
 7.1.3. Field 13.003: Impression type (IMP)
 Dette obligatoriske en- eller to-byte ASCII-felt angiver, hvordan de latente billeddata blev indsamlet. I dette felt indlæses den relevante latente kode fra tabel 4 (finger) eller tabel 9 (håndflade).
 7.1.4. Field 13.004: Source agency/ORI (SRC)
 Dette obligatoriske ASCII-felt indeholder identifikationen af den administration eller organisation, der først indlæste ansigtsbilledet i recorden. Normalt vil feltet angive "the Originating Agency Identifier" (ORI) for det agentur, der tog billedet. Det består af to informationselementer i følgende format: CC/agency.
 Det første element angiver INTERPOL's landekode på to alfanumeriske tegn. Det andet element, agenturet (agency), er en fritekstidentificering af agenturet på højst 32 alfanumeriske tegn.
 7.1.5. Field 13.005: Latent capture date (LCD)
 Dette obligatoriske ASCII-felt angiver den dato, hvor det latente billede i recorden blev taget. Datoen er angivet med otte chifre i formatet CCYYMMDD. CCYY angiver det år, hvor billedet blev taget, MM angiver måneden, og DD angiver datoen. For eksempel angiver 20000229 den 29. februar 2000. Den fuldstændige dato skal være i et ægte datoformat.
 7.1.6. Field 13.006: Horizontal line length (HLL)
 Dette obligatoriske ASCII-felt angiver antallet af pixel i en enkelt horisontal linje af det overførte billede.
 7.1.7. Field 13.007: Vertical line length (VLL)
 Dette obligatoriske ASCII-felt angiver antallet af horisontale linjer i det overførte billede.
 7.1.8. Field 13.008: 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.
 7.1.9. Field 13.009: Horizontal pixel scale (HPS)
 Dette obligatoriske ASCII-felt angiver den horisontale pixeltæthed i hele tal, når SLC indeholder et "1" eller et "2". Ellers angiver det den horisontale komponent af pixelaspektratioen.
 7.1.10. Field 13.010: Vertical pixel scale (VPS)
 Dette obligatoriske ASCII-felt angiver den vertikale pixeltæthed i hele tal, når SLC indeholder et "1" eller et "2". Ellers angiver det den vertikale komponent af pixelaspektratioen.
 7.1.11. Field 13.011: Compression algorithm (CGA)
 Dette obligatoriske ASCII-felt angiver den algoritme, der anvendes til at komprimere gråtonebilleder. Kompressionskoderne findes i tillæg 39-7.
 7.1.12. Field 13.012: Bits per pixel (BPX)
 Dette obligatoriske ASCII-felt angiver antal bit per pixel. I feltet angiver "8" normale gråtoneværdier fra "0" til "255". Hvis der i dette felt indlæses en værdi højere eller lavere end "8", repræsenterer det en gråtoneværdi med henholdsvis større eller mindre præcision.
 7.1.13. Field 13.013: Finger/palm position


text:
(PLP)
 Dette obligatoriske mærkede felt angiver en eller flere finger- eller håndfladepositioner, der kan matche det latente billede. Decimalkodenummeret, der svarer til den kendte eller mest sandsynlige fingerposition, tages fra tabel 5 eller den mest sandsynlige håndfladeposition fra tabel 10 og indlæses som et ét- eller tocifret ASCII-subfelt. Der kan henvises til supplerende finger- og/eller håndfladepositioner ved at indlæse de alternative positionskoder som subfelter adskilt af "RS"-separatortegnet. Kode "0" for "Unknown Finger" (ukendt finger) anvendes til at henvise til fingerposition 1-10. Kode "20" for "Unknown Palm" (ukendt håndflade) anvendes til at henvise til alle opførte håndfladeaftrykspositioner.
 7.1.14. Field 13.014-019: Reserved for future definition (RSV)
 Disse felter er reserveret til indlæsning af kommende revisioner af denne standard. Ingen af disse felter må anvendes på nuværende revisionsniveau. Hvis disse felter forekommer, skal de ignoreres.
 7.1.15. Field 13.020: Comment (COM)
 Dette fakultative felt kan anvendes til at indlæse bemærkninger eller anden ASCII-tekstinformation sammen med data vedrørende håndfladeaftryksdata.
 7.1.16. Field 13.021-199: Reserved for future definition (RSV)
 Disse felter er reserveret til indlæsning af kommende revisioner af denne standard. Ingen af disse felter må anvendes på nuværende revisionsniveau. Hvis disse felter forekommer, skal de ignoreres.
 7.1.17. Field 13.200-998: User-defined fields (UDF)
 Disse felter kan defineres af brugerne og vil blive anvendt til fremtidige krav. Deres størrelse og indhold defineres af brugeren efter aftale med det modtagende agentur. Hvis disse felter forekommer, skal de indeholde ASCII-tekstinformation
 7.1.18. Field 13.999: Image data (DAT)
 Dette felt indeholder alle data fra et håndfladeaftryksbillede. Det skal altid have feltnummer 999 og være det sidste fysiske felt i recorden. For eksempel efterfølges "13.999:" af billeddata i binær repræsentation.
 Hver pixel af ukomprimerede gråtonedata skal normalt angives med otte bit (256 gråtoneniveauer) indeholdt i en enkelt byte. Hvis indlæsningen i BPX Felt 13.012 er højere eller lavere end 8, vil det antal bytes, der kræves til at indeholde en pixel, være forskelligt. Hvis der anvendes kompression, skal pixeldataene komprimeres i overensstemmelse med den kompressionsteknik, der er angivet i GCA-feltet.
 7.2. Afslutning af type-13-record: latente billeder med variabel opløsning
 Af hensyn til sammenhængen skal der umiddelbart efter den sidste databyte i felt 13.999 indsættes en "FS"-separator for at adskille den fra den næste logiske record. Denne separator skal indlæses i længdefeltet i type-13-recorden.
 8. Type-15-record: håndfladeaftryk med variabel opløsning
 Type-15-logisk record med mærkede felter indeholder og anvendes til at udveksle håndfladeaftryksbilleddata sammen med fastlagte og brugerdefinerede tekstinformationsfelter, der er relevante for det digitaliserede billede. Information om scanningopløsning, billedstørrelse og andre parametre eller bemærkninger, der kræves til at behandle billedet, registreres som mærkede felter i recorden. Håndfladeaftryksbilleder, der overføres til andre agenturer vil blive behandlet af modtageragenturerne, så de kan ekstrahere de informationstegn, der kræves med henblik på matchning.
 Billeddataene fås direkte fra en person, der anvender live scan-udstyr, eller fra en håndfladeaftryksformular eller andre medier, der indeholder personens håndfladeaftryk.
 Enhver metode til at optage håndfladeaftryksbilleder skal kunne tage et sæt af billeder for hver hånd. Dette sæt skal omfatte lillefingerbalden som et enkelt scannet billede og hele håndfladen fra håndleddet til fingerspidserne som


text:
et eller to scannede billeder. Hvis der anvendes to billeder til at repræsentere hele håndfladen, skal det nederste billede gå fra håndleddet til toppen af interdigitalregionen (tredje fingerled) og omfatte tenar- og hypotenarregionen i håndfladen. Det øverste billede skal gå fra den nederste del af interdigitalregionen til de yderste fingerspidser. Dette giver et passende antal overlapninger mellem de to billeder, som begge findes over håndfladens interdigitalregion. Ved at sammenholde linjestrukturer og detaljer i dette fælles område, kan en undersøger med sikkerhed konstatere, om begge billeder kommer fra samme håndflade.
 Da en håndfladeaftrykstransaktion kan anvendes til forskellige formål, kan den indeholde et eller flere unikke billedområder optaget fra håndfladen eller hånden. Et fuldstændigt recordsæt af håndfladeaftryk for en enkelt person vil normalt omfatte lillefingerbalden og det/de fulde håndfladebillede(r) fra hver hånd. Da logiske billedrecords med mærkede felter kun kan indeholde et binært felt, kræves der en enkelt type-15-record for hver lillefingerbalde og en eller to type-15-record(s) for hver fulde håndflade. Derfor kræves der 4-6 type-15-records til at repræsentere personens håndfladeaftryk i en normal håndfladeaftrykstransaktion.
 8.1. Felter i type-15-logisk record
 Følgende afsnit beskriver de data, der er indeholdt i hvert af felterne i type-15-logiske records.
 I type-15-logiske records skal indlæsninger foretages i nummererede felter. Det er nødvendigt, at de to første felter i recorden står i samme rækkefølge, og feltet med billeddata skal være angivet i recordens sidste fysiske felt. For hvert felt i type-15-recorden indeholder tabel 8 feltet "condition code" som "mandatory" (obligatorisk) "M" eller "optional" (fakultativ) "O", feltnummer, feltnavn, tegntype, feltstørrelse og grænser for forekomst. Baseret på et trecifret feltnummer er det maksimale antal bytes angivet i sidste kolonne. Da der anvendes flere cifre til feltnummeret, vil det maksimale antal bytes også stige. De to felter i "field size per occurence" omfatter alle separatortegn, der anvendes i feltet. "Maximum byte count" omfatter feltnummer, oplysninger og alle separatortegn, herunder tegnet "GS".
 8.1.1. Field 15.001: Logical record length (LEN)
 Dette obligatoriske ASCII-felt skal indeholde det samlede antal bytes i den logiske type-15-record. Felt 15.001 skal angive recordens længde og omfatte samtlige tegn i hvert eneste felt samt informationsseparatorerne.
 8.1.2. Field 15.002: Image designation character (IDC)
 Dette obligatoriske ASCII-felt anvendes til at identificere det håndfladeaftryksbillede, der er indeholdt i recorden. Dette IDC skal matche det IDC, der blev fundet i filindholdsfeltet (CNT) i type-1-recorden.
 8.1.3. Field 15.003: Impression type (IMP)
 Dette obligatoriske en-byte ASCII-felt angiver, hvordan informationen om håndfladeaftryksbilledet blev indsamlet. I dette felt indlæses den relevante kode fra tabel 9.
 8.1.4. Field 15.004: Source agency/ORI (SRC)
 Dette obligatoriske ASCII-felt indeholder identifikationen af den administration eller organisation, der først indlæste ansigtsbilledet i recorden. Normalt vil feltet angive "the Originating Agency Identifier" (ORI) for det agentur, der tog billedet. Det består af to informationselementer i følgende format: CC/agency.
 Det første element angiver INTERPOL's landekode på to alfanumeriske tegn. Det andet element, agenturet (agency), er en fritekstidentificering af agenturet på højst 32 alfanumeriske tegn.
 8.1.5. Field 15.005: Palmprint capture date (PCD)
 Dette obligatoriske ASCII-felt angiver den dato, hvor håndfladeaftrykket blev taget. Datoen er angivet med


text:
otte chifre i formatet CCYYMMDD. CCYY angiver det år, hvor billedet blev taget, MM angiver måneden, og DD angiver datoen. For eksempel angiver 20000229 den 29. februar 2000. Den fuldstændige dato skal være i et ægte datoformat.
 8.1.6. Field 15.006: Horizontal line length (HLL)
 Dette obligatoriske ASCII-felt angiver antallet af pixel i en enkelt horisontal linje af det overførte billede.
 8.1.7. Field 15.007: Vertical line length (VLL)
 Dette obligatoriske ASCII-felt angiver antallet af horisontale linjer i det overførte billede.
 8.1.8. Field 15.008: 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.
 8.1.9. Field 15.009: Horizontal pixel scale (HPS)
 Dette obligatoriske ASCII-felt angiver den horisontale pixeltæthed i hele tal, når SLC indeholder et "1" eller et "2". Ellers angiver det den horisontale komponent af pixelaspektratioen.
 8.1.10. Field 15.010: Vertical pixel scale (VPS)
 Dette obligatoriske ASCII-felt angiver den vertikale pixeltæthed i hele tal, når SLC indeholder et "1" eller et "2". Ellers angiver det den vertikale komponent af pixelaspektratioen.
 Tabel 8:
 Type-15-record: håndfladeaftryk med variabel opløsning
 Ident
 Cond. code
 Field Number
 Field Name
 Char type
 Field size per occurrence
 Occur count
 Max byte count
 min.
 max.
 min
 max
 LEN
 M
 15.001
 LOGICAL RECORD LENGTH
 n
 4
 8
 1
 1
 15
 IDC
 M
 15.002
 IMAGE DESIGNATION CHARACTER
 n
 2
 5
 1
 1
 12
 IMP
 M
 15.003
 IMPRESSION TYPE
 n
 2
 2
 1
 1
 9
 SRC
 M
 15.004
 SOURCE AGENCY/ORI
 AN
 6
 35
 1
 1
 42
 PCD
 M
 15.005
 PALMPRINT CAPTURE DATE
 n
 9
 9
 1
 1
 16
 HLL
 M
 15.006
 HORIZONTAL LINE LENGTH
 n
 4
 5
 1
 1
 12
 VLL
 M
 15.007
 VERTICAL LINE LENGTH
 n
 4
 5
 1
 1
 12
 SLC
 M
 15.008
 SCALE UNITS
 n
 2
 2
 1
 1
 9
 HPS
 M
 15.009
 HORIZONTAL PIXEL SCALE
 n
 2
 5
 1
 1
 12
 VPS
 M
 15.010
 VERTICAL PIXEL SCALE
 n
 2
 5
 1
 1
 12
 CGA
 M
 15.011
 COMPRESSION ALGORITHM
 AN
 5
 7
 1
 1
 14
 BPX
 M
 15.012
 BITS PER PIXEL
 n
 2
 3
 1
 1
 10
 PLP
 M
 15.013
 PALMPRINT POSITION
 n
 2
 3
 1
 1
 10
 RSV
 15.014
 RESERVED FOR FUTURE INCLUSION
 —
 —
 —
 —
 —
 —
 15.019
 COM
 O
 15.020
 COMMENT
 AN
 2
 128
 0
 1
 128
 RSV
 15.021
 RESERVED FOR FUTURE INCLUSION
 —
 —
 —
 —
 —
 —
 15.199
 UDF
 O
 15.200
 USER-DEFINED FIELDS
 —
 —
 —
 —
 —
 —
 15.998
 DAT
 M
 15.999
 IMAGE DATA
 B
 2
 —
 1
 1
 —
 Tabel 9:
 Håndfladeaftrykstype
 Description
 Code
 Live-scan palm
 10
 Nonlive-scan palm
 11
 Latent palm impression
 12
 Latent palm tracing
 13
 Latent palm photo
 14
 Latent palm lift
 15
 8.1.11. Field 15.011: Compression algorithm (CGA)
 Dette obligatoriske ASCII-felt angiver den algoritme, der anvendes til at komprimere gråtonebilleder. Hvis der indlæses "NONE" i dette felt, angiver det, at dataene i denne record ikke er


text:
komprimerede. For de billeder, der skal komprimeres, indeholder feltet den foretrukne metode til at komprimere tenprint fingeraftryksbilleder. Gyldige kompressionskoder er angivet i tillæg 39-7.
 8.1.12. Field 15.012: Bits per pixel (BPX)
 Dette obligatoriske ASCII-felt angiver antal bit per pixel. I feltet angiver "8" normale gråtoneværdier fra "0" til "255". Hvis der i dette felt indlæses en værdi højere eller lavere end "8", repræsenterer det en gråtoneværdi med henholdsvis større eller mindre præcision.
 Tabel 10:
 Håndfladekoder, områder og størrelser
 Palm Position
 Palm code
 Image area (mm2)
 Width (mm)
 Height (mm)
 Unknown Palm
 20
 28387
 139,7
 203,2
 Right Full Palm
 21
 28387
 139,7
 203,2
 Right Writer s Palm
 22
 5645
 44,5
 127,0
 Left Full Palm
 23
 28387
 139,7
 203,2
 Left Writer s Palm
 24
 5645
 44,5
 127,0
 Right Lower Palm
 25
 19516
 139,7
 139,7
 Right Upper Palm
 26
 19516
 139,7
 139,7
 Left Lower Palm
 27
 19516
 139,7
 139,7
 Left Upper Palm
 28
 19516
 139,7
 139,7
 Right Other
 29
 28387
 139,7
 203,2
 Left Other
 30
 28387
 139,7
 203,2
 8.1.13. Field 15.013: Palmprint position (PLP)
 Dette obligatoriske mærkede felt angiver håndfladeaftrykkets position, der matcher håndfladeaftryksbilledet. Decimalkodenummeret, der skal svare til den kendte eller mest sandsynlige håndfladeaftryksposition, tages fra tabel 10 og indlæses som et tocifret ASCII-subfelt. Tabel 10 angiver også de maksimale billedområder og -dimensioner for hver af de mulige håndfladeaftrykspositioner.
 8.1.14. Field 15.014-019: Reserved for future definition (RSV)
 Disse felter er reserveret til indlæsning af kommende revisioner af denne standard. Ingen af disse felter må anvendes på nuværende revisionsniveau. Hvis disse felter forekommer, skal de ignoreres.
 8.1.15. Field 15.020: Comment (COM)
 Dette fakultative felt kan anvendes til at indlæse bemærkninger eller anden ASCII-tekstinformation sammen med data vedrørende håndfladeaftryksdata.
 8.1.16. Field 15.021-199: Reserved for future definition (RSV)
 Disse felter er reserveret til indlæsning af kommende revisioner af denne standard. Ingen af disse felter må anvendes på nuværende revisionsniveau. Hvis disse felter forekommer, skal de ignoreres.
 8.1.17. Field 15.200-998: User-defined fields (UDF)
 Disse felter kan defineres af brugerne og vil blive anvendt til fremtidige krav. Deres størrelse og indhold defineres af brugeren efter aftale med det modtagende agentur. Hvis disse felter forekommer, skal de indeholde ASCII-tekstinformation
 8.1.18. Field 15.999: Image data (DAT)
 Dette felt indeholder alle data fra et håndfladeaftryksbillede. Det skal altid have feltnummer 999 og være det sidste fysiske felt i recorden. For eksempel efterfølges "15.999:" af billeddata i binær repræsentation. Hver pixel af ukomprimerede gråtonedata skal normalt angives med otte bit (256 gråtoneniveauer) indeholdt i en enkelt byte. Hvis indlæsningen i BPX-felt 15.012 er højere eller lavere end 8, vil det antal bytes, der kræves til at indeholde en pixel, være forskelligt. Hvis der anvendes kompression, skal pixeldataene komprimeres i overensstemmelse med den kompressionsteknik, der er angivet i CGA-feltet.
 8.2. Afslutning af type-15-record: håndfladeaftryk med variabel opløsning
 Af hensyn til sammenhængen skal der umiddelbart efter den sidste databyte i felt 15.999 indsættes en "FS"-separator for at adskille den fra den næste logiske record. Denne separator skal indlæses i længdefeltet i type-15-recorden.
 8.3. Supplerende type-15-record: håndfladeaftryk med variabel opløsning
 Der kan indlæses yderligere


text:
type-15-records i denne fil. For hvert supplerende håndfladeaftryksbillede kræves en komplet type-15 logisk record sammen med en "FS"-separator.
 Tabel 11:
 Det maksimale antal personer, der accepteres med henblik på kontrol pr. overførsel
 Type of AFIS Search
 TP/TP
 LT/TP
 LP/PP
 TP/UL
 LT/UL
 PP/ULP
 LP/ULP
 Maximum Number of Candidates
 1
 10
 5
 5
 5
 5
 5
 Søgningstyper:
 TP/TP: ten-print against ten-print
 LT/TP: fingerprint latent against ten-print
 LP/PP: palmprint latent against palmprint
 TP/UL: ten-print against unsolved fingerprint latent
 LT/UL: fingerprint latent against unsolved fingerprint latent
 PP/ULP: palmprint against unsolved palmprint latent
 LP/ULP: palmprint latent against unsolved palmprint latent.
 9. Tillæg til kapitel 2 (Udveksling af fingeraftryksoplysninger)
 9.1. Tillæg 39-1: ASCII-separatorkoder
 ASCII
 Position (2)
 Description
 LF
 1/10
 Separates error codes in field 2.074
 FS
 1/12
 Separates logical records of a file
 GS
 1/13
 Separates fields of a logical record
 RS
 1/14
 Separates the subfields of a record field
 US
 1/15
 Separates individual information items of the field or subfield
 9.2. Tillæg 39-2: Beregning af alfanumeriske kontroltegn
 For TCN og TCR (Felt 1.09 og 1.10):
 Det tal, der svarer til kontroltegnet, findes ved at anvende følgende formel:
 (YY * 108 + SSSSSSSS) Modulo 23
 Hvor YY og SSSSSSSS er numeriske værdier for henholdsvis de sidste to cifre for året og serienummeret.
 Kontroltegnet findes herefter i opslagstabellen nedenfor.
 For CRO (Felt 2.010)
 Det tal, der svarer til kontroltegnet, findes ved at anvende følgende formel:
 (YY * 106 + NNNNNN) Modulo 23
 Hvor YY og NNNNNN er numeriske værdier for henholdsvis de to sidste cifre for året og serienummeret.
 Kontroltegnet findes herefter i opslagstabellen nedenfor.
 Opslagstabel for kontroltegn
 1-A
 9-J
 17-T
 2-B
 10-K
 18-U
 3-C
 11-L
 19-V
 4-D
 12-M
 20-W
 5-E
 13-N
 21-X
 6-F
 14-P
 22-Y
 7-G
 15-Q
 0-Z
 8-H
 16-R
 9.3. Tillæg 39-3: Tegnkoder
 7-bit ANSI-kode for informationsudveksling
 ASCII Character Set
 +
 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
 30
 !
 ’
 #
 $
 %
 &
 ‘
 40
 (
 )
 *
 +
 ,
 -
 .
 /
 0
 1
 50
 2
 3
 4
 5
 6
 7
 8
 9
 :
 ;
 60
 <
 =
 >
 ?
 @
 A
 B
 C
 D
 E
 70
 F
 G
 H
 I
 J
 K
 L
 M
 n
 O
 80
 P
 Q
 R
 S
 T
 U
 V
 W
 X
 Y
 90
 Z
 [
 \
 ]
 ^
 _
 `
 a
 b
 c
 100
 d
 e
 f
 g
 h
 i
 j
 k
 l
 m
 110
 n
 o
 p
 q
 r
 s
 t
 u
 v
 w
 120
 x
 y
 z
 {}{
 |
 }}
 ~
 9.4. Tillæg 39-4: Transaktionsresumé
 Type-1-record (obligatorisk)
 Identifier
 Field Number
 Field Name
 CPS/PMS
 SRE
 ERR
 LEN
 1.001
 Logical Record Length
 M
 M
 M
 VER
 1.002
 Version Number
 M
 M
 M
 CNT
 1.003
 File Content
 M
 M
 M
 TOT
 1.004
 Type of Transaction
 M
 M
 M
 DAT
 1.005
 Date
 M
 M
 M
 PRY
 1.006
 Priority
 M
 M
 M
 DAI
 1.007
 Destination Agency
 M
 M
 M
 ORI
 1.008
 Originating Agency
 M
 M
 M
 TCN
 1.009
 Transaction Control Number
 M
 M
 M
 TCR
 1.010
 Transaction Control Reference
 C
 M
 M
 NSR
 1.011
 Native Scanning


text:
Resolution
 M
 M
 M
 NTR
 1.012
 Nominal Transmitting Resolution
 M
 M
 M
 DOM
 1.013
 Domain name
 M
 M
 M
 GMT
 1.014
 Greenwich mean time
 M
 M
 M
 I kolonnen "Condition":
 O = Optional (fakultativ); M = Mandatory (obligatorisk); C = Conditional (betinget), hvis transaktionen er et svar til det anmodende agentur.
 Type-2-record (obligatorisk)
 Identifier
 Field Number
 Field Name
 CPS/PMS
 MPS/MMS
 SRE
 ERR
 LEN
 2.001
 Logical Record Length
 M
 M
 M
 M
 IDC
 2.002
 Image Designation Character
 M
 M
 M
 M
 SYS
 2.003
 System Information
 M
 M
 M
 M
 CNO
 2.007
 Case Number
 —
 M
 C
 —
 SQN
 2.008
 Sequence Number
 —
 C
 C
 —
 MID
 2.009
 Latent Identifier
 —
 C
 C
 —
 CRN
 2.010
 Criminal Reference Number
 M
 —
 C
 —
 MN1
 2.012
 Miscellaneous Identification Number
 —
 —
 C
 C
 MN2
 2.013
 Miscellaneous Identification Number
 —
 —
 C
 C
 MN3
 2.014
 Miscellaneous Identification Number
 —
 —
 C
 C
 MN4
 2.015
 Miscellaneous Identification Number
 —
 —
 C
 C
 INF
 2.063
 Additional Information
 O
 O
 O
 O
 RLS
 2.064
 Respondents List
 —
 —
 M
 —
 ERM
 2.074
 Status/Error Message Field
 —
 —
 —
 M
 ENC
 2.320
 Expected Number of Candidates
 M
 M
 —
 —
 I kolonnen "Condition":
 O = Optional (fakultativ); M = Mandatory (obligatorisk); C = Conditional (betinget), afhængigt af, om dataene er tilgængelige.
 *
 =
 Hvis transmissionen af dataene er i overensstemmelse med national lovgivning (der ikke er omfattet af artikel 533 og 534 i denne aftale).
 9.5. Tillæg 39-5: Definitioner i type-1-record
 Identifier
 Condition
 Field number
 Field name
 Character type
 Example data
 LEN
 M
 1.001
 Logical Record Length
 n
 1.001:230{}{GS}}
 VER
 M
 1.002
 Version Number
 n
 1.002:0300{}{GS}}
 CNT
 M
 1.003
 File Content
 n
 1.003:1{}{US}}15{}{RS}}2{}{US}}00{}{RS}}4{}{US}}01{}{RS}}4{}{US}}02{}{RS}}4{}{US}}03{}{RS}}4{}{US}}04{}{RS}}4{}{US}}05{}{RS}}4{}{US}}06{}{RS}}4{}{US}}07{}{RS}}4{}{US}}08{}{RS}}4{}{US}}09{}{RS}}4{}{US}}10{}{RS}}4{}{US}}11{}{RS}}4{}{US}}12{}{RS}}4{}{US}}13{}{RS}}4{}{US}}14{}{GS}}
 TOT
 M
 1.004
 Type of Transaction
 A
 1.004:CPS{}{GS}}
 DAT
 M
 1.005
 Date
 n
 1.005:20050101{}{GS}}
 PRY
 M
 1.006
 Priority
 n
 1.006:4{}{GS}}
 DAI
 M
 1.007
 Destination Agency
 1*
 1.007:DE/BKA{}{GS}}
 ORI
 M
 1.008
 Originating Agency
 1*
 1.008:NL/NAFIS{}{GS}}
 TCN
 M
 1.009
 Transaction Control Number
 AN
 1.009:0200000004F{}{GS}}
 TCR
 C
 1.010
 Transaction Control Reference
 AN
 1.010:0200000004F{}{GS}}
 NSR
 M
 1.011
 Native Scanning Resolution
 AN
 1.011:19.68{}{GS}}
 NTR
 M
 1.012
 Nominal Transmitting Resolution
 AN
 1.012:19,68{}{GS}}
 DOM
 M
 1.013
 Domain Name
 AN
 1013: INT-I{}{US}}4,22{}{GS}}
 GMT
 M
 1.014
 Greenwich Mean Time
 AN
 1.014:20050101125959Z
 I kolonnen "Condition": O = Optional (fakultativ), M = Mandatory (obligatorisk), C = Conditional (betinget).
 I kolonnen "Character Type" (tegntype): A = Alpha, N = Numeric, B = Binary.
 1* Tilladte tegn for agenturnavn er: ["0...9", "A...Z", "a...z", "_", ".", "" og "-"].
 9.6. Tillæg 39-6: Definitioner i type-2-record
 Tabel A.6.1:
 CPS- og PMS-transaktion
 Identifier
 Condition
 Field number
 Field name
 Character type
 Example data
 LEN
 M
 2.001
 Logical Record Length
 n
 2.001:909{}{GS}}
 IDC
 M
 2.002
 Image Designation Character
 n
 2.002:00{}{GS}}
 SYS
 M
 2.003
 System Information
 n
 2.003:0422{}{GS}}
 CRN
 M
 2.010
 Criminal Reference Number
 AN
 2.010:DE/E999999999{}{GS}}
 INF
 O
 2.063
 Additional Information
 1*
 2.063:Additional Information 123{}{GS}}
 ENC
 M
 2.320
 Expected Number of Candidates
 n
 2.320:1{}{GS}}
 Tabel A.6.2:
 SRE-transaktion
 Identifier
 Condition
 Field number
 Field name
 Character type
 Example data
 LEN
 M
 2.001
 Logical Record Length
 n
 2.001:909{}{GS}}
 IDC
 M
 2.002
 Image Designation Character
 n
 2.002:00{}{GS}}
 SYS


text:
M
 2.003
 System Information
 n
 2.003:0422{}{GS}}
 CRN
 C
 2.010
 Criminal Reference Number
 AN
 2.010:NL/2222222222{}{GS}}
 MN1
 C
 2.012
 Miscellaneous Identification Number
 AN
 2.012:E999999999{}{GS}}
 MN2
 C
 2.013
 Miscellaneous Identification Number
 AN
 2.013:E999999999{}{GS}}
 MN3
 C
 2.014
 Miscellaneous Identification Number
 n
 2.014:0001{}{GS}}
 MN4
 C
 2.015
 Miscellaneous Identification Number
 A
 2.015:A{}{GS}}
 INF
 O
 2.063
 Additional Information
 1*
 2.063:Additional Information 123{}{GS}}
 RLS
 M
 2.064
 Respondents List
 AN
 2.064:CPS{}{RS}}I{}{RS}}001/001{}{RS}}999999{}{GS}}
 Tabel A.6.3:
 ERR-transaktion
 Identifier
 Condition
 Field number
 Field name
 Character type
 Example data
 LEN
 M
 2.001
 Logical Record Length
 n
 2.001:909{}{GS}}
 IDC
 M
 2.002
 Image Designation Character
 n
 2.002:00{}{GS}}
 SYS
 M
 2.003
 System Information
 n
 2.003:0422{}{GS}}
 MN1
 M
 2.012
 Miscellaneous Identification Number
 AN
 2.012:E999999999{}{GS}}
 MN2
 C
 2.013
 Miscellaneous Identification Number
 AN
 2.013:E999999999{}{GS}}
 MN3
 C
 2.014
 Miscellaneous Identification Number
 n
 2.014:0001{}{GS}}
 MN4
 C
 2.015
 Miscellaneous Identification Number
 A
 2.015:A{}{GS}}
 INF
 O
 2.063
 Additional Information
 1*
 2.063:Additional Information 123{}{GS}}
 ERM
 M
 2.074
 Status/Error Message Field
 AN
 2074: 201: IDC - 1 FIELD 1.009 WRONG CONTROL CHARACTER {}{LF}} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION {}{GS}}
 Tabel A.6.4:
 MPS- og MMS-transaktion
 Identifier
 Condition
 Field number
 Field name
 Character type
 Example data
 LEN
 M
 2.001
 Logical Record Length
 n
 2.001:909{}{GS}}
 IDC
 M
 2.002
 Image Designation Character
 n
 2.002:00{}{GS}}
 SYS
 M
 2.003
 System Information
 n
 2.003:0422{}{GS}}
 CNO
 M
 2.007
 Case Number
 AN
 2.007:E999999999{}{GS}}
 SQN
 C
 2.008
 Sequence Number
 n
 2.008:0001{}{GS}}
 MID
 C
 2.009
 Latent Identifier
 A
 2.009:A{}{GS}}
 INF
 O
 2.063
 Additional Information
 1*
 2.063:Additional Information 123{}{GS}}
 ENC
 M
 2.320
 Expected Number of Candidates
 n
 2.320:1{}{GS}}
 I kolonnen "Condition": O = Optional (fakultativ), M = Mandatory (obligatorisk), C = Conditional (betinget).
 I kolonnen "Character Type" (tegntype): A = Alpha, N = Numeric, B = Binary.
 1* Tilladte tegn er: ["0..9", "A..Z", "a..z", "_",".", "", "-" og ","].
 9.7. Tillæg 39-7: Gråtonekompressionskoder
 Kompressionskoder
 Compression
 Value
 Remarks
 Wavelet Scalar Quantisation Greyscale Fingerprint Image Compression Specification
 IAFIS-IC-0010(V3), dated 19 December 1997
 WSQ
 Algorithm to be used for the compression of greyscale images in Type-4, Type-7 and Type-13 to Type-15 records. Shall not be used for resolutions > 500dpi.
 JPEG 2000
 [ISO 15444/ITU T.800]
 J2K
 To be used for lossy and losslessly compression of greyscale images in Type-13 to Type-15 records. Strongly recommended for resolutions > 500 dpi
 9.8. Tillæg 39-8: Mailspecifikation
 For at forbedre det interne workflow skal "mail subject" for en PRUEM-transaktion udfyldes med landekoden (CC) for den stat, der sender mailen og transaktionstypen (TOT-felt 1.004).
 Format: CC/type of transaction
 Eksempel: "DE/CPS"
 Mailens tekstfelt kan være tomt.
 KAPITEL 3
 UDVEKSLING AF OPLYSNINGER FRA KØRETØJSREGISTRE
 1. Fælles data med henblik på elektronisk søgning af oplysninger fra køretøjsregistre
 1.1. Definitioner
 Definitionerne af henholdsvis de obligatoriske og de fakultative dataelementer, jf. kapitel 0, artikel 14, stk. 4, er som følger:
 Obligatoriske (Mandatory (M)):
 Dataelementet skal meddeles, når oplysningerne er tilgængelige i en stats nationale register. Der er altså en forpligtelse til at udveksle oplysningerne, hvis de er tilgængelige.
 Fakultative (Optional (O)):
 Dataelementet kan meddeles, når oplysningerne er tilgængelige i en stats nationale register. Der er altså ingen forpligtelse til at udveksle oplysningerne, selv om de er tilgængelige.
 For


text:
hvert dataelement markeres det med "Y", hvis elementet udtrykkelig er udpeget som betydningsfuldt i henhold til artikel 537 i denne aftale.
 1.2. Søgen efter køretøj/ejer/bruger
 1.2.1. Søgeelementer
 Der findes to forskellige måder at søge de oplysninger, der er anført i det følgende afsnit:
 —
 via stelnummer (VIN), referencedato og -tidspunkt (fakultativt)
 —
 via registreringsnummer, stelnummer (VIN) (kan udelades), referencedato og -tidspunkt (fakultativt).
 Ved søgning ud fra disse kriterier fås oplysninger om et enkelt og i visse tilfælde flere køretøjer. Hvis der kun fås oplysninger om et enkelt køretøj, gives alle oplysningerne som et samlet svar. Hvis der findes mere end et køretøj, kan den anmodede stat selv bestemme, hvilke oplysninger der skal gives: alle oplysningerne eller kun oplysninger til indskrænkning af søgningen (f.eks. af hensyn til privatlivets fred eller af tekniske årsager).
 Afsnit 1.2.2.1 omhandler de oplysninger, der er nødvendige for at indskrænke søgningen. Afsnit 1.2.2.2 beskriver samtlige oplysninger.
 Hvis der søges via stelnummer samt referencedato og -tidspunkt, kan søgningen omfatte en eller alle de deltagende stater.
 Hvis der søges via registreringsnummer samt referencedato og -tidspunkt, skal søgningen omfatte en bestemt stat.
 Normalt søges der med gældende dato og tidspunkt, men det er muligt at foretage søgninger med referencedatoer og -tidspunkter i fortiden. Hvis der søges med en referencedato og et referencetidspunkt i fortiden, og der ikke foreligger historiske oplysninger i den pågældende stats register, fordi sådanne oplysninger slet ikke registreres, kan de gældende oplysninger fås med angivelse af, at det drejer sig om gældende oplysninger.
 1.2.2. Data
 1.2.2.1.
 Oplysninger, der er nødvendige for at indskrænke søgningen
 Item
 M/O (3)
 Remarks
 Prüm Y/N (4)
 Data relating to vehicles
 Licence number
 M
 Y
 Chassis number/VIN
 M
 Y
 Country of registration
 M
 Y
 Make
 M
 (D.1 (5)) e.g. Ford, Opel, Renault, etc.
 Y
 Commercial type of the vehicle
 M
 (D.3) e.g. Focus, Astra, Megane
 Y
 EU Category Code
 M
 (J) mopeds, motorbikes, cars, etc.
 Y
 1.2.2.2.
 Komplette datasæt
 Item
 M/O (6)
 Remarks
 Prüm Y/N
 Data relating to holders of the vehicle
 (C.1 (7)) The data refer to the holder of the specific registration certificate.
 Registration holders' (company) name
 M
 (C.1.1.)
 separate fields will be used for surname, infixes, titles, etc., and the name in printable format will be communicated
 Y
 First name
 M
 (C.1.2)
 separate fields for first name(s) and initials will be used, and the name in printable format will be communicated
 Y
 Address
 M
 (C.1.3)
 separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence, etc., and the Address in printable format will be communicated
 Y
 Gender
 M
 Male, female
 Y
 Date of birth
 M
 Y
 Legal entity
 M
 individual, association, company, firm, etc.
 Y
 Place of Birth
 O
 Y
 ID Number
 O
 An identifier that uniquely identifies the person or the company.
 n
 Type of ID Number
 O
 The type of ID Number (e.g. passport number).
 n
 Start date holdership
 O
 Start date of the holdership of the car. This date will often be the same as printed under (I)


text:
on the registration certificate of the vehicle.
 n
 End date holdership
 O
 End data of the holdership of the car.
 n
 Type of holder
 O
 If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate:
 —
 is the vehicle owner,
 —
 is not the vehicle owner,
 —
 is not identified by the registration certificate as being the vehicle owner.
 n
 Data relating to owners of the vehicle
 (C.2)
 Owners' (company) name
 M
 (C.2.1)
 Y
 First name
 M
 (C.2.2)
 Y
 Address
 M
 (C.2.3)
 Y
 Gender
 M
 male, female
 Y
 Date of birth
 M
 Y
 Legal entity
 M
 individual, association, company, firm, etc.
 Y
 Place of Birth
 O
 Y
 ID Number
 O
 An identifier that uniquely identifies the person or the company.
 n
 Type of ID Number
 O
 The type of ID Number (e.g. passport number).
 n
 Start date ownership
 O
 Start date of the ownership of the car.
 n
 End date ownership
 O
 End data of the ownership of the car.
 n
 Data relating to vehicles
 Licence number
 M
 Y
 Chassis number/VIN
 M
 Y
 Country of registration
 M
 Y
 Make
 M
 (D.1) e.g. Ford, Opel, Renault, etc.
 Y
 Commercial type of the vehicle
 M
 (D.3) e.g. Focus, Astra, Megane.
 Y
 Nature of the vehicle/EU Category Code
 M
 (J) mopeds, motorbikes, cars, etc.
 Y
 Date of first registration
 M
 (B) Date of first registration of the vehicle somewhere in the world.
 Y
 Start date (actual) registration
 M
 (I) Date of the registration to which the specific certificate of the vehicle refers.
 Y
 End date registration
 M
 End data of the registration to which the specific certificate of the vehicle refers. It is possible this date indicates the period of validity as printed on the document if not unlimited (document abbreviation = H).
 Y
 Status
 M
 Scrapped, stolen, exported, etc.
 Y
 Start date status
 M
 Y
 End date status
 O
 n
 kW
 O
 (P.2)
 Y
 Capacity
 O
 (P.1)
 Y
 Type of licence number
 O
 Regular, transito, etc.
 Y
 Vehicle document id 1
 O
 The first unique document ID as printed on the vehicle document.
 Y
 Vehicle document id 2 (8)
 O
 A second document ID as printed on the vehicle document.
 Y
 Data relating to insurances
 Insurance company name
 O
 Y
 Begin date insurance
 O
 Y
 End date insurance
 O
 Y
 Address
 O
 Y
 Insurance number
 O
 Y
 ID number
 O
 An identifier that uniquely identifies the company.
 n
 Type of ID number
 O
 The type of ID number (e.g. number of the Chamber of Commerce)
 n
 2. Datasikkerhed
 2.1. Oversigt
 Eucarissoftwareprogrammet sørger for sikker kommunikation med de øvrige stater og kommunikerer til staternes back-end legacysystemer via XML. Staterne udveksler meddelelser ved at sende dem direkte til modtageren. Den enkelte stats datacenter er forbundet med TESTA-nettet.
 XML-meddelelser, der sendes over nettet, er krypteret. Teknikken til kryptering af disse meddelelser er SSL. De meddelelser, der sendes til back-end, er XML-meddelelser med almindelig tekst, eftersom forbindelsen mellem programmet og back-end etableres i et beskyttet


text:
miljø.
 Der stilles et klientprogram til rådighed, som kan bruges inden for en stat til søgning i eget register eller andre staters registre. Klienterne identificeres ved hjælp af et bruger-id/en adgangskode eller et brugercertifikat. Forbindelsen til en bruger kan være krypteret, men dette har den enkelte stat ansvaret for.
 2.2. Sikkerhedsfeatures i forbindelse med udveksling af meddelelser
 Sikkerhedssystemet er udformet som en kombination af HTTPS og XML-signatur. Dette alternativ benytter en XML-signatur til at underskrive alle meddelelser, der sendes til serveren, og kan autentificere afsenderen ved kontrol af signaturen. Ensidig SSL (kun servercertifikat) bruges til at beskytte meddelelsens fortrolighed og integritet under overførslen og beskytter mod sletnings-/replay- og indsætningsangreb. I stedet for skræddersyet softwareudvikling til implementering af tosidet SSL implementeres en XML-signatur. Brug af XML-signatur svarer bedre til køreplanen for webtjenester end tosidet SSL og er derfor mere strategisk.
 XML-signaturen kan implementeres på flere måder, men den valgte tilgang er at anvende XML-signaturen som del af Web Services Security (WSS). WSS specificerer, hvordan XML-signaturen skal anvendes. Da WSS bygger på SOAP-standarden, er det logisk så vidt muligt at overholde denne standard.
 2.3. Sikkerhedsfeatures uden forbindelse med udveksling af meddelelser
 2.3.1. Brugerautentificering
 Brugerne af Eucariswebprogrammet autentificerer sig ved hjælp af et brugernavn og en adgangskode. Da der anvendes standard-Windows-autentificering, kan staterne om nødvendigt etablere et højere niveau af brugerautentificering ved at anvende brugercertifikater.
 2.3.2. Brugerroller
 Eucarissoftwareprogrammet giver mulighed for forskellige brugerroller. Hver gruppe af tjenester kræver en speciel autorisation. F.eks. kan brugere, der (udelukkende) anvender "Eucaristraktat"-funktionen, ikke anvende "Prüm"-funktionen. Administratortjenester er adskilt fra de almindelige slutbrugerroller.
 2.3.3. Logføring og sporing af udveksling af meddelelser
 Eucarissoftwareprogrammet gør det nemt at logføre alle typer meddelelser. En administratorfunktion giver den nationale administrator mulighed for at afgøre, hvilke meddelelser der skal logføres: anmodninger fra slutbrugere, indkommende anmodninger fra andre stater, oplysninger, der er meddelt fra de nationale registre osv.
 Programmet kan konfigureres til at anvende enten en intern database til denne logføring eller en ekstern (Oracle) database. Beslutningen om, hvilke meddelelser der skal logføres, afhænger naturligvis af logfaciliteterne andre steder i legacysystemerne og de dermed forbundne brugerprogrammer.
 Den enkelte meddelelses teksthoved indeholder oplysninger om den anmodende stat, den anmodende organisation i den pågældende stat og den berørte bruger. Årsagen til anmodningen er også anført.
 Ved at sammenholde logføringen i de stater, der henholdsvis anmoder og besvarer anmodningen, er det muligt fuldt ud at spore alle udvekslinger af meddelelser (f.eks. efter anmodning fra en berørt borger).
 Logføringen konfigureres ved hjælp af Eucaris web client (menu Administration, Logging configuration). Logføringsfunktionen udføres af det centrale system (Core System). Når logføring er aktiveret, lagres hele meddelelsen (teksthovedet og selve teksten) i en enkelt logpost. Logføringsniveauet kan indstilles i forhold til de definerede tjenester og de meddelelsestyper, der går gennem det centrale system.
 Logføringsniveauer
 Følgende logføringsniveauer er mulige:
 Privat — meddelelsen logføres: Logføringen er IKKE tilgængelig for udtræk fra logføringstjenesten, men er kun tilgængelig på nationalt niveau med henblik på audit og problemløsning.
 Intet — meddelelsen logføres slet ikke.
 Meddelelsestyper
 Udvekslingen af oplysninger mellem staterne omfatter flere forskellige meddelelser; i


text:
nedenstående figur 5 findes en skematisk fremstilling af disse.
 De mulige meddelelsestyper (i figur 5 vist for Eucariscentralsystemet i stat X) er som følger:
 1.
 Request to Core System_Request message by Client
 2.
 Request to Other State_Request message by Core System of this State
 3.
 Request to Core System of this State_Request message by Core System of other State
 4.
 Request to Legacy Register_Request message by Core System
 5.
 Request to Core System_Request message by Legacy Register
 6.
 Response from Core System_Request message by Client
 7.
 Request to Other State_Request message by Core System of this State
 8.
 Response from Core System of this State_Request message by other State
 9.
 Response from Legacy Register_Request message by Core System
 10.
 Response from Core System_Request message by Legacy Register.
 Følgende udvekslinger af oplysninger vises i figur 5:
 —
 Anmodning om oplysninger fra stat X til stat Y — blå pile. Denne anmodning og besvarelse omfatter henholdsvis meddelelsestype 1, 2, 7 og 6.
 —
 Anmodning om oplysninger fra stat Z til stat X — røde pile. Denne anmodning og besvarelse omfatter henholdsvis meddelelsestype 3, 4, 9 og 8.
 —
 Anmodning om oplysninger fra legacyregistret til eget centralsystem (heri kan også indgå en anmodning fra en specielt udviklet klient længere tilbage end legacyregistret) — grønne pile. Denne type anmodning omfatter meddelelsestype 5 og 10.
 2.3.4. Hardwaresikkerhedsmodul
 Der anvendes ikke et hardwaresikkerhedsmodul.
 Et hardwaresikkerhedsmodul (HSM) giver god beskyttelse af den nøgle, der bruges til at signere meddelelser og identificere servere. Dette øger det samlede sikkerhedsniveau, men et HSM er dyrt at købe/vedligeholde, og der er ingen krav om at anskaffe et FIPS 140-2 niveau 2 eller niveau 3 HSM. Eftersom der anvendes et lukket net, der effektivt begrænser trusler, har man som udgangspunkt besluttet ikke at anvende et HSM. Hvis et HSM er nødvendigt, f.eks. for at opnå akkreditering, kan det tilføjes til systemarkitekturen.
 3. De tekniske betingelser for dataudvekslingen
 3.1. Generel beskrivelse af Eucarisprogrammet
 3.1.1. Oversigt
 Eucarisprogrammet forbinder alle de deltagende stater i et fuldmasket net, hvor hver stat kommunikerer direkte med en anden stat. Der er ikke behov for en central komponent for at etablere kommunikationen. Eucarisprogrammet sørger for sikker kommunikation med de øvrige stater og kommunikerer til staternes back-end legacysystemer via XML. Nedenstående tegning anskueliggør denne konstruktion.
 Staterne udveksler meddelelser ved at sende dem direkte til modtageren. Den enkelte stats datacenter er forbundet med det net, der anvendes til udveksling af meddelelser (TESTA). For at få adgang til TESTA-nettet, kobler staterne sig på TESTA via deres nationale adgangsportal. Der skal anvendes en firewall ved opkobling til nettet, og en router forbinder Eucarisprogrammet med firewallen. Afhængigt af hvilken form for beskyttelse af meddelelserne man har valgt, udstedes et certifikat enten af routeren eller af Eucarisprogrammet.
 Der stilles et klientprogram til rådighed, som kan bruges inden for en stat til søgning i eget register eller andre staters registre. Klientprogrammet kobles til Eucaris. Klienterne identificeres ved hjælp af et bruger-id/en adgangskode eller et brugercertifikat. Forbindelsen til en bruger i en ekstern organisation (f.eks. politiet) kan


text:
være krypteret, men dette har den enkelte stat ansvaret for.
 3.1.2. Systemets anvendelsesområde
 Eucarissystemets anvendelsesområde er begrænset til de processer, der indgår i udveksling af oplysninger mellem staternes registreringsmyndigheder og en simpel præsentation af disse oplysninger. Procedurer og elektroniske processer, hvor disse oplysninger skal anvendes, falder uden for systemets anvendelsesområde.
 Staterne kan vælge enten at anvende Eucarisklientfunktionen eller at udarbejde deres eget specielt udviklede klientprogram. I nedenstående skema gøres der rede for, hvilke aspekter af Eucarissystemet der er obligatoriske og/eller anbefales, og hvilke der er fakultative og/eller frit kan fastsættes af staterne.
 Eucaris aspects
 M/O (9)
 Remark
 Network concept
 M
 The concept is an "any-to-any" communication
 Physical network
 M
 TESTA
 Core application
 M
 The core application of Eucaris has to be used to connect to the other States. The following functionality is offered by the core:
 —
 Encrypting and signing of the messages;
 —
 Checking of the identity of the sender;
 —
 Authorisation of States and local users;
 —
 Routing of messages;
 —
 Queuing of asynchronous messages if the recipient service is temporally unavailable;
 —
 Multiple country inquiry functionality;
 —
 Logging of the exchange of messages;
 —
 Storage of incoming messages
 Client application
 O
 In addition to the core application the Eucaris II client application can be used by a State. When applicable, the core and client application are modified under auspices of the Eucaris organisation.
 Security concept
 M
 The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates.
 Message specifications
 M
 Every State has to comply with the message specifications as set by the Eucaris organisation and this Chapter. The specifications can only be changed by the Eucaris organisation in consultation with the States.
 Operation and Support
 M
 The acceptance of new States or a new functionality is under auspices of the Eucaris organisation. Monitoring and help desk functions are managed centrally by an appointed State.
 3.2. Funktionelle og ikkefunktionelle krav
 3.2.1. Generiske funktioner
 I denne sektion er de vigtigste generiske funktioner beskrevet i generelle vendinger.
 Nr.
 Beskrivelse
 1.
 Systemet giver staternes registreringsmyndigheder mulighed for interaktivt at udveksle meddelelser med anmodninger og besvarelser.
 2.
 Systemet omfatter et klientprogram, der giver slutbrugerne mulighed for at sende anmodninger, og som viser svaroplysningerne med henblik på manuel behandling.
 3.
 Systemet giver mulighed for "brede" henvendelser, så en stat kan sende en anmodning til alle de øvrige stater. De indkommende besvarelser konsolideres af det centrale program til en enkelt svarmeddelelse til klientprogrammet (denne funktionalitet kaldes en "Multiple Country Inquiry").
 4.
 Systemet kan håndtere forskellige typer meddelelser. Brugerroller, autorisation, routing, signering og logføring er defineret for hver specifik tjeneste.
 5.
 Systemet giver staterne mulighed for at udveksle bundter af meddelelser eller meddelelser, der indeholder et stort antal anmodninger eller besvarelser. Disse meddelelser behandles asynkront.
 6.
 Systemet sætter asynkrone meddelelser i kø, hvis modtagerstaten midlertidigt ikke kan kontaktes, og garanterer levering, så snart modtageren er tilgængelig igen.
 7.
 Systemet lagrer indkommende asynkrone meddelelser, indtil de kan behandles.
 8.
 Systemet giver kun adgang til de øvrige staters Eucarisprogrammer,


text:
ikke til individuelle organisationer i disse stater, dvs. den enkelte registreringsmyndighed fungerer som eneste gateway mellem egne nationale slutbrugere og de tilsvarende myndigheder i de øvrige stater.
 9.
 Det er muligt på en Eucarisserver at definere brugere fra forskellige stater og give dem autorisation i henhold til den pågældende stats rettigheder.
 10.
 Oplysninger om den anmodende stat, organisation og slutbruger er indeholdt i meddelelserne.
 11.
 Systemet giver mulighed for logføring af udveksling af meddelelser mellem de forskellige stater og mellem det centrale program og de nationale registreringssystemer.
 12.
 Systemet giver en særlig sekretær, som er en organisation eller en stat, der udtrykkelig er udpeget til denne opgave, mulighed for at indsamle oplysninger om meddelelser, der er afsendt/modtaget af alle de deltagende stater, med henblik på udarbejdelse af statistiske opgørelser.
 13.
 Hver enkelt stat anfører selv, hvilke logførte oplysninger der er stillet til rådighed for sekretæren, og hvilke oplysninger der er "private".
 14.
 Systemet tillader den enkelte stats nationale administratorer at uddrage statistikker om brugen.
 15.
 Systemet muliggør tilføjelse af nye stater ved hjælp af enkle administrative procedurer.
 3.2.2. Anvendelighed
 Nr.
 Beskrivelse
 16.
 Systemet tilbyder en grænseflade (interface) for elektronisk behandling af meddelelser udført af back-end-systemer/legacy og giver mulighed for, at brugergrænsefladen integreres i disse systemer (specielt udviklet brugergrænseflade).
 17.
 Systemet er nemt at lære, selvforklarende og indeholder hjælpetekst.
 18.
 Systemet indeholder dokumentation, der kan bistå staterne med integrering, operative aktiviteter og fremtidig vedligeholdelse (f.eks. referencevejledninger, dokumentation vedrørende funktionsmåde/teknisk dokumentation, brugervejledning mv.).
 19.
 Brugergrænsefladen er flersproget og giver slutbrugeren mulighed for at vælge et foretrukket sprog.
 20.
 Brugergrænsefladen har faciliteter, så en lokal administrator kan oversætte både skærmtekst og kodede oplysninger til det nationale sprog.
 3.2.3. Driftssikkerhed
 Nr.
 Beskrivelse
 21.
 Systemet er udformet som et robust og pålideligt operativt system, der er modstandsdygtigt over for operatørfejl og kan genetableres fuldt ud efter strømafbrydelser eller andre uheld. Det skal være muligt at genstarte systemet uden datatab eller med minimale datatab.
 22.
 Systemet skal give stabile og reproducerbare resultater.
 23.
 Systemet er udformet til at fungere stabilt. Det er muligt at implementere systemet i en konfiguration, der garanterer 98 % tilgængelighed (ved hjælp af redundans, brug af backup-servere osv.) ved enhver bilateral kommunikation.
 24.
 Det er muligt at bruge en del af systemet, selv om visse komponenter ikke fungerer (hvis stat C har nedbrud, kan stat A og B stadig kommunikere). Antallet af lokale fejl "single points of failure" i informationskæden bør holdes på et minimum.
 25.
 Genetableringstiden efter et alvorligt nedbrud bør være mindre end en dag. Det bør være muligt at minimere nedbrudsperioden ved hjælp af fjernsupport, f.eks. via en central servicetjeneste.
 3.2.4. Ydeevne
 Nr.
 Beskrivelse
 26.
 Systemet kan anvendes døgnet rundt alle ugens dage (24×7). Det forudsættes dermed også, at staternes legacysystemer er tilgængelige 24×7.
 27.
 Systemet reagerer hurtigt på anmodninger fra brugere uanset eventuelle baggrundsopgaver. Dette kræves også af parternes legacysystemer, så der sikres en acceptabel svartid. En samlet svartid på højst 10 sekunder for en enkelt anmodning er acceptabel.
 28.
 Systemet er udformet som et flerbrugersystem og på


text:
en sådan måde, at baggrundsopgaver fortsat kan udføres, mens brugeren udfører opgaver "i forgrunden".
 29.
 Systemet er udformet med henblik på løbende udvidelse, så det kan understøtte en potentiel forøgelse af antallet af meddelelser, når der tilføjes nye funktioner eller nye organisationer eller stater kommer til.
 3.2.5. Sikkerhed
 Nr.
 Beskrivelse
 30.
 Systemet er egnet (f.eks. hvad angår sikkerhedsforanstaltninger) til udveksling af meddelelser med følsomme oplysninger af personlig karakter (f.eks. vedrørende ejere/brugere af køretøjer), der klassificeres som "EU Restricted".
 31.
 Systemet vedligeholdes på en sådan måde, at uautoriseret adgang til data hindres.
 32.
 Systemet indeholder en tjeneste, der behandler nationale slutbrugeres rettigheder og tilladelser.
 33.
 Staterne kan kontrollere afsenderens identitet (på statsniveau) ved hjælp af en XML-signatur.
 34.
 Staterne skal udtrykkelig give andre stater autorisation til at anmode om bestemte oplysninger.
 35.
 På programniveau omfatter systemet en komplet sikkerheds- og krypteringspolitik, der er i overensstemmelse med det sikkerhedsniveau, der kræves i sådanne tilfælde. Brug af XML-signatur og kryptering ved hjælp af SSL-tunneling sikrer, at oplysningerne ikke kommer ud, og garanterer deres integritet.
 36.
 Al udveksling af meddelelser kan spores ved hjælp af logføring.
 37.
 Der er beskyttelse mod sletningsangreb (en tredjepart sletter en meddelelse) og replay- eller indsætningsangreb (en tredjepart gensender eller indsætter en meddelelse).
 38.
 Systemet benytter certifikater fra en betroet tredjepart (TTP).
 39.
 Systemet kan håndtere forskellige certifikater for den enkelte stat, afhængig af meddelelsens eller tjenestens art.
 40.
 Sikkerhedsforanstaltningerne på programniveau er tilstrækkelige til at tillade brug af ikkeakkrediterede net.
 41.
 Systemet kan anvende ukomplicerede sikkerhedsteknikker såsom en XML-firewall.
 3.2.6. Fleksibilitet
 Nr.
 Beskrivelse
 42.
 Systemet kan udbygges med nye meddelelser og nye funktioner. Tilpasningsomkostningerne er meget lave. Dette skyldes den centraliserede udvikling af programkomponenter.
 43.
 Staterne kan definere nye meddelelsestyper til bilateral brug. Det er ikke nødvendigt, at alle stater understøtter alle meddelelsestyper.
 3.2.7. Support og vedligeholdelse
 Nr.
 Beskrivelse
 44.
 Systemet omfatter overvågningsfaciliteter til brug for en central servicetjeneste og/eller centrale operatører for så vidt angår nettet og serverne i de forskellige stater.
 45.
 Systemet omfatter faciliteter til fjernsupport fra en central servicetjeneste.
 46.
 Systemet omfatter faciliteter til problemanalyse.
 47.
 Systemet kan udbygges til nye stater.
 48.
 Programmet kan nemt installeres af personale med et minimum af færdigheder og erfaring inden for edb. Installationsproceduren skal automatiseres i størst muligt omfang.
 49.
 Systemet omfatter et miljø til brug for løbende testning og godkendelse.
 50.
 De årlige omkostninger til vedligeholdelse og support er reduceret mest muligt gennem overholdelse af markedsstandarderne og ved udformning af programmet, så der kræves mindst mulig support fra en central servicetjeneste.
 3.2.8. Krav til udformningen
 Nr.
 Beskrivelse
 51.
 Systemet er udformet og forsynet med dokumentation med henblik på en lang driftslevetid.
 52.
 Systemet er udformet, så det er uafhængigt af netværksudbyderen.
 53.
 Systemet er foreneligt med staternes nuværende hardware/software, idet det arbejder sammen med de registreringssystemer, der anvender åben standard-webtjenesteteknologi (XML, XSD, SOAP, WSDL, HTTP(s), Web services, WSS, X.509 osv.).
 3.2.9. Standarder, der anvendes
 Nr.
 Beskrivelse
 54.
 Systemet er foreneligt med databeskyttelsesreglerne i forordning (EF) nr. 45/2001 (artikel 21, 22 og 23) og direktiv 95/46/EF.
 55.


text:
Systemet er foreneligt med IDA-standarderne.
 56.
 Systemet understøtter UTF-8.
 KAPITEL 4
 EVALUERINGSPROCEDURE I HENHOLD TIL Artikel 540
 Artikel 1
 Spørgeskema
 1. Den relevante arbejdsgruppe i Rådet for Den Europæiske Union ("arbejdsgruppe i Rådet") udarbejder et spørgeskema vedrørende hver af de elektroniske dataudvekslinger, der er fastlagt i artikel 527-539 i denne aftale.
 2. Så snart Det Forenede Kongerige mener, at det opfylder forudsætningerne for dataudveksling i den relevante datakategori, besvarer det det relevante spørgeskema.
 Artikel 2
 Forsøgsfase
 1. Hvis det er påkrævet og med henblik på at evaluere resultaterne af spørgeskemaet, gennemfører Det Forenede Kongerige en forsøgsfase med en eller flere andre medlemsstater, der allerede udveksler data, jf. Rådets afgørelse 2008/615/RIA. Forsøgsfasen finder sted umiddelbart før eller efter evalueringsbesøget.
 2. Vilkårene for og de nærmere bestemmelser om denne forsøgsfase identificeres af den relevante arbejdsgruppe i Rådet og baseres på forudgående aftale med Det Forenede Kongerige. De praktiske detaljer fastlægges af de stater, der deltager i forsøgsfasen.
 Artikel 3
 Evalueringsbesøg
 1. Med henblik på evaluering af resultaterne af spørgeskemaet gennemføres der et evalueringsbesøg.
 2. Vilkårene for og de nærmere bestemmelser om besøget identificeres af den relevante arbejdsgruppe i Rådet og baseres på forudgående aftale mellem Det Forenede Kongerige og evalueringsgruppen. Det Forenede Kongerige giver evalueringsgruppen mulighed for at kontrollere den elektroniske dataudveksling i den eller de datakategorier, der skal evalueres, navnlig ved at tilrettelægge et program for besøget, som tager hensyn til evalueringsgruppens ønsker.
 3. Inden for en måned efter besøget fremlægger evalueringsgruppen en rapport om evalueringsbesøget, som den sender til Det Forenede Kongerige med henblik på bemærkninger. Gruppen kan i givet fald revidere denne rapport på baggrund af Det Forenede Kongeriges bemærkninger.
 4. Evalueringsgruppen består af højst tre eksperter, som udpeges af de medlemsstater, der deltager i den elektroniske dataudveksling i de datakategorier, der skal evalueres, og som har erfaringer med hensyn til den pågældende datakategori, relevant national sikkerhedsgodkendelse til at behandle disse spørgsmål og er rede til at deltage i mindst ét evalueringsbesøg i en anden stat. Evalueringsgruppen omfatter også en repræsentant for Kommissionen.
 5. Medlemmerne af evalueringsgruppen respekterer den fortrolige karakter af de oplysninger, de kommer i besiddelse af, når de varetager deres opgave.
 Artikel 4
 Evalueringer foretaget i henhold til Rådets afgørelse 2008/615/RIA og 2008/616/RIA
 Ved gennemførelsen af den evalueringsprocedure, der er omhandlet i artikel 540 i denne aftale og i dette kapitel, tager Rådet gennem den relevante arbejdsgruppe i Rådet hensyn til resultaterne af de evalueringsprocedurer, der er gennemført i forbindelse med vedtagelsen af Rådets gennemførelsesafgørelse (EU) 2019/968 (10) og (EU) 2020/1188 (11). Den relevante arbejdsgruppe i Rådet træffer afgørelse om, hvorvidt det er nødvendigt at gennemføre den forsøgsfase, der er omhandlet i denne aftales artikel 540, stk. 1, i dette bilags kapitel 0, artikel 23, stk. 2, og i dette kapitels artikel 2.
 Artikel 5
 Rapport til Rådet
 Rådet forelægges en samlet evalueringsrapport, som opsummerer resultaterne af spørgeskemaerne, evalueringsbesøget og, hvis det er relevant, forsøgsfasen, med henblik på Rådets afgørelse i henhold til artikel 540 i denne aftale.
 (1) "Fulde udpegede" betyder, at behandlingen af sjældne


text:
allelværdier er medtaget.
 (2) Dette er positionen som defineret i ASCII-standarden.
 (3) M = obligatoriske, når de findes i et nationalt register, O = fakultative.
 (4) Alle de elementer, der specifikt er tildelt af staterne, er angivet med Y.
 (5) Harmoniseret dokumentforkortelse, jf. Rådets direktiv 1999/37/EF af 29. april 1999.
 (6) M = obligatoriske, når de findes i et nationalt register, O = fakultative.
 (7) Harmoniseret dokumentforkortelse, jf. Rådets direktiv 1999/37/EF af 29. april 1999.
 (8) I Luxembourg anvendes to særskilte køretøjsregistreringsdokument-ID'er.
 (9) M = obligatorisk at anvende eller at overholde; O = fakultativ at anvende eller at overholde.
 (10) Rådets gennemførelsesafgørelse (EU) 2019/968 af 6. juni 2019 om elektronisk udveksling med Det Forenede Kongerige af DNA-oplysninger (EUT L 156 af 13.6.2019, s. 8).
 (11) Rådets gennemførelsesafgørelse (EU) 2020/1188 af 6. august 2020 om Det Forenede Kongeriges elektroniske udveksling af fingeraftryksdata (EUT L 265 af 12.8.2020, s. 1).
 BILAG 40
 PASSAGERLISTEOPLYSNINGER
 Passagerlisteoplysninger (indsamlet af luftfartsselskaber):
 1.
 PNR-nummer
 2.
 Dato for reservation/udstedelse af billet
 3.
 Planlagt(e) rejsedato(er)
 4.
 Navn(e)
 5.
 Adresse, telefonnummer og elektroniske kontaktoplysninger på passageren, de personer, der har foretaget flyreservationen for passageren, personer, der kan kontaktes for at kontakte en flypassager, og personer, der skal underrettes i tilfælde af en nødsituation
 6.
 Alle disponible oplysninger om betaling/fakturering (herunder oplysninger, der udelukkende vedrører betalingsmetoder for og fakturering af flybilletten, og som ikke indeholder andre oplysninger, der ikke direkte vedrører flyvningen)
 7.
 Fuldstændig rejseplan for en konkret passagerliste
 8.
 Oplysninger om bonusprogrammer (designatorkoden for det luftfartsselskab/den sælger, der forvalter programmet, den rejsendes bonusprogramnummer, medlemsniveau, niveaubeskrivelse og alliancekode)
 9.
 Rejsebureau/rejseagent
 10.
 Rejsestatus for passagerer, herunder bekræftelser, indtjekningsstatus, oplysninger om "no-show" og "go-show"
 11.
 Opsplittede/opdelte PNR-oplysninger
 12.
 OSI-oplysninger (Other Supplementary Information), SSI-oplysninger (Special Service Information) og SSR-oplysninger (Special Service Request)
 13.
 Oplysninger i billetrubrikken, herunder billetnummer, dato for udstedelse af billetten og enkeltbilletter, automatisk billetprisangivelse ("automated ticket fare quote")
 14.
 Pladsoplysninger, herunder pladsnummer
 15.
 Oplysninger om fælles rutenummer ("code sharing")
 16.
 Alle bagageoplysninger
 17.
 Andre passagerers navne på passagerlisten og antal passagerer på passagerlisten, der rejser sammen
 18.
 Eventuelt indsamlede forhåndsoplysninger om passagerer (API-oplysninger) (typen, nummeret, udstedelseslandet og udløbsdatoen for ethvert identitetsdokument, nationalitet, efternavn, fornavn, køn, fødselsdato, luftfartsselskab, rutenummer, afgangsdato, ankomstdato, afgangslufthavn, ankomstlufthavn, afgangstidspunkt og ankomsttidspunkt)
 19.
 Alle historiske ændringer til passagerlisten anført i punkt 1-18.
 BILAG 41
 FORMER FOR KRIMINALITET, DER HENHØRER UNDER EUROPOLS KOMPETENCE
 —
 Terrorisme
 —
 Organiseret kriminalitet
 —
 Narkotikahandel
 —
 Hvidvaskning af penge
 —
 Kriminalitet i forbindelse med nukleare og radioaktive materialer
 —
 Smugling af immigranter
 —
 Menneskehandel
 —
 Kriminalitet i forbindelse med motorkøretøjer
 —
 Manddrab og grov legemsbeskadigelse
 —
 Ulovlig handel med menneskeorganer og -væv
 —
 Bortførelse, frihedsberøvelse og gidseltagning
 —
 Racisme og fremmedhad
 —
 Røveri og tyveri af særlig grov beskaffenhed
 —
 Ulovlig handel med kulturgoder, herunder antikviteter og kunstgenstande
 —
 Underslæb og bedrageri
 —
 Kriminalitet, der skader Unionens finansielle interesser
 —
 Insiderhandel og kursmanipulation på finansmarkederne
 —
 Afkrævning af beskyttelsespenge og pengeafpresning
 —
 Efterligninger og fremstilling af piratudgaver af produkter
 —
 Forfalskning af officielle dokumenter og ulovlig handel med disse
 —
 Falskmøntneri, forfalskning af betalingsmidler