PRÍLOHA

OBSAH

KAPITOLA 1:

Výmena údajov o DNA

1.	Súdne otázky týkajúce sa DNA, pravidlá zhodnosti a algoritmy

1.1.	Vlastnosti profilov DNA

1.2.	Pravidlá zhodnosti

1.3.	Pravidlá oznamovania

2.	Tabuľka kódov členských štátov

3.	Funkčná analýza

3.1.	Dostupnosť systému

3.2.	Druhý krok

4.	Dokument o riadení prepojenia pre DNA

4.1.

Úvod

4.2.	Vymedzenie štruktúry XML

5.	Aplikačná, bezpečnostná a komunikačná architektúra

5.1.

Prehľad

5.2.	Architektúra vyššieho stupňa

5.3.	Bezpečnostné normy a ochrana údajov

5.4.	Protokoly a normy na použitie v šifrovacích mechanizmoch: sMIME a súvisiace balíky

5.5.	Aplikačná architektúra

5.6.	Protokoly a normy na použitie v aplikačnej architektúre

5.7.	Komunikačné prostredie

KAPITOLA 2:

Výmena daktyloskopických údajov (dokument o riadení prepojenia)

1.	Prehľad obsahu súboru

2.	Formát záznamu

3.	Logický záznam typu 1: Hlavička súboru

4.	Logický záznam typu 2: Opisný text

5.	Logický záznam typu 4: Obrázok v odtieňoch šedej s vysokým rozlíšením

6.	Logický záznam typu 9: Záznam o markantoch

7.	Logický záznam typu 13: Skrytý obrázok s rôznym rozlíšením

8.	Logický záznam typu 15: Odtlačok dlane s rôznym rozlíšením

9.	Dodatky ku kapitole 2 (výmena daktyloskopických údajov)

9.1.	Oddeľovacie kódy ASCII

9.2.	Výpočet alfanumerických kontrolných znakov

9.3.	Znakové kódy

9.4.	Súhrn transkacií

9.5.	Vymedzenia záznamov typu 1

9.6.	Vymedzenia záznamov typu 2

9.7.	Kódy na kompresiu odtieňov šedej

9.8.	Špecifikácia pošty

KAPITOLA 3:

Výmena údajov z evidencie vozidiel

1.	Spoločný súbor údajov na automatizované vyhľadávanie údajov z evidencie vozidiel

1.1.	Vymedzenie pojmov

1.2.	Vyhľadávanie podľa vozidla/vlastníka/držiteľa

2.	Bezpečnosť údajov

2.1.

Prehľad

2.2.	Bezpečnostné prvky výmeny správ

2.3.	Bezpečnostné prvky, ktoré sa netýkajú výmeny správ

3.	Technické podmienky výmeny údajov

3.1.	Všeobecný opis aplikácie EUCARIS

3.2.	Požiadavky na funkčnosť a požiadavky, ktoré sa netýkajú funkčnosti

KAPITOLA 4:

Hodnotenie

1.	Hodnotiaci postup podľa článku 20 (príprava rozhodnutí podľa článku 25 ods. 2 rozhodnutia 2008/615/SVV)

1.1.

Dotazník

1.2.	Skúšobná prevádzka

1.3.	Hodnotiaca návšteva

1.4.	Správa Rade

2.	Hodnotiaci postup podľa článku 21

2.1.	Štatistika a správa

2.2.

Revízia

3.	Stretnutia expertov

Kapitola 1: Výmena údajov o DNA

1.   Súdne otázky týkajúce sa DNA, pravidlá zhodnosti a algoritmy

1.1.   Vlastnosti profilov DNA

Profil DNA môže obsahovať 24 párov čísiel, ktoré predstavujú alely na 24 lokusoch a ktoré sa používajú aj v postupoch Interpolu týkajúcich sa DNA. Názvy uvedených lokusov sa nachádzajú v nasledujúcej tabuľke:

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

Sedem šedých miest v hornom riadku predstavuje aj súčasný európsky štandardný súbor lokusov (ESS) aj štandardný súbor lokusov DNA Interpolu (ISSOL).

Pravidlá začlenenia:

Profily DNA, ktoré členské štáty sprístupnia na účely vyhľadávania a porovnávania, ako aj profily DNA, ktoré sa odošlú na vyhľadávanie a porovnávania, musia obsahovať aspoň 6 úplných vymedzených (1) lokusov a v závislosti od dostupnosti môžu obsahovať dodatočné vymedzené lokusy alebo úseky mimo vymedzeného profilu. Referenčné profily DNA musia obsahovať aspoň 6 zo siedmich lokusov európskeho štandardného súboru. V záujme zvýšenia presnosti zhodných výsledkov sa do indexovanej databázy profilov DNA uložia všetky dostupné alely a budú sa využívať na vyhľadávanie a porovnávanie. Každý členský štát by hneď, ako to bude prakticky možné, mal implementovať všetky nové ESS lokusov, ktoré prijme EÚ.

Nepovoľujú sa zmiešané profily, aby alelová hodnota každého lokusu pozostávala len z dvoch čísiel, ktoré môžu byť v prípade homozygotov na rovnakom lokuse rovnaké.

Pre zástupný znak a mikrosatelity platia tieto pravidlá:

—	Každá nečíselná hodnota v profile okrem amelogenínu (napr. „o“, „f“, „r“, „na“, „nr“ alebo „un“) sa automaticky prekonvertuje na zástupný znak (*) a vyhľadávanie sa uskutoční medzi všetkými inými hodnotami.

—	Hodnoty „0“, „1“ a „99“ sa automaticky konvertujú na zástupný znak (*) a vyhľadávajú medzi všetkými inými hodnotami.

—	Ak sa pri jednom mieste poskytnú 3 alely, akceptuje sa len prvá alela a ostávajúce dve sa musia automaticky prekonvertovať na zástupný znak (*) a vyhľadávať medzi všetkými inými hodnotami.

—	Ak sa zástupné znaky použijú pri prvej alebo druhej alele, budú sa vyhľadávať obe permutácie číselnej hodnoty pre daný lokus (napr. „12, *“ by mohlo hlásiť zhodu s „12,14“ aj „9,12“).

—	Pentanukleotidové mikrosatelity (Penta D, Penta E a CD4) sa budú porovnávať takto: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x.4 — x.4 = x.3, x.4, x + 1

—	Tetranukleotidové mikrosatelity (zvyšné lokusy sú tetranukleotidy) sa budú porovnávať takto: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x + 1

1.2.   Pravidlá zhodnosti

Porovnávanie dvoch profilov DNA sa uskutoční na základe tých lokusov, pri ktorých je v oboch profiloch dostupný alelový pár. Na oznámenie pozitívnej lustrácie sa v oboch profiloch DNA musí zhodovať aspoň 6 úplných vymedzených lokusov (okrem amelogenínu).

Úplná zhoda (prvá úroveň kvality) sa definuje ako zhoda v prípade, keď sú rovnaké všetky alely porovnávaných spoločných lokusov v oboch porovnávaných profiloch DNA. Čiastočná zhoda sa definuje ako zhoda v prípade, ak sa v oboch profiloch DNA medzi porovnávanými alelami vyskytuje len jedna nerovnaká alela (druhá, tretia a štvrtá úroveň kvality). Čiastočná zhoda sa akceptuje, len ak sa v dvoch porovnávaných profiloch vyskytuje aspoň 6 úplných vymedzených zhodných lokusov.

Dôvodom čiastočnej zhody môže byť:

—	preklep pri vkladaní jedného z profilov DNA do vyhľadávača alebo databázy DNA,

—	chyba pri určovaní alely alebo analýze alely počas vytvárania profilu DNA.

1.3.   Pravidlá oznamovania

Oznamovať sa budú úplné zhody, čiastočné zhody a „negatívna lustrácia“.

Oznámenie o zhode sa zašle žiadajúcemu národnému kontaktnému bodu a sprístupní sa aj dožadovanému národnému kontaktnému bodu (aby mohlo odhadnúť charakter a počet možných následných žiadostí o ďalšie dostupné osobné údaje a iné informácie spojené s profilom DNA, ktorý zodpovedá pozitívnemu výsledku vyhľadávania, v súlade s článkami 5 a 10 rozhodnutia 2008/615/SVV).

2.   Tabuľka kódov členských štátov

V súlade s rozhodnutím 2008/615/SVV sa na vytvorenie názvov domén a ďalších konfiguračných parametrov, ktoré sa pri uzavretej sieti vyžadujú v prümských aplikáciách pri výmene údajov o DNA, používajú dvojpísmenové kódy zo zoznamu ISO 3166-1 alpha-2.

Pri členských štátoch sa používajú tieto dvojpísmenové kódy zo zoznamu ISO 3166-1 alpha-2:

Názov členského štátu	Kód	Názov členského štátu	Kód
Belgicko	BE	Luxembursko	LU
Bulharsko	BG	Maďarsko	HU
Česká republika	CZ	Malta	MT
Dánsko	DK	Holandsko	NL
Nemecko	DE	Rakúsko	AT
Estónsko	EE	Poľsko	PL
Grécko	EL	Portugalsko	PT
Španielsko	ES	Rumunsko	RO
Francúzsko	FR	Slovensko	SK
Írsko	IE	Slovinsko	SI
Taliansko	IT	Fínsko	FI
Cyprus	CY	Švédsko	SE
Lotyšsko	LV	Spojené kráľovstvo	UK
Litva	LT

3.   Funkčná analýza

3.1.   Dostupnosť systému

Žiadosti podľa článku 3 rozhodnutia 2008/615/SVV by sa do cieľovej databázy mali dostať v chronologickom poradí podľa odoslania a odpoveď by sa mala žiadajúcemu členskému štátu zaslať tak, aby ju dostal do 15 minút od doručenia žiadosti.

3.2.   Druhý krok

Keď členský štát dostane oznámenie o zhode, jeho národný kontaktný bod zodpovedá za porovnanie hodnôt predloženého profilu s hodnotami v prijatej odpovedi (profiloch) s cieľom overiť a skontrolovať dôkaznú hodnotu profilu. Národné kontaktné body sa na účely overovania môžu vzájomne kontaktovať priamo.

Postupy právnej pomoci sa začínajú po overení existujúcej zhody medzi dvoma profilmi na základe „úplnej zhody“ alebo „čiastočnej zhody“ získanej počas automatizovanej fázy vyhľadávania.

4.   Dokument o riadení prepojenia pre DNA

4.1.   Úvod

4.1.1.   Ciele

V tejto kapitole sa vymedzujú požiadavky na výmenu informácií o profiloch DNA medzi databázovými systémami všetkých členských štátov. Polia v hlavičkách sa definujú špecificky pre prümskú výmenu informácií o DNA, dátová časť vychádza z dátovej časti DNA profilu vo formáte XML vymedzenom pre bránu Interpolu na výmenu informácií o DNA.

Údaje sa vymieňajú prostredníctvom protokolu SMTP (Simple Mail Transfer Protocol) a iných moderných technológií, pomocou centrálneho poštového relay servera od poskytovateľa sieťových služieb. Súbor XML sa prenáša ako telo správy.

4.1.2.   Rozsah

V tomto dokumente o riadení prepojenia (ICD – Interface Control Document) sa vymedzuje len obsah (poštovej) správy. Všetky témy týkajúce sa špecificky siete alebo pošty sa definujú jednotne, aby sa zabezpečila spoločná technická báza na výmenu údajov o DNA.

Rieši sa:

—	formát predmetového poľa správy na umožnenie/zabezpečenie automatizovaného spracovania pošty,

—	či je potrebné šifrovanie obsahu a ak áno, aký spôsob by sa mal zvoliť,

—	maximálna dĺžka správ.

4.1.3.   Štruktúra a zásady formátu XML

Správa vo formáte XML sa delí na

—	hlavičku (header), ktorá obsahuje informácie o prenose a

—	dátovú časť (data), ktorá obsahuje informácie o konkrétnom profile, ako aj samotný profil.

Na žiadosť i odpoveď sa využíva rovnaká schéma XML.

Na účely úplnej kontroly neidentifikovaných profilov DNA (článok 4 rozhodnutia 2008/615/SVV) sa musí dať v jednej správe zaslať súbor profilov. Musí sa vymedziť i maximálny počet profilov v rámci jednej správy. Tento počet závisí od maximálnej povolenej veľkosti správy v elektronickej pošte a vymedzí sa po výbere poštového servera.

Príklad správy vo formáte XML:

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

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

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

<header>

(...)

</header>

</datas>

(...)

</datas>

[<datas> (....) v prípade, že sa prostredníctvom jedinej správy SMTP zasiela viacero profilov, štruktúra „datas“ sa opakuje; toto je možné len v prípadoch podľa článku 4

</datas>]

</PRUEMDNA>

4.2.   Vymedzenie štruktúry XML

Nasledujúce definície sú len na dokumentačné účely a kvôli lepšej čitateľnosti, ozajstné záväzné informácie sa nachádzajú v súbore so schémou vo formáte XML (PRUEM DNA.xsd).

4.2.1.   Schéma PRUEMDNAx

Obsahuje tieto polia:

Fields	Type	Description
header	PRUEM_header	Occurs: 1
datas	PRUEM_datas	Occurs: 1 … 500

4.2.2.   Obsah štruktúry hlavičky

4.2.2.1.

PRUEM header Touto štruktúrou sa opisuje hlavička súboru vo formáte XML. Obsahuje tieto polia: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting Member State info requested PRUEM_header_info Requested Member State info

4.2.2.2.

PRUEM_header dir Typ údajov obsiahnutých v správe, hodnota môže byť: Value Description R Request A Answer

4.2.2.3.

PRUEM header info Štruktúra na opis členského štátu, obsahuje aj dátum/čas správy. Obsahuje tieto polia: Fields Type Description source_isocode String ISO 3166-2 code of the requesting Member State destination_isocode String ISO 3166-2 code of the requested Member State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message

4.2.3.   Obsah údajov v profile PRUEM

4.2.3.1.

PRUEM_datas Touto štruktúrou sa opisuje dátová časť súboru vo formáte XML. Obsahuje tieto polia: Fields Type Description reqtype PRUEM request type Type of request (Article 3 or 4) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique Member State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (Hit) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of Hit hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality !=0 (the original requested profile), then empty.

4.2.3.2.

PRUEM_request_type Typ údajov obsiahnutých v správe, hodnota môže byť: Value Description 3 Requests pursuant to Article 3 of Decision 2008/615/JHA 4 Requests pursuant to Article 4 of Decision 2008/615/JHA

4.2.3.3.

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

4.2.3.4.

PRUEM_data_type Typ údajov obsiahnutých v správe, hodnota môže byť: Value Description P Person profile S Stain

4.2.3.5.

PRUEM_data_result Typ údajov obsiahnutých v správe, hodnota môže byť: Value Description U Undefined, If direction = R (request) H Hit N No Hit E Error

4.2.3.6.

IPSG_DNA_profile Štruktúra, ktorou sa opisuje profil DNA. Obsahuje tieto polia: Fields Type Description ess_issol IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile

4.2.3.7.

IPSG_DNA_ISSOL Štruktúra, ktorá obsahuje lokusy ISSOL (štandardná skupina lokusov Interpolu). Obsahuje tieto polia: Fields Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amelogin

4.2.3.8.

IPSG_DNA_additional_loci Štruktúra, ktorá obsahuje iné lokusy. Obsahuje tieto polia: Fields Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba

4.2.3.9.

IPSG_DNA_locus Štruktúra, prostredníctvom ktorej sa opisuje lokus. Obsahuje tieto polia: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele

5.   Aplikačná, bezpečnostná a komunikačná architektúra

5.1.   Prehľad

Pri realizácii žiadostí o výmenu údajov o DNA v rámci rozhodnutia 2008/615/SVV sa používa spoločná komunikačná sieť, ktorá bude medzi členskými štátmi logicky uzavretá. Na účinnejšie využitie tejto spoločnej komunikačnej infraštruktúry, ktorá zahŕňa zasielanie žiadostí a získavanie odpovedí, sa prijal asynchrónny mechanizmus na prenos žiadostí o údaje DNA a daktyloskopické údaje v správe elektronickej pošty v protokole SMTP. Aby sa vyriešili bezpečnostné obavy a s cieľom vytvoriť ozajstný bezpečný tunel z jedného konca siete na druhý, bude sa používať mechanizmus sMIME ako rozšírenie protokolu SMTP.

Ako komunikačná sieť na výmenu údajov medzi členskými štátmi sa používa funkčná TESTA (Trans European Services for Telematics between Administrations – transeurópska komunikačná sieť telematických služieb medzi orgánmi štátnej správy). Za sieť TESTA v súčasnosti zodpovedá Európska komisia. Vzhľadom na skutočnosť, že vnútroštátne databázy DNA a súčasné vnútroštátne prístupové miesta do siete TESTA sa môžu v členských štátoch nachádzať na iných lokalitách, prístup do siete TESTA sa môže zriadiť buď:

1.	prostredníctvom využitia existujúceho vnútroštátneho prístupového miesta alebo vytvorenia nového prístupového miesta do siete TESTA, alebo

2.	prostredníctvom vytvorenia bezpečného miestneho pripojenia z lokality, na ktorej je umiestnená databáza DNA a na ktorej ju spravuje príslušná vnútroštátna agentúra, na existujúce vnútroštátne prístupové miesto do siete TESTA.

Protokoly a normy, ktoré sa využívajú pri realizácii žiadostí na základe rozhodnutia 2008/615/SVV, sú v súlade s otvorenými normami a spĺňajú požiadavky uložené tvorcami vnútroštátnych bezpečnostných politík členských štátov.

5.2.   Architektúra vyššieho stupňa

Každý členský štát sprístupní iným členským štátom svoje údaje DNA na výmenu a vyhľadávanie v súlade so štandardným spoločným formátom údajov v rozsahu pôsobnosti rozhodnutia 2008/615/SVV. Architektúra vychádza z komunikačného modelu „každý s každým“. Na uchovávanie profilov DNA neexistuje ani centrálny počítačový server, ani centralizovaná databáza.

Obrázok 1: Topológia výmeny údajov o DNA

Okrem súladu s vnútroštátnymi právnymi predpismi na lokalitách členských štátov sa každý z týchto štátov môže rozhodnúť, aký hardvér a softvér by mal na svojich lokalitách využiť na konfiguráciu, aby boli splnené požiadavky vyplývajúce z rozhodnutia 2008/615/SVV.

5.3.   Bezpečnostné normy a ochrana údajov

Posúdili a zaviedli sa tri úrovne bezpečnosti.

5.3.1.   Dátová úroveň

Údaje v profile DNA, ktoré poskytnú jednotlivé členské štáty, sa musia pripraviť v súlade so spoločnými normami ochrany údajov tak, aby žiadajúci členský štát dostal odpoveď, v ktorej sa uvádza najmä, či ide o POZITÍVNY alebo NEGATÍVNY výsledok vyhľadávania; ak je výsledok vyhľadávania POZITÍVNY, v odpovedi sa bude nachádzať identifikačné číslo, ale žiadne osobné údaje. Ďalšie vyšetrovanie po oznámení, že výsledok vyhľadávania bol POZITÍVNY, sa vykoná na dvojstrannej úrovni podľa existujúcich vnútroštátnych právnych a organizačných predpisov, ktoré sa vzťahujú na lokality jednotlivých členských štátov.

5.3.2.   Komunikačná úroveň

Správy, v ktorých sa nachádzajú informácie o profiloch DNA (od žiadajúceho i dožadovaného členského štátu) sa zašifrujú najmodernejším mechanizmom zodpovedajúcim otvoreným normám, ako napríklad sMIME, ešte pred tým, ako sa odošlú na lokality iných členských štátov.

5.3.3.   Prenosová úroveň

Všetky zašifrované správy, v ktorých sa nachádzajú informácie o profile DNA, sa budú zasielať do systémov iných členských štátov prostredníctvom privátneho virtuálneho tunelového systému, ktorý spravuje dôveryhodný poskytovateľ siete na medzinárodnej úrovni a prostredníctvom bezpečných liniek k tomuto tunelovému systému pod vnútroštátnou zodpovednosťou. Tento súkromný virtuálny tunelový systém nemá žiadny spoločný bod s verejným internetom.

5.4.   Protokoly a normy na použitie v šifrovacích mechanizmoch: sMIME a súvisiace balíky

Na šifrovanie správ obsahujúcich informácie o profiloch DNA sa použije otvorená norma sMIME ako rozšírenie v podstate štandardného protokolu elektronickej pošty SMTP. Protokol sMIME (V3) umožňuje podpísané potvrdenia, bezpečnostné nálepky a bezpečné zoznamy adresátov na základe syntaxe kryptografických správ (CMS – Cryptographic Message Syntax), špecifikácie osobitnej skupiny pre internetové inžinierstvo (IETF – Internet Engineering Task Force) pre kryptograficky chránené správy. Môže sa využiť na digitálne podpisovanie, spracovanie, overovanie alebo šifrovanie akejkoľvek formy digitálnych údajov.

Základný certifikát, ktorý využíva mechanizmus sMIME, musí byť v súlade s normou X.509. S cieľom zabezpečiť súlad spoločných noriem a postupov s inými prümskými aplikáciami platia pre operácie šifrovania s mechanizmom sMIME alebo na uplatnenie v rámci rôznych aplikačných a užívateľských softvérov (COTS – Commercial Products of the Shelves) tieto pravidlá spracovania:

—	Následnosť operácií je: najprv šifrovanie a potom podpis.

—	Na symetrické šifrovanie sa použije šifrovací algoritmus AES (Advanced Encryption Standard) s 256-bitovým kľúčom a na nesymetrické algoritmus RSA s 1 024-bitovým kľúčom.

—	Využije sa hašovací algoritmus SHA-1.

Funkcia sMIME je zabudovaná do obrovskej väčšiny moderných balíkov softvéru pre elektronickú poštu vrátane aplikácií Outlook, Mozilla Mail a Netscape Communicator 4.x a funguje pri ich prepojení.

Pretože sMIME sa ľahko integruje do vnútroštátnej informačnej infraštruktúry na lokalitách všetkých členských štátov, vybral sa ako životaschopný mechanizmus na realizáciu komunikačnej úrovne bezpečnosti. Na efektívnejšie splnenie cieľa získania „dôkazu vhodnosti koncepcie“ a zníženie nákladov sa však na prvotnú výmenu údajov o DNA vybralo otvorené štandardné rozhranie na programovanie aplikácií (API – Application Programming Interface) JavaMail. Rozhranie JavaMail poskytuje jednoduché šifrovanie a dešifrovanie emailov pomocou mechanizmov s/MIME a/alebo OpenPGP. Zámerom je poskytnúť jediné a jednoduché rozhranie API klientom elektronickej pošty, ktorí si želajú odosielať a prijímať zašifrovanú poštu v jednom z dvoch najrozšírenejších emailových šifrovacích formátov. Preto budú na splnenie požiadaviek ustanovených v rozhodnutí 2008/615/SVV postačovať akékoľvek moderné implementácie rozhrania JavaMail, ako napríklad produkt spoločnosti Bouncy Castle JCE (Java Cryptographic Extension), ktorý sa použije na zavedenie protokolu sMIME na prvotnú výmenu údajov o DNA medzi členskými štátmi.

5.5.   Aplikačná architektúra

Každý členský štát poskytne ostatným členským štátom súbor štandardizovaných údajov o profiloch DNA, ktoré zodpovedajú platnému spoločnému ICD. Môže tak urobiť buď prostredníctvom poskytnutia logického prehľadu jednotlivých vnútroštátnych databáz, alebo vytvorenia fyzicky exportovateľnej databázy (indexovanej databázy).

Pomocou štyroch hlavných zložiek – emailového servera sMIME, aplikačného servera, oblasti štruktúrovania dát na získavanie/vkladanie údajov a evidenciu prichádzajúcich/odchádzajúcich správ a vyhľadávača zhodných profilov – sa celá aplikačná logika realizuje nezávisle od produktu.

Na uľahčenie integrácie uvedených komponentov do príslušných vnútroštátnych lokalít členských štátov sa určené spoločné funkcie implementovali prostredníctvom „open source“ komponentov, ktoré si každý členský štát môže vybrať na základe svojej vnútroštátnej politiky a vnútroštátnych predpisov v oblasti informačných technológií. Pretože na účely získania prístupu do indexovaných databáz, v ktorých sa nachádzajú profily DNA začlenené v rozhodnutí 2008/615/SVV, sa majú zaviesť uvedené nezávislé mechanizmy, každý členský štát má voľný výber hardvérovej a softvérovej platformy vrátane databázy a operačných systémov.

V rámci existujúcej spoločnej siete sa vytvoril a úspešne odskúšal prototyp výmeny údajov o DNA. Vo funkčnom prostredí sa zaviedla verzia 1.0 a používa sa v každodennej prevádzke. Členské štáty môžu využívať uvedený spoločný produkt, ale môžu si vytvoriť aj vlastné. Komponenty spoločného produktu sa budú udržiavať, prispôsobovať a naďalej rozvíjať podľa meniacich sa požiadaviek IT, súdneho lekárstva alebo operačných požiadaviek polície.

Obrázok 2: Prehľad aplikačnej topológie

5.6.   Protokoly a normy na použitie v aplikačnej architektúre

5.6.1.   XML

Pri výmene údajov o DNA sa naplno využije schéma XML ako príloha k poštovým správam vo formáte SMTP. Rozšíriteľný značkovací jazyk (XML – eXtensible Markup Language) je všeobecným značkovacím jazykom odporúčaným konzorciom W3C na vytváranie značkovacích jazykov na konkrétne účely, v ktorom je možné opísať mnoho rôznych druhov údajov. Profil DNA, ktorý je vhodný na výmenu medzi členskými štátmi, sa prostredníctvom jazyka XML a schémy XML opísal v dokumente ICD.

5.6.2.   ODBC

Databázové rozhranie ODBC (Open DataBase Connectivity) poskytuje štandardnú softvérovú API metódu na prístup do riadiacich systémov databáz nezávisle od programovacích jazykov a databázových a operačných systémov. ODBC má však niekoľko nedostatkov. Správa väčšieho počtu klientských zariadení si môže vyžadovať rôzne ovládače a knižnice DLL. Takáto komplexnosť môže zvýšiť réžiu správy systému.

5.6.3.   JDBC

Rozhranie JDBC (Java DataBase Connectivity) je API pre programovací jazyk Java, v ktorom sa vymedzujú spôsoby prístupu do databázy zo strany klienta. Na rozdiel od ODBC si JDBC nevyžaduje použitie určitého súboru miestnych knižníc DLL na ploche.

Aplikačná logika spracovania žiadostí o profil DNA a odpovedí na lokalite každého členského štátu sa opisuje v nasledujúcom diagrame. Spracovanie žiadostí i odpovedí sa prekrýva s neutrálnou dátovou oblasťou, v ktorej sa nachádzajú rôzne skupiny údajov so spoločnou dátovou štruktúrou.

Obrázok 3: Schéma fungovania aplikácie na lokalite každého členského štátu

5.7.   Komunikačné prostredie

5.7.1.   Spoločná komunikačná sieť: TESTA a ďalšia infraštruktúra

Aplikácia výmena údajov o DNA bude využívať asynchrónny mechanizmus elektronickej pošty na zasielanie žiadostí a prijímanie odpovedí medzi členskými štátmi. Keďže všetky členské štáty majú aspoň jedno vnútroštátne prístupové miesto do siete TESTA, výmena údajov o DNA bude fungovať v rámci tejto siete. TESTA poskytuje prostredníctvom svojho emailového prenosu niekoľko služieb s pridanou hodnotou. Okrem prevádzkovania a spravovania špecifických emailových schránok pre sieť TESTA sa prostredníctvom uvedenej infraštruktúry realizujú aj zoznamy adresátov pošty a postupy presmerovania. Toto umožňuje, aby sa TESTA využívala ako spracovateľské stredisko pre správy adresované štátnym orgánom prepojeným s celoeurópskymi doménami. Zaviesť sa môže aj mechanizmus antivírusovej kontroly.

Prenos poštových správ v rámci siete TESTA je postavený na vysoko dostupnej hardvérovej platforme umiestnenej v centrálnych aplikačných priestoroch siete TESTA a chránenej bránou firewall. Systém správy doménových mien (DNS – Domain Name Services) v rámci siete TESTA preloží informácie z vyhľadávačov zdroja na IP adresy a skryje informácie o adrese pred používateľom a aplikáciami.

5.7.2.   Bezpečnostné otázky

V rámci siete TESTA sa realizovala koncepcia virtuálnej privátnej siete (VPN – Virtual Private Network). Štítkovacia technológia použitá na vytvorenie uvedenej VPN sa bude ďalej vyvíjať, aby podporovala štandard MPLS (Multi-Protocol Label Switching), ktorý vytvorila osobitná skupina IETF.

MPLS je štandardnou technológiou, ktorá zvyšuje rýchlosť smerovania dát v sieti tým, že zabraňuje analýze paketov zo strany priebežných smerovačov (vynechávajú sa skoky). Funguje to na základe tzv. značiek, ktoré paketu pridelí okrajový smerovač chrbticovej siete na základe informácií uložených v smerovacej tabuľke FIB (Forwarding Information Base). Značky sa používajú aj na implementáciu virtuálnych súkromných sietí (VPN).

MPLS spája výhody smerovania protokolu tretej vrstvy a prepínania protokolu druhej vrstvy. Pretože počas prechodu cez chrbticovú sieť sa nevyhodnocujú IP adresy, v štandarde MPLS nie sú žiadne obmedzenia týkajúce sa týchto adries.

Okrem toho budú emailové správy v sieti TESTA II chránené šifrovacím mechanizmom na základe sMIME. Bez poznania kľúča a bez správneho certifikátu sa nikomu v sieti nepodarí správy dešifrovať.

5.7.3.   Protokoly a normy, ktoré sa budú využívať v rámci komunikačnej siete

5.7.3.1.

SMTP Protokol SMTP (Simple Mail Transfer Protocol) je vlastne štandardným protokolom na prenos elektronickej pošty cez Internet. SMTP je relatívne jednoduchým textovým protokolom, v ktorom sa špecifikuje jeden alebo viac príjemcov správ a následne sa odošle text správy. SMTP využíva TCP port 25 podľa špecifikácie IETF. Na určenie servera SMTP pre príslušný názov domény sa využíva záznam MX (Mail eXchange) DNS (Domain Name Systems). Keďže tento protokol bol vytvorený ako čistý textový protokol na základe tabuľky ASCII, prácu s binárnymi súbormi nezvládal. Na zakódovanie binárnych súborov na účely prenosu prostredníctvom SMTP sa vytvorili normy typu MIME. V súčasnosti väčšina serverov SMTP podporuje rozšírenia 8BITMIME a sMIME, ktoré umožňujú prenos binárnych súborov s ľahkosťou čistého textu. Postupy spracovania pre operácie s/MIME sa opisujú v oddiele s/MIME (pozri kapitolu 5.4). SMTP je protokolom typu „push“, ktorý neumožňuje používateľovi stiahnuť si správy zo vzdialeného servera na žiadosť. Na to musí klient elektronickej pošty využívať protokoly POP3 alebo IMAP. V rámci realizácie výmeny údajov o DNA sa rozhodlo, že sa bude využívať protokol POP3.

5.7.3.2.

POP Miestni klienti elektronickej pošty využívajú na stiahnutie pošty zo vzdialeného servera cez spojenie TCP/IP tretiu verziu protokolu POP (Post Office Protocol), štandardný internetový protokol aplikačnej vrstvy. Klienti elektronickej pošty posielajú správy cez Internet alebo sieť spoločnosti prostredníctvom profilu SMTP Submit protokolu SMTP. Normou pre prílohy a text, ktorý nie je vytvorený pomocou znakov ASCII, je MIME. Hoci ani POP3, ani SMTP nevyžaduje email formátovaný cez protokol MIME, internetová elektronická pošta prichádza v takomto formáte, a preto klienti služby POP musia MIME chápať a používať. V celom komunikačnom prostredí podľa rozhodnutia 2008/615/SVV sa preto budú nachádzať zložky protokolu POP.

5.7.4.   Pridelenie sieťovej adresy

Operačné prostredie

Sieti TESTA pridelil Európsky úrad na registráciu IP adries (RIPE) vymedzený blok podsiete triedy C. V prípade potreby sa v budúcnosti sieti TESTA môžu prideliť ďalšie bloky adries. Prideľovanie IP adries členským štátom sa zakladá na geografickej schéme Európy. Výmena údajov medzi členskými štátmi v rámci rozhodnutia 2008/615/SVV sa prevádzkuje cez celoeurópsku, logicky uzavretú sieť IP.

Testovacie prostredie

Na zabezpečenie hladko fungujúceho prostredia každodennej prevádzky vo všetkých pripojených členských štátoch je potrebné v rámci uzavretej siete vytvoriť testovacie prostredie pre nové členské štáty, ktoré sa pripravujú na pripojenie. Vymedzil sa zoznam parametrov, ktorý obsahuje IP adresy, nastavenia siete, emailové domény a účty používateľa aplikácií, a tieto parametre sa nastavia na zodpovedajúcej lokalite príslušného členského štátu. Okrem toho sa na skúšobné účely vytvoril súbor pseudoprofilov DNA.

5.7.5.   Konfiguračné parametre

Vytvoril sa bezpečný systém elektronickej pošty, ktorý využíva doménu eu-admin.net. K tejto doméne a pridruženým adresám nebude existovať prístup z lokalít, ktoré sa nenachádzajú na celoeurópskej doméne TESTA, pretože príslušné mená pozná len centrálny DNS server TESTA, ktorý je chránený pred prístupom z internetu.

Mapovanie uvedených adries lokalít (doménových mien) na ich IP adresy sa vykonáva prostredníctvom služby DNS siete TESTA. Ku každej miestnej doméne sa na uvedenom centrálnom serveri DNS pre sieť TESTA pridá poštová položka, čím sa zabezpečí presmerovanie všetkých emailov odoslaných na miestne domény siete TESTA na centrálny poštový relay server siete TESTA. Tento relay server siete TESTA potom správy presmeruje na špecifický poštový server miestnej domény pomocou emailových adries miestnych domén. Prostredníctvom takéhoto prenosu elektronickej pošty sa zabezpečí, že zásadné informácie obsiahnuté v emailoch sa budú pohybovať len cez celoeurópsku uzavretú sieťovú infraštruktúru, a nie cez málo bezpečný internet.

Na lokalitách všetkých členských štátov je preto potrebné vytvoriť subdomény ( tučná kurzíva ) s takouto syntaxou:

„ typ-aplikácie.pruem.kód-členského štátu. eu-admin.net“, kde:

„kód-členského-štátu“ je dvojpísmenovým kódom členského štátu (napr. AT, BE atď.),

„ typ-aplikácie “ je buď DNA, alebo FP.

V nasledujúcej tabuľke sa nachádzajú subdomény členských štátov vytvorené na základe uvedenej syntaxe:

MS	Subdomény	Poznámky
BE	dna.pruem.be.eu-admin.net	Vytvára bezpečné miestne pripojenie k existujúcemu vnútroštátnemu prístupovému miestu do siete TESTA II
	fp.pruem.be.eu-admin.net
BG	dna.pruem.bg.eu-admin.net
	fp.pruem.bg.eu-admin.net
CZ	dna.pruem.cz.eu-admin.net
	fp.pruem.cz.eu-admin.net
DK	dna.pruem.dk.eu-admin.net
	fp.pruem.dk.eu-admin.net
DE	dna.pruem.de.eu-admin.net	Využíva existujúce vnútroštátne prístupové miesta do siete TESTA II
	fp.pruem.de.eu-admin.net
EE	dna.pruem.ee.eu-admin.net
	fp.pruem.ee.eu-admin.net
IE	dna.pruem.ie.eu-admin.net
	fp.pruem.ie.eu-admin.net
EL	dna.pruem.el.eu-admin.net
	fp.pruem.el.eu-admin.net
ES	dna.pruem.es.eu-admin.net	Využíva existujúce vnútroštátne prístupové miesto do siete TESTA II
	fp.pruem.es.eu-admin.net
FR	dna.pruem.fr.eu-admin.net	Využíva existujúce vnútroštátne prístupové miesto do siete TESTA II
	fp.pruem.fr.eu-admin.net
IT	dna.pruem.it.eu-admin.net
	fp.pruem.it.eu-admin.net
CY	dna.pruem.cy.eu-admin.net
	fp.pruem.cy.eu-admin.net
LV	dna.pruem.lv.eu-admin.net
	fp.pruem.lv.eu-admin.net
LT	dna.pruem.lt.eu-admin.net
	fp.pruem.lt.eu-admin.net
LU	dna.pruem.lu.eu-admin.net	Využíva existujúce vnútroštátne prístupové miesto do siete TESTA II
	fp.pruem.lu.eu-admin.net
HU	dna.pruem.hu.eu-admin.net
	fp.pruem.hu.eu-admin.net
MT	dna.pruem.mt.eu-admin.net
	fp.pruem.mt.eu-admin.net
NL	dna.pruem.nl.eu-admin.net	Plánuje vytvoriť nové prístupové miesto do siete TESTA II pri Holandskom forenznom inštitúte (NFI – Nederlands Forensisch Instituut)
	fp.pruem.nl.eu-admin.net
AT	dna.pruem.at.eu-admin.net	Využíva existujúce vnútroštátne prístupové miesto do siete TESTA II
	fp.pruem.at.eu-admin.net
PL	dna.pruem.pl.eu-admin.net
	fp.pruem.pl.eu-admin.net
PT	dna.pruem.pt.eu-admin.net	......
	fp.pruem.pt.eu-admin.net	......
RO	dna.pruem.ro.eu-admin.net
	fp.pruem.ro.eu-admin.net
SI	dna.pruem.si.eu-admin.net	......
	fp.pruem.si.eu-admin.net	.......
SK	dna.pruem.sk.eu-admin.net
	fp.pruem.sk.eu-admin.net
FI	dna.pruem.fi.eu-admin.net	[Vloží sa]
	fp.pruem.fi.eu-admin.net
SE	dna.pruem.se.eu-admin.net
	fp.pruem.se.eu-admin.net
UK	dna.pruem.uk.eu-admin.net
	fp.pruem.uk.eu-admin.net

Kapitola 2: Výmena daktyloskopických údajov (dokument o riadení prepojenia)

Cieľom tohto dokumentu o riadení prepojenia je vymedziť požiadavky na výmenu daktyloskopických informácií medzi automatickými systémami na identifikáciu odtlačkov prstov (AFIS – Automated Fingerprint Identification Systems) v jednotlivých členských štátoch. Vychádza z vykonávania normy ANSI/NIST-ITL 1-2000 (INT-I, verzia 4.22b) zo strany Interpolu.

Táto verzia zahŕňa všetky základné definície logických záznamov typu 1, 2, 4, 9, 13 a 15, ktoré sa vyžadujú na daktyloskopické spracovanie založené na obrázku alebo charakteristických individuálnych znakoch (markantoch).

1.   Prehľad obsahu súboru

Daktyloskopický súbor pozostáva z viacerých logických záznamov. V pôvodnej norme ANSI/NIST-ITL 1-2000 je vymedzených šestnásť typov záznamov. Medzi každým záznamom a poliami a subpoliami v rámci záznamov sa používajú príslušné oddeľovacie znaky podľa tabuľky ASCII.

Na výmenu informácií medzi agentúrou pôvodu a určenia sa používa len 6 typov záznamov:

Typ-1	→	Informácie o operácii
Typ-2	→	Alfanumerické údaje o osobách/prípade
Typ-4	→	Daktyloskopické obrázky v odtieňoch šedej s vysokým rozlíšením
Typ-9	→	Záznam o markantoch
Typ-13	→	Záznam latentného obrázku s rôznym rozlíšením
Typ-15	→	Záznam odtlačku dlane s rôznym rozlíšením

1.1.   Typ 1 – Hlavička súboru

Tento záznam obsahuje informácie o smerovaní a informácie opisujúce štruktúru zvyšku súboru. V tomto type záznamu sa tiež vymedzujú typy operácií, ktoré patria do nasledujúcich širších kategórií:

1.2.   Typ 2 – Opisný text

Tento záznam obsahuje textové informácie, ktoré môžu byť zaujímavé pre odosielajúcu a prijímajúcu agentúru.

1.3.   Typ 4 – Obrázok v odtieňoch šedej s vysokým rozlíšením

Tento záznam sa používa na výmenu daktyloskopických obrázkov v odtieňoch šedej (s 8 bitovým kódovaním) s vysokým rozlíšením 500 pixelov na palec. Daktyloskopické obrázky sa komprimujú pomocou algoritmu WSQ (Wavelet/Scalar Quantization) s kompresným pomerom nepresahujúcim 15 : 1. Nesmú sa využívať iné kompresné algoritmy ani nekomprimované obrázky.

1.4.   Typ 9 – Záznam o markantoch

Záznamy typu 9 sa používajú na výmenu údajov o papilárnych líniách alebo markantoch. Ich účelom je čiastočne sa vyhnúť nepotrebnému zdvojeniu kódovacích procesov AFIS a čiastočne umožniť prenos kódov AFIS, ktoré obsahujú menej údajov ako zodpovedajúce obrázky.

1.5.   Typ 13 – Záznam latentného obrázku s rôznym rozlíšením

Tento záznam sa používa na výmenu skrytých obrázkov odtlačkov prstov a dlaní s rôznym rozlíšením spolu s alfanumerickou informáciou o textúre. Skenovacie rozlíšenie obrázkov je 500 pixelov na palec pri 256 odtieňoch šedej. V prípade dostatočnej kvality sa skrytý obrázok komprimuje pomocou algoritmu WSQ. V prípade potreby sa rozlíšenie obrázkov na základe dvojstrannej dohody môže zvýšiť na viac ako 500 pixelov na palec pri viac než 256 odtieňoch šedej. V tomto prípade sa dôsledne odporúča využiť formát JPEG 2000 (pozri dodatok 7).

1.6.   Typ 15 – Záznam odtlačku dlane s rôznym rozlíšením

Záznamy obrázkov s označením polí typu 15 sa používajú na výmenu obrázkov odtlačkov dlane s rôznym rozlíšením spolu s alfanumerickou informáciou o textúre. Skenovacie rozlíšenie obrázkov je 500 pixelov na palec pri 256 odtieňoch šedej. Kvôli minimalizácii objemu údajov sa všetky obrázky odtlačkov dlane komprimujú pomocou algoritmu WSQ. V prípade potreby sa rozlíšenie obrázkov na základe dvojstrannej dohody môže zvýšiť na viac ako 500 pixelov na palec pri viac než 256 odtieňoch šedej. V tomto prípade sa dôsledne odporúča využiť formát JPEG 2000 (pozri dodatok 7).

2.   Formát záznamu

Prenášaný súbor sa skladá z jedného alebo viacerých logických záznamov. Pri každom logickom zázname v súbore sa nachádza niekoľko informačných polí, ktoré k takémuto záznamu prináležia. Každé informačné pole môže obsahovať jeden alebo viacero základných informačných prvkov s jedinou hodnotou. Tieto prvky sa spoločne používajú na prenos rôznych aspektov údajov, ktoré sa v danom poli nachádzajú. Informačné pole môže pozostávať aj z jedného alebo viacerých zoskupených informačných prvkov, ktoré sa v danom poli niekoľkokrát opakujú. Takéto zoskupenie informačných prvkov sa nazýva podpole. Informačné pole preto pozostáva z jedného alebo viacerých podpolí obsahujúcich informačné prvky.

2.1.   Separátory informácií

V logických záznamoch ohraničených tagmi sa mechanizmy na ohraničenie informácií uplatňujú vo forme štyroch separátorov informácií ASCII. Ohraničené informácie môžu byť prvkami v rámci poľa alebo podpoľa, poliami v rámci logických záznamov alebo viackrát sa vyskytujúcimi podpoliami. Uvedené separátory informácií sa vymedzujú v norme ANSI X3.4. Sú to znaky, ktoré sa používajú na oddelenie a zatriedenie informácií v logickom zmysle. V rámci hierarchických vzťahov je najinkluzívnejším znakom separátor súboru „FS“, po ňom separátor skupiny „GS“, separátor záznamu „RS“ a nakoniec separátor jednotky „US“. V tabuľke 1 sa nachádza zoznam týchto separátorov a opis ich použitia v rámci uvedenej normy.

Z funkčného hľadiska by sa mali separátory informácií považovať za označenie typu údajov, ktoré po nich nasledujú. Znak „US“ oddeľuje jednotlivé informácie v poli či podpoli. Signalizuje, že ďalšia informácia bude údaj, ktorý sa týka daného poľa či podpoľa. Viaceré podpolia v poli oddelenom pomocou znaku „RS“ naznačujú začiatok ďalšej skupiny opakovaných informácií. Separátor „GS“ použitý medzi informačnými poliami signalizuje začiatok nového poľa, ktoré predchádza poľu identifikovanému zobrazeným číslom. Podobne by aj výskyt separátora „FS“ mal znamenať začiatok nového logického záznamu.

Tieto štyri znaky majú význam len v prípade, ak sa použijú ako separátory jednotlivých údajov v poliach textových záznamov ASCII. V binárnych obrázkoch či v binárnych poliach nemajú tieto znaky žiaden osobitný význam – sú len súčasťou vymieňaných údajov.

Za bežných okolností by sa nemali vyskytovať prázdne polia ani nulové informácie, a preto by sa medzi akýmikoľvek dvoma údajmi mal objavovať len jeden separátor. Výnimkou z tohto pravidla sú prípady, keď nie sú údaje v poliach alebo informáciách v rámci transakcie dostupné, ak chýbajú alebo sú nepovinné, a ak priebeh transakcie nezávisí od prítomnosti takýchto údajov. V takýchto prípadoch sa namiesto vkladania „vaty“ medzi separátory môžu spolu objaviť viaceré priľahlé separátory.

Pri definovaní poľa, ktoré sa skladá z troch informácií, platia tieto pravidlá. Ak chýba druhá informácia, medzi prvou a treťou informáciou sa objavia dva znaky „US“ vedľa seba. Ak by chýbala druhá i tretia informácia, mali by sa použiť tri separátory – dva znaky „US“ a separátor uzatvárajúci pole či podpole. Vo všeobecnosti platí, že ak pre pole alebo podpole nie je dostupná jedna povinná alebo nepovinná informácia, alebo viacero takýchto informácií, mal by sa vložiť zodpovedajúci počet separátorov.

Je možné, aby vedľa seba existovali kombinácie dvoch alebo viacerých zo štyroch dostupných separátorov. Ak pri informačných položkách, podpoliach alebo poliach chýbajú údaje alebo ak nie sú dostupné, počet použitých separátorov musí byť o jeden nižší, ako počet vyžadovaných informácií, podpolí alebo polí.

Tabuľka 1: Použité separátory

Kód	Typ	Opis	Hexadecimálna hodnota	Decimálna hodnota
US	separátor jednotky	oddeľuje jednotlivé informácie	1F	31
RS	separátor záznamu	oddeľuje podpolia	1E	30
GS	separátor skupiny	oddeľuje polia	1D	29
FS	separátor súboru	oddeľuje logické záznamy	1C	28

2.2.   Rozvrhnutie záznamu

V logických záznamoch označených tagmi sa každé použité informačné pole očísluje v súlade s touto normou. Formát pre každé pole pozostáva z čísla typu logického záznamu, po ktorom nasleduje bodka „.“, a z čísla poľa, po ktorom nasleduje dvojbodka „:“; po nich nasledujú príslušné informácie pre dané pole. Číslo poľa ohraničeného tagmi môže byť akékoľvek číslo pozostávajúce z jednej až deviatich číslic medzi bodkou a dvojbodkou. Vykladá sa ako nezáporný celočíselný kód poľa. Z toho vyplýva, že číslo poľa „2.123:“ je rovnocenné a malo by sa vykladať rovnakým spôsobom ako číslo poľa „2.000000123:“.

Na účely objasnenia sa v tomto dokumente na výpočet polí obsiahnutých v každom z opísaných logických záznamov ohraničených tagmi používa číslo pozostávajúce z troch číslic. Čísla polí budú mať formát „TT.xxx:“, pričom „TT“ bude typ záznamu pozostávajúci z jedného alebo dvoch znakov, po ktorých nasleduje bodka. Ďalšie tri znaky označujú príslušné číslo poľa a nasleduje po nich dvojbodka. Za dvojbodkou sa nachádzajú opisné informácie vo formáte ASCII alebo údaje o obrázku.

V logických záznamoch typu 1 a 2 sa môžu nachádzať len textové dátové polia vo formáte ASCII. V každom type takéhoto záznamu sa ako prvé pole vo formáte ASCII zaznamená úplná dĺžka záznamu (vrátane čísiel polí, bodkočiarok a separátorov). Kontrolný znak separátora ASCII poľa „FS“ (ktorý znamená koniec logického záznamu alebo transakcie) nasleduje po poslednom bajte informácie vo formáte ASCII a zahrnie sa do dĺžky záznamu.

Na rozdiel od konceptu poľa ohraničeného tagmi obsahuje záznam typu 4 len binárne údaje zaznamenané ako usporiadané binárne polia s pevnou dĺžkou. Celá dĺžka záznamu sa zaznamená v prvom štvorbajtovom binárnom poli každého záznamu. Pri tomto binárnom zázname sa nezaznamenáva ani číslo záznamu s bodkou, ani číslo identifikátora poľa a nasledujúca dvojbodka. Okrem toho v dôsledku skutočnosti, že všetky polia v tomto zázname majú buď pevnú, alebo vymedzenú dĺžku, sa každý zo štyroch separátorov (US, RS, GS ani FS) môže interpretovať len ako binárny údaj. Znak FS sa pri binárnom zázname nesmie použiť ako separátor ani ako označenie ukončenia transakcie.

3.   Logický záznam typu 1: Hlavička súboru

Prostredníctvom tohto záznamu sa opisuje štruktúra súboru, jeho typ a iné dôležité informácie. Súbor znakov používaných pre polia typu 1 obsahuje len 7-bitový ANSI kód na výmenu informácií.

3.1.   Polia pre logický záznam typu 1

3.1.1   Pole 1.001: Dĺžka logického záznamu (LEN – Logical Record Length)

Toto pole obsahuje informáciu o celkovom počte bajtov v celom logickom zázname typu 1. Pole sa začína kódom „1.001:“, po ktorom nasleduje celková dĺžka záznamu vrátane každého znaku každého poľa a separátorov informácií.

3.1.2.   Pole 1.002: Číslo verzie (VER – Version Number)

Toto štvorbajtové pole konkretizuje číslo verzie normy ANSI/NIST, ktorú použil softvér alebo systém, pomocou ktorého sa vytvoril predmetný súbor, aby sa zabezpečilo, že používatelia vedia, ktorá verzia uvedenej normy sa používa. Prvé dva bajty špecifikujú referenčné číslo hlavnej verzie, druhé dva číslo jej menšej revízie. Napríklad pôvodná norma z roku 1986 sa považuje za prvú verziu a dostane označenie „0100“, zatiaľ čo súčasná norma ANSI/NIST-ITL 1-2000 sa označuje „0300“.

3.1.3.   Pole 1.003: Obsah poľa (CNT – File Content)

V tomto poli sa nachádza zoznam záznamov v súbore usporiadaný podľa typu a poradia, v ktorom sa tieto záznamy v logickom súbore objavujú. Pozostáva z jedného alebo viacerých podpolí, z ktorých každé naopak obsahuje dve informácie opisujúce jeden logický záznam, ktorý sa nachádza v danom súbore. Takéto podpolia sa vkladajú v rovnakom poradí, v akom sa záznamy zaznamenávajú a prenášajú.

Prvá informácia v prvom podpoli je „1“ a odkazuje na to, že ide o záznam typu 1. Nasleduje za ňou druhá informácia, ktorá pozostáva z počtu ďalších záznamov v danom súbore. Tento počet sa rovná počtu ostávajúcich podpolí poľa 1.003.

Každé z ostávajúcich podpolí sa spája s jedným záznamom v súbore a poradie podpolí zodpovedá poradiu záznamov. Každé podpole obsahuje dve informácie. Prvou je identifikácia typu záznamu, druhou IDC záznamu. Na oddelenie týchto informácií sa používa separátor „US“.

3.1.4.   Pole 1.004: Typ transakcie (TOT – Type of Transaction)

Toto pole obsahuje trojpísmenovú skratku, ktorou sa označuje typ transakcie. Tieto kódy sa môžu líšiť od kódov, ktoré sa používajú pri inom uplatňovaní normy ANSI/NIST.

CPS: vyhľadávanie odtlačkov súvisiacich s trestnou činnosťou (Criminal Print-to-Print Search). Táto transakcia je žiadosťou o vyhľadanie záznamu, ktorý sa týka trestného činu, v rámci databázy odtlačkov. Odtlačky sa v súbore musia nachádzať ako obrázok komprimovaný algoritmom WSQ.

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2.

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2,

—	1 až 14 záznamov typu 4.

Typ transakcie CPS je zhrnutý v tabuľke A.6.1 (v dodatku 6).

PMS: vyhľadávanie v databáze skrytých obrazcov (Print-to-Latent Search). Táto transakcia sa použije v prípade, ak sa súbor odtlačkov pri vyhľadávaní porovnáva s databázou neidentifikovaných skrytých obrazcov. Odpoveď bude obsahovať pozitívny/negatívny výsledok vyhľadávania v cieľovom automatizovanom systéme identifikácie odtlačkov. Ak sa nájde viac neidentifikovaných skrytých obrazcov, vráti sa niekoľko transakcií SRE, pričom v každej sa bude nachádzať jeden obrázok. Odtlačky sa v súbore musia nachádzať ako obrázok komprimovaný algoritmom WSQ.

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2.

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2,

—	1 záznam typu 13.

Typ transakcie PMS je zhrnutý v tabuľke A.6.1 (v dodatku 6).

MPS: vyhľadávanie skrytých obrazcov v databáze odtlačkov (Latent-to-Print Search). Táto transakcia sa používa pri vyhľadávaní latentného obrazca v databáze odtlačkov prstov. V súbore sa musia nachádzať informácie o markantoch latentného obrazca a obrázok (komprimovaný algoritmom WSQ).

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2.

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2,

—	1 záznam typu 4 alebo typu 15

Typ transakcie MPS je zhrnutý v tabuľke A.6.4 (v dodatku 6).

MMS: vyhľadávanie skrytých obrazcov v databáze skrytých obrazcov (Latent-to-Latent Search). Pri tejto transakcii sa v súbore nachádza skrytý obrazec, ktorý sa má porovnávať s databázou neidentifikovaných skrytých obrazcov, aby sa zistila spojitosť medzi rôznymi miestami činu. V súbore sa musia nachádzať informácie o markantoch latentného obrazca a obrázok (komprimovaný algoritmom WSQ).

V prípade NEGATÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2.

V prípade POZITÍVNEHO výsledku vyhľadávania sa vrátia tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2,

—	1 záznam typu 13.

Typ transakcie MMS je zhrnutý v tabuľke A.6.4 (v dodatku 6).

SRE: Túto transakciu vracia agentúra určenia ako reakciu na daktyloskopické informácie. Odpoveď bude obsahovať pozitívny/negatívny výsledok vyhľadávania v cieľovom automatizovanom systéme identifikácie odtlačkov. Ak sa nájde viac kandidátov, vráti sa niekoľko transakcií SRE, pričom v každej sa bude nachádzať jeden kandidát.

Typ transakcie SRE je zhrnutý v tabuľke A.6.2 (v dodatku 6).

ERR: Túto transakciu vracia cieľový AFIS ako označenie chyby v transakcii. Obsahuje pole so správou (ERM), v ktorej sa oznamuje zistená chyba. Vrátia sa tieto logické záznamy:

—	1 záznam typu 1,

—	1 záznam typu 2.

Typ transakcie ERR je zhrnutý v tabuľke A.6.3 (v dodatku 6).

Tabuľka 2: Povolené kódy v transakciách

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

Kľúč:

M	=	povinné (Mandatory),
M*	=	môže sa použiť len jeden z dvoch typov záznamov,
O	=	nepovinné (Optional),
C	=	závisí od dostupnosti údajov (Conditional),
–	=	nie je povolené,
1*	=	závisí od pôvodných systémov.

3.1.5.   Pole 1.005: Dátum transakcie (DAT – Date of Transaction)

Toto pole označuje dátum začatia transakcie a musí zodpovedať štandardnému tvaru ISO: RRRRMMDD,

v ktorom RRRR je rok, MM je mesiac a DD je deň v mesiaci. Pri dátumoch s jednou číslicou sa používa úvodná nula. Napríklad tvar „19931004“ znamená 4. októbra 1993.

3.1.6.   Pole 1.006: Priorita (PRY – Priority)

V tomto nepovinnom poli sa určuje priorita žiadosti na stupnici od 1 po 9. Číslom 1 sa označuje najvyššia priorita, číslom 9 najnižšia. Transakcie s prioritou 1 sa spracúvajú bezodkladne.

3.1.7.   Pole 1.007: Identifikátor agentúry určenia (DAI – Destination Agency Identifier)

V tomto poli sa pre transakciu špecifikuje agentúra určenia.

Pozostáva z dvoch informácií v tomto formáte: CC/agency.

Prvá informácia obsahuje kód krajiny (Country Code) vymedzený v norme ISO 3166, ktorý pozostáva z dvoch alfanumerických znakov. Druhá informácia, agency (agentúra), je voliteľný text na identifikáciu agentúry obsahujúci najviac 32 alfanumerických znakov.

3.1.8.   Pole 1.008: Identifikátor agentúry pôvodu (ORI – Originating Agency Identifier)

V tomto poli sa špecifikuje pôvodca súboru, a to v rovnakom formáte ako DAI (pole 1.007).

3.1.9.   Pole 1.009: Kontrolné číslo transakcie (TCN – Transaction Control Number)

Kontrolné číslo na referenčné účely. Mal by ho generovať počítač a malo by mať tento formát: RRSSSSSSSSA,

kde RR je rok transakcie, SSSSSSSS je osemmiestne sériové číslo a A je kontrolný znak vytvorený podľa postupu v dodatku 2.

Ak TCN neexistuje, pole RRSSSSSSSS sa vyplní nulami a kontrolný znak sa vytvorí postupom opísaným vyššie.

3.1.10.   Pole 1.010: Kontrolná odpoveď transakcie (TCR – Transaction Control Response)

Ak je predmetný súbor odpoveďou na žiadosť, toto nepovinné pole bude obsahovať kontrolné číslo transakcie žiadosti. Preto má rovnaký formát ako TCN (pole 1.009).

3.1.11.   Pole 1.011: Pôvodné skenovacie rozlíšenie (NSR – Native Scanning Resolution)

V tomto poli sa špecifikuje bežné skenovacie rozlíšenie systému, ktorý podporuje pôvodca transakcie. Rozlíšenie sa vymedzuje vo formáte dve číslice, desatinná čiarka a ďalšie dve číslice.

Pri všetkých transakciách podľa rozhodnutia 2008/615/SVV by mal byť pomer pri rozlíšení vzoriek 500 pixelov/palec alebo 19,68 pixelu/mm.

3.1.12.   Pole 1.012: Nominálne rozlíšenie pri prenose (NTR – Nominal Transmitting Resolution)

V tomto päťbajtovom poli sa špecifikuje nominálne rozlíšenie prenášaných obrázkov. Rozlíšenie sa vyjadruje v pixeloch/mm v rovnakom formáte ako pri NSR (pole 1.011).

3.1.13.   Pole 1.013: Názov domény (DOM – Domain name)

V tomto povinnom poli sa určuje názov domény na implementáciu logických záznamov typu 2, ktoré definuje používateľ. Obsahuje dve informácie a má formát „INT-I{US}4.22{GS}“.

3.1.14.   Pole 1.014: Greenwichský čas (GMT – Greenwich Mean Time)

Toto povinné pole poskytuje mechanizmus na vyjadrenie dátumu a času v univerzálnych jednotkách stredného greenwichského času (GMT). V prípade použitia obsahuje pole GMT univerzálny dátum, ktorý bude doplnkom miestneho dátumu uvedeného v poli 1.005 (DAT). Využitím poľa GMT sa odstránia nezrovnalosti v miestnych časoch, ktoré sa vyskytujú v prípade, ak sa transakcia a odpoveď prenášajú medzi dvoma miestami oddelenými niekoľkými časovými pásmami. Pole GMT poskytuje univerzálny dátum a 24-hodinový svetový čas nezávisle od časových pásiem. Funguje vo formáte „CCRRMMDDHHMMSSZ“, pričom tento 15-znakový reťazec je vytvorený spojením dátumu a GMT a zakončený písmenom Z, Znaky „CCRR“ predstavujú rok transakcie, „MM“ desiatkové a jednotkové hodnoty mesiaca, „DD“ rovnaké hodnoty dňa, „HH“ zastupujú hodinu, „MM“ minútu a „SS“ sekundu. Úplný dátum nesmie byť neskorší, ako je aktuálny dátum.

4.   Logický záznam typu 2: Opisný text

Štruktúra väčšiny tohto záznamu sa v pôvodnej norme ANSI/NIST nedefinuje. Obsahuje informácie, ktoré môžu byť konkrétne zaujímavé pre odosielajúcu a prijímajúcu agentúru. Na zabezpečenie kompatibilnosti komunikujúcich daktyloskopických systémov sa vyžaduje, aby sa v záznamoch nachádzali iba polia, ktoré sú uvedené nižšie. V tomto dokumente sa upresňuje, ktoré polia sú povinné a ktoré nepovinné, a vymedzuje sa v ňom štruktúra jednotlivých polí.

4.1.   Polia pre logický záznam typu 2

4.1.1.   Pole 2.001: Dĺžka logického záznamu (LEN – Logical Record Length)

V tomto povinnom poli sa uvádza dĺžka daného záznamu typu 2 a celkový počet bajtov vrátane každého znaku každého poľa v zázname a separátorov informácií.

4.1.2.   Pole 2.002: Znak označenia obrázku (IDC – Image Designation Character)

IDC v tomto povinnom poli je zobrazením IDC definovaného v poli obsah súboru (CNT) záznamu typu 1 (pole 1.003), a to vo formáte ASCII.

4.1.3.   Pole 2.003: Systémové informácie (SYS – System Information)

Toto pole je povinné a obsahuje štyri bajty, ktoré označujú verziu INT-I, s ktorou je daný záznam typu 2 v súlade.

Prvé dva bajty špecifikujú číslo hlavnej verzie, druhé dva číslo jej menšej revízie. Napríklad, táto implementácia vychádza z verzie 4 revízie 22 INT-I, a preto bude označená kódom „0422“.

4.1.4.   Pole 2.007: Číslo prípadu (CNO – Case Number)

Číslo, ktoré miestny daktyloskopický úrad pridelil zbierke skrytých obrazcov nájdených na mieste činu. Prijal sa tento formát: CC/number,

kde CC je kód krajiny v databáze Interpolu s dĺžkou dvoch alfanumerických znakov a number (číslo) sa riadi podľa príslušných miestnych usmernení, pričom môže mať až 32 alfanumerických znakov.

Toto pole umožňuje systému identifikovať latentné obrazce spojené s konkrétnym trestným činom.

4.1.5.   Pole 2.008: Číslo sekvencie (SQN – Sequence Number)

Toto číslo špecifikuje každú sekvenciu skrytých obrazcov v rámci prípadu a môže byť až štvormiestne. Sekvencia je skrytý obrazec alebo súbor skrytých obrazcov, ktoré sú spojené na účely archivácie a/alebo vyhľadávania. Z tejto definície vyplýva, že číslo sekvencie treba prideliť každému jednotlivému latentnému obrazcu.

Toto pole sa spolu s MID (pole 2.009) môže využiť na identifikáciu konkrétneho latentného obrazca v rámci sekvencie.

4.1.6.   Pole 2.009: Identifikátor latentného obrazca (MID – Latent Identifier)

Toto pole špecifikuje jednotlivé latentné obrazce v rámci sekvencie. Jeho hodnota je jedno alebo dve písmená, pričom „A“ sa prideľuje prvému latentnému obrazcu, „B“ druhému a tak ďalej až po „ZZ“. Toto pole sa využíva analogicky ako číslo sekvencie pri skrytých obrazcoch uvedené v opise poľa SQN (pole 2.008).

4.1.7.   Pole 2.010: Trestné referenčné číslo (CRN)

Toto jedinečné referenčné číslo prideľuje vnútroštátna agentúra osobe, ktorá je po prvýkrát obvinená zo spáchania trestného činu. V jednej krajine nemôže mať tá istá osoba viac CRN, a taktiež nesmie mať rovnaké CRN ako iná osoba. Rovnaká osoba však môže mať rôzne trestné referenčné čísla v iných krajinách, pričom na ich rozlíšenie slúži kód krajiny.

Pre pole CRN sa prijal tento formát: CC/number,

kde CC je kód krajiny v norme ISO 3166 s dĺžkou dvoch alfanumerických znakov a number (číslo) sa riadi podľa príslušných vnútroštátnych usmernení agentúry pôvodu, pričom môže mať až 32 alfanumerických znakov.

Pri transakciách v súlade s rozhodnutím 2008/615/SVV sa bude toto pole používať na zapísanie vnútroštátneho trestného referenčného čísla agentúry pôvodu, ktoré je spojené s obrázkami v záznamoch typu 4 alebo typu 15.

4.1.8.   Pole 2.012: Neurčené identifikačné číslo (MN1 – Miscellaneous Identification Number)

Toto pole obsahuje CRN (pole 2.010) prenesené prostredníctvom transakcie CPS alebo PMS bez úvodného kódu krajiny.

4.1.9.   Pole 2.013: Neurčené identifikačné číslo (MN2 – Miscellaneous Identification Number)

Toto pole obsahuje CNO (pole 2.007) prenesené prostredníctvom transakcie MPS alebo MMS bez úvodného kódu krajiny.

4.1.10.   Pole 2.014: Neurčené identifikačné číslo (MN3 – Miscellaneous Identification Number)

Toto pole obsahuje SQN (pole 2.008) prenesené prostredníctvom transakcie MPS alebo MMS

4.1.11.   Pole 2.015: Neurčené identifikačné číslo (MN4 – Miscellaneous Identification Number)

Toto pole obsahuje MID (pole 2.009) prenesené prostredníctvom transakcie MPS alebo MMS

4.1.12.   Pole 2.063: Ďalšie informácie (INF – Additional Information)

V prípade transakcie SRE na základe žiadosti PMS sa v tomto poli nachádzajú informácie o prste, ktorý znamenal POZITÍVNY výsledok vyhľadávania. Formát poľa je:

NN, kde NN je dvojmiestny numerický kód pozície prsta podľa definície v tabuľke 5.

Vo všetkých ostatných prípadoch je toto pole nepovinné. Pozostáva z 32 alfanumerických znakov a môže poskytovať dodatočné informácie týkajúce sa žiadosti.

4.1.13.   Pole 2.064: Zoznam respondentov (RLS – Respondents List)

Toto pole obsahuje aspoň dve podpolia. Prvé z nich opisuje typ vykonaného vyhľadávania, a to pomocou trojpísmenovej skratky, ktorou sa špecifikuje typ transakcie v poli TOT (pole 1.004). Druhé podpole obsahuje jeden znak. Znak „I“ sa používa na označenie POZITÍVNEHO výsledku vyhľadávania, zatiaľ čo v opačnom prípade (NEGATÍVNY výsledok vyhľadávania) sa použije znak „N“. Tretie podpole obsahuje identifikátor sekvencie pre výsledky kandidátov a celkový počet kandidátov, pričom tieto dve informácie sú oddelené lomkou. V prípade viacerých kandidátov sa vráti viac správ.

V prípade potenciálneho POZITÍVNEHO výsledku vyhľadávania obsahuje štvrté podpole reťazec z najviac šiestich číslic. Ak sa POZITÍVNY výsledok vyhľadávania overil, hodnota tohto poľa sa definuje ako „999999“.

Príklad: „CPS{RS}I{RS}001/001{RS}999999{GS}“.

Ak vzdialený AFIS neprideľuje skóre, na príslušnom mieste sa zapíše nula.

4.1.14.   Pole 2.074: Pole správy o stave/chybe (ERM)

Toto pole obsahuje chybové správy vyplývajúce z transakcií, ktoré sa budú zasielať späť žiadateľovi ako súčasť chybových transakcií.

Tabuľka 3: Chybové správy

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

Chybové správy od 100 do 199:

Tieto chybové správy sa týkajú overenia záznamov ANSI/NIST a sú definované ako:

<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>...

kde

—	„error_code“ je kód, ktorý sa vzťahuje výlučne na konkrétny dôvod (pozri tabuľku 3),

—	„field_id“ je číslo chybného poľa podľa ANSI/NIST (napr. 1.001, 2.001) vo formáte <record_type>.field_id>.<sub_field_id>,

—	„dynamic text“ je podrobnejší dynamický opis chyby,

—	„LF“ je znak posunu o riadok, ktorým sa oddeľujú viaceré chyby,

—	pre záznamy typu 1 sa ICD definuje ako „-1“.

Príklad:

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

Toto pole je pre chybové transakcie povinné.

4.1.15.   Pole 2.320: Očakávaný počet kandidátov (ENC – Expected Number of Candidates)

Toto pole obsahuje najvyšší počet kandidátov na overenie, ktorý očakáva žiadajúca agentúra. Hodnota ENC nesmie prekročiť hodnoty vymedzené v tabuľke 11.

5.   Logický záznam typu 4: Obrázok v odtieňoch šedej s vysokým rozlíšením

Malo by sa pripomenúť, že záznamy typu 4 sú vo svojej podstate skôr binárne než ASCII. Preto má každé pole v zázname pridelenú konkrétnu pozíciu, z čoho vyplýva, že všetky polia sú povinné.

Norma umožňuje, aby sa v rámci záznamu špecifikovala veľkosť i rozlíšenie obrázku. Vyžaduje si, aby logické záznamy typu 4 obsahovali údaje o daktyloskopických obrázkoch, ktoré sa prenášajú pri nominálnej hustote od 500 do 520 pixelov na palec. Uprednostňovaný pomer pri nových obrázkoch je 500 pixelov na palec alebo 19,68 pixelu na milimeter. Hustota vymedzená v INT-I je 500 pixelov na palec, ale podobné systémy môžu medzi sebou komunikovať pri inom pomere, v rámci rozmedzia od 500 do 520 pixelov na palec.

5.1.   Polia pre logický záznam typu 4

5.1.1.   Pole 4.001: Dĺžka logického záznamu (LEN – Logical Record Length)

V tomto štvorbajtovom poli sa uvádza dĺžka daného záznamu typu 4 a celkový počet bajtov vrátane každého bajtu každého poľa v zázname.

5.1.2.   Pole 4.002: Znak označenia obrázku (IDC – Image Designation Character)

Binárna forma čísla IDC v hlavičke s veľkosťou jedného bajtu.

5.1.3.   Pole 4.003: Typ zobrazenia (IMP – Impression Type)

Typ zobrazenia je pole s veľkosťou jedného bajtu, ktoré sa nachádza na šiestom bajte záznamu.

Tabuľka 4: Typ zobrazenia odtlačku

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.   Pole 4.004: Poloha prsta (FGP – Finger Position)

Toto pole s pevnou dĺžkou šiestich bajtov sa nachádza na siedmom až dvanástom bajte záznamu typu 4. Obsahuje možné polohy prstov začínajúc od bajtu najviac vľavo (siedmy bajt záznamu). Známa alebo najpravdepodobnejšia poloha prsta sa vyberá z tabuľky 5. Vložením polohy ďalších prstov v rovnakom formáte sa v rámci ostávajúcich piatich bajtov môže odkázať až na ďalších päť prstov. Ak sa má použiť odkaz na menej než päť polôh prsta, nevyužité bajty sa vyplnia binárnym číslom 255. Na neznámu polohu prsta sa pri všetkých prstoch používa kód 0.

Tabuľka 5: Kód polohy prsta a maximálna veľkosť

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

Pre latentné obrázky z miesta činu sa používajú len kódy 0 až 10.

5.1.5.   Pole 4.005: Rozlíšenie skenovaného obrázku (ISR – Image Scanning Resolution)

Toto jednobajtové pole sa nachádza na 13. bajte záznamu typu 4. Ak obsahuje nulu („0“), potom sa vzorka skenovala pri uprednostňovanom skenovacom pomere 19,68 pixelu/mm (500 pixelov na palec). Ak obsahuje jednotku („1“), potom sa vzorka skenovala pri alternatívnom skenovacom pomere vymedzenom pri zázname typu 1.

5.1.6.   Pole 4.006: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto pole sa nachádza na 14. a 15. bajte záznamu typu 4. Uvádza počet pixelov na každej skenovacej línii. Najdôležitejší bude prvý bajt.

5.1.7.   Pole 4.007: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto pole sa nachádza na 16. a 17. bajte a zaznamenáva sa v ňom počet skenovaných línií na obrázku. Najdôležitejší je prvý bajt.

5.1.8.   Pole 4.008: Algoritmus kompresie odtieňov šedej (GCA – Gray-scale Compression Algorithm)

Toto jednobajtové pole špecifikuje algoritmus kompresie odtieňov šedej, ktorý sa použil na šifrovanie údajov o obrázku. Binárny kód 1 znamená (na účely tejto aplikácie), že sa použila kompresia WSQ (dodatok 7).

5.1.9.   Pole 4.009: Obrázok

Toto pole obsahuje bajtový tok, ktorý predstavuje obrázok. Jeho štruktúra bude zjavne závisieť od použitého kompresného algoritmu.

6.   Logický záznam typu 9: Záznam o markantoch

Záznamy typu 9 obsahujú text vo formáte ASCII, ktorým sa opisujú markanty a súvisiace informácie odšifrované zo latentného obrazca. Pri vyhľadávaní medzi skrytými obrázkami je počet takýchto záznamov v súbore neobmedzený, pričom každý záznam sa musí týkať iného pohľadu alebo obrazca.

6.1.   Výber markantov

6.1.1.   Identifikácia typu markanta

Touto normou sa definujú tri identifikačné čísla, ktoré sa používajú na opis typu markanta. Uvádzajú sa v tabuľke 6. Koniec papilárnej línie sa označí ako typ 1. Rozdvojenie sa označí ako typ 2. Ak sa markant nedá jasne začleniť medzi tieto dva typy, označí sa ako „iné“, čiže typ 0.

Tabuľka 6: Typy markantov

Type	Description
0	Other
1	Ridge ending
2	Bifurcation

6.1.2.   Umiestnenie a typ markanta

Kvôli dodržaniu súladu šablón s oddielom 5 normy ANSI INCITS 378-2004 sa na určenie umiestnenia (polohy a smeru uhla) jednotlivých markantov použije nasledujúca metóda, ktorou sa rozširuje platná norma INCITS 378-2004.

Poloha alebo umiestnenie markantu, ktorým je zakončenie papilárnej línie, je miesto rozvetvenia centrálneho skeletu priestoru papilárnej brázdy presne pred zakončením danej línie. Ak by sa tri vetvy papilárnej brázdy zúžili na skelet so šírkou jedného pixelu, polohou markantu je bod ich rozvetvenia. Podobne sa aj poloha markantu pri rozdvojení určí ako bod rozvetvenia centrálneho skeletu papilárnej línie. Ak by sa tri vetvy papilárnej línie zúžili na skelet so šírkou jedného pixelu, polohou markantu je bod ich rozvetvenia.

Po konverzii všetkých zakončení papilárnych línií na rozdvojenia sú všetky markanty daktyloskopického obrazca zastúpené ako rozdvojenia. Súradnice bodu rozvetvenia troch vetiev každého markantu na osi x a y (v pixeloch) sa dajú priamo formátovať. Z každého rozdvojenia skeletu sa dá priamo určiť smer markantu. Tri vetvy každého rozdvojenia skeletu sa musia preskúmať v bode zakončenia každej určenej vetvy. Na obrázku 6.1.2 sú zobrazené tri použité metódy na určenie konca vetvy pri skenovacom rozlíšení 500 ppi.

Zakončenie sa určuje podľa následnosti udalostí. Počet pixelov vychádza z rozlíšenia 500 ppi. Z iných rozlíšení bude vyplývať iný počet pixelov.

—	Vzdialenosť 0,064" (32. pixel),

—	zakončenie vetvy skeletu vo vzdialenosti od 0,02" do 0,064" (od 10. do 32. pixela) kratšie vetvy sa nepoužívajú,

—	druhé rozdvojenie sa nachádza vo vzdialenosti do 0,064" (pred 32. pixelom).

Obrázok 6.1.2

Uhol markantu sa určuje na základe vytvorenia troch virtuálnych lúčov vybiehajúcich z bodu rozdvojenia smerom k zakončeniu každej z vetiev. Najmenší z troch uhlov, ktoré tieto lúče vytvoria, sa rozdelia na polovicu, čím sa určí smer markantu.

6.1.3.   Súradnicový systém

Na vyjadrenie polohy markanta sa použije karteziánsky súradnicový systém. Polohu markantov zastupujú ich súradnice na osi x a y. Stred súradnicového systému sa nachádza v ľavom hornom rohu pôvodného obrázku, pričom kladná časť osi x smeruje vpravo a osi y nadol. Súradnice markanta na osi x aj y sú vyjadrené vo vzdialenosti od stredu v pixeloch. Malo by sa poznamenať, že poloha stredu a meracie jednotky nie sú v súlade s dohovorom použitým pri definíciách typu 9 v norme ANSI/NIST-ITL 1-2000.

6.1.4.   Smer markantov

Uhly sa vyjadrujú v štandardnom matematickom formáte s nulou vpravo a uhlom rastúcim proti smeru hodinových ručičiek. Zaznamenané uhly sú pri zakončení papilárnej línie v smere dozadu od jej konca a popri nej a pri rozdvojení smerom k stredu papilárnej brázdy. Tento dohovor sa od dohovoru o uhloch vo vymedzeniach pre typ 9 normy ANSI/NIST-ITL 1-2000 líši o 180 stupňov.

6.2.   Polia pre logický záznam typu 9 vo formáte INCITS-378

Všetky polia v záznamoch typu 9 sa zaznamenajú ako text ASCII. V týchto záznamoch polí označených tagmi nie sú povolené žiadne binárne polia.

6.2.1.   Pole 9.001: Dĺžka logického záznamu (LEN – Logical Record Length)

V tomto povinnom poli vo formáte ASCII sa uvádza dĺžka logického záznamu s celkovým počtom bajtov vrátane každého znaku každého poľa v zázname.

6.2.2.   Pole 9.002: Znak označenia obrázku (IDC – Image Designation Character)

Toto povinné dvojbajtové pole sa používa na identifikáciu a určenie polohy údajov o markantoch. Znak označenia obrázku v tomto poli je rovnaký ako IDC v poli obsah súboru v zázname typu 1.

6.2.3.   Pole 9.003: Typ zobrazenia (IMP – Impression Type)

Týmto povinným jednobajtovým poľom sa opisuje spôsob, akým sa získala informácia vo forme daktyloskopického obrázku. Vloží sa doň hodnota ASCII príslušného kódu z tabuľky 4, ktorá vyjadruje typ zobrazenia.

6.2.4.   Pole 9.004: Formát markanta (FMT – Minutiæ Format)

Toto pole obsahuje znak „U“, aby sa uviedlo, že markanty sa formátujú podľa normy M1-378. Napriek tomu, že informácie môžu byť zašifrované v súlade s uvedenou normou, všetky dátové polia záznamu typu 9 musia ostať vo formáte textových polí ASCII.

6.2.5.   Pole 9.126: Informácie CBEFF (Common Biometric Exchange File Format)

Toto pole obsahuje tri informácie. Prvá položka obsahuje hodnotu „27“ (0x1B). Táto hodnota vyjadruje totožnosť vlastníka formátu CBEFF, ktorú pridelilo Medzinárodné združenie biometrických odvetví (IBIA) technickému výboru M1 INCITS. Kódom <US> sa táto položka oddeľuje od typu formátu CBEFF, ktorý má hodnotu „513“ (0x0201) na označenie, že tento záznam obsahuje len údaje o polohe a smere uhla bez informácií v rozšírenom dátovom bloku. Kódom <US> sa táto informácia oddelí aj od identifikátora produktu CBEFF (PID), ktorým sa určuje „vlastník“ šifrovacieho vybavenia. Túto hodnotu určí predajca. V prípade, že bola zverejnená, sa dá zistiť na webovej stránke IBIA (www.ibia.org).

6.2.6.   Pole 9.127: Identifikácia vybavenia na odber vzoriek

Toto pole obsahuje dve informácie oddelené separátorom <US>. Prvé obsahuje kód „APPF“ v prípade, že pôvodne použité vybavenie na získanie obrázku malo osvedčenie zhody potvrdzujúce súlad s dodatkom F (IAFIS Image Quality Specification, 29. januára 1999) špecifikácie FBI na elektronický prenos odtlačkov prstov CJIS-RS-0010. Ak takéto osvedčenie neexistovalo, pole bude obsahovať hodnotu „NONE“. Druhá informácia obsahuje identifikačné číslo vybavenia na odber vzoriek, čo je evidenčné číslo vybavenia, ktoré prideľuje predajca. Hodnota „0“ znamená, že identifikačné číslo nebolo nahlásené.

6.2.7.   Pole 9.128: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet pixelov na jednej horizontálnej línii prenášaného obrázku. Maximálna horizontálna veľkosť je obmedzená na 65 534 pixelov.

6.2.8.   Pole 9.129: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet horizontálnych línií na prenášanom obrázku. Maximálna vertikálna veľkosť je obmedzená na 65 534 pixelov.

6.2.9.   Pole 9.130: Jednotky zobrazenia (SLC – Scale Units)

Toto povinné pole vo formáte ASCII obsahuje jednotky, v ktorých sa opisuje vzorkovacia frekvencia obrázku (hustota pixelov). Jednotka („1“) v tomto poli znamená pixely na palec, zatiaľ čo dvojka („2“) označuje pixely na centimeter. Nula („0“) v tomto poli označuje, že sa nezadala žiadna stupnica. V tomto prípade sa zobrazovací pomer v pixeloch udáva na základe podielu HPS/VPS.

6.2.10.   Pole 9.131: Horizontálny rozsah v pixeloch (HPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov v horizontálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje horizontálnu zložku pomeru zobrazenia v pixeloch.

6.2.11.   Pole 9.132: Vertikálny rozsah v pixeloch (VPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov vo vertikálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje vertikálnu zložku pomeru zobrazenia v pixeloch.

6.2.12.   Pole 9.133: Zobrazenie odtlačku prsta

Toto povinné pole obsahuje číslo zobrazenia odtlačku prsta spojeného s údajmi v tomto zázname. Číslo zobrazenia začína nulou („0“) a rastie po jednej až do „15“.

6.2.13.   Pole 9.134: Poloha prsta (FGP – Finger Position)

Toto pole obsahuje kód, ktorým sa označuje poloha prsta, z ktorej vyplynuli informácie v danom zázname typu 9. Na označenie tejto polohy prsta alebo dlane sa zvolí kód medzi 1 a 10 z tabuľky 5 alebo príslušný kód dlane z tabuľky 10.

6.2.14.   Pole 9.135: Kvalita odtlačku prsta

Pole uvádza celkovú kvalitu údajov o markantoch a jeho hodnota je od 0 do 100. Toto číslo vyjadruje celkovú kvalitu záznamu odtlačku prsta a spája kvalitu pôvodného obrázku, výberu markantov a všetkých dodatočných operácií, ktoré mohli ovplyvniť záznam o markantoch.

6.2.15.   Pole 9.136: Počet markantov

Toto povinné pole obsahuje výpočet markantov v predmetnom logickom zázname.

6.2.16.   Pole 9.137: Údaje o markantoch odtlačku

Toto povinné pole obsahuje šesť informácií oddelených separátorom <US>. Pozostáva z niekoľkých podpolí, pričom každé z nich obsahuje podrobnosti o jednom markante. Celkový počet podpolí s markantmi musí zodpovedať počtu v poli 136. Prvá informácia je indexový počet markantov, ktorý začína číslom „1“ a rastie o „1“ pri každom ďalšom markante na odtlačku prsta. Druhou a treťou informáciou sú súradnice znaku v pixeloch na osi x a y. Štvrtá informácia vyjadruje uhol markanta v v jednotkách s dvojstupňovým rozlíšením. Táto hodnota je nezáporné číslo od 0 do 179. Piatou informáciou je typ markanta. Hodnota „0“ zastupuje markant typu „INÉ“, hodnota „1“ je zakončenie papilárnej línie a hodnota „2“ je rozdvojenie papilárnej línie. Šiestou informáciou je kvalita každého markanta. Táto hodnota je v rozmedzí od 1 (najnižšia kvalita) do 100 (najvyššia kvalita). Hodnota „0“ znamená, že informácia o kvalite nie je dostupná. Každé podpole musí byť od ďalšieho oddelené separátorom <RS>.

6.2.17.   Pole 9.138: Informácia o počte papilárnych línií

Toto pole je zložené zo súboru podpolí, z ktorých každé obsahuje tri informácie. Prvá informácia prvého podpoľa označuje metódu počítania papilárnych línií. Nula („0“) znamená, že nie je možné zistiť metódu sčítania papilárnych línií ani ich poradie v zázname. Číslica „1“ znamená že pri každom centrálnom markante sa údaje o počte papilárnych línií zisťovali smerom k susednému markantu v štyroch kvadrantoch a údaje za centrálny markant sa uvádzajú spoločne. Číslica „2“ znamená že pri každom centrálnom markante sa údaje o počte papilárnych línií zisťovali smerom k susednému markantu v ôsmich oktantoch a údaje za centrálny markant sa uvádzajú spoločne. Zvyšné dve informácie prvého podpoľa obsahujú obe nulu („0“). Informácie sa oddeľujú separátorom <US>. Následné podpolia budú obsahovať indexový počet centrálnych markantov ako prvú informáciu, indexový počet susediacich markantov ako druhú informáciu a počet prekrížených papilárnych línií ako tretiu informáciu. Podpolia sa oddeľujú separátorom <RS>.

6.2.18.   Pole 9.139: Informácie o jadre

Toto pole pozostáva z jedného podpoľa pre každé jadro, ktoré sa nachádza v pôvodnom obrázku. Každé podpole obsahuje tri informácie. Prvé dve informácie obsahujú súradnice na osi x a y v pixeloch. Tretia informácia obsahuje uhol jadra v dvojstupňových jednotkách. Táto hodnota je nezáporné číslo od 0 do 179. Viaceré jadrá sa oddelia separátorom <RS>.

6.2.19.   Pole 9.140: Informácie o delte

Toto pole pozostáva z jedného podpoľa pre každú deltu, ktorá sa nachádza v pôvodnom obrázku. Každé podpole obsahuje tri informácie. Prvé dve informácie obsahujú súradnice na osi x a y v pixeloch. Tretia informácia obsahuje uhol delty v dvojstupňových jednotkách. Táto hodnota je nezáporné číslo od 0 do 179. Viaceré jadrá sa oddelia separátorom <RS>.

7.   Logický záznam typu 13: Skrytý obrázok s rôznym rozlíšením

Logický záznam typu 13 s poliami ohraničenými tagmi obsahuje údaje vo forme obrázkov získané zo skrytých obrazcov. Tieto obrázky sú určené na prenos do agentúr, v ktorých sa z nich automaticky alebo prostredníctvom ľudského zásahu a spracovania získajú potrebné informácie.

Informácie, ktoré sa týkajú použitého skenovacieho rozlíšenia, veľkosti obrázku a iných parametrov vyžadovaných na spracovanie obrázku, sa v rámci záznamu nachádzajú vo forme polí ohraničených tagmi.

Tabuľka 7: Rozvrh záznamu typu 13: skrytý obrázok s rôznym rozlíšením

Ident	Cond.code	Field Number	Field Name	Char type	Field size per occurrence		Occur count		Max byte count
					min.	max.	min	max
LEN	M	13.001	LOGICAL RECORD LENGTH	N	4	8	1	1	15
IDC	M	13.002	IMAGE DESIGNATION CHARACTER	N	2	5	1	1	12
IMP	M	13.003	IMPRESSION TYPE	A	2	2	1	1	9
SRC	M	13.004	SOURCE AGENCY/ORI	AN	6	35	1	1	42
LCD	M	13.005	LATENT CAPTURE DATE	N	9	9	1	1	16
HLL	M	13.006	HORIZONTAL LINE LENGTH	N	4	5	1	1	12
VLL	M	13.007	VERTICAL LINE LENGTH	N	4	5	1	1	12
SLC	M	13.008	SCALE UNITS	N	2	2	1	1	9
HPS	M	13.009	HORIZONTAL PIXEL SCALE	N	2	5	1	1	12
VPS	M	13.010	VERTICAL PIXEL SCALE	N	2	5	1	1	12
CGA	M	13.011	COMPRESSION ALGORITHM	A	5	7	1	1	14
BPX	M	13.012	BITS PER PIXEL	N	2	3	1	1	10
FGP	M	13.013	FINGER POSITION	N	2	3	1	6	25
RSV		13.014 13.019	RESERVED FOR FUTURE DEFINITION	—	—	—	—	—	—
COM	O	13.020	COMMENT	A	2	128	0	1	135
RSV		13.021 13.199	RESERVED FOR FUTURE DEFINITION	—	—	—	—	—	—
UDF	O	13.200 13.998	USER-DEFINED FIELDS	—	—	—	—	—	—
DAT	M	13.999	IMAGE DATA	B	2	—	1	1	—

Kľúč k typu znakov: N = numerický, A = abecedný, AN = alfanumerický, B = binárny.

7.1.   Polia pre logický záznam typu 13

V nasledujúcich odsekoch sa opisujú údaje obsiahnuté v každom poli logického záznamu typu 13.

V rámci logických záznamov typu 13 sa vstupy robia do číslovaných polí. Vyžaduje sa usporiadanie prvých dvoch polí záznamu a pole obsahujúce údaje vo forme obrázku musí byť posledným fyzickým poľom v zázname. V tabuľke 7 sa pre každé pole v zázname typu 13 nachádza „stavový kód“ (buď „M“ označujúce povinné pole, alebo „O“ označujúce pole nepovinné), číslo poľa, typ znaku, veľkosť poľa a obmedzenie výskytu. V poslednom stĺpci sa nachádza maximálna veľkosť v bajtoch, ktorá vychádza z trojmiestneho čísla poľa. Ak sa v čísle poľa nachádza viac číslic, zvýši sa aj maximálny počet bajtov. Dve položky v stĺpci „veľkosť poľa pri každom výskyte“ zahŕňajú všetky separátory, ktoré sú v poli použité. Údaj v stĺpci „maximálny počet bajtov“ zahŕňa číslo poľa, informáciu a všetky separátory vrátane separátora „GS“.

7.1.1.   Pole 13.001: Dĺžka logického záznamu (LEN – Logical Record Length)

Toto povinné pole vo formáte ASCII obsahuje informáciu o celkovom počte bajtov v logickom zázname typu 13. Pole 13.001 špecifikuje dĺžku záznamu vrátane každého znaku každého poľa v zázname a separátorov.

7.1.2.   Pole 13.002: Znak označenia obrázku (IDC – Image Designation Character)

Toto povinné pole vo formáte ASCII sa používa na identifikáciu údajov vo forme latentného obrázku, ktoré sa nachádzajú v zázname. Tento IDC je rovnaký ako IDC v poli obsah súboru (CNT) v zázname typu 1.

7.1.3.   Pole 13.003: Typ zobrazenia (IMP – Impression Type)

Týmto povinným jednobajtovým alebo dvojbajtovým poľom vo formáte ASCII sa opisuje spôsob, akým sa získala informácia vo forme latentného obrázku. Do tohto poľa sa vloží príslušný kód latentného obrázku z tabuľky 4 (pri odtlačkoch prstov) alebo z tabuľky 9 (odtlačok dlane).

7.1.4.   Pole 13.004: Agentúra pôvodu/ORI (SRC – Source Agency)

Toto povinné pole vo formáte ASCII obsahuje totožnosť správneho orgánu alebo organizácie, ktorá pôvodne získala obrázok v zázname. Za bežných okolností sa v tomto poli uvedie identifikátor agentúry pôvodu (ORI – Originating Agency Identifier) agentúry, ktorá získala obrázok. Pozostáva z dvoch informácií v tomto formáte: CC/agency.

Prvá informácia obsahuje kód krajiny v databáze Interpolu, ktorý pozostáva z dvoch alfanumerických znakov. Druhá informácia, agency (agentúra), je voliteľný text na identifikáciu agentúry obsahujúci najviac 32 alfanumerických znakov.

7.1.5.   Pole 13.005: Dátum získania latentného obrázku (LCD – Latent Capture Date)

V tomto povinnom poli vo formáte ASCII sa uvádza dátum získania latentného obrázku, ktorý sa nachádza v zázname. Tento dátum sa uvádza ako osem číslic vo formáte CCRRMMDD. CCRR je rok získania obrázku; znaky MM sú desiatkové a jednotkové hodnoty mesiaca a znaky DD zastupujú rovnaké hodnoty pri dni v danom mesiaci. Napríklad, dátum 20000229 znamená 29. februára 2000. Úplný dátum musí skutočne existovať.

7.1.6.   Pole 13.006: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet pixelov na jednej horizontálnej línii prenášaného obrázku.

7.1.7.   Pole 13.007: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet horizontálnych línií na prenášanom obrázku.

7.1.8.   Pole 13.008: Jednotky zobrazenia (SLC – Scale Units)

Toto povinné pole vo formáte ASCII obsahuje jednotky, v ktorých sa opisuje vzorkovacia frekvencia obrázku (hustota pixelov). Jednotka („1“) v tomto poli znamená pixely na palec, zatiaľ čo dvojka („2“) označuje pixely na centimeter. Nula („0“) v tomto poli označuje, že sa nezadala žiadna škála. V tomto prípade sa zobrazovací pomer v pixeloch udáva na základe podielu HPS/VPS.

7.1.9.   Pole 13.009: Horizontálny rozsah v pixeloch (HPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov v horizontálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje horizontálnu zložku pomeru zobrazenia v pixeloch.

7.1.10.   Pole 13.010: Vertikálny rozsah v pixeloch (VPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov vo vertikálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje vertikálnu zložku pomeru zobrazenia v pixeloch.

7.1.11.   Pole 13.011: Kompresný algoritmus (CGA – Compression Algorithm)

V tomto povinnom poli ASCII sa špecifikuje algoritmus, ktorý sa používa na kompresiu obrázkov v odtieňoch šedej. Kompresné kódy sa nachádzajú v dodatku 7.

7.1.12.   Pole 13.012: Bity na pixel (BPX)

Toto povinné pole vo formáte ASCII obsahuje počet bitov, ktoré predstavujú jeden pixel. Pri bežných hodnotách odtieňov šedej v škále od „0“ do „255“ sa v ňom nachádza číslica „8“. Ak sa v tomto poli nachádza číslica vyššia ako „8“, predstavuje pixel v odtieni šedej s vyššou presnosťou.

7.1.13.   Pole 13.013: Poloha prsta/dlane (FGP – Finger/Palm Position)

V tomto povinnom poli označenom tagmi sa uvádza jedna alebo viac polôh prsta alebo dlane, ktoré sa môžu zhodovať so skrytým obrázkom. Číslo v desiatkovej sústave, ktoré zodpovedá známej alebo najpravdepodobnejšej polohe prsta, sa vyberie z tabuľky 5, alebo ktoré zodpovedá najpravdepodobnejšej polohe dlane, sa vyberie z tabuľky 10 a vloží sa ako jednomiestne alebo dvojmiestne podpole vo formáte ASCII. Na ďalšie polohy prstov alebo dlaní sa môže odkázať vložením alternatívnych kódov polôh vo forme podpolí oddelených separátorom „RS“. Kód „0“ pre „neznámy prst“ sa použije pri odkaze na ktorúkoľvek polohu prsta od 1 do 10. Pri odkaze na všetky polohy dlane v zozname sa použije kód „20“ pre „neznámu dlaň“.

7.1.14.   Polia 13.014 – 13.019: Rezervované na vymedzenie v budúcnosti (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

7.1.15.   Pole 13.020: Poznámka (COM – Comment)

Toto nepovinné pole sa môže použiť na vloženie poznámok alebo iných textových informácií vo formáte ASCII s údajmi o skrytom obrázku.

7.1.16.   Polia 13.021 – 13.199: Rezervované na vymedzenie v budúcnosti (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

7.1.17.   Polia 13.200 – 13.998: Polia vymedzené používateľmi (UDF – User-defined Fields)

Tieto polia vymedzuje používateľ a využijú sa v budúcnosti. Používateľ definuje aj ich veľkosť a obsah, a to v súlade s požiadavkami agentúry určenia. Ak existujú, musia obsahovať textové informácie vo formáte ASCII.

7.1.18.   Pole 13.999: Údaje z obrázku (DAT – Image Data)

Toto pole obsahuje všetky údaje zo získaného latentného obrázku. Jeho číslo je vždy 999 a musí byť posledným fyzickým poľom v zázname. Napríklad, po poli „13.999:“ nasleduje údaj vo forme obrázku zastúpený binárnymi znakmi.

Každý pixel nekomprimovaného údaju v odtieňoch šedej je vyjadrený ôsmimi bitmi (pri 256 odtieňoch šedej) obsiahnutými v jednom bajte. Ak je údaj v poli BPX 13.012 vyšší alebo nižší ako „8“, počet bajtov na pixel bude iný. Ak sa použije kompresia, údaje v pixeloch sa skomprimujú v súlade s technikou špecifikovanou v poli CGA.

7.2.   Koniec logického záznamu typu 13: Skrytý obrázok s rôznym rozlíšením

Kvôli konzistentnosti sa po poslednom bajte údaju z poľa 13.999 použije separátor „FS“ na oddelenie poľa od nasledujúceho logického záznamu. Tento separátor sa musí použiť aj v poli „dĺžka“ logického záznamu typu 13.

8.   Logický záznam typu 15: Odtlačok dlane s rôznym rozlíšením

Logický záznam typu 15 obsahujúci polia ohraničené tagmi obsahuje údaje z obrázku s odtlačkom dlane spolu so súvisiacimi pevnými textovými poliami a poliami definovanými používateľmi a používa sa na výmenu takýchto údajov. Informácie, ktoré sa týkajú použitého skenovacieho rozlíšenia, veľkosti obrázku a iných parametrov alebo poznámok vyžadovaných na spracovanie obrázku, sa v rámci záznamu nachádzajú vo forme polí ohraničených tagmi. Obrázky odtlačkov dlaní poskytnuté iným agentúram spracujú agentúry určenia tak, aby z nich získali potrebné informácie na účely zistenia zhody.

Údaje vo forme obrázku sa získavajú priamo od dotknutej osoby pomocou zariadenia na biometrické skenovanie alebo z karty z odtlačkom dlane alebo iného média, na ktorom sú uložené odtlačky dlane dotknutej osoby.

Každá metóda použitá na získanie obrázkov odtlačkov dlane by mala umožniť získanie súboru obrázkov z každej ruky. Tento súbor by mal obsahovať dlaň dominantnej ruky vo forme jedného naskenovaného obrázku a oblasť celej dlane od zápästia až po končeky prstov na jednom alebo dvoch naskenovaných obrázkoch. Ak sa na celú dlaň použijú dva obrázky, spodný obrázok by mal zahŕňať oblasť od zápästia až po vrch medziprstovej oblasti (tretí prstový kĺb) vrátane oblasti palcovej a malíčkovej podušky. Vrchný obrázok by mal zahŕňať priestor od spodku medziprstovej oblasti až po končeky prstov. Takéto rozdelenie poskytuje dostatočné prekrytie oboch obrázkov, keďže oba zahŕňajú medziprstovú oblasť dlane. Porovnaním štruktúry a podrobných znakov papilárnych línií v tejto spoločnej oblasti môže osoba, ktorá obrázok skúma, presvedčivo vyhlásiť, že oba obrázky pochádzajú z rovnakej dlane.

Keďže sa odtlačok dlane môže použiť na rôzne účely, môže obsahovať jednu alebo viac jedinečných zobrazených oblastí získaných z dlane alebo prsta. Úplný súbor záznamov odtlačkov dlane jednotlivca bude za bežných okolností obsahovať dlaň dominantnej ruky a úplný obrázok alebo úplné obrázky odtlačkov dlaní oboch rúk. Keďže logický záznam obrázku vo forme polí označených tagmi môže obsahovať len jedno binárne pole, pre každú dlaň dominantnej ruky sa bude vyžadovať jeden záznam typu 15, zatiaľ čo pre úplný odtlačok dlane bude potrebný jeden alebo dva takéto záznamy. Preto pri bežnej transakcii s odtlačkami dlaní sa na zobrazenie odtlačkov dlaní dotknutej osoby budú vyžadovať štyri až šesť záznamov typu 15.

8.1.   Polia pre logický záznam typu 15

V nasledujúcich odsekoch sa opisujú údaje obsiahnuté v každom poli logického záznamu typu 15.

V rámci logických záznamov typu 15 sa vstupy robia do číslovaných polí. Vyžaduje sa usporiadanie prvých dvoch polí záznamu a pole obsahujúce údaje vo forme obrázku musí byť posledným fyzickým poľom v zázname. V tabuľke 8 sa pre každé pole v zázname typu 15 nachádza „stavový kód“ (buď „M“ označujúce povinné pole alebo „O“ označujúce pole nepovinné), číslo poľa, typ znaku, veľkosť poľa a obmedzenie výskytu. V poslednom stĺpci sa nachádza maximálna veľkosť v bajtoch, ktorá vychádza z trojmiestneho čísla poľa. Ak sa v čísle poľa nachádza viac číslic, zvýši sa aj maximálny počet bajtov. Dve položky v stĺpci „veľkosť poľa pri každom výskyte“ zahŕňajú všetky separátory, ktoré sú v poli použité. Údaj v stĺpci „maximálny počet bajtov“ zahŕňa číslo poľa, informáciu a všetky separátory vrátane separátora „GS“.

8.1.1.   Pole 15.001: Dĺžka logického záznamu (LEN – Logical Record Length)

Toto povinné pole vo formáte ASCII obsahuje informáciu o celkovom počte bajtov v logickom zázname typu 15. Pole 15.001 špecifikuje dĺžku záznamu vrátane každého znaku každého poľa v zázname a separátorov.

8.1.2.   Pole 15.002: Znak označenia obrázku (IDC – Image Designation Character)

Toto povinné pole vo formáte ASCII sa používa na identifikáciu údajov vo forme obrázku odtlačku dlane, ktoré sa nachádzajú v zázname. Tento IDC je rovnaký ako IDC v poli obsah súboru (CNT) v zázname typu 1.

8.1.3.   Pole 15.003: Typ zobrazenia (IMP – Impression Type)

Týmto povinným jednobajtovým poľom vo formáte ASCII sa uvádza spôsob, akým sa získala informácia vo forme obrázku odtlačku dlane. Do tohto poľa sa vpíše vhodný kód vybraný z tabuľky 9.

8.1.4.   Pole 15.004: Agentúra pôvodu/ORI (SRC – Source Agency)

Toto povinné pole vo formáte ASCII obsahuje totožnosť správneho orgánu alebo organizácie, ktorá pôvodne získala obrázok v zázname. Za bežných okolností sa v tomto poli uvedie identifikátor agentúry pôvodu (ORI – Originating Agency Identifier) agentúry, ktorá získala obrázok. Pozostáva z dvoch informácií v tomto formáte: CC/agency.

Prvá informácia obsahuje kód krajiny v databáze Interpolu, ktorý pozostáva z dvoch alfanumerických znakov. Druhá informácia, agency (agentúra), je voliteľný text na identifikáciu agentúry obsahujúci najviac 32 alfanumerických znakov.

8.1.5.   Pole 15.005: Dátum získania odtlačku dlane (PCD – Palmprint Capture Date)

Toto povinné pole vo formáte ASCII obsahuje dátum získania obrázku odtlačku dlane. Tento dátum sa uvádza ako osem číslic vo formáte CCRRMMDD. CCRR je rok získania obrázku; znaky MM sú desiatkové a jednotkové hodnoty mesiaca a znaky DD zastupujú rovnaké hodnoty pri dni v danom mesiaci. Napríklad, dátum 20000229 znamená 29. februára 2000. Úplný dátum musí skutočne existovať.

8.1.6.   Pole 15.006: Dĺžka horizontálnej línie (HLL – Horizontal Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet pixelov na jednej horizontálnej línii prenášaného obrázku.

8.1.7.   Pole 15.007: Dĺžka vertikálnej línie (VLL – Vertical Line Length)

Toto povinné pole vo formáte ASCII obsahuje počet horizontálnych línií na prenášanom obrázku.

8.1.8.   Pole 15.008: Jednotky zobrazenia (SLC – Scale Units)

Toto povinné pole vo formáte ASCII obsahuje jednotky, v ktorých sa opisuje vzorkovacia frekvencia obrázku (hustota pixelov). Jednotka („1“) v tomto poli znamená pixely na palec, zatiaľ čo dvojka („2“) označuje pixely na centimeter. Nula („0“) v tomto poli označuje, že sa nezadala žiadna škála. V tomto prípade sa zobrazovací pomer v pixeloch udáva na základe podielu HPS/VPS.

8.1.9.   Pole 15.009: Horizontálny rozsah v pixeloch (HPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov v horizontálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje horizontálnu zložku pomeru zobrazenia v pixeloch.

8.1.10.   Pole 15.010: Vertikálny rozsah v pixeloch (VPS)

Toto povinné pole vo formáte ASCII špecifikuje celočíselnú hustotu pixelov vo vertikálnom smere za predpokladu, že pole SLC obsahuje znak „1“ alebo „2“. V iných prípadoch označuje vertikálnu zložku pomeru zobrazenia v pixeloch.

Tabuľka 8: Rozvrh záznamu typu 15: odtlačok dlane s rôznym rozlíšením

Ident	Cond.code	Field Number	Field Name	Char type	Field size per occurrence		Occur count		Max byte count
					min.	max.	min	max
LEN	M	15.001	LOGICAL RECORD LENGTH	N	4	8	1	1	15
IDC	M	15.002	IMAGE DESIGNATION CHARACTER	N	2	5	1	1	12
IMP	M	15.003	IMPRESSION TYPE	N	2	2	1	1	9
SRC	M	15.004	SOURCE AGENCY/ORI	AN	6	35	1	1	42
PCD	M	15.005	PALMPRINT CAPTURE DATE	N	9	9	1	1	16
HLL	M	15.006	HORIZONTAL LINE LENGTH	N	4	5	1	1	12
VLL	M	15.007	VERTICAL LINE LENGTH	N	4	5	1	1	12
SLC	M	15.008	SCALE UNITS	N	2	2	1	1	9
HPS	M	15.009	HORIZONTAL PIXEL SCALE	N	2	5	1	1	12
VPS	M	15.010	VERTICAL PIXEL SCALE	N	2	5	1	1	12
CGA	M	15.011	COMPRESSION ALGORITHM	AN	5	7	1	1	14
BPX	M	15.012	BITS PER PIXEL	N	2	3	1	1	10
PLP	M	15.013	PALMPRINT POSITION	N	2	3	1	1	10
RSV		15.014 15.019	RESERVED FOR FUTURE INCLUSION	—	—	—	—	—	—
COM	O	15.020	COMMENT	AN	2	128	0	1	128
RSV		15.021 15.199	RESERVED FOR FUTURE INCLUSION	—	—	—	—	—	—
UDF	O	15.200 15.998	USER-DEFINED FIELDS	—	—	—	—	—	—
DAT	M	15.999	IMAGE DATA	B	2	—	1	1	—

Tabuľka 9: Typ zobrazenia dlane

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.   Pole 15.011: Kompresný algoritmus (CGA – Compression Algorithm)

V tomto povinnom poli ASCII sa špecifikuje algoritmus, ktorý sa používa na kompresiu obrázkov v odtieňoch šedej. Údaj „NONE“ v tomto poli znamená, že údaje v zázname nie sú komprimované. Pri obrázkoch, ktoré sa majú komprimovať, sa v tomto poli uvedie uprednostňovaná metóda kompresie obrázkov s odtlačkami všetkých desiatich prstov. Platné kompresné kódy sa uvádzajú v dodatku 7.

8.1.12.   Pole 15.012: Bity na pixel (BPX)

Toto povinné pole vo formáte ASCII obsahuje počet bitov, ktoré predstavujú jeden pixel. Pri bežných hodnotách odtieňov šedej v škále od „0“ do „255“ sa v ňom nachádza číslica „8“. Ak sa v tomto poli nachádza číslica vyššia alebo nižšia ako „8“, predstavuje pixel v odtieni šedej s vyššou alebo nižšou presnosťou.

Tabuľka 10: Kódy, oblasti a veľkosti dlaní

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
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.   Pole 15.013: Poloha odtlačku dlane (PLP – Palmprint Position)

Toto povinné pole vo formáte ASCII obsahuje polohu odtlačku dlane, ktorá zodpovedá obrázku odtlačku dlane. Číselný kód v desiatkovej sústave zodpovedajúci známej alebo najpravdepodobnejšej polohe odtlačku dlane sa vyberie z tabuľky 10 a vloží ako dvojmiestne podpole vo formáte ASCII. V tabuľke 10 sa vymedzujú aj maximálne veľkosti a rozmery pri každej z možných polôh odtlačku dlane.

8.1.14.   Polia 15.014 – 15.019: Rezervované pre budúce vymedzenie (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

8.1.15.   Pole 15.020: Poznámka (COM – Comment)

Toto nepovinné pole sa môže použiť na vloženie poznámok alebo iných textových informácií vo formáte ASCII s údajmi o obrázku odtlačku dlane.

8.1.16.   Polia 15.021 – 15.199: Rezervované pre budúce vymedzenie (RSV – Reserved for future definition)

Tieto polia sú rezervované na zahrnutie do budúcich revízií tejto normy. Žiadne z nich sa nepoužije na tejto úrovni revízie. Ak sa predsa len vyskytnú, majú sa ignorovať.

8.1.17.   Polia 15.200 – 15.998: Polia vymedzené používateľmi (UDF – User-defined Fields)

Tieto polia vymedzuje používateľ a využijú sa v budúcnosti. Používateľ definuje aj ich veľkosť a obsah, a to v súlade s požiadavkami agentúry určenia. Ak existujú, musia obsahovať textové informácie vo formáte ASCII.

8.1.18.   Pole 15.999: Údaje z obrázku (DAT – Image Data)

Toto pole obsahuje všetky údaje zo získaného obrázku odtlačku dlane. Jeho číslo je vždy 999 a musí byť posledným fyzickým poľom v zázname. Napríklad, po poli „15.999:“ nasleduje údaj vo forme obrázku zastúpený binárnymi znakmi. Každý pixel nekomprimovaného údaju v stupňoch šedej je vyjadrený ôsmimi bitmi (pri 256 odtieňoch šedej) obsiahnutými v jednom bajte. Ak je údaj v poli BPX 15.012 vyšší alebo nižší ako „8“, počet bajtov na pixel bude iný. Ak sa použije kompresia, údaje v pixeloch sa skomprimujú v súlade s technikou špecifikovanou v poli CGA.

8.2.   Koniec logického záznamu typu 15: Odtlačok dlane s rôznym rozlíšením

Kvôli konzistentnosti sa po poslednom bajte údaju z poľa 15.999 použije separátor „FS“ na oddelenie poľa od nasledujúceho logického záznamu. Tento separátor sa musí použiť aj v poli „dĺžka“ logického záznamu typu 15.

8.3.   Ďalšie logické záznamy typu 15: Odtlačok dlane s rôznym rozlíšením

Do súboru sa môžu vložiť ďalšie záznamy typu 15. Pre každý ďalší odtlačok dlane sa vyžaduje úplný logický záznam typu 15 spolu so separátorom „FS“.

Tabuľka 11: Maximálny počet kandidátov prijatých na overenie na jeden prenos

Type of AFIS Search	TP/TP	LT/TP	LP/PP	TP/UL	LT/UL	PP/ULP	LP/ULP
Maximum Number of Candidates	1	10	5	5	5	5	5

Typy vyhľadávaní:

TP/TP: obrázok s odtlačkami desiatich prstov proti obrázku s odtlačkami desiatich prstov,

LT/TP: skrytý odtlačok prsta proti obrázku s odtlačkami desiatich prstov,

LP/PP: skrytý odtlačok dlane proti odtlačku dlane,

TP/UL: obrázok s odtlačkami desiatich prstov proti nevyriešenému latentnému odtlačku prsta,

LT/UL: skrytý odtlačok prsta proti nevyriešenému latentnému odtlačku prsta,

PP/ULP: odtlačok dlane oproti nevyriešenému latentnému odtlačku dlane,

LP/ULP: skrytý odtlačok dlane oproti nevyriešenému latentnému odtlačku dlane.

9.   Dodatky ku kapitole 2 (výmena daktyloskopických údajov)

9.1.   Dodatok 1: Oddeľovacie kódy ASCII

ASCII	Position (2)	Description
LF	1/10	Separates error codes in field 2.074
FS	1/12	Separates logical records of a file
GS	1/13	Separates fields of a logical record
RS	1/14	Separates the subfields of a record field
US	1/15	Separates individual information items of the field or subfield

9.2.   Dodatok 2: Výpočet alfanumerických kontrolných znakov

Pre TCN a TCR (polia 1.09 a 1.10):

Číslo zodpovedajúce kontrolnému znaku sa vytvorí na základe tohto vzorca:

(RR * 108 + SSSSSSSS) Modulo 23,

kde RR sú posledné dve číslice roka a SSSSSSSS je sériové číslo.

Kontrolný znak sa potom vytvorí na základe kontrolnej tabuľky, ktorá sa nachádza nižšie.

Pre CRO (pole 2.010)

Číslo zodpovedajúce kontrolnému znaku sa vytvorí na základe tohto vzorca:

(RR * 106 + NNNNNN) Modulo 23,

kde RR sú posledné dve číslice roka a NNNNNN je sériové číslo.

Kontrolný znak sa potom vytvorí na základe kontrolnej tabuľky, ktorá sa nachádza nižšie.

Kontrolná tabuľka kontrolných znakov

1-A	9-J	17-T
2-B	10-K	18-U
3-C	11-L	19-V
4-D	12-M	20-W
5-E	13-N	21-X
6-F	14-P	22-Y
7-G	15-Q	0-Z
8-H	16-R

9.3.   Dodatok 3: Znakové kódy

7-bitové kódy ANSI na výmenu informácií

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.   Dodatok 4: Súhrn transakcií

Záznam typu 1 (povinné)

Identifier	Field Number	Field Name	CPS/PMS	SRE	ERR
LEN	1.001	Logical Record Length	M	M	M
VER	1.002	Version Number	M	M	M
CNT	1.003	File Content	M	M	M
TOT	1.004	Type of Transaction	M	M	M
DAT	1.005	Date	M	M	M
PRY	1.006	Priority	M	M	M
DAI	1.007	Destination Agency	M	M	M
ORI	1.008	Originating Agency	M	M	M
TCN	1.009	Transaction Control Number	M	M	M
TCR	1.010	Transaction Control Reference	C	M	M
NSR	1.011	Native Scanning 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

V stĺpci s podmienečnosťou:

O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou, že transakcia je odpoveďou pre agentúru pôvodu (conditional).

Záznam typu 2 (povinné)

Identifier	Field Number	Field Name	CPS/PMS	MPS/MMS	SRE	ERR
LEN	2.001	Logical Record Length	M	M	M	M
IDC	2.002	Image Designation Character	M	M	M	M
SYS	2.003	System Information	M	M	M	M
CNO	2.007	Case Number	—	M	C	—
SQN	2.008	Sequence Number	—	C	C	—
MID	2.009	Latent Identifier	—	C	C	—
CRN	2.010	Criminal Reference Number	M	—	C	—
MN1	2.012	Miscellaneous Identification Number	—	—	C	C
MN2	2.013	Miscellaneous Identification Number	—	—	C	C
MN3	2.014	Miscellaneous Identification Number	—	—	C	C
MN4	2.015	Miscellaneous Identification Number	—	—	C	C
INF	2.063	Additional Information	O	O	O	O
RLS	2.064	Respondents List	—	—	M	—
ERM	2.074	Status/Error Message Field	—	—	—	M
ENC	2.320	Expected Number of Candidates	M	M	—	—

V stĺpci s podmienečnosťou:

O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou, že sú dostupné údaje (conditional).

*

=

ak je prenos údajov v súlade s vnútroštátnymi právnymi predpismi (nepatrí do rozhodnutia 2008/615/SVV).

9.5.   Dodatok 5: Vymedzenia záznamov typu 1

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	1.001	Logical Record Length	N	1.001:230{GS}
VER	M	1.002	Version Number	N	1.002:0300{GS}
CNT	M	1.003	File Content	N	1.003:1{US}15{RS}2{US}00{RS}4{US}01{RS}4{US}02{RS}4{US}03{RS}4{US}04{RS}4{US}05{RS}4{US}06{RS}4{US}07{RS}4{US}08{RS}4{US}09{RS}4{US}10{RS}4{US}11{RS}4{US}12{RS}4{US}13{RS}4{US}14{GS}
TOT	M	1.004	Type of Transaction	A	1.004:CPS{GS}
DAT	M	1.005	Date	N	1.005:20050101{GS}
PRY	M	1.006	Priority	N	1.006:4{GS}
DAI	M	1.007	Destination Agency	1*	1.007:DE/BKA{GS}
ORI	M	1.008	Originating Agency	1*	1.008:NL/NAFIS{GS}
TCN	M	1.009	Transaction Control Number	AN	1.009:0200000004F{GS}
TCR	C	1.010	Transaction Control Reference	AN	1.010:0200000004F{GS}
NSR	M	1.011	Native Scanning Resolution	AN	1.011:19.68{GS}
NTR	M	1.012	Nominal Transmitting Resolution	AN	1.012:19.68{GS}
DOM	M	1.013	Domain Name	AN	1.013: INT-I{US}4.22{GS}
GMT	M	1.014	Greenwich Mean Time	AN	1.014:20050101125959Z

V stĺpci s podmienečnosťou: O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou (conditional).

V stĺpci s typom znaku: A = abecedný, N = numerický, B = binárny.

1* Povolené znaky pre názov agentúry sú [„0..9“, „A..Z“, „a..z“, „_“, „.“, „“, „-“].

9.6.   Dodatok 6: Vymedzenia záznamov typu 2

Tabuľka A.6.1: Transakcie CPS a PMS

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CRN	M	2.010	Criminal Reference Number	AN	2.010:DE/E999999999{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ENC	M	2.320	Expected Number of Candidates	N	2.320:1{GS}

Tabuľka A.6.2: Transakcia SRE

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CRN	C	2.010	Criminal Reference Number	AN	2.010:NL/2222222222{GS}
MN1	C	2.012	Miscellaneous Identification Number	AN	2.012:E999999999{GS}
MN2	C	2.013	Miscellaneous Identification Number	AN	2.013:E999999999{GS}
MN3	C	2.014	Miscellaneous Identification Number	N	2.014:0001{GS}
MN4	C	2.015	Miscellaneous Identification Number	A	2.015:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
RLS	M	2.064	Respondents List	AN	2.064:CPS{RS}I{RS}001/001{RS}999999{GS}

Tabuľka A.6.3: Transakcia ERR

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
MN1	M	2.012	Miscellaneous Identification Number	AN	2.012:E999999999{GS}
MN2	C	2.013	Miscellaneous Identification Number	AN	2.013:E999999999{GS}
MN3	C	2.014	Miscellaneous Identification Number	N	2.014:0001{GS}
MN4	C	2.015	Miscellaneous Identification Number	A	2.015:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ERM	M	2.074	Status/Error Message Field	AN	2.074: 201: IDC - 1 FIELD 1.009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION {GS}

Tabuľka A.6.4: Transakcie MPS a MMS

Identifier	Condition	Field Number	Field Name	Character Type	Example Data
LEN	M	2.001	Logical Record Length	N	2.001:909{GS}
IDC	M	2.002	Image Designation Character	N	2.002:00{GS}
SYS	M	2.003	System Information	N	2.003:0422{GS}
CNO	M	2.007	Case Number	AN	2.007:E999999999{GS}
SQN	C	2.008	Sequence Number	N	2.008:0001{GS}
MID	C	2.009	Latent Identifier	A	2.009:A{GS}
INF	O	2.063	Additional Information	1*	2.063:Additional Information 123{GS}
ENC	M	2.320	Expected Number of Candidates	N	2.320:1{GS}

V stĺpci s podmienečnosťou: O = nepovinné (optional), M = povinné (mandatory), C = s podmienkou (conditional).

V stĺpci s typom znaku: A = abecedný, N = numerický, B = binárny.

1* Povolené znaky sú [„0..9“, „A..Z“, „a..z“, „_“, „.“, „“, „-“].

9.7.   Dodatok 7: Kódy na kompresiu odtieňov šedej

Kompresné kódy

Compression	Value	Remarks
Wavelet Scalar Quantization Grayscale Fingerprint Image Compression Specification IAFIS-IC-0010(V3), dated December 19, 1997	WSQ	Algorithm to be used for the compression of grayscale images in Type-4, Type-7 and Type-13 to Type-15 records. Shall not be used for resolutions > 500dpi.
JPEG 2000 [ISO 15444/ITU T.800]	J2K	To be used for lossy and losslessly compression of grayscale images in Type-13 to Type-15 records. Strongly recommended for resolutions > 500 dpi

9.8.   Dodatok 8: Špecifikácia pošty

S cieľom zlepšiť vnútorný rozvrh práce sa do predmetu poštovej správy pri transakcii typu PRUEM napíše kód krajiny (CC) členského štátu, ktorý správu odosiela a typ transakcie (TOT, pole 1.004).

Formát: CC/type of transaction

Príklad: „DE/CPS“.

Telo správy môže ostať prázdne.

Kapitola 3: Výmena údajov z evidencie vozidiel

1.   Spoločný súbor údajov na automatizované vyhľadávanie údajov z evidencie vozidiel

1.1.   Vymedzenie pojmov

Povinné a nepovinné prvky údajov ustanovené v článku 16 ods. 4 sú vymedzené takto:

Povinné (M)

Tento prvok sa musí oznámiť v prípade, že sa informácia nachádza vo vnútroštátnom registri členského štátu. Preto v prípade dostupnosti informácie existuje povinnosť jej výmeny.

Nepovinné (O)

Tento prvok sa môže oznámiť v prípade, že sa informácia nachádza vo vnútroštátnom registri členského štátu. Preto neexistuje povinnosť výmeny informácie ani v prípade, ak je dostupná.

Ak sa prvok v súbore údajov identifikuje ako osobitne dôležitý vzhľadom na rozhodnutie 2008/615/SVV, označí sa (znakom Y).

1.2.   Vyhľadávanie podľa vozidla/vlastníka/držiteľa

1.2.1.   Spúšťacie mechanizmy vyhľadávania

Existujú dva spôsoby vyhľadávania informácií, ktoré sa vymedzujú v ďalšom odseku:

—	podľa čísla karosérie (VIN), referenčného dátumu a času (nepovinné),

—	podľa čísla poznávacej značky, čísla karosérie (VIN) (nepovinné), referenčného dátumu a času (nepovinné).

Na základe týchto kritérií vyhľadávania sa ako výsledok vrátia informácie týkajúce sa jedného alebo viacerých vozidiel. Ak sa musí vrátiť informácia o len jednom vozidle, všetky jej prvky sa vrátia v rámci jednej odpovede. Ak sa nájde viac než jedno vozidlo, informácie, ktoré sa vrátia, určí samotný dožiadaný členský štát; budú to buď všetky informácie, alebo len informácie potrebné na rozšírenie vyhľadávania (napr. z dôvodu ochrany súkromia alebo z dôvodu výkonu vyhľadávača).

Informácie potrebné na rozšírenie vyhľadávania sa uvádzajú v odseku 1.2.2.1. V odseku 1.2.2.2 sa uvádza kompletný súbor informácií.

Pri vyhľadávaní podľa čísla karosérie a referenčného dátumu a času sa môže vyhľadávať v databázach jedného alebo všetkých zúčastnených členských štátov.

Ak sa vyhľadáva podľa poznávacej značky a referenčného dátumu a času, musí sa vyhľadávať v databáze konkrétneho členského štátu.

Bežne sa vyhľadáva s použitím skutočného času a dátumu, ale je možné použiť aj referenčný dátum a čas v minulosti. Ak sa vyhľadáva s referenčným dátumom a časom v minulosti a informácie z minulosti nie sú v registri členského štátu dostupné, pretože jednoducho vôbec neexistujú, ako odpoveď sa môžu poskytnúť aktuálne informácie, pričom sa táto skutočnosť výslovne uvedie.

1.2.2.   Súbor údajov

1.2.2.1.

Informácie potrebné na rozšírenie vyhľadávania Item M/O (3) Remarks Prüm Y/N (4) Data relating to vehicles       Licence number M   Y Chassis number/VIN M   Y Country of registration M   Y Make M [D.1 (5)] e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y EU Category Code M (J) mopeds, motorbikes, cars etc. Y

1.2.2.2.

Kompletný súbor údajov Item M/O (6) Remarks Prüm Y/N Data relating to holders of the vehicle   [C.1 (7)] The data refer to the holder of the specific registration certificate.   Registration holders’ (company) name M (C.1.1.) separate fields will be used for surname, infixes, titles etc., and the name in printable format will be communicated Y First name M (C.1.2) separate fields for first name(s) and initials will be used, and the name in printable format will be communicated Y Address M (C.1.3) separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Country of residence etc., and the Address in printable format will be communicated Y Gender M Male, female Y Date of birth M   Y Legal entity M individual, association, company, firm etc. Y Place of Birth O   Y ID Number O An identifier that uniquely identifies the person or the company. N Type of ID Number O The type of ID Number (e.g. passport number). N Start date holdership O Start date of the holdership of the car. This date will often be the same as printed under (I) on the registration certificate of the vehicle. N End date holdership O End data of the holdership of the car. N Type of holder O If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate: — is the vehicle owner — is not the vehicle owner — is not identified by the registration certificate as being the vehicle owner N Data relating to owners of the vehicle   (C.2)   Owners’ (company) name M (C.2.1) Y First name M (C.2.2) Y Address M (C.2.3) Y Gender M male, female Y Date of birth M   Y Legal entity M individual, association, company, firm etc. Y Place of Birth O   Y ID Number O An identifier that uniquely identifies the person or the company. N Type of ID Number O The type of ID Number (e.g. passport number). N Start date ownership O Start date of the ownership of the car. N End date ownership O End data of the ownership of the car. N Data relating to vehicles       Licence number M   Y Chassis number/VIN M   Y Country of registration M   Y Make M (D.1) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y Nature of the vehicle/EU Category Code M (J) mopeds, motorbikes, cars etc. Y Date of first registration M (B) date of first registration of the vehicle somewhere in the world Y Start date (actual) registration M (I) Date of the registration to which the specific certificate of the vehicle refers Y End date registration M End data of the registration to which the specific certificate of the vehicle refers. It is possible this date indicates the period of validity as printed on the document if not unlimited (document abbreviation = H). Y Status M scrapped, stolen, exported etc. Y Start date status M   Y End date status O   N kW O (P.2) Y Capacity O (P.1) Y Type of licence number O regular, transito etc. Y Vehicle document id 1 O The first unique document ID as printed on the vehicle document Y Vehicle document id 2 (8) O A second document ID as printed on the vehicle document. Y Data relating to insurances       Insurance company name O   Y Begin date insurance O   Y End date insurance O   Y Address O   Y Insurance number O   Y ID Number O An identifier that uniquely identifies the company. N Type of ID Number O The type of ID Number (e.g. number of the Chamber of Commerce) N

2.   Bezpečnosť údajov

2.1.   Prehľad

Softvérová aplikácia Eucaris umožňuje bezpečnú komunikáciu s inými členskými štátmi a s podpornými (back-end) pôvodnými systémami členských štátov pomocou protokolu XML. Členské štáty si vymieňajú správy prostredníctvom ich priameho odosielania prijímateľovi. Dátové stredisko členského štátu je napojené na sieť Európskej únie TESTA.

Správy vo formáte XML, ktoré sa cez sieť posielajú, sú šifrované. Na šifrovanie sa používa technika SSL. Správy, ktoré sa zasielajú podporným aplikáciám, sú čisto textové správy XML, keďže spojenie medzi klientskou a podpornou aplikáciou by malo byť v chránenom prostredí.

Poskytne sa klientská aplikácia, ktorá sa v rámci členského štátu môže použiť na vyhľadávanie vo vlastnom registri alebo v registri ostatných členských štátov. Títo klienti sa identifikujú prostredníctvom prihlasovacieho mena/hesla alebo klientského certifikátu. Spojenie s používateľom môže byť šifrované, pričom je to v zodpovednosti každého jednotlivého členského štátu.

2.2.   Bezpečnostné prvky výmeny správ

Bezpečnostný dizajn sa zakladá na kombinácii podpisu HTTPS a XML. V tejto alternatíve sa na podpísanie všetkých správ zaslaných na server používa podpis XML, pričom sa prostredníctvom kontroly tohto podpisu dá overiť odosielateľ správy. Na ochranu dôvernosti a celistvosti správy pri prenose sa používa jednostranné zabezpečené spojenie SSL (len s certifikátom servera), ktorým sa poskytuje ochrana proti vymazaniu/opakovaniu a vkladaniu údajov. Namiesto vývoja softvéru na mieru, ktorý by realizoval obojstranné spojenie SSL, sa zaviedol podpis XML. Používanie tohto podpisu je bližšie k plánu webových služieb ako obojstranné spojenie SSL, a preto je aj strategickejšie.

Podpis XML sa môže implementovať rôznymi spôsobmi, pričom zvolený spôsob je v tomto prípade využitie tohto podpisu ako časti špecifikácie Web Services Security (WSS). V tejto špecifikácii sa vymedzuje spôsob použitia podpisu XML. Keďže WSS je postavená na štandarde SOAP, je logické, že SOAP sa bude dodržiavať v čo najväčšej možnej miere.

2.3.   Bezpečnostné prvky, ktoré sa netýkajú výmeny správ

2.3.1.   Autorizácia používateľov

Používatelia webovej aplikácie sa autorizujú sami pomocou používateľského mena a hesla. Keďže sa pritom využíva štandardná autorizácia systému Windows, členské štáty môžu úroveň autorizácie v prípade potreby zvýšiť prostredníctvom využitia klientských certifikátov.

2.3.2.   Úlohy používateľov

Softvérová aplikácia Eucaris podporuje rôzne úlohy používateľov. Každý súbor služieb má vlastnú autorizáciu. Napríklad (výhradní) používatelia funkcie „Treaty of Eucaris“ nemôžu používať funkciu „Prüm“. Služby administrátorov sú od bežných úloh koncových používateľov oddelené.

2.3.3.   Zaznamenávanie a vyhľadávanie údajov o výmene správ

Softvérová aplikácia Eucaris uľahčuje zaznamenávanie všetkých typov informácií. Funkcia správcu umožňuje správcovi vnútroštátneho systému, aby určil, ktoré správy sa zaznamenávajú: žiadosti koncových používateľov, prichádzajúce žiadosti členských štátov, poskytnuté informácie z vnútroštátnych registrov atď.

Aplikácia sa môže nakonfigurovať tak, aby na zaznamenávanie používala vnútornú databázu alebo vonkajšiu databázu (Oracle). Rozhodnutie o tom, ktoré správy sa budú zaznamenávať, jasne závisí od zariadení na zaznamenávanie v pôvodných systémoch a pripojených klientských aplikáciách.

V hlavičke každej správy sa nachádza informácia o žiadajúcom členskom štáte, žiadajúcej organizácii a zúčastnenom používateľovi. Uvádza sa aj dôvod žiadosti.

Prostredníctvom kombinovaného zaznamenávania v žiadajúcom a odpovedajúcom členskom štáte je možné vyhľadať údaje o akejkoľvek výmene správ (napr. na základe žiadosti zúčastneného občana).

Zaznamenávanie sa konfiguruje prostredníctvom webového klienta (menu Administration, Logging configuration). Funkciu zaznamenávania vykonáva Core System. Po umožnení zaznamenávania sa v jednom zázname uloží úplná správa (hlavička aj telo). Úroveň zaznamenávania sa dá nastaviť v súvislosti s definovanou službou a typom správy, ktorá prechádza cez Core System.

Úrovne zaznamenávania

Možné sú tieto úrovne zaznamenávania:

Private (súkromná) – správa sa zaznamenáva: zaznamenávanie NIE je dostupné pre službu „extract logging“, ale je dostupné len na vnútroštátnej úrovni, a to na účely auditu a riešenia problémov.

None (žiadna) – správa sa vôbec nezaznamenáva.

Typy správ

Výmena informácií medzi členskými štátmi pozostáva z niekoľkých správ, ktoré schematicky predstavuje obrázok nachádzajúci sa nižšie.

Existujú tieto typy správ (na obrázku sa uvádzajú pre Core System aplikácie Eucaris členského štátu X):

1.	Request to Core System_Request message by Client,

2.	Request to Other Member State_Request message by Core System of this Member State,

3.	Request to Core System of this Member State_Request message by Core System of other Member State,

4.	Request to Legacy Register_Request message by Core System,

5.	Request to Core System_Request message by Legacy Register,

6.	Response from Core System_Request message by Client,

7.	Response from Other Member State_Request message by Core System of this Member State,

8.	Response from Core System of this Member State_Request message by other Member State,

9.	Response from Legacy Register_Request message by Core System,

10.

Response from Core System_Request message by Legacy Register. Na obrázku sa nachádzajú tieto výmeny informácií: — Žiadosť o informáciu od členského štátu X členskému štátu Y – modré šípky. Táto žiadosť a odpoveď pozostáva zo správ typu 1, 2, 7 a 6. — Žiadosť o informáciu od členského štátu Z členskému štátu X – červené šípky. Táto žiadosť a odpoveď pozostáva zo správ typu 3, 4, 9 a 8. — Žiadosť o informáciu zo strany pôvodného registra na hlavný systém (táto cesta obsahuje aj žiadosť od bežného klienta pred pôvodným registrom) – zelené šípky. Tento druh žiadosti pozostáva zo správ typu 5 a 10.

Obrázok: Typy správ na zaznamenávanie

2.3.4.   Hardvérový bezpečnostný modul

Hardvérový bezpečnostný modul sa nepoužíva.

Hardvérový bezpečnostný modul (HSM – Hardware Security Module) poskytuje kvalitnú ochranu pre kľúč, ktorý sa používa na podpisovanie správ a identifikáciu serverov. Hoci prispieva k celkovej úrovni bezpečnosti, jeho kúpa/údržba je nákladnou záležitosťou a neexistujú žiadne požiadavky na rozhodovanie medzi druhou a treťou úrovňou bezpečnosti HSM FIPS 140-2. Keďže sa používa uzavretá sieť, ktorá účinne znižuje ohrozenie, rozhodlo sa, že HSM sa pre začiatok nepoužije. Ak bude HSM nevyhnutný napr. na získanie akreditácie, môže sa do architektúry systému pridať.

3.   Technické podmienky výmeny údajov

3.1.   Všeobecný opis aplikácie EUCARIS

3.1.1.   Prehľad

Aplikácia Eucaris pripája všetky zúčastnené členské štáty do viaccestnej siete, v ktorej každý členský štát komunikuje priamo s iným členským štátom. Na vytvorenie spojenia nie je potrebný žiadny centrálny komponent. Aplikácia Eucaris umožňuje bezpečnú komunikáciu s inými členskými štátmi a s koncovými pôvodnými systémami členských štátov pomocou protokolu XML. Túto architektúru znázorňuje nasledujúci obrázok.

Členské štáty si vymieňajú správy prostredníctvom ich priameho odosielania prijímateľovi. Dátové stredisko členského štátu je napojené na sieť používanú na výmenu správ (TESTA). Členský štát sa do siete TESTA pripája cez vlastnú vnútroštátnu bránu. Na pripojenie k sieti sa používa brána firewall, ku ktorej je aplikácia Eucaris pripojená pomocou smerovača. V závislosti od alternatívy, ktorá sa zvolí na ochranu správ, používa certifikát buď smerovač alebo samotná aplikácia Eucaris.

Poskytne sa klientská aplikácia, ktorá sa v rámci členského štátu môže použiť na vyhľadávanie vo vlastnom registri alebo v registri ostatných členských štátov. Klientská aplikácia sa pripája k aplikácii Eucaris. Títo klienti sa identifikujú prostredníctvom prihlasovacieho mena/hesla alebo klientského certifikátu. Spojenie s používateľom v externej organizácii (napr. polícii) môže byť šifrované, pričom je to v zodpovednosti každého jednotlivého členského štátu.

3.1.2.   Rozsah funkčnosti systému

Rozsah systému Eucaris je obmedzený na procesy v rámci výmeny informácií medzi orgánmi zodpovednými za evidenciu v členských štátoch a základnou prezentáciou týchto informácií. Postupy a automatizované procesy, pri ktorých sa tieto informácie používajú, sú mimo rozsahu funkčnosti systému.

Členské štáty sa môžu rozhodnúť, či budú využívať klientskú aplikáciu Eucaris alebo si vytvoria vlastnú prispôsobenú klientskú aplikáciu. V tabuľke pod týmto textom sa opisuje, ktoré aspekty systému Eucaris sa používajú povinne a/alebo sú predpísané a ktoré sú nepovinné a/alebo na voľnom zvážení zo strany členských štátov.

EUCARIS aspects	M/O (9)	Remark
Network concept	M	The concept is an „any-to-any“ communication.
Physical network	M	TESTA
Core application	M	The core application of EUCARIS has to be used to connect to the other Member States. The following functionality is offered by the core: — Encrypting and signing of the messages; — Checking of the identity of the sender; — Authorization of Member States and local users; — Routing of messages; — Queuing of asynchronous messages if the recipient service is temporally unavailable; — Multiple country inquiry functionality; — Logging of the exchange of messages; — Storage of incoming messages
Client application	O	In addition to the core application the EUCARIS II client application can be used by a Member State. When applicable, the core and client application are modified under auspices of the EUCARIS organisation.
Security concept	M	The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates.
Message specifications	M	Every Member State has to comply with the message specifications as set by the EUCARIS organisation and this Council Decision. The specifications can only be changed by the EUCARIS organisation in consultation with the Member States.
Operation and Support	M	The acceptance of new Member States or a new functionality is under auspices of the EUCARIS organisation. Monitoring and help desk functions are managed centrally by an appointed Member State.

3.2.   Požiadavky na funkčnosť a požiadavky, ktoré sa netýkajú funkčnosti

3.2.1.   Generické funkcie

V tomto oddiele sa vo všeobecnosti opisujú hlavné generické funkcie.

Číslo	Opis
1.	Systém umožňuje orgánom členských štátov zodpovedným za evidenciu interaktívnu výmenu správ so žiadosťami a odpoveďami.
2.	Systém obsahuje klientskú aplikáciu, ktorá umožňuje koncovým používateľom zasielanie žiadostí a predkladanie informácií v odpovediach na účely manuálneho spracovania.
3.	Systém uľahčuje „vysielanie“, ktorým sa členskému štátu umožňuje zaslať žiadosť všetkým ostatným členským štátom. Centrálna aplikácia konsoliduje prichádzajúce odpovede do jednej správy pre klientskú aplikáciu (táto funkcia sa nazýva „Multiple Country Inquiry“).
4.	Systém dokáže riešiť rôzne typy správ. Úlohy používateľa, autorizácia, smerovanie, podpisovanie i zaznamenávanie sa vymedzujú v závislosti od konkrétnej služby.
5.	Systém umožňuje členským štátom, aby si vymieňali balíky správ alebo správy, ktoré obsahujú veľký počet žiadostí alebo odpovedí. Tieto správy sa spracúvajú asynchrónne.
6.	V prípade, ak je prijímajúci členský štát nedostupný, systém zoradí asynchrónne správy a zabezpečí ich doručenie hneď, ako sa príjemca sprístupní.
7.	Systém ukladá prichádzajúce asynchrónne správy až do ich spracovania.
8.	Systém umožňuje prístup len aplikáciám Eucaris iných členských štátov, a nie jednotlivým organizáciám v týchto členských štátoch, t. j. každý orgán zodpovedný za evidenciu funguje ako jediná brána medzi vnútroštátnymi koncovými používateľmi a zodpovedajúcimi orgánmi v iných členských štátoch.
9.	Na jednom serveri pre Eucaris je možné zadefinovať používateľov z rôznych členských štátov a autorizovať ich v súlade s právami daného členského štátu.
10.	V správach sa nachádzajú informácie o žiadajúcom členskom štáte, organizácii a koncovom používateľovi.
11.	Systém uľahčuje zaznamenávanie údajov o výmene správ medzi rôznymi členskými štátmi a medzi centrálnou aplikáciou a vnútroštátnymi evidenčnými systémami.
12.	Systém umožňuje, aby osobitný tajomník (buď organizácia, alebo členský štát, ktorý je na túto úlohu výslovne vymenovaný) na účely vypracovávania štatistických správ zhromažďoval informácie o správach, ktoré zúčastnené členské štáty odoslali/prijali.
13.	Každý členský štát sám uvedie, ktoré zo zaznamenaných informácií sú pre uvedeného „tajomníka“ dostupné a ktoré sú „súkromné“.
14.	Systém umožňuje správcom vnútroštátnych systémov každého štátu, aby zo systému získali štatistické údaje o používaní.
15.	Systém umožňuje pridanie nových členských štátov prostredníctvom jednoduchých administratívnych postupov.

3.2.2.   Používanie

Číslo	Opis
16.	Systém poskytuje rozhranie na automatizované spracovanie správ zo strany podporných systémov/pôvodných systémov a umožňuje integráciu používateľského rozhrania do týchto systémov (prispôsobené používateľské rozhranie).
17.	Systém sa ľahko učí, je názorný a obsahuje pomoc v textovom formáte.
18.	Systém preukázateľne pomáha členským štátom pri integrácii, operačných činnostiach a budúcej údržbe (napr. prostredníctvom referenčných pokynov, funkčnej/technickej dokumentácie, operačných pokynov...).
19.	Používateľské rozhranie je viacjazyčné a poskytuje koncovému používateľovi prostriedky na výber uprednostňovaného jazyka.
20.	Používateľské rozhranie poskytuje správcovi miestneho systému prostriedky na preklad položiek na monitore a kódovaných informácií do svojho jazyka.

3.2.3.   Spoľahlivosť

Číslo	Opis
21.	Systém je vytvorený ako robustný a spoľahlivý operačný systém, tolerantný voči chybám zo strany prevádzkovateľa, pričom sa bez problémov obnovuje po výpadkoch energie alebo iných haváriách. Musí byť možné reštartovať systém bez straty údajov alebo s ich minimálnou stratou.
22.	Systém musí vykazovať stabilné a opakovateľné výsledky.
23.	Systém bol navrhnutý na spoľahlivé fungovanie. Je možné ho implementovať v takej konfigurácii, ktorá zabezpečí 98-percentnú dostupnosť (využitím nadbytočnosti, záložných serverov atď.)
24.	Využitie časti systému je možné dokonca i pri zlyhaní niektorých komponentov (ak „spadol“ členský štát C, členské štáty A a B môžu naďalej komunikovať). Mal by sa minimalizovať počet jednotlivých bodov zlyhania v informačnom reťazci.
25.	Čas obnovenia po vážnom zlyhaní by nemal presiahnuť jeden deň. Malo by byť možné minimalizovať dobu nedostupnosti prostredníctvom podpory na diaľku, napr. zo strany servisného centra.

3.2.4.   Výkon

Číslo	Opis
26.	Systém sa dá využívať nepretržite, 24 hodín denne a 7 dní v týždni. Tento harmonogram (24 × 7) sa vyžaduje aj od pôvodných systémov členských štátov.
27.	Systém odpovedá na žiadosti používateľov rýchlo bez ohľadu na ďalšie úlohy, ktoré vykonáva. Túto funkčnosť si vyžadujú aj pôvodné systémy zúčastnených strán, aby sa zabezpečil prijateľný reakčný čas. Za prijateľný reakčný čas sa považuje celkový reakčný čas 10 sekúnd na jednu odpoveď.
28.	Systém bol navrhnutý ako systém pre viacerých používateľov a tak, aby zvládal podporné úlohy, zatiaľ čo používateľ vykonáva úlohy základné.
29.	Systém bol navrhnutý ako pružný z hľadiska rozsahu, aby podporoval možný nárast správ v prípade pridania novej funkcie, organizácie alebo nového členského štátu.

3.2.5.   Bezpečnosť

Číslo	Opis
30.	Systém je vhodný (napr. čo sa týka bezpečnostných opatrení) na výmenu správ, ktoré obsahujú citlivé osobné údaje (napr. vlastník/užívateľ vozidla) klasifikované ako „EU restricted“.
31.	Údržba systému sa vykonáva spôsobom, pri ktorom sa neumožňuje neoprávnený prístup k údajom.
32.	Systém obsahuje službu pre správu práv a povolení vnútroštátnych koncových používateľov.
33.	Členské štáty môžu skontrolovať totožnosť odosielateľa (na úrovni členského štátu) prostredníctvom podpisu XML.
34.	Členské štáty musia výslovne oprávniť iné členské štáty na žiadanie špecifických informácií.
35.	Na úrovni aplikácie poskytuje systém plnú bezpečnosť a šifrovací postup kompatibilný s úrovňou bezpečnosti, ktorá sa v takýchto situáciách vyžaduje. Výlučnosť a celistvosť informácie sa zaručuje použitím podpisu XML a šifrovania prostredníctvom tunelingu SSL.
36.	Údaje o celej výmene informácií sa dajú vyhľadávať na základe ich zaznamenávania.
37.	Poskytuje sa ochrana proti vymazaniu správ (treťou stranou) a opakovanému prehrávaniu a vkladaniu správ (treťou stranou).
38.	Systém využíva certifikáty TTP (Trusted Third Party) pre dôveryhodné tretie strany.
39.	Systém je schopný zvládať rôzne certifikáty od jedného členského štátu, v závislosti od typu správy alebo služby.
40.	Bezpečnostné opatrenia na úrovni aplikácie postačujú na umožnenie používania neakreditovaných sietí.
41.	Systém dokáže používať najnovšie bezpečnostné technológie, ako napr. bránu XML-firewall.

3.2.6.   Prispôsobivosť

Číslo	Opis
42.	Systém sa dá rozšíriť o nové správy a nové funkcie. Náklady na prispôsobenie sú zanedbateľné z dôvodu centralizovaného vývoja komponentov aplikácie.
43.	Členské štáty môžu definovať nové typy správ na dvojstranné použitie. Podpora všetkých typov správ od všetkých členských štátov sa nevyžaduje.

3.2.7.   Podpora a údržba

Číslo	Opis
44.	Systém poskytuje servisnému centru a/alebo prevádzkovateľom monitorovacie zariadenia na sledovanie siete a serverov v rôznych členských štátoch.
45.	Systém poskytuje prostriedky na podporu na diaľku zo strany servisného centra.
46.	Systém poskytuje prostriedky na analýzu problémov.
47.	Systém sa dá rozšíriť o nové členské štáty.
48.	Aplikáciu môže jednoducho nainštalovať personál s minimálnou kvalifikáciou a skúsenosťami v oblasti IT. Inštalačný postup je maximálne automatizovaný.
49.	Systém poskytuje stále prostredie pre testovanie a schvaľovanie.
50.	Ročné náklady na údržbu a podporu sa znížili prostredníctvom dodržiavania trhových štandardov a vytvorenia aplikácie spôsobom, ktorý si vyžaduje čo najmenšiu podporu zo strany servisného strediska.

3.2.8.   Požiadavky na dizajn

Číslo	Opis
51.	Systém bol navrhnutý a overený tak, aby fungoval mnoho rokov.
52.	Systém bol vytvorený tak, aby fungoval nezávisle od poskytovateľa siete.
53.	Systém je v súlade s používaným hardvérom/softvérom v členských štátoch tým, že funguje spolu s evidenčnými systémami, ktoré využívajú voľne dostupné štandardné technológie webových služieb [XML, XSD, SOAP, WSDL, HTTP(s), Web services, WSS, X.509 atď.].

3.2.9.   Uplatniteľné normy

Číslo	Opis
54.	Systém je v súlade s otázkami ochrany údajov uvedenými v nariadení (ES) č. 45/2001 (články 21, 22 a 23) a so smernicou 95/46/ES.
55.	Systém je v súlade s normami IDA.
56.	Systém podporuje UTF8.

Kapitola 4: Hodnotenie

1.   Hodnotiaci postup podľa článku 20 (príprava rozhodnutí podľa článku 25 ods. 2 rozhodnutia 2008/615/SVV)

1.1.   Dotazník

Príslušná pracovná skupina Rady vypracuje dotazník týkajúci sa každej z automatizovaných výmen údajov ustanovených v kapitole 2 rozhodnutia 2008/615/SVV.

Hneď ako bude členský štát presvedčený, že spĺňa predpoklady na výmenu údajov v relevantnej kategórii, vyplní príslušný dotazník.

1.2.   Skúšobná prevádzka

S cieľom vyhodnotiť výsledky dotazníka uskutoční členský štát, ktorý si želá začať výmenu údajov, skúšobnú prevádzku spolu s jedným alebo viacerými členskými štátmi, ktoré si už vymieňajú údaje podľa predmetného rozhodnutia Rady. Skúšobná prevádzka sa uskutoční krátko pred hodnotiacou návštevou alebo krátko po nej.

Podmienky a pravidlá tejto skúšobnej prevádzky určí príslušná pracovná skupina Rady, pričom budú vychádzať z predchádzajúcej samostatnej dohody s dotknutým členským štátom. O jej praktických podrobnostiach rozhodnú členské štáty, ktoré sa na tejto skúšobnej prevádzke zúčastňujú.

1.3.   Hodnotiaca návšteva

V členskom štáte, ktorý si želá začať výmenu údajov, sa uskutoční hodnotiaca návšteva s cieľom vyhodnotiť výsledky dotazníka.

Podmienky a pravidlá tejto návštevy určí príslušná pracovná skupina Rady, pričom budú vychádzať z predchádzajúcej samostatnej dohody medzi dotknutým členským štátom a hodnotiacim tímom. Dotknutý členský štát umožní hodnotiacemu tímu, aby skontroloval automatizovanú výmenu údajov v kategórii alebo kategóriách údajov, ktoré sa majú hodnotiť, a to najmä prostredníctvom organizácie programu návštevy, v ktorom sa zohľadnia požiadavky hodnotiaceho tímu.

Hodnotiaci tím pripraví do jedného mesiaca správu o hodnotiacej návšteve, ktorú postúpi dotknutému členskému štátu na pripomienkovanie. V prípade potreby hodnotiaci tím správu na základe pripomienok členského štátu zreviduje.

Hodnotiaci tím pozostáva z najviac troch členov, ktorých vymenujú členské štáty, ktoré sa zúčastňujú na automatizovanej výmene údajov v hodnotených kategóriách; títo členovia musia mať skúsenosti s dotknutou kategóriou údajov, musia mať príslušnú vnútroštátnu bezpečnostnú previerku na tieto záležitosti a musia byť ochotní zúčastniť sa na najmenej jednej hodnotiacej návšteve v inom členskom štáte. Komisia sa vyzve, aby sa k hodnotiacemu tímu pridala ako pozorovateľ.

Členovia hodnotiaceho tímu budú dodržiavať dôverný charakter informácií, ktoré získajú pri výkone svojich úloh.

1.4.   Správa Rade

Rade sa na rozhodnutie podľa článku 25 ods. 2 rozhodnutia 2008/615/SVV predloží celková hodnotiaca správa, v ktorej sa zhrnú výsledky dotazníkov, hodnotiacej návštevy a skúšobnej prevádzky.

2.   Hodnotiaci postup podľa článku 21

2.1.   Štatistika a správa

Každý členský štát zostaví štatistiku o výsledkoch automatizovanej výmeny údajov. V záujme zabezpečenia porovnateľnosti, zostaví vzor takejto štatistiky príslušná pracovná skupina Rady.

Štatistika sa každý rok postúpi Komisii a generálnemu sekretariátu, ktorý vypracuje všeobecný prehľad za ukončený rok.

Okrem toho sa členské štáty požiadajú, aby pravidelne, ale nie viac ako raz ročne, zasielali ďalšie informácie o administratívnej, technickej a finančnej realizácii automatizovanej výmeny údajov, ktoré sú potrebné na analýzu a skvalitnenie procesu. Na základe týchto informácií sa pre Radu pripraví správa.

2.2.   Revízia

Rada v primeranom časovom horizonte preskúma uvedený mechanizmus hodnotenia a v prípade potreby ho zreviduje.

3.    Stretnutia expertov

Experti sa budú pravidelne stretávať v rámci príslušnej pracovnej skupiny Rady, aby organizovali a realizovali uvedené postupy hodnotenia, vymieňali si skúsenosti a rokovali o možných zlepšeniach. Ak je to možné, výsledky týchto rokovaní sa začlenia do správy uvedenej v bode 2.1.

---

(1)  „Úplný vymedzený“ znamená, že je zahrnuté aj spracovanie zriedkavých alel.

(2)  Ide o pozíciu vymedzenú v norme ASCII.

(3)  M = mandatory when available in national register, O = optional.

(4)  All the attributes specifically allocated by the Member States are indicated with Y.

(5)  Harmonised document abbreviation, see Council Directive 1999/37/EC of 29 April 1999.

(6)  M = mandatory when available in national register, O = optional.

(7)  Harmonised document abbreviation, see Council Directive 1999/37/EC of 27 April 1999.

(8)  In Luxembourg two separate vehicle registration document ID’s are used.

(9)  M = mandatory to use or to comply with O = optional to use or to comply with.