text:
Record
 Denne record benyttes til udveksling af latente fingeraftryksbilleder og latente
 håndfladeaftryksbilleder med variabel opløsning ledsaget af alfanumeriske teksturoplysninger.
 Billederne skannes med en opløsning på 500 DPI og med 256 gråtoner. Hvis det latente billedes
 kvalitet er tilstrækkelig god, komprimeres det efter WSQ-algoritmen. Om nødvendigt kan
 billedopløsningen øges til mere end 500 DPI og mere end 256 gråtoner efter fælles aftale. I så
 tilfælde anbefales det kraftigt at benytte JPEG 2000 (jf. tillæg 7).
 1.6. Variable-Resolution Palmprint Image Record
 Type-15-billedrecords med mærkede felter benyttes til udveksling af håndfladeaftryksbilleder med
 variabel opløsning sammen med alfanumeriske teksturoplysninger. Billederne skannes med en
 986
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 opløsning på 500 DPI og med 256 gråtoner. For at begrænse datamængden bør alle
 håndfladeaftryksbilleder komprimeres efter WSQ-algoritmen. Om nødvendigt kan billedopløsningen
 øges til mere end 500 DPI og mere end 256 gråtoner efter fælles aftale. I så tilfælde anbefales det
 kraftigt at benytte JPEG 2000 (jf. tillæg 7).
 2. Record-formatet
 En transaktionsfil består af en eller flere logiske records. For hver logisk record, som filen indeholder,
 skal der være en række informationsfelter, der passer til den pågældende recordtype. Hvert af
 informationsfelterne kan indeholde et eller flere grundlæggende informationselementer, der hver
 især består af en enkelt værdi. Tilsammen benyttes disse elementer til at angive forskellige aspekter
 af oplysningerne i feltet. Et informationsfelt kan også bestå af et eller flere informationselementer,
 der grupperes og gentages flere gange i et felt. En sådan gruppe af informationselementer kaldes et
 subfelt. Et informationsfelt kan således bestå af et eller flere subfelter med informationselementer.
 2.1. Information separators
 I de logiske records med mærkede felter er der indsat mekanismer til adskillelse af oplysningerne,
 som benytter fire ASCII-informationsseparatorer. De adskilte oplysninger kan være elementer i et
 felt eller subfelt, felter inden for en logisk record eller subfelter, der forekommer flere gange. De
 benyttede informationsseparatorer er defineret i standarden ANSI X3.4. Disse tegn benyttes til at
 adskille og karakterisere information på en logisk måde. Set ud fra en hierarkisk synsvinkel er
 filseparatortegnet "FS" det mest inklusive, og derefter følger gruppeseparatortegnet "GS",
 recordseparatortegnet "RS" og endelig enhedsseparatortegnet "US". Tabel 1 viser disse ASCII-
 separatorer og giver en beskrivelse af deres brug i forbindelse med denne standard.
 Informationsseparatorer bør funktionelt set betragtes som en angivelse af, hvilken type data der
 følger efter. "US"-tegnet adskiller individuelle informationselementer inde i et felt eller subfelt.
 Dette signalerer, at det efterfølgende informationselement vedrører det pågældende felt eller
 subfelt. En række subfelter i et felt, som er adskilt af "RS"-tegnet, angiver starten af den næste
 gruppe af gentagne informationselementer. "GS"-separatortegnet, der benyttes mellem
 informationsfelter, angiver starten af et nyt felt, der efterfølges af det angivne
 feltidentificeringsnummer. På tilsvarende vis markeres begyndelsen af en ny logisk record med
 angivelse af tegnet "FS".
 De fire tegn giver kun mening, når de benyttes som separatorer mellem dataelementer i felter i
 ASCII-tekstrecords. Tegnene har ingen specifik betydning, når


text:
de forekommer i binære billedrecords
 og binære felter — de indgår blot som en del af de udvekslede oplysninger.
 Normalt bør der ikke være nogen tomme felter eller informationselementer, så der bør derfor kun
 være ét separatortegn mellem to givne dataelementer. Undtagelsen fra denne regel indtræder, når
 data i felterne eller informationselementer i en transaktion ikke er tilgængelige, ikke findes eller er
 fakultative, og behandlingen af transaktionen ikke er afhængig af, at de pågældende data er til
 stede. I sådanne tilfælde skal man angive flere separatortegn i træk snarere end at indsætte fylddata
 mellem separatortegnene.
 Med henblik på definitionen af et felt, der består af tre informationselementer, gælder følgende.
 Hvis oplysningerne i det andet informationselement mangler, anføres der to "US"-
 informationsseparatortegn ved siden af hinanden mellem det første og det tredje
 informationselement. Hvis både andet og tredje informationselement mangler, anføres der tre
 987
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 separatortegn — to "US"-tegn samt det afsluttende separatortegn for feltet eller subfeltet. Som
 hovedregel bør det korrekte antal separatortegn indsættes, hvis et eller flere obligatoriske eller
 fakultative informationselementer ikke er tilgængelige for et felt eller subfelt.
 Det er muligt at have kombinationer af to eller flere af de fire separatortegn lige efter hinanden. Hvis
 dataene ikke foreligger eller ikke er tilgængelige til informationselementer, subfelter eller felter, skal
 der være et separatortegn mindre end det fornødne antal informationselementer, subfelter eller
 felter.
 Tabel 1: Benyttede separatorer
 Code Type Description Hexadecimal Value Decimal Value
 US Unit Separator Separates information 1F 31
 items
 RS Record Separator Separates subfields 1E 30
 GS Group Separator Separates fields 1D 29
 FS File Separator Separates logical records 1C 28
 2.2. Record layout
 I logiske records med mærkede felter, skal hvert af de benyttede informationsfelter nummereres i
 overensstemmelse med denne standard. Formatet for hvert felt skal bestå af den logiske records
 typenummer efterfulgt af et punktum ".", et feltnummer efterfulgt af et kolon ":", efterfulgt af de
 oplysninger, der skal stå i feltet. Det mærkede felts nummer er et etcifret tal fra 1 til 9, som anføres
 mellem punktummet "." og kolonet ":". Det skal fortolkes som et nummer i et usigneret talfelt. Det
 vil sige, at feltnummeret "2.123:" svarer til og skal fortolkes på samme måde som feltnummeret
 "2.000000123:".
 I eksemplerne i resten af dette dokument benyttes et trecifret tal til angivelse af felterne i hver af de
 logiske records med mærkede felter, der beskrives heri. Feltnumrene udformes således: "TT.xxx:",
 hvor "TT" repræsenterer recordtypen med et eller to tegn 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

type: contracts

jurisdiction: EU


text:
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 fire-byte-felt i hver record. Recordens samlede længde skal angives i det første
 binære fire-byte-felt i hver record. Hertil kommer, at da alle felterne i denne record enten har fast
 988
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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. Type-1-logisk record: 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 der 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 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
 transaktionstypen. Disse koder kan være forskellige fra dem, der benyttes af andre
 implementeringer af ANSI/NIST-standarden.
 989
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder


text:
heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 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 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
 990
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 – 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 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 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 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 6).
 991
 ---pagebreak---


text:
Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Tabel 2: Tilladte koder i transaktionerne
 Transaction Type Logical Record Type
 1 2 4 9 13 15
 CPS M M M — — —
 SRE M M C — C C
 (C in case of latent HITs)
 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)
 992
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 "agency" (agentur) 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 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 LAW.PRUM.11 [Fingeraftryksoplysninger] og LAW.PRUM.12
 [Elektronisk søgning af fingeraftryksdata] skal opløsningen være på 500 DPI (= pixels/inch) eller 19,68
 pixels/mm.
 3.1.12. Field 1.012: Nominal Transmitting Resolution (NTR)
 Dette felt


text:
på fem byte angiver den nominelle overførselsopløsning for de billeder, der overføres.
 Opløsningen angives i pixels/mm i samme format som NSR (Felt 1.011).
 3.1.13. Field 1.013: Domain name (DOM)
 993
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 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 et "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
 994
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 hvor CC er INTERPOL's landekode på to alfanumeriske tegn, og "number"


text:
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 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 LAW.PRUM.11 [Fingeraftryksoplysninger] og LAW.PRUM.12
 [Elektronisk søgning af fingeraftryksdata] 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)
 995
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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


text:
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 til "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 Invalid record type
 996
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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)
 997
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 – 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


text:
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 (pixels/inch) eller 19,68
 pixels/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.
 998
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Tabel 4: Fingeraftrykstype
 Code Description
 0 Live-scan of plain fingerprint
 1 Live-scan of rolled fingerprint
 2 Non-live scan impression of plain fingerprint captured from paper
 3 Non-live scan impression of rolled fingerprint captured from paper
 4 Latent impression captured directly
 5 Latent tracing
 6 Latent photo
 7 Latent lift
 8 Swipe
 9 Unknown
 5.1.4. Field 4.004: Finger Position (FGP)
 Dette felt, der har en fast længde 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 Length
 (mm) (mm)
 Unknown 0 40,0 40,0
 Right thumb 1 45,0 40,0
 Right index finger 2 40,0 40,0
 999
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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


text:
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 pixels/mm (500 pixels/inch). 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 antallet af pixels 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 7) er benyttet.
 1000
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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.
 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æ


text:
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
 1001
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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).
 Figur 4
 Minutiævinklen bestemmes ved at konstruere tre virtuelle stråler, der starter ved
 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 180o 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
 1002
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 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


text:
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 65 534 pixel.
 1003
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 65 534 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. inch 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 "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. 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 en ad gangen til "15".
 6.2.13. Field 9.134: Finger Position (FGP)
 Dette felt angiver koden


text:
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 minutiae, der
 indledes med "1" og øges med "1" for hver yderligere minutiae i fingeraftrykket. Andet og tredje
 informationselement er x-koordinaten og y-koordinaterne i minutiae angivet i pixelenheder. Fjerde
 1004
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 informationselement er minutiae-vinklen angivet i enheder på to grader. Denne værdi skal være
 ikkenegativ mellem 0 og 179. Femte informationselement er minutiae-typen. "0" angiver minutiae 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 minutiæ blev ekstraheret data om linjeantal til nærmeste
 minutiæ i fire kvadranter, og linjeantal for hver centrale minutiae opgives samlet. "2" angiver, at der
 for hver centrale minutiæ blev ekstraheret data om linjeantal til nærmeste minutiæ i otte oktanter,
 og linjeantal for hver centrale minutiae 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 kerner adskilles af <RS>-
 separatortegnet.
 6.2.19. Field 9.140:


text:
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.
 1005
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Tabel 7: Type-13-record: latent billede med variabel opløsning
 Ident Cond. Field Field Char Field size per Occur count Max
 code Numbe Name type occurrence byte
 r count
 min. max. min max
 LEN M 13.001 LOGICA n 4 8 1 1 15
 L
 RECOR
 D
 LENGT
 H
 IDC M 13.002 IMAGE n 2 5 1 1 12
 DESIGN
 ATION
 CHARA
 CTER
 IMP M 13.003 IMPRES A 2 2 1 1 9
 SION
 TYPE
 SRC M 13.004 SOURC AN 6 35 1 1 42
 E
 AGENC
 Y/ORI
 LCD M 13.005 LATENT n 9 9 1 1 16
 CAPTU
 RE
 DATE
 HLL M 13.006 HORIZO n 4 5 1 1 12
 NTAL
 LINE
 LENGT
 H
 VLL M 13.007 VERTIC n 4 5 1 1 12
 AL LINE
 LENGT
 H
 1006
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 SLC M 13.008 SCALE n 2 2 1 1 9
 UNITS
 HPS M 13.009 HORIZO n 2 5 1 1 12
 NTAL
 PIXEL
 SCALE
 VPS M 13.010 VERTIC n 2 5 1 1 12
 AL
 PIXEL
 SCALE
 CGA M 13,011 COMPR A 5 7 1 1 14
 ESSION
 ALGORI
 THM
 BPX M 13.012 BITS n 2 3 1 1 10
 PER
 PIXEL
 FGP M 13.013 FINGER n 2 3 1 6 25
 POSITI
 ON
 RSV 13.014 RESERV — — — — — —
 ED FOR
 13.019 FUTUR
 E
 DEFINIT
 ION
 COM O 13.020 COMM A 2 128 0 1 135
 ENT
 RSV 13.021 RESERV — — — — — —
 ED FOR
 13.199 FUTUR
 E
 DEFINIT
 ION
 UDF O 13.200 USER- — — — — — —
 DEFINE
 1007
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 13.998 D
 FIELDS
 DAT M 13.999 IMAGE B 2 — 1 1 —
 DATA
 Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric;


text:
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 size per occurence" omfatter alle
 separatortegn, der anvendes i feltet. "Maximum byte count" omfatter feltnummer, oplysninger og
 alle separatortegn herunder også "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
 "agency" (agentur) er en fritekstidentificering af agenturet på højst 32 alfanumeriske tegn.
 7.1.5. Field 13.005: Latent capture date (LCD)
 1008
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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. inch og et "2" angiver pixel pr. centimeter. Et "0" i dette felt angiver, at
 der ikke er angivet nogen skala.


text:
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 "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.
 Gyldige kompressionskoder findes i tillæg 7.
 7.1.12. Field 13.012: Bits per pixel (BPX)
 Dette obligatoriske ASCII-felt angiver antal bits pr. 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 (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 et- 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
 1009
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 bits (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


text:
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
 1010
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 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


text:
to felter i "field size per occurence" omfatter alle
 separatortegn, der anvendes i feltet. "Maximum byte count" omfatter feltnummer, oplysninger og
 alle separatortegn herunder også "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.
 1011
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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
 "agency" (agentur) 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 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. inch 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 "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
 1012
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Ident Cond. Field Field Char Field size per Occur count Max
 code Numbe


text:
Name type occurrence byte
 r count
 min. max. min max
 LEN M 15.001 LOGICA n 4 8 1 1 15
 L
 RECOR
 D
 LENGT
 H
 IDC M 15.002 IMAGE n 2 5 1 1 12
 DESIGN
 ATION
 CHARA
 CTER
 IMP M 15.003 IMPRES n 2 2 1 1 9
 SION
 TYPE
 SRC M 15.004 SOURC AN 6 35 1 1 42
 E
 AGENC
 Y/ORI
 PCD M 15.005 PALMP n 9 9 1 1 16
 RINT
 CAPTU
 RE
 DATE
 HLL M 15.006 HORIZO n 4 5 1 1 12
 NTAL
 LINE
 LENGT
 H
 VLL M 15.007 VERTIC n 4 5 1 1 12
 AL LINE
 LENGT
 H
 1013
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 SLC M 15.008 SCALE n 2 2 1 1 9
 UNITS
 HPS M 15.009 HORIZO n 2 5 1 1 12
 NTAL
 PIXEL
 SCALE
 VPS M 15.010 VERTIC n 2 5 1 1 12
 AL
 PIXEL
 SCALE
 CGA M 15.011 COMPR AN 5 7 1 1 14
 ESSION
 ALGORI
 THM
 BPX M 15.012 BITS n 2 3 1 1 10
 PER
 PIXEL
 PLP M 15.013 PALMP n 2 3 1 1 10
 RINT
 POSITI
 ON
 RSV 15.014 RESERV — — — — — —
 ED FOR
 15.019 FUTUR
 E
 INCLUSI
 ON
 COM O 15.020 COMM AN 2 128 0 1 128
 ENT
 RSV 15.021 RESERV — — — — — —
 ED FOR
 15.199 FUTUR
 E
 INCLUSI
 ON
 1014
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 UDF O 15.200 USER- — — — — — —
 DEFINE
 15.998 D
 FIELDS
 DAT M 15.999 IMAGE B 2 — 1 1 —
 DATA
 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 et "NONE" i dette felt angiver det, at dataene i denne record ikke er
 komprimerede. For de billeder, der skal komprimeres, indeholder feltet den foretrukne metode til at
 komprimere tenprint fingeraftryksbilleder. Gyldige kompressionskoder findes i tillæg 7.
 8.1.12. Field 15.012: Bits per pixel (BPX)
 Dette obligatoriske ASCII-felt angiver antal bits pr. 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 28 387 139,7 203,2
 Right Full Palm 21 28 387 139,7 203,2
 1015
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke


text:
udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Right Writer s Palm 22 5 645 44,5 127,0
 Left Full Palm 23 28 387 139,7 203,2
 Left Writer s Palm 24 5 645 44,5 127,0
 Right Lower Palm 25 19 516 139,7 139,7
 Right Upper Palm 26 19 516 139,7 139,7
 Left Lower Palm 27 19 516 139,7 139,7
 Left Upper Palm 28 19 516 139,7 139,7
 Right Other 29 28 387 139,7 203,2
 Left Other 30 28 387 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)
 1016
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 bits (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 type-15-records i denne fil. For hvert supplerende
 håndfladeaftryksbillede kræves der 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 TP/TP LT/TP LP/PP TP/UL LT/UL PP/ULP LP/ULP
 Search
 Maximum 1 10 5 5 5


text:
5 5
 Number of
 Candidates
 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)
 1017
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 9.1. Tillæg 1: ASCII-separatorkoder
 ASCII Position148 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 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
 148
 This is the position as defined in the ASCII standard.
 1018
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 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 4: Transaktionsresumé
 Type-1-record (obligatorisk)
 1019
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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


text:
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 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 Field Name CPS/PMS MPS/MMS SRE ERR
 Number
 LEN 2.001 Logical Record Length M M M M
 IDC 2.002 Image Designation M M M M
 Character
 1020
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 M — C —
 Number
 MN1 2.012 Miscellaneous — — C C
 Identification Number
 MN2 2.013 Miscellaneous — — C C
 Identification Number
 MN3 2.014 Miscellaneous — — C C
 Identification Number
 MN4 2.015 Miscellaneous — — C C
 Identification Number
 INF 2.063 Additional Information O O O O
 RLS 2.064 Respondents List — — M —
 ERM 2.074 Status/Error Message — — — M
 Field
 ENC 2.320 Expected Number of M M — —
 Candidates
 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 LAW.PRUM.11 [Fingeraftryksoplysninger] og LAW.PRUM.12
 [Elektronisk søgning af fingeraftryksdata])
 9.5. Tillæg 5: Definitioner i type-1-record
 1021
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Identifier Condition Field Number Field Name Character Type Example Data
 LEN M 1.001 Logical Record n 1.001:230{}{GS}
 Length }
 VER M 1.002 Version n 1.002:0300{}{GS
 Number }}
 CNT M 1.003 File Content n 1.003:1{}{US}}1
 5{}{RS}}2{}{US}}
 00{}{RS}}4{}{US}
 }01{}{RS}}4{}{US
 }}02{}{RS}}4{}{U
 S}}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{}{R
 S}}4{}{US}}11{}{
 RS}}4{}{US}}12{}
 {RS}}4{}{US}}13{
 }{RS}}4{}{US}}14
 {}{GS}}
 TOT M 1.004 Type of A 1.004:CPS{}{GS}
 Transaction }
 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 1* 1.007:DE/BKA{}
 Agency {GS}}
 ORI M 1.008 Originating 1* 1.008:NL/NAFIS
 Agency {}{GS}}
 TCN M 1.009 Transaction AN 1.009:02000000
 Control Number 04F{}{GS}}
 1022
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 TCR C 1.010 Transaction


text:
AN 1.010:02000000
 Control 04F{}{GS}}
 Reference
 NSR M 1.011 Native Scanning AN 1.011:19.68{}{G
 Resolution S}}
 NTR M 1.012 Nominal AN 1.012:19,68{}{G
 Transmitting S}}
 Resolution
 DOM M 1.013 Domain Name AN 1 013: INT-
 I{}{US}}4,22{}{G
 S}}
 GMT M 1.014 Greenwich AN 1.014:20050101
 Mean Time 125959Z
 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", "_", ".", "", "-"]
 9.6. Tillæg 6: Definitioner i type-2-record
 Tabel A.6.1: CPS- og PMS-transaktion
 Identifier Condition Field Field Name Character Example Data
 Numbe Type
 r
 LEN M 2.001 Logical n 2.001:909{}{GS}}
 Record
 Length
 IDC M 2.002 Image n 2.002:00{}{GS}}
 Designation
 Character
 SYS M 2.003 System n 2.003:0422{}{GS}}
 Information
 1023
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 CRN M 2.010 Criminal AN 2.010:DE/E999999999{}{GS}}
 Reference
 Number
 INF O 2.063 Additional 1* 2.063:Additional Information
 Information 123{}{GS}}
 ENC M 2.320 Expected n 2.320:1{}{GS}}
 Number of
 Candidates
 Tabel A.6.2: SRE-transaktion
 Identifier Condition Field Number Field Name Character Type Example Data
 LEN M 2.001 Logical Record n 2.001:909{}{GS}
 Length }
 IDC M 2.002 Image n 2.002:00{}{GS}}
 Designation
 Character
 SYS M 2.003 System n 2.003:0422{}{GS
 Information }}
 CRN C 2.010 Criminal AN 2.010:NL/22222
 Reference 22222{}{GS}}
 Number
 MN1 C 2.012 Miscellaneous AN 2.012:E9999999
 Identification 99{}{GS}}
 Number
 MN2 C 2.013 Miscellaneous AN 2.013:E9999999
 Identification 99{}{GS}}
 Number
 MN3 C 2.014 Miscellaneous n 2.014:0001{}{GS
 Identification }}
 Number
 MN4 C 2.015 Miscellaneous A 2.015:A{}{GS}}
 Identification
 1024
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Number
 INF O 2.063 Additional 1* 2.063:Additiona
 Information l Information
 123{}{GS}}
 RLS M 2.064 Respondents AN 2.064:CPS{}{RS}
 List }I{}{RS}}001/001
 {}{RS}}999999{}{
 GS}}
 Tabel A.6.3: ERR-transaktion
 Identifier Condition Field Field Name Character Example Data
 Numbe Type
 r
 LEN M 2.001 Logical Record n 2.001:909{}{GS}}
 Length
 IDC M 2.002 Image n 2.002:00{}{GS}}
 Designation
 Character
 SYS M 2.003 System n 2.003:0422{}{GS}}
 Information
 MN1 M 2.012 Miscellaneous AN 2.012:E999999999{}{GS}}
 Identification
 Number
 MN2 C 2.013 Miscellaneous AN 2.013:E999999999{}{GS}}
 Identification
 Number
 MN3 C 2.014 Miscellaneous n 2.014:0001{}{GS}}
 Identification
 Number
 MN4 C 2.015 Miscellaneous A 2.015:A{}{GS}}
 Identification
 Number
 1025
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 INF O 2.063 Additional 1* 2.063:Additional
 Information Information 123{}{GS}}
 ERM M 2.074 Status/Error AN 2 074: 201: IDC - 1 FIELD
 Message 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 Field Name Character Example Data
 Numbe Type
 r
 LEN M 2.001 Logical Record n 2.001:909{}{GS}}
 Length
 IDC M 2.002 Image n 2.002:00{}{GS}}
 Designation
 Character
 SYS M 2.003 System n 2.003:0422{}{GS}}
 Information
 CNO


text:
M 2.007 Case Number AN 2.007:E999999999{}{GS}}
 SQN C 2.008 Sequence n 2.008:0001{}{GS}}
 Number
 MID C 2.009 Latent Identifier A 2.009:A{}{GS}}
 INF O 2.063 Additional 1* 2.063:Additional
 Information Information 123{}{GS}}
 ENC M 2.320 Expected n 2.320:1{}{GS}}
 Number of
 Candidates
 I kolonnen "Condition": O = Optional (fakultativ), M = Mandatory (obligatorisk), C = Conditional
 (betinget).
 1026
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 I kolonnen "Character Type" (tegntype): A = Alpha, N = Numeric, B = Binary.
 1* tilladte tegn er: ["0..9", "A..Z", "a..z", "_",".", "", "-", ","]
 9.7. Tillæg 7: Gråtonekompressionskoder
 Kompressionskoder
 Compression Value Remarks
 Wavelet Scalar Quantisation Greyscale WSQ Algorithm to be used for the compression of
 Fingerprint Image Compression greyscale images in Type-4, Type-7 and Type-
 Specification 13 to Type-15 records. Shall not be used for
 resolutions > 500dpi.
 IAFIS-IC-0010(V3), dated 19 December
 1997
 JPEG 2000 J2K To be used for lossy and losslessly
 compression of greyscale images in Type-13
 [ISO 15444/ITU T.800] to Type-15 records. Strongly recommended
 for resolutions > 500 dpi
 9.8. Tillæg 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)):
 1027
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 hvert dataelement markeres det med "Y", hvis elementet udtrykkelig er udpeget som
 betydningsfuldt i henhold til Artikel LAW.PRUM.15 [Elektronisk søgning af oplysninger i
 køretøjsregistre].
 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,


text:
der er nødvendige for at indskrænke søgningen. Afsnit
 1.2.2.2 omhandler 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/O149 Remarks Prüm Y/N150
 149
 M = mandatory when available in national register, O = optional.
 150
 All the attributes specifically allocated by the States are indicated with Y.
 1028
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Data relating to vehicles
 Licence number M Y
 Chassis number/VIN M Y
 Country of registration M Y
 Make M (D.1151) e.g. Ford, Opel, Renault, Y
 etc.
 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/O152 Remarks Prüm
 Y/N
 Data relating to (C.1153) The data refer to the holder of the specific
 holders of the registration certificate.
 vehicle
 Registration M (C.1.1.) Y
 holders' (company)
 name separate fields will be used for surname, infixes, titles,
 etc., and the name in printable format will be
 communicated
 First name M (C.1.2) Y
 separate fields for first name(s) and initials will be used,
 and the name in printable format will be communicated
 Address M (C.1.3) Y
 separate fields will be used for Street, House number and
 151
 Harmonised document abbreviation, see Council Directive 1999/37/EC of 29 April 1999.
 152
 M = mandatory when available in national register, O = optional.
 153
 Harmonised document abbreviation, see Council Directive 1999/37/EC of 29 April 1999.
 1029
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 Annex, Zip code, Place of residence, Country of residence,
 etc., and the Address in printable format will be
 communicated
 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 n
 company.
 Type of ID Number O The type of ID Number (e.g. passport number). n
 Start date O Start date of the holdership of the car. This date will n
 holdership often be the same as printed under (I) on the registration
 certificate of the vehicle.
 End date O End data of the holdership of


text:
the car. n
 holdership
 Type of holder O If there is no owner of the vehicle (C.2) the reference to n
 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.
 Data relating to (C.2)
 owners of the
 vehicle
 Owners' M (C.2.1) Y
 (company) name
 First name M (C.2.2) Y
 Address M (C.2.3) Y
 Gender M male, female Y
 1030
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 n
 company.
 Type of ID Number O The type of ID Number (e.g. passport number). n
 Start date O Start date of the ownership of the car. n
 ownership
 End date O End data of the ownership of the car. n
 ownership
 Data relating to
 vehicles
 Licence number M Y
 Chassis M Y
 number/VIN
 Country of M Y
 registration
 Make M (D.1) e.g. Ford, Opel, Renault, etc. Y
 Commercial type M (D.3) e.g. Focus, Astra, Megane. Y
 of the vehicle
 Nature of the M (J) mopeds, motorbikes, cars, etc. Y
 vehicle/EU
 Category Code
 Date of first M (B) Date of first registration of the vehicle somewhere in Y
 registration the world.
 Start date (actual) M (I) Date of the registration to which the specific certificate Y
 registration of the vehicle refers.
 End date M End data of the registration to which the specific Y
 registration certificate of the vehicle refers. It is possible this date
 indicates the period of validity as printed on the
 1031
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 document if not unlimited (document abbreviation = H).
 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 O Regular, transito, etc. Y
 number
 Vehicle document O The first unique document ID as printed on the vehicle Y
 id 1 document.
 Vehicle document O A second document ID as printed on the vehicle Y
 id 2154 document.
 Data relating to
 insurances
 Insurance O Y
 company name
 Begin date O Y
 insurance
 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 n
 Commerce)
 2. Datasikkerhed
 154
 In Luxembourg two separate vehicle registration document ID's are used.
 1032
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er


text:
kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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 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
 1033
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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,


text:
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 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
 1034
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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.
 Figur 5: Meddelelsestyper, der logføres
 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.
 1035
 ---pagebreak--- Dette dokument er aftalt mellem Den Europæiske Union og Det Forenede Kongerige og er kun til orientering. Der kan ikke
 udledes rettigheder heraf før anvendelsesdatoen Nummereringen af artiklerne er foreløbig.
 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