ZAMAWIAJĄCY: URZĄD PATENTOWY RZECZYPOSPOLITEJ POLSKIEJ

Załącznik A	do SOPZ	Wskaźniki projektu
Załącznik B	do SOPZ	Zestawienie rodzaju i ilości posiadanych licencji
Załącznik C	do SOPZ	Szablon opisu usługi
Załącznik D	do SOPZ	Zestawienie minimalnych ilości komponentów infrastruktury i oprogramowania dostarczanego w ramach realizacji Umowy oraz wymagane parametry techniczne
Załącznik E	do SOPZ	Procedury odbioru
Załącznik F	do SOPZ	Wymagania funkcjonalne i niefunkcjonalne
Załącznik G	do SOPZ	Makieta systemu PUEUP (plik jar)
Załącznik H	do SOPZ	Wymagania do projektu aranżacji serwerowni
Załącznik I	do SOPZ	Wzory protokołów odbioru

W poniższym słowniku zostały zawarte akronimy (skróty) pojęć i terminów występujących w Szczegółowym Opisie Przedmiotu Zamówienia i towarzyszących mu załącznikach. Niniejszy dokument składa się z dwóch elementów: słownika oraz indeksu.

Słownik zawiera:

• pojęcia odnoszące się do struktury organizacyjnej Urzędu Patentowego Rzeczypospolitej Polskiej (UPRP), systemów informatycznych używanych przez UPRP oraz pojęć właściwych dla działalności UPRP,

• objaśnienie skrótów technologicznych (akronimów),

• objaśnienie terminów technologicznych,

• pojęcia odnoszące się do ITIL v3, PRINCE2, AGILE i innych metodyk lub standardów. Indeks jest listą alfabetyczną wszystkich pojęć zdefiniowanych w słowniku.

OPIS SKRÓTÓW I POJĘĆ

Termin	Opis
3DES	ang. Triple Data Encryption Standard, Symetryczny algorytm szyfrowania.
A2A	ang. Administration-To- Administration, Pojęcie to opisuje transakcje, relacje i połączenia pomiędzy urzędami i resortami w sektorze administracji publicznej.
AD	ang. Microsoft Active Directory Domain Services
Administrator	(Jeżeli nie zaznaczono inaczej) Administrator systemu PUEUP
AES	ang. Advanced Encryption Standard, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx_Xxxxxxxxxx_Xxxxxxxx
Akcja	Działanie automatycznie wykonywane przez System Zarządzania Zdarzeniami w odpowiedzi na Zdarzenie, spełniające określone kryteria. Patrz: System, Zarządzanie Zdarzeniami, Zdarzenie.
Aktywa	Termin używany w ITIL v3.(ITIL, Strategia Usług). Xxxxx Xxxxx lub Zdolność. Aktywa Dostawcy Usług obejmują wszystko, co przyczynia się do świadczenia Usług. Aktywa mogą być jednego z następujących typów: kadra zarządcza, organizacja, Proces, wiedza, ludzie, informacje, Aplikacje, Infrastruktura oraz środki finansowe. Patrz: Aktywa, Aplikacja, Dostawca, Infrastruktura, Usługa, Zasób, Zdolność.
API	ang. Application Programming Interface, Interfejs programistyczny aplikacji
B+R	Prace badawczo-rozwojowe
BO (BackOffice)	System dziedzinowy do udzielania i utrzymywania praw ochronnych w zakresie znaków towarowych i wzorów przemysłowych
BPMN	ang. Business Process Model and Notation, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx_Xxxxxxx_Xxxxxxxx_Xxxxxxxx
CMS	ang. Content Management System, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxx_xxxx%X0%00xxxxxx_xxx%X0%0Xxx%X0%00 W kontekście wymagań PUEUP: CMS to narzędzie do zarządzania i publikowania treści na e- Baza Wiedzy.
COTS	ang. Commercial off-the-shelf, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxxx_xxx-xxx-xxxxx

CRM	ang. Customer Relationship Managment, W kontekscie PUEUP - UPRP korzysta z Microsoft Dynamic 365
CSR	ang. Country-Specific Recommendations, wytyczne Rady Unii Europejskiej w sprawie krajowego programu reform Polski
DGC	ang. Dynamic Generation Cost, Dynamiczny Koszt Jednostkowy
DIP	Dokument Ininicjujący Projekt
Dokument	Zestaw danych (w tym metadanych), plików składający się na dany obiekt i jego opisujący (metadane), np. Korespondencję. W opisie wymagań termin „Dokument” często używany jest w znaczeniu „Korespondencji”
DR	Disaster Recovery, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx_xxxxxxxx
EFRR	Europejski Fundusz Rozwoju Regionalnego
EFS	Europejski Fundusz Społeczny
eIDAS	Rozporządzenie Parlamentu Europejskiego i Rady w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym (eIDAS) zastąpi od dnia 1 lipca 2016 r. dyrektywę 1999/93/WE w sprawie wspólnotowych ram prawnych dla podpisów elektronicznych.
ENPV	ang. Economic Net Present Value Ekonomiczna, zaktualizowana wartość netto z inwestycji
EP	ang. European Patent, Patent Europejski
EPO	ang. European Patent Office, Europejski Urząd Patentowy
ePUAP	Elektroniczna Platforma Usług Administracji Publicznej
ERR	ang. Economic Internal Rate of Return, Ekonomiczna wewnętrzna stopa zwrotu z inwestycji
ESB	ang. Electronic Serial Bus, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxxx_Xxxxxxx_Xxx
ESP	Elektroniczna Skrzynka Podawcza zaimplementowana wg. "Standard Elektronicznej Skrzynki Podawczej Wersja 1.02" Ministerstwa Administracji i Cyfryzacji (MAC), Departament Informatyzacji: xxxxx://xxx.xxx.xxx.xx/xxxxx/?xx_xxxxx00000 (uwzględniając dostępnę aktualizacje standardu lub dodatkowych wytycznych opublikowane przez odpowiednie ministerstwo do momentu finalnego odbioru projektu)
ETL	ang. Extract, Transform and Load, Wydobywanie danych i plików ze źródeł, ich transformaja oraz ładowanie do modułu wyszukiwarki xxxxx://xx.xxxxxxxxx.xxx/xxxx/XXX
EUIPO	ang.European Union Intellectual Property Office, Urząd Unii Europejskiej ds.Własności Intelektualnej; wcześniej: OHIM
EUM	ang. End User Monitoring
EZD	System Elektronicznego Zarządzania Dokumentacją Podlaskiego Urzędu Wojewódzkiego wdrożony w UPRP (system kanclearyjny)
Finalny Odbiór Projektu	Data/moment odbioru i zaakceptownia produktów wytworzonych w ramach Projektu PUEUP - zawarta w harmonogramie projektu (zapisana w Umowie z Wykonawcą).
FNPV	ang. Financial Net Present Value, Zaktualizowana wartość netto z inwestycji
FNPV/K	ang. Financial Net Present Value Of Capital, Zaktualizowana wartość netto z kapitału własnego
Formularz zgłoszeniowy	patrz: Zgłoszenie
GP	Generator Powiadomień
GUI	ang. Graphical User Interface, Interfejs Graficzny Użytkownika w kontekście PUEUP, pod pojęciem GUI, należy rozumieć także w pełni funkcjonalny, zaimplementowany moduł (aplikację).
GUS	Główny Urząd Statystyczny

HA	Konfiguracja systemu zapewniająca wysoką dostępność xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_xxxxxxxxxxxx
Hitlista	Widok prezentowany użytownikowi poprzez GUI zawierający listę pozycji będących rezultatem wyszukiwania/filtrowania.
HSM	ang. Hardware security module, moduł w systemie PUEUP umożliwiający automatyczny podpis dokumentów zgodnie z definicją kwalifikowanego podpisu elektronicznego zawartego w Rozporządzeniu eIDAS.
HTTP/HTTPS	ang. Hypertext Transfer Protocol/Secure, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxx_Xxxxxxxx_Xxxxxxxx
I18N	xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxxxxxxxxxxxxx_xxx_xxxxxxxxxxxx
ICT, IT	ang. Information and Communication Technologies. Szeroki zakrestechnologii przetwarzających, gromadzących i przesyłających informacje w formie elektronicznej
IPE	Internetowa Platforma Edukacyjna Urzędu Patentowego RP dostępna pod linkiem: xxxx://xxx.xxxx.xx/xxxxx/xxxxx.xxx, składająca się ze: Strefy szkoleń (szkolenie e-learningowe zawierające aktualnie 10 modułów tematycznych) oraz Strefy wiedzy (zbiór artykułów i opracowań specjalistycznych).
IPU	Internetowy Portal Usługowy UPRP
IRR	ang. Internal Rate of Return, wewnętrzna stopa zwrotu z inwestycji
IRR/K	ang. Internal Rate of Return of Capital, wewnętrzna stopa zwrotu z kapitału własnego
JDBC	ang. Java DataBase Connectivity, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_XxxxXxxx_Xxxxxxxxxxxx
JMS	ang. Java Message Service, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_Xxxxxxx_Xxxxxxx
Kategoria opłaty	(W kontekście MR oraz SGW) kategoria opłaty, w ramach której możemy rozróżnić opłaty przypisane do danego rodzaju prawa ochronego (sprawy) oraz przydzielić je do poszczególnych departamentów.
Klient	Użytkownik zewnętrzny (z punktu widzenia UPRP) korzystający z systemów PUEUP
Kod źródłowy	Pliki źródłowe, skrypty, biblioteki .dll i inne niestandardowe narzędzia, niezbędne w procesie kompilacji i/lub konsolidacji Oprogramowana, a także strukturę baz danych i opis struktury baz danych, słowników, definicji niezbędnych dla dalszego utrzymywania Systemu. Pliki te muszą być dostarczone w formie, która nie wymaga deasemblacji ani dekompilacji i pozwala na ich modyfikację oraz kompletną dokumentację/materiały Kod źródłowego.
Komunikaty	Komunikaty systemowe niezwiązane z konkretnym prawem własności przemysłowej dotyczące konta użytkownika np.: 1. Założenie konta i danych do logowania 2. Awarie systemu PUEUP 3. Awarie systemów dziedzinowych 4. Komunikaty dotyczące faktur wprowadzających w błąd 5. Inne ważne z punktu widzenia użytkownika Profilu 6. Komunikat błędu 7. Komunikat dotyczący zapisania się i wypisania się do/z newslettera
Konto Klienta PUEUP (w skrócie: Konto Klienta)	Konto używane przez Klienta (Użytkownika Zewnętrznego) do zalogowania do modułu "e- Profil IP". W definicji wymagań używana i dopuszczalna jest również skrótowa nazwa Konto Klienta.
Konto Pracownika PUEUP (w skrócie: Konto Pracownika)	Konto do systemów stworzonych w ramach Projektu PUEUP dostępne dla Pracownika UPRP (np. do Modułu Kancelaryjno-Administracyjnego). W definicji wymagań używana i dopuszczalna jest również skrótowa nazwa Konto Pracownika.
Korespondencja przychodząca	Korespondecja wpływająca OD Klienta DO UPRP ([KLIENT] --> UPRP)Korespondecja wpływająca od Klienta DO UPRP ([KLIENT] --> UPRP). Klient wysyła Korespondencję poprzez wypełnienie formularza dostępnego w Koncie Klienta.

Korespondencja wychodząca	Korespondecja wysyłana Z UPRP DO Klienta (UPRP --> [KLIENT])Korespondecja wysyłana Z UPRP DO Klienta (UPRP --> [KLIENT])
Koszyk	W zależności od kontekstu: 1. Funkcjonalność Odnośnie Płatności w ramach Konta Klienta (wymaganie dot. modułu e- Profil IP, e-Płatności, e-Powiadomienia) 2. Funkcjonalność w ramach modułu e-Rejestry (nie związana z płatnościami).
KPI	(ang. Key Performance Indicator) Kluczowy wskaźnik efektywności - finansowy i niefinansowy wskaźnik pomiaru stopnia realizacji celów, wyrażony w liczbach, procentach itd.
MAAT	patrz SGW
Makieta	Proponowana poglądowa wizualizacja systemu/poszczególnych modułów mająca na celu ułatwienie zrozumienia wymagań funkcjonalnych oraz niefunkcjonalnych. Makieta nie prezentuje definitywnego wyglądu oraz nie ogranicza zakresu informacji prezentowanych w docelowym systemie. Wygląd oraz funkcjonalności GUI docelowego systemu powinny być wzorowane na wizualizacji przedstawionej w ramach Makiety.
MC	Ministerstwo Cyfryzacji
Mechanizm livesearch (w kontekście wyszukiwania)	Funkcjonalność livesearch (w kontekście wyszukiwania) oznacza, że wyszukiwanie rozpoczyna się z chwilą wprowadzenia kolejnego znaku lub zmiany/dodania wartości z predefiniowanej listy.
MG	Ministerstwo Gospodarki
MIR	Ministerstwo Infrastruktury i Rozwoju
MPE	Moduł Płatności Elektronicznych
MR	Xxxxx Rozliczeń (w kontekście funkcjonalności związanych z modułem e-Płatności)
MR	Ministerstwo Rozwoju
MŚP	sektor mikro- małych i średnich przedsiębiorstw
Należność	oczekiwana przez UP RP zapłata za jedną, nierozbijalną, z punktu widzenia księgowości, rzecz. Należności są generowane przez systemy dziedzinowe wUPRP i dostarczane do obecnego MR w uzgodnym formacie.
Newsletter	Krótka forma informacji dotycząca najważniejszych aspektów działania Urzędu Patentowego RP. Przesyłana do użytkowników, którzy wyrażą na to zgodę poprzez wypełnienie formularza zgłoszenia do Newslettera. Formularz bedzie udostępniony na głównej stronie internetowej oraz z pozycji ustawień konta w panelu użytkownika. Wybór tematów: 1. Sympozja 2. Konferencje 3. Szkolenia 4. Nowe publikacje UPRP 5. Wydarzenia UPRP 6. Konkursy 7. Zmiany w Prawie Własności Przemysłowej 8. Ważne informacje - aktualizacja
Numer Dokumentu	Unikalny identyfikator dokumentu
Numer Rejestracji	Numer nadawany przez UPRP w momencie udzielenia prawa na przedmiot ochrony. Nazywany także numerem ochrony.
Numer Sprawy	Numery spraw indetyfikowane są poprzez numery PWP (numer zgłoszenia oraz numer rejestracji(ochrony) - w zależności od kontekstu oraz statusu danego PWP). Np. z uwagi na to, że numer rejestracji nadawany jest dopiero po udzieleniu prawa w

	pierwszej kolejności używany jest numer zgłoszenia. W przypadku funkcjoanlności obsługi rejestrów (ze względu na to, że operują one wyłącznie na PWP z nadanym numerem ochrony/rejestracji) używany jest numer rejestracji.
Numer Zgłoszenia	Numer nadawany przez UPRP w momencie potwierdzenia przyjęcia zgłoszenia PWP.
Obiekt Danych w ramach Konta Klienta	To spójny zestaw danych reprezentujący następujące obiekty: dokument/korespondencję/płatność/powiadomienie dostępny (poprzez GUI) w Koncie Klienta PUEUP.
ODBC	ang. Open DataBase Connectivity, xxxxx://xx.xxxxxxxxx.xxx/xxxx/XXXX
OPE	Operatorzy Płatności Elektronicznych
Opłata	Płatność rozbita mająca oprócz danych płatności wypełniony numer wyciągu oraz pozycję księgową.
Opłata	Pojedyncza opłata z formularza / pozycja z tabeli opłat.
Oprogramowanie	Oprogramowanie Standardowe i Oprogramowanie Dedykowane
Oprogramowanie Dedykowane	Oprogramowanie wytwarzane przez Wykonawcę w warstwie aplikacyjnej.
Oprogramowanie Standardowe	Oprogramowanie komercyjne, produkowane seryjnie, stosowane w najpopularniejszej dziś architekturze x86_64 zarówno na platformie serwerowej, wirtualizacyjnej, jak i systemów operacyjnych (ang. COTS - Commercial Off The Shelf)
OU	ang. Organizational Unit (w kontekscie Active Directory-AD)
PCT	ang. Patent Cooperation Treaty, Układ o współpracy patentowej
PIRP	Polska Izba Rzeczników Patentowych
Płatność	Płatność to pozycja na Zamówieniu za jedną rzecz np. formularz bądź jedną pozycję z Tabeli Opłat.
Płatność online	Operacja dokonania zapłaty drogą elektroniczną
Płatność zrealizowana	Zrealizowana płatność, dla której dostępny jest identyfikator transakcji (potwierdzający dokonanie płatności).
POPC	Program Operacyjny Polska Cyfrowa
Powiadomienia	Krótkie wiadomości z przypomnieniem o upływającym terminie ochrony poszczególnych praw własności.
Profil Zaufany	Profil Zaufany - usługa zewnętrzna, udostępniona na xxxxx://xx.xxx.xx/xx/xxxxx
Projekt PUEUP	Przedsięwzięcie polegające na opracowaniu Platformy Usług Elektronicznych Urzędu Patentowego (PUEUP) w ramach porozumienia o dofinansowanie projektu ze środków POPC.
Przedmioty Ochrony	Przedmiot Własności Przemysłowej (PWP), Przedmioty Ochrony, których rejestracją i ochroną zajmuje się UPRP: Znaki Towarowe (Z), Wzory Przemysłowe (Wp), Wynalazki (P), Wzory Użytkowe (W), Patent Europejski (EP), Dodatkowe Prawo Ochronne (SPC)
PTS	Projekt Techniczny Systemu PUEUP (PTS) wytworzony przez Wykonawcę w uzgodnieniu z UPRP zawierający opis funkcjonalności do zaimplementowania.
PUEUP	Platforma Usług Elektronicznych Urzędu Patentowego
PWP	Przedmiot Własności Przemysłowej, (patrz także: Przedmiot Ochrony). W kontekście definicji wymagań PUEUP przyjęto dla uproszczenia, że PWP jako obiekt danych istniejący w systemie od momentu wysłania zgłoszenia o ochronę danego PWP.
PWP	Prawo własności przemysłowej
PWW	Proces Wypełniania Wniosków
PZIP	Program Zintegrowanej Informatyzacji Państwa
REST	ang. Hypertext Transfer Protocol, xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxx_Xxxxxxxx_Xxxxxxxx

RMI	Remote Method Invocation (xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxx_Xxxxxx_Xxxxxxxxxx)
RODO	Ogólne Rozporządzenie o Ochronie Danych. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE . xxxx://xxx-xxx.xxxxxx.xx/xxxxx- content/PL/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.POL&toc=OJ:L:2016:119:TOC
RPO	ang. Recovery Point Objective: xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx_xxxxx_xxxxxxxxx
RTO	ang. Recovery Time Objective: xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx_xxxx_xxxxxxxxx
RWD	ang. Responsive Web Design, Rozpoznanie i dostosowanie do wielkości urządzenia - technika projektowania stron www w taki sposób, aby ich układ i wygląd dopasowywał się automatycznie do okna urządzenia, na którym jest wyświetlany, np. smartfonów, tabletów itd.
SGW (System Gospodarki Własnej)	System Gospodarki Własnej. Obecnie w UPRP system MAAT.
SIEM	ang. Security Information and Event Management Scentralizowany system wykrywania i korelacji zdarzeń bezpieczeństwa umożliwiający zarządzanie informacjami związanymi z bezpieczeństwem oraz zdarzeniami bezpieczeństwa.
SOA	ang. Service Oriented Architecture, Architektura oparta na usługach - model architektury, w którym dla użytkowników zdefiniowano stanowiące odrębną całość funkcje systemu teleinformatycznego (usługi sieciowe) oraz opisano sposób korzystania z tych funkcji, inaczej system zorientowany na usługi (wg rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności)
SPC	ang. Supplementary Protection Certificate, Dodatkowe Prawo Ochronne
Sprawa (także Sprawa PWP) w ramach funkcjonalności PUEUP	Sprawa to zestaw informacji, dokumentów oraz zdarzeń związanych z obsługą danego PWP. np. PWP: Znak Towarowy Z.123456, R.654321, korespondencja, płatności, powiadomienia związane z danym PWP. Zestaw informacji, dokumentów oraz zdarzeń związanych z obsługą danego PWP. Każda Sprawa posiada swój unikalny identyfikator nadawany przez Serwis Numeracyjny. Sprawa w Koncie Klienta PUEUP to zestaw zgrupowanych po Numerze Zgłoszenia PWP Obiektów Danych (dokumentów/korespondencji/płatności/powiadomień), które zostały wysłane/odebrane przez Klienta. Wspomniane Obiekty Danych dostępne są Klientowi (poprzez GUI) po zalogowaniu na jego konto PUEUP.
SRK	Strategia Rozwoju Kraju
Studium	Opracowanie analityczne dla projektu Platforma Usług Elektronicznych Urzędu Patentowego (PUEUP)
Subskrypcje	Usługa zawierająca zbiór funkcjonalności pozwalających na okresowe otrzymywanie informacji dla wybranych parametrów zapytania lub względem zmian dla wskazanych praw ochrony własności przemysłowej
Symbol opłaty	(W kontekście MR oraz SGW) symbol opłaty przekazywany do MR przez SGW. Symbol opłaty umożliwa rozróżnienie poszczególnych typów opłat w ramach danej kategorii opłat.
System	Wszystkie moduły/produkty zaimplementowane/dostarczone w ramach Projektu PUEUP
System kancelaryjny UPRP	System do zarządzania korespondencją przychodzącą oraz wychodzącą do/z UPRP. System Kancelaryjny UPRP zawiera (agreguje) całość korespondencji związanej ze wszystkimi PWP. Systemem kancelaryjnym w UPRP jest obecnie EZD.

System wewnętrzny UPRP	System/aplikacja utrzymywana i dostarczona przez UPRP
System zewnętrzny	System/aplikacja utrzymywana i dostarczona przez podmiot zewnętrzny niezależny od Wykonawcy oraz UPRP.
TCO	ang. Total Cost of Ownership, Całkowity Koszt Pozyskania
Umowa	Umowa między Wykonawcą a UPRP w sprawie realizacji projektu PUEUP.
UPRP	UPRP, Urząd Patentowy Rzeczypospolitej Polskiej
Urząd	Patrz: UPRP.
UX	User experience, UX (ang. doświadczenie użytkownika) – całość wrażeń, jakich doświadcza użytkownik podczas korzystania z produktu interaktywnego. [..] Źródło: xxxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_xxxxxxxxxx
Użytkownik	Użytkownik danego systemu/funkcjonalności. Użytkownik może być zewnętrzny (Klient posiadający konto PUEUP lub nie posiadający takiego konta) lub wewnętrzny (pracownik UPRP). -Użytkownik zewnętrzny (Klient) niezalogowany -Użytkownik zewnętrzny (Klient) zalogowany -Użytkownik wewnętrzny (domyślnie zawsze zalogowany) -Użytkownik publicznego API
WCAG 2.0	ang. Web Content Accessibility Guidelines 2.0, Międzynarodowy standard w dziedzinie budowania stron internetowych.
WIPO	ang. World Intellectual Property Organization, Światowa Organizacja Własności Intelektualnej
Zamawiający	UPRP
Zamówienie	W zależności od kontekstu: 1. w SOPZ dotyczy przedmiotu Zamówienia niniejszego Projektu 2. w ramach Konta Klienta: jedna lub więcej płatności oznaczonych unikalnym numerem. Zamówienie jest opłacane jedną (autoryzowaną przez Xxxxxxx) operacją zapłaty (np. przelew, blik, operacja na karcie)
Zawiadomienie	Automatyczne generowana wiadomość dot. korespondencji oczekującej na odbiór Klienta. Zawiadomienie wysyłane jest poprzez email/sms wg konfiguracji Konta Klienta.
Zgłoszenie	Korespondencja przychodząca wysyłana przez Klienta PUEUP na podstawie tzw. formularzy Zgłoszeniowych: Formularz: Zgłoszenie - znak towarowy Formularz: Zgłoszenie - wynalazek Formularz: Zgłoszenie - wzór użytkowy Formularz: Zgłoszenie - wzór przemysłowy
ZT	skrót od: Znaki Towarowe (np. Numer Zgłoszenia ZT = "Z.123456")

ROZDZIAŁ I. Wstęp

Celem zamówienia jest opracowanie i dostarczenie dedykowanej platformy komunikacyjnej dla Klientów i pracowników Urzędu Patentowego Rzeczypospolitej Polskiej (UPRP) w sposób umożliwiający osiągnięcie zakładanych poziomów dostępności, wydajności i bezpieczeństwa oraz zapewnienie neutralności technologicznej zastosowanych rozwiązań. Zamówienie jest realizowane w ramach projektu Platforma Usług Elektronicznych Urzędu Patentowego (PUEUP), dofinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Polska Cyfrowa 2014-2020.

Głównym elementem przedmiotu zamówienia jest dostarczenie Oprogramowania Dedykowanego realizującego funkcjonalności opisane w SOPZ, bazującego na udostępnionej makiecie PUEUP. Przedmiot zamówienia obejmuje również swoim zakresem dostawę nowoczesnej infrastruktury teleinformatycznej, w tym oprogramowania standardowego oraz rozbudowę istniejących systemów infrastrukturalnych. W celu umożliwienia Zamawiającemu samodzielnego utrzymania i rozwoju uruchomionego środowiska w zakresie przedmiotu zamówienia znajduje się również dostarczenie szkoleń produktowych i zapewnienie transferu wiedzy o wdrożonych technologiach i rozwiązaniach do UPRP, jako organizacji przejmującej ich eksploatację. Wykonawca jest również zobowiązany do świadczenia usług gwarancyjnych i asysty technicznej dla dostarczonych produktów i wdrożonych rozwiązań, a także przygotowania szkoleń e-learningowych dla administratorów i użytkowników Systemu. Dodatkowo, w ramach zamówienia Wykonawca zobowiązany będzie do przeprowadzenia digitalizacji rejestrów, prowadzonych obecnie w formie papierowej.

Osiągnięcie celów Projektu PUEUP jest mierzone w oparciu o wskaźniki produktu i wskaźniki rezultatu projektu opisane w Załączniku A do SOPZ. Wykonawca musi wykonać przedmiot Umowy w sposób, który umożliwi Zamawiającemu osiągnięcie tych wskaźników. Wykonawca jest zobowiązany do przygotowania PUEUP w sposób umożliwiający stałe raportowanie poziomu osiągnięcia wskaźników produktu i rezultatu Projektu PUEUP.

Wykonawca w ramach realizacji przedmiotu zamówienia jest zobowiązany do takiego zaprojektowania wdrażanej infrastruktury teleinformatycznej, aby w przyszłości wdrożenie Planów Ciągłości Działania (obejmujących rozproszoną architekturę UPRP - w szczególności DR) było możliwe poprzez jej rozbudowę i nie wymagało wymiany dostarczonego sprzętu teleinformatycznego i oprogramowania.

W kolejnych rozdziałach SOPZ, oraz załącznikach wymienionych na liście Załączników do SOPZ, opisano szczegółowe wymagania w stosunku do przedmiotu zamówienia, w tym wymagania w stosunku do: dostarczanego sprzętu teleinformatycznego i oprogramowania standardowego, oprogramowania dedykowanego, architektury systemów infrastrukturalnych oraz PUEUP oraz sposobu i zakresu wdrożenia PUEUP.

Terminy i skróty użyte w Szczegółowym Opisie Przedmiotu Zamówienia zostały wyjaśnione na początku SOPZ.

ROZDZIAŁ II. Wymagania do architektury rozwiązania w domenie infrastrukturalnej

1. Zamawiający wymaga od Wykonawcy, aby w Projekcie w opisie architektury, opracowanej w ramach realizacji przedmiotu zamówienia, opisał system PUEUP stosując model warstwowy. Opis musi zawierać informację o technologiach i użytych mechanizmach. W szczególności Zamawiający wymaga, aby Wykonawca zawarł w opisie architektury PUEUP informacje dotyczące:

1.1. sposobu zapewnienia redundancji fizycznych elementów Infrastruktury IT – w tym przełączników LAN i SAN, serwerów fizycznych i ich elementów takich jak porty interfejsów czy dyski lokalne;

1.2. sposobu zapewnienia redundancji wirtualnych elementów Infrastruktury IT – w tym serwerów wirtualnych działających w środowisku wirtualizacji;

1.3. sposobu grupowania serwerów – w postaci klastrów niezawodnościowych, klastrów wydajnościowych lub farm;

1.4. sposobu lokalnej replikacji danych – w obrębie siedziby UPRP;

1.5. sposobu możliwej zdalnej replikacji danych – pomiędzy siedzibą UPRP, a inną lokalizacją.

2. Zamawiający wymaga od Wykonawcy, aby w trakcie realizacji przedmiotu zamówienia zastosował technologie wirtualizacyjne zgodne z posiadanym przez Zamawiającego środowiskiem VMware vSphere wraz z funkcjonalnościami służącym do przenoszenia aktywności poszczególnych logicznych komponentów systemów między obiektami fizycznymi, które będą zarządzane za pomocą centralnej konsoli Zamawiającego VMware vCenter Server. Wykonawca musi zastosować taką technologię wirtualizacji serwerów oraz poszczególnych komponentów wchodzących w skład rozwiązania, aby parametry tego rozwiązania były nie gorsze od parametrów wyspecyfikowanych w wymaganiach i było ono wspierane przez producentów dostarczonego Sprzętu i Oprogramowania.

3. Zamawiający wymaga od Wykonawcy, aby w trakcie realizacji przedmiotu zamówienia zastosował technologie backupu zgodne z posiadanym przez Zamawiającego środowiskiem Veeam Backup & Replication, zarządzanym za pomocą centralnej konsoli Zamawiającego dla systemu backupu. Wykonawca musi zastosować taki system backupu oraz poszczególnych komponentów wchodzących w skład rozwiązania, aby parametry tego rozwiązania były nie gorsze od parametrów wyspecyfikowanych w wymaganiach i było ono wspierane przez producentów dostarczonego Sprzętu i Oprogramowania.

4. Integracja z infrastrukturą Zamawiającego LAN, SAN.

Sieć teleinformatyczna UPRP jest podzielona na logiczne części. Poszczególne części odpowiadają konkretnym podsieciom VLAN. Podział taki ma na celu wyodrębnienie poszczególnych segmentów w sieci i zabezpieczenie ich urządzeniami firewall przed nieautoryzowanym dostępem. Za dystrybucje VLAN’ów odpowiadają klastry przełączników rdzeniowych i dostępowych. W sieci teleinformatycznej UPRP znajdują się dwa klastry firewalli usytuowane w różnych częściach logicznych środowiska szkieletowego sieci UPRP

t.j. Firewall brzegowy (ang. Edge Firewall) i Firewall wewnętrzny (ang. Internal Firewall). Zasady komunikacji sieci wewnętrznych z strefami ograniczonego zaufania (DMZ) oraz sieciami WAN są konfigurowane na Internal Firewallu. Konfiguracja publikacji w sieci WAN usług świadczonych przez UPRP odbywa się na Edge Firewallu.

Rysunek poglądowy:

Źródło: Opracowanie własne UPRP

Wykonawca zobowiązany jest do integracji wdrażanego rozwiązania z istniejącą infrastrukturą Urzędu w sposób niezakłócający działania systemów i sieci teleinformatycznej Urzędu. Zamawiający na potrzeby Projektu udostępni symetryczne stałe łącza internetowe wraz z urządzeniami teletransmisji niezbędnymi do zapewnienia komunikacji wdrażanego rozwiązania z globalną siecią komputerową.

5. Zamawiający wymaga od Wykonawcy, aby ochrona antywirusowa serwerów została zrealizowana przy użyciu komponentów Systemu Antywirusowego Symantec Endpoint Protection udostępnionych przez Zamawiającego, raportujących do centralnej konsoli Zamawiającego. Zamawiający zapewnia wszelkie niezbędne licencje oraz oprogramowanie antywirusowe Symantec. W okresie realizacji Umowy lub Gwarancji przez Wykonawcę oprogramowanie antywirusowe dostarczane przez Zamawiającego może ulegać wymianie (wymiana produktu lub producenta). Wykonawca w okresie realizacji Umowy lub Gwarancji, po otrzymaniu nowych komponentów systemu antywirusowego od Zamawiającego, jest zobowiązany do jego zainstalowania na wszystkich dostarczonych komponentach, na

których dotychczas funkcjonowało oprogramowanie antywirusowe. Ewentualna wymiana oprogramowania nie będzie realizowana częściej niż raz na rok.

6. Zamawiający wymaga od Wykonawcy, aby realizując przedmiot zamówienia stosował serwery kasetowe, tak by osiągnąć wysoki współczynnik konsolidacji i optymalizacji wykorzystania zasobów IT. Zamawiający dopuszcza stosowanie serwerów stelażowych wyłącznie w przypadku, gdy nie jest możliwe użycie serwerów kasetowych, ograniczając równocześnie zakres powyższego wyjątku do obsługi komponentów podpisu elektronicznego i systemu backupu.

7. Dostarczona w ramach realizacji zamówienia infrastruktura sprzętowa oraz jej konfiguracja musi zapewniać ciągłość i stabilność działania całego środowiska PUEUP.

8. W ramach dostarczonej przez Wykonawcę infrastruktury sprzętowej wyodrębnione zostaną cztery środowiska systemowe: środowisko rozwojowe (DEV), środowisko testowe- wewnętrzne (TEST-WEW), środowisko testowe-zewnętrzne (TEST-ZEW) i środowisko produkcyjne (PROD).

9. Systemy środowiska produkcyjnego muszą działać jako maszyny wirtualne uruchomione w klastrze serwerów działających w trybie wysokiej dostępności (HA).

10. Dostarczone rozwiązanie musi cechować się stabilnością i ciągłością działania maszyn wirtualnych podczas awarii fizycznej jednego z węzłów klastra. Elementy klastra serwerów wirtualizacyjnych muszą uruchamiać się z macierzy dyskowych. Maszyny wirtualne oraz ich zasoby dyskowe muszą być umieszczone na macierzach dyskowych.

11. Ze względu na homogeniczne środowisko zarządzania Zamawiającego wdrażane rozwiązanie musi być podłączone do aktualnego środowiska AD Zamawiającego (autentykacja użytkowników). Struktura AD w UPRP składa się z jednego lasu, jednego drzewa i jednej domeny, pod którą podlegają jednostki organizacyjne tzw. OU (ang. Organizational Units). Struktura domeny wyposażona jest w dwa kontrolery domeny. Obydwa kontrolery domeny znajdują się w tym samym segmencie sieci. Obydwa kontrolery domeny oparte są o system operacyjny Windows Server 2012 R2. Bieżący poziom funkcjonalności domeny to Windows Server 2012 R2. Pierwszy kontroler domeny pełni dodatkowo rolę serwera DNS oraz DHCP.

12. W przypadku, gdy Wykonawca analizując wymagania dla PUEUP stwierdzi konieczność zastosowania dla pracowników Zamawiającego systemu zarządzania tożsamością lub systemu zarządzania tożsamością własnego autorstwa lub zaimplementowania dedykowanych funkcji programistycznych w tym zakresie, Wykonawca zobowiązany jest do wykorzystania oprogramowania NetIQ Identity Manager Advanced, będącego w posiadaniu Zamawiającego. Zestawienie rodzaju i ilości posiadanych licencji na oprogramowanie NetIQ Identity Manager zostało wyszczególnione w Załączniku B do SOPZ, w rozdziale VII. W przypadku konieczności zapewnienia większej liczby licencji systemu NetIQ Identity

Manager niż podana i posiadana przez Zamawiającego, Wykonawca jest zobowiązany do ich dostarczenia na własny koszt, przy czym licencje te muszą być objęte wsparciem technicznym na zasadach określonych w Umowie dla Oprogramowania Standardowego.

13. Zarządzanie użytkownikami wewnętrznymi i ich uprawnieniami w systemie PUEUP musi być zorganizowane i zaimplementowane w taki sposób, aby istniała techniczna możliwość integracji systemu PUEUP z zewnętrznym systemem zarządzania tożsamością na poziomie funkcji w PUEUP dostępnej w odpowiednio zabezpieczonym interfejsie. W przypadku zarządzania użytkownikami lub ich uprawnieniami z wykorzystaniem tego interfejsu, w rejestrze zdarzeń musi być odkładana precyzyjna informacja o źródle wprowadzającym takie zmiany.

14. Zamawiający wymaga od Wykonawcy dostarczenia i wdrożenia systemu klasy SIEM instalowanego lokalnie. W ramach wdrożenia Wykonawca musi zaprojektować architekturę systemu, zaplanować i skonfigurować system do pobierania informacji ze źródeł danych Sprzętu i Oprogramowania, które zostały dostarczone przez Wykonawcę. Dostarczony przez Wykonawcę system SIEM musi charakteryzować się parametrami wyszczególnionymi w Załączniku D do SOPZ. Na podstawie zebranych danych system w czasie rzeczywistym musi normalizować i korelować zdarzenia w celu wykrywania nadużyć oraz zaawansowanych zagrożeń i ataków zewnętrznych i wewnętrznych. System musi w czytelny sposób prezentować przepływy w sieci oraz zdarzenia, jakie w niej występują. Wykonawca musi przygotować procedury eksploatacyjne umożliwiające Zamawiającemu samodzielne podpinanie nowych źródeł danych do systemu SIEM.

15. Zamawiający wymaga od Wykonawcy, aby monitoring środowiska PUEUP został zrealizowany we wszystkich warstwach przy użyciu komponentów Systemu Monitorowania udostępnionych przez Zamawiającego, raportujących do centralnej konsoli Zamawiającego. Do monitorowania poziomu dostępności e-Usług Zamawiający będzie wykorzystywał monitorowanie na poziomie EUM (ang. End User Monitoring). Zamawiający zapewni wszelkie niezbędne licencje oraz oprogramowanie Systemu Monitorowania. Zestawienie rodzaju i ilości posiadanych licencji na oprogramowanie Systemu Monitorowania zostało wyszczególnione w Załączniku B do SOPZ, w rozdziale VIII.

16. Zamawiający wymaga od Wykonawcy dostarczenia Bramki SMS, która umożliwi masowe wysyłanie krótkich wiadomości tekstowych (SMS) w liczbie co najmniej 5 SMS’ów na sekundę. W ramach konfiguracji systemu PUEUP musi być możliwość skonfigurowania systemu do wysyłania SMS’ów z wykorzystaniem dostarczonej Bramki SMS lub z wykorzystaniem zewnętrznych usług tego typu oferowanych przez operatorów. Dostarczona Bramka SMS musi być pozbawiona pojedynczego punktu awarii. Musi posiadać co najmniej następujące funkcjonalności:

• wysyłanie SMS do pojedynczego telefonu komórkowego,

• wysyłanie SMS do grupy telefonów komórkowych,

• obsługa raportów doręczenia,

• obsługa wysyłania wiadomości tekstowych, flashowych i unicode,

• konfigurowalna długość tekstu do wysłania,

• zdolność do obsłużenia dużej liczby SMSów (co miesiąc do 200 tys.),

• przekazywanie pojedynczych wiadomości SMS z telefonu komórkowego do grupy telefonów komórkowych,

• dostarczanie wiadomości SMS i e-mail do wiadomości SMS przez odpytywanie skrzynki pocztowej,

• przesyłanie dalej przychodzących wiadomości SMS na e-mail, eksportowanie danych do JSON i XML,

• obsługę ankiet SMS, zarządzanie systemem odpytywania za pomocą SMS, eksportowanie danych w postaci wykresu, co najmniej formatów JSON i XML,

• wysyłanie SMS za pomocą zabezpieczonego web serwisu wywoływanego z parametrami,

• równoległa obsługa wielu aktywnych kart SIM od różnych operatorów,

• obsługa bramki SMS z poziomu interfejsu WWW,

• możliwość zdefiniowania indywidualnego nagłówka identyfikacyjnego dla wszystkich wiadomości wysyłanych z systemu

• programowanie czasu wysyłki wiadomości (wysyłanie jednorazowe oraz okresowe)

• przeglądanie wiadomości (wysłane, oczekujące, zaplanowane do wysyłki, historia działań podejmowanych w systemie),

• funkcje wyszukiwania wiadomości i odbiorców,

• szyfrowanie danych przy wykorzystaniu protokołu TLS/SSL.

17. Zamawiający wymaga od Wykonawcy dostarczenia Bramki E-mail, która umożliwi bezpieczne wysyłanie wiadomości (szyfrowanie danych przy wykorzystaniu protokołu TLS/SSL) w liczbie co najmniej 5 wiadomości na sekundę. Bramka E-mail musi być pozbawiona pojedynczego punktu awarii. System PUEUP musi być skonfigurowany do wykorzystywania tej bramki do propagacji informacji przeznaczonej do wysyłki mail’em. Konfiguracja bramki musi być dostępna z poziomu interfejsu PUEUP.

18. Wszystkie oferowane urządzenia muszą działać pod kontrolą oprogramowania, które jest publiczną wersją, udostępnianą na rynku przez producenta oferowanych urządzeń. Zamawiający nie dopuszcza stosowania oprogramowania stworzonego na potrzeby niniejszego zamówienia, dla zaoferowanych urządzeń.

ROZDZIAŁ III. Wymagania do architektury rozwiązania w domenie aplikacyjnej

1. Założenia architektoniczne

1.1. Projekt przewiduje budowę dedykowanej Platformy Usług Elektronicznych Urzędu Patentowego (PUEUP) stanowiącej jednolity interfejs dla usług on-line UPRP. W ramach

platformy zostanie uruchomionych 7 głównych e-usług dla interesariuszy i Klientów UPRP, w tym:

• udostępnianie wglądu i wydawanie wyciągu z rejestrów,

• walidacja patentu europejskiego,

• powiadamianie o upływającym terminie ochrony,

• zgłoszenie o udzielenie ochrony dla wynalazku, wzoru użytkowego, wzoru przemysłowego i znaku towarowego,

• subskrypcja informacji,

• zmiany w rejestrach,

• składanie wniosków związanych z obsługą spraw PWP.

1.2. Zamawiający wymaga od Wykonawcy, aby platforma PUEUP została zaprojektowana i wdrożona zgodnie z założeniami SOA (ang. Service Oriented Architecture) w układzie modułowym (komponentowym). W skład Platformy Aplikacyjnej wejdą implementacje Modułów aplikacyjnych oraz usług określonych w architekturze docelowej systemu. Stosowanie modelu architektury SOA, wg której dla użytkowników definiuje się funkcje systemu teleinformatycznego stanowiące odrębną całość (usługi sieciowe) oraz opisuje się sposób korzystania z tych funkcji, to inaczej system zorientowany na usługi (wg rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności), który oferując wiele funkcjonalności i wysoki poziom dostępności dla dużej liczby użytkowników, wymaga odpowiednio wydajnej infrastruktury.

1.3. Zamawiający wymaga od Wykonawcy, aby platforma PUEUP została zaprojektowana i wykonana w taki sposób, aby wszystkie funkcje Systemu realizowane na potrzeby integracji z systemami wewnętrznymi były możliwe do wykonania za pomocą dedykowanego, zabezpieczonego interfejsu API. System musi zostać dostarczony z dedykowaną szyną usług ESB, na której będą publikowane usługi dedykowane do integracji z innymi systemami Zamawiającego, dowolnie skomponowane z metod i funkcji dostępnych w systemie za pośrednictwem interfejsu API.

1.4. System PUEUP będzie wspomagał przetwarzanie danych źródłowych poprzez:

• podpisywanie podpisem kwalifikowanym lub Profilem Zaufanym korespondencji elektronicznej przesyłanej do Urzędu oraz udostępnianie jej w Koncie Klienta;

• przyjmowanie i zapisywanie dokumentów elektronicznych podpisanych podpisem kwalifikowanym lub Profilem Zaufanym,

• identyfikowanie nadawców dokumentów podpisanych elektronicznie,

• przypisywanie dokumentów elektronicznych do spraw,

• przekazywanie korespondencji wraz z danymi do wewnętrznego systemu EZD,

• udostępnianie danych z innych systemów Urzędu np. danych o zgłoszeniach i prawach własności przemysłowej,

• zarządzanie oraz udostępnianie danych w ramach elektronicznego rejestru praw własności przemysłowej.

1.5. Podstawą przetwarzania w Systemie będzie sprawa, identyfikowana przez unikatowy, w ramach poszczególnych przedmiotów ochrony, numer zgłoszenia, a w przypadku udzielenia prawa wyłącznego także numer ochrony dla poszczególnych przedmiotów własności przemysłowej. W ramach wdrożenia zostanie opracowany Serwis Numeracyjny, zapewniający sekwencyjną auto-numerację dla dokumentów i spraw prowadzonych w UPRP.

1.6. Architektura Systemu musi być przystosowana do ciągłego i zaplanowanego rozwoju. W związku ze zwiększającym się zapotrzebowaniem klientów zewnętrznych na informacje oraz rozszerzaniem zasobów publicznych architektura systemu musi być podatna na zmiany. Oznacza to, że musi ona zapewniać:

• skalowalność – możliwość rozwoju poprzez zwiększanie wydajności, przepustowości, pojemności bez konieczności wymiany całych jednostek sprzętu (poprzez np. dodawanie: pamięci, dysków, kart rozszerzeń, nowych serwerów).

• elastyczność – wykorzystywanie otwartych standardów technologicznych umożliwiających łatwe i nie ingerujące w logikę Systemu dołączanie nowych usług.

• zarządzanie – wykorzystywanie ustabilizowanych sprawdzonych standardów technologicznych.

1.7. Zakres merytoryczny informacji prezentowanych w ramach PUEUP, dostęp do poszczególnych funkcji oraz możliwość ich realizacji muszą być uzależnione od profilu użytkownika i uprawnień przypisanych do profilu. Profile użytkowników Systemu to:

• użytkownik anonimowy z sieci WWW,

• użytkownik zewnętrzny z sieci Internet zalogowany do Konta Klienta,

• użytkownik wewnętrzny (pracownik UPRP),

• użytkownik publicznego API.

1.8. Zamawiający wymaga od Wykonawcy, aby wykonana platforma PUEUP w żaden sposób nie ograniczała Zamawiającego w wyborze przyszłego wykonawcy mogącego utrzymać system po zakończeniu realizacji umowy.

2. Moduły aplikacyjne

2.1. Platforma Usług Elektronicznych Urzędu Patentowego musi zostać zaprojektowana i wytworzona w oparciu o Moduły oraz komponenty funkcjonalne, umożliwiające realizację projektowanych usług elektronicznych. W ramach realizacji zamówienia Wykonawca musi zaprojektować i wytworzyć 7 Modułów:

2.1.1. e-Profil IP – profilowane konto Klienta na PUEUP

Moduł e-Profil IP stanowiący główny punkt dostępu (poprzez profilowane konto Klienta na PUEUP) do usług wymagających autoryzacji. Będzie umożliwiał Klientom: prowadzenie elektronicznej korespondencji z Urzędem w sprawach PWP i dokonywanie zgłoszeń, dokonywanie płatności online, dostęp do subskrybowanej informacji, widoku spraw, powiadomień, komunikatów oraz książki adresowej. Poza dostępem za pośrednictwem przeglądarek internetowych moduł umożliwi także dostęp (w zakresie opisanym w wymaganiach funkcjonalnych) do konta e-Profil IP poprzez dedykowane aplikacje mobilne przygotowane dla najpopularniejszych platform mobilnych (iOS, Android). E-Profil IP będzie realizował funkcję Podpisu Elektronicznego, która umożliwi Klientowi podpisywanie dokumentów z wykorzystaniem Profilu Zaufanego (ePUAP) oraz podpisów spełniających wymogi rozporządzenia eIDAS. W skład modułu wejdą następujące komponenty:

• GUI konta Klienta (korespondencja, widok spraw, płatności, subskrypcje, powiadomienia, komunikaty, książka adresowa),

• Elektroniczna Skrzynka Podawcza (ESP),

• Podpis Elektroniczny wraz z HSM,

• Serwis Numeracyjny,

• Komponent Kancelaryjno-Administracyjny,

• integracje wewnętrzne (z innymi modułami PUEUP oraz systemami UPRP) i zewnętrzne (OPE),

• aplikacje mobilne.

2.1.2. e-Wsparcie PWW (Proces Wypełniania Wniosków) – narzędzia zapewniające oraz usprawniające wymianę dokumentów z Klientem w formie elektronicznej

Moduł e-Wsparcie PWW umożliwi i usprawni proces wypełniania wniosków (formularzy elektronicznych) dla Klienta PUEUP. Moduł będzie implementował mechanizmy ułatwiające wprowadzanie oraz weryfikację danych wprowadzanych do formularzy przez Klientów. Moduł będzie umożliwiać: weryfikację wprowadzanej klasyfikacji Towarów i Usług, wyszukiwanie (za pomocą mechanizmów modułu e-Wyszukiwarka) podobieństwa w zakresie znaków towarowych (w zakresie opisanym w wymaganiach funkcjonalnych), pobieranie danych o wcześniejszych sprawach, automatyczne wypełnianie formularzy danymi pochodzącymi z książki adresowej oraz rejestrów publicznych (np. identyfikację uprawnionych na podstawie danych z REGON). W skład modułu wejdą następujące komponenty:

• elektroniczne formularze,

• integracje z systemami zewnętrznymi i wewnętrznymi w zakresie pobierania i walidacji danych wprowadzanych do formularzy.

2.1.3. e-Powiadomienia – przypominanie i informowanie Klientów o upływającym terminie ochrony poszczególnych praw wyłącznych

Moduł odpowiedzialny za realizację powiadomień o zbliżającym się terminie wygaśnięcia ochrony znaku towarowego i możliwości jego przedłużenia przez złożenie wniosku i wniesienie stosownych opłat. W przypadku pozostałych kategorii praw własności przemysłowej Klient będzie powiadamiany wybranym przez siebie kanałem komunikacji o zbliżającym się terminie na wniesienie opłaty za kolejny okres ochronny. Powiadomienia będą wysyłane drogą wskazaną przez Klienta tj. e-mail/SMS/publikacja w koncie Klienta PUEUP/korespondencja papierowa. Dodatkowo, dla klientów posiadających konto e-Profil IP system ułatwi wypełnienie wniosku o przedłużenie ochrony oraz udostępni możliwość wniesienia opłaty online. W skład modułu wejdą następujące komponenty:

• GUI pracownika UPRP (generowanie i zarządzanie powiadomieniami),

• GUI w koncie Klienta PUEUP (podgląd i możliwość przedłużenia ochrony),

• Bramka SMS,

• Bramka e-mail,

• Generator Powiadomień

• integracja z systemami UPRP

Moduł będzie wdrażany w dwóch etapach: pierwszy obejmujący powiadomienia dla znaków towarowych, drugi (odbierany łącznie z całym systemem PUEUP) dla pozostałych przedmiotów ochrony.

Na potrzeby realizacji etapu pierwszego modułu e-Powiadomienia Zamawiający udostępni niezbędną infrastrukturę sprzętową. Konfiguracja infrastruktury będzie obejmowała serwer wirtualny hostowany na środowisku VMware Zamawiającego w konfiguracji 2 vCPU (4 rdzenie per vCPU), 32 GB vRAM, 400 GB vHDD. W razie konieczności zwiększenie zasobów serwera może nastąpić po uprzednim uzgodnieniu z Zamawiającym. Zwiększenie zasobów sprzętowych nie może przekroczyć 30% pierwotnej konfiguracji.

Po wdrożeniu etapu drugiego modułu e-Powiadomienia Wykonawca przeniesie całe środowisko wirtualne etapu pierwszego na infrastrukturę dostarczoną i skonfigurowaną przez Wykonawcę w ramach realizacji PUEUP.

2.1.4. e-Rejestry – prowadzenie i zarządzenie elektronicznymi rejestrami

Moduł e-Rejestry umożliwi gromadzenie i udostępnianie informacji publicznych na temat chronionych przedmiotów własności przemysłowej wraz z ich

historycznym i aktualnym stanem prawnym. W ramach modułu, w formie elektronicznej będzie prowadzonych 8 Rejestrów publicznych będących we właściwości UPRP, w tym: rejestr patentowy, rejestr patentów europejskich (EP

– stanowiący wyodrębnioną część rejestru patentowego), rejestr dodatkowych praw ochronnych, rejestr wzorów użytkowych, rejestr wzorów przemysłowych, rejestr znaków towarowych, rejestr oznaczeń geograficznych oraz rejestr topografii układów scalonych. Klient będzie miał dostęp online przez przeglądarkę internetową do aktualnego statusu sprawy w e-Rejestrze. Dodatkowo Klient posiadający konto e-Profil IP będzie mógł wypełnić i wysłać wniosek o wydanie wyciągu z rejestru oraz wnieść opłatę online. Dzięki modułowi nie będzie potrzeby bezpośredniego (na miejscu w UPRP) przeglądania Ksiąg Rejestrowych, co zaoszczędzi koszty i czas, zarówno Klientowi, jak i pracownikom UPRP. W skład modułu wejdą następujące komponenty:

• GUI e-Rejestry (dla pracownika UPRP),

• GUI dla Klienta UPRP (podgląd kart i zamawianie wyciągu),

• integracje wewnętrzne (z innymi modułami PUEUP oraz systemami UPRP).

2.1.5. e-Płatności – realizacja płatności elektronicznych i zarządzanie opłatami w postępowaniu

Moduł e-Płatności służący do przechowywania i zarządzania wszystkimi informacjami o operacjach i transakcjach finansowych dotyczących przedmiotów ochrony odpowiadający jednocześnie za elektroniczną obsługę płatności w PUEUP. W ramach modułu zostanie zaimplementowany Kalkulator Opłat (dostępny przy wypełnianiu wniosków/formularzy), który automatycznie wyliczy wysokość opłaty (na podstawie Tabel Opłat) za usługę w zależności od danych wprowadzonych do formularza elektronicznego przez Klienta. Wyliczoną opłatę klient będzie mógł opłacić elektronicznie. Opłata zostanie automatycznie skojarzona z oczekującą należnością, co umożliwi automatyczne sprawdzenie części wymagań formalnych i przyspieszy procedowanie spraw oraz zmniejszy liczbę koniecznych wyjaśnień w przypadku błędnych lub niejasnych płatności. Moduł umożliwi Klientom w każdym momencie wgląd w historię i status ich płatności. W celu zapewnienia funkcjonowania mechanizmu płatności elektronicznych, UPRP przeprowadzi na etapie projektowania Modułu, wybór OPE (Operator Płatności Elektronicznych) świadczącego usługi obsługi płatności on-line. Mechanizmy przygotowane przez Wykonawcę w ramach realizacji projektu muszą zagwarantować możliwość skorzystania z usług dowolnego OPE w PUEUP, niezależnie czy będzie to operator komercyjny czy też operator dedykowany dla administracji publicznej. Wskazane przez klienta opłaty będą grupowane w Zamówienie z unikalnym identyfikatorem. Po dokonaniu płatności i potwierdzeniu przez OPE prawidłowo dokonanej opłaty moduł e-Płatności musi

umożliwić prezentację szczegółowych danych o zamówieniu. Moduł składa się z dwóch zintegrowanych ze sobą komponentów:

• Modułu Rozliczeń – wewnętrznego narzędzia (wraz z GUI dla użytkownika wewnętrznego) do zarządzania i kontroli opłat dotyczących przedmiotów ochrony – wymieniającego informacje z systemami UPRP;

• Modułu Płatności Elektronicznych (MPE) – narzędzia do zarządzania procesem obsługi płatności elektronicznych (wniesienie opłaty online, wspomaganie procesu księgowania, informacje o opłatach w koncie klienta)

– wymieniającego informacje z systemami UPRP. W skład MPE wchodzą także:

o GUI pracownika UPRP

o GUI w koncie Klienta PUEUP

• Kalulator Opłat – komponent wyliczający wysokość opłat w odniesieniu do danych formularza

• Tabele Opłat – jedyne i wspólne źródło danych dot. opłat dla wszystkich modułów PUEUP

2.1.6. e-Wyszukiwarka – wyszukiwanie informacji w zbiorach i publikacjach UPRP

Moduł odpowiedzialny za wyszukiwanie danych publicznych dotyczących przedmiotów własności przemysłowej z poziomu jednej wyszukiwarki poprzez intuicyjny interfejs użytkownika. Będzie to nowoczesny system wyszukiwawczy spełniający wymagania stawiane tego rodzaju serwisom (np. zapewniające autouzupełnianie pól, przeszukiwanie, pełno-tekstowe, polską fleksję). Wyszukiwanie informacji będzie możliwe, zarówno w danych z baz systemów dziedzinowych UPRP, jak i oficjalnych publikacjach (BUP, WUP). W skład modułu wejdą następujące komponenty:

• GUI dla Klienta UPRP (wyszukiwanie, definiowanie parametrów dla usługi subskrypcji informacji),

• GUI dla pracownika UPRP.

2.1.7. e-Baza wiedzy – modernizacja sposobu informowania oraz kontaktowania z Klientem.

Moduł umożliwi implementację nowych kanałów komunikacji z Klientem oraz zwiększy atrakcyjność dostępnych materiałów informacyjno-szkoleniowych dla Klienta. E-Baza Wiedzy stanowić będzie również internetowe kompendium wiedzy z zakresu szeroko rozumianej tematyki ochrony własności intelektualnej, w tym także związanej z zarządzaniem prawami wyłącznymi oraz transferem technologii. Moduł zawierać będzie informacje, publikacje, bazy danych i inne materiały skierowane zarówno do podmiotów posiadających zaawansowaną

wiedzę w tym zakresie (np. przedsiębiorców prowadzących działalność innowacyjną, którzy posiadają duże doświadczenie w tym zakresie, rzeczników patentowych itp.), jak i przedsiębiorców szukających podstawowych informacji o przedmiotach ochrony, obowiązujących procedurach czy też tworzeniu strategii ochrony IP oraz zarządzania prawami wyłącznymi. W ramach tego Modułu, oprócz modułów szkoleniowych wynikających z wymagań funkcjonalnych, Wykonawca będzie także zobowiązany do przygotowania i wdrożenia kursów e-learningowych dotyczących wypełnienia wniosków (w tym, w szczególności, dotyczących uzyskania patentu na wynalazek czy uzyskania prawa ochronnego na znak towarowy) oraz obsługi PUEUP. E-Baza wiedzy zaopatrzona będzie też w nowoczesną wyszukiwarkę - narzędzie pozwalające na proste i precyzyjne dotarcie do informacji w niej zawartych (wszukiwarka po stronach). Ponadto Moduł będzie zawierał rozwiązania mające na celu zwiększenie efektywności komunikacji z Klientem jak np. interaktywne konsultacje z pracownikiem UPRP w trakcie przeglądania stron UPRP (np. czat, formularz kontaktowy, telefon). Moduł składa się z następujących komponentów:

• Strona główna (PUEUP)

• Internetowa Platforma Edukacyjna UPRP (IPE)

• CMS (ang. Content Management System)

2.2. Zamawiający wymaga od Wykonawcy, aby komponenty Podpis Elektroniczny, Serwis Numeracyjny, Moduł Rozliczeń, Bramka SMS, Bramka E-mail wchodzące w skład platformy PUEUP, zostały zrealizowane w postaci wydzielonych podsystemów. Architektura tych podsystemów oraz proces ich realizacji musi być zgodny z wymaganiami określonymi w SOPZ dla aplikacji dedykowanych. W szczególności oznacza to, że:

• Nie jest dopuszczalne współdzielenie funkcji i zasobów pomiędzy tymi podsystemami oraz innymi Modułami PUEUP, również tymi, w których skład wchodzą,

• Dokumentacja dla każdego z wymienionych powyżej podsystemów, musi zostać utworzona w postaci dokumentów możliwych do wyodrębnienia z dokumentacji systemu PUEUP.

2.3. Poniżej przedstawiono diagram kontekstowy (schemat uproszczony) obrazujący podział systemu PUEUP na Moduły i komponenty funkcjonalne.

Rys. Schemat PUEUP

Źródło: Opracowanie własne UPRP

ROZDZIAŁ IV. Bezpieczeństwo teleinformatyczne, audyty

1. Zamawiający wymaga od Wykonawcy, aby realizując przedmiot zamówienia spełnił wszystkie wymagania w obszarze bezpieczeństwa teleinformatycznego określone w SOPZ i jej załącznikach oraz w przepisach prawa powszechnie obowiązującego, w szczególności w sferze ochrony i przetwarzania danych osobowych i prawa własności przemysłowej.

2. PUEUP wytworzony przez Wykonawcę będzie poddany procesowi zewnętrznego audytu w zakresie bezpieczeństwa (również odporności na ataki typu DoS/DDos), niezawodności i wydajności całego systemu, bezpieczeństwa i jakości kodu źródłowego oraz zgodności ze standardem WCAG 2.0 na poziomie AA (wszystkie kryteria) i AAA (co najmniej: 2.2.4 Zakłócenia, 2.2.5 Ponowne potwierdzenie autentyczności, 2.3.2 Trzy błyski, 3.1.3 Nietypowe słowa). Zamawiający będzie wymagał od Wykonawcy zaimplementowania zmian w PUEUP, które usuną dostrzeżone podatności, wady, niezgodności lub ułomności zgłoszone w trakcie działań weryfikacyjno-audytowych.

3. Zamawiający wymaga od Wykonawcy, aby w okresie obowiązywania Umowy i Gwarancji, dostarczał i instalował wszelkie wymagane certyfikaty do obsługi PUEUP, w szczególności w obszarze zabezpieczania komunikacji sieciowej oraz podpisywania poświadczeń generowanych przez PUEUP (dostarczane certyfikaty muszą być publicznie zaufane, muszą być oparte o najnowsze protokoły kryptograficzne oraz muszą jednoznacznie identyfikować Zamawiającego). Obowiązek ten nie dotyczy wyłącznie certyfikatów do imiennego podpisu elektronicznego pracowników Zamawiającego.

4. Użytkownik posiadający ważny podpis kwalifikowany lub Profil Zaufany musi mieć możliwość założenia konta Zaawansowanego dla użytkownika zewnętrznego w systemie PUEUP, bez konieczności dodatkowych poświadczeń. Dodatkowo, Wykonawca systemu PUEUP musi uwzględnić wykonanie jednej dodatkowej autentykacji z wykorzystaniem interfejsów, które zostaną udostępnione Wykonawcy w ramach realizacji Umowy (np. potwierdzenie tożsamości przez banki, eIDAS, PUE ZUS, Krajowy System Indentyfikacji Elektronicznej).

5. System PUEUP dla użytkowników zewnętrznych, korzystających z autentykacji opartej o dedykowane konto platformy, musi umożliwiać zdefiniowanie polityki haseł co najmniej w zakresie minimalnej liczby znaków, wymaganej złożoności hasła (kombinacja cyfr, znaków specjalnych, małych i dużych liter), powtarzalności hasła oraz terminu jego ważności.

6. Użytkownicy wewnętrzni w pierwszym kontakcie z systemem PUEUP muszą wykorzystywać mechanizmy automatycznej autentykacji (brak obowiązku odrębnego, ręcznego logowania) i polityki haseł opartej o centralną usługę katalogową Zamawiającego AD.

7. Logi systemowe generowane przez wszystkie komponenty systemu PUEUP muszą być składowane w jednym, uzgodnionym z Zamawiającym miejscu, muszą rejestrować zdarzenia

systemowe oraz wszystkie działania administratorów i użytkowników (zalogowanych i niezalogowanych). Rejestrowane czynności użytkowników w systemie muszą obejmować co najmniej: dokonanie wpisu, usunięcie wpisu, zmiana wpisu, odczytanie danych. W celu zachowania ścieżki rewizyjnej i chronologii zdarzeń wszelkie operacje muszą być oznaczane identyfikatorem użytkownika i czasem wykonania każdej z nich (rejestracja zdarzeń). Wszystkie aplikacje muszą być wyposażone w mechanizmy logowania co najmniej na kilku poziomach, umożliwiając rejestrowanie zdarzeń, zarówno poprawnie wykonanych operacji, jak również wyjątków i błędów. We wszystkich warstwach aplikacji wszelkie próby nieautoryzowanego dostępu lub użycia funkcji systemu bez posiadanych uprawnień muszą być monitorowane i rejestrowane. Wykonawca będzie zobowiązany również do zorganizowania zasilania systemu SIEM informacją pochodzącą ze składowanych logów.

8. Dla wszystkich komponentów PUEUP Wykonawca z wykorzystaniem dostarczonego sprzętu i oprogramowania przygotuje, przetestuje i wdroży dedykowane wielopoziomowe polityki zabezpieczenia danych w centralnym systemie kopii bezpieczeństwa UPRP, w architekturze backupu B2D2T (ang. Backup To Disk To Tape) z okresową retencją nośników.

9. Wykonawca musi zastosować w PUEUP model architektury, który zapewni wysoką dostępność i niezawodność rozwiązania poprzez zastosowanie redundancji komponentów systemu we wszystkich jego warstwach.

10. Wykonawca musi zastosować w PUEUP bezpieczny model zapewniający podział infrastruktury sieciowej na strefy bezpieczeństwa.

11. Wykonawca musi zastosować w PUEUP zabezpieczenia gwarantujące ochronę poufności komunikacji.

12. W systemie PUEUP muszą być rejestrowane wszelkie zdarzenia dotyczące operacji na danych osobowych oraz źródeł ich wywołania.

13. System PUEUP musi zapewniać bezpieczeństwo danych oraz podsystemów przetwarzających dane, a zabezpieczenia opracowane na etapie projektowania muszą być poprzedzone analizą ryzyka.

14. Wykonawca po podpisaniu umowy będzie zapoznany z Systemem Zarzadzania Bezpieczeństwem Teleinformatycznym (SZBTi) funkcjonującym u Zamawiającego i będzie zobowiązany do jego przestrzegania. SZBTi został zbudowany zgodnie z normą PN-ISO/IEC 27001 określającą wymagane cele zabezpieczenia teleinformatycznego x.xx. w obszarach: zarządzania systemami i sieciami, kontroli dostępu, pozyskiwania, rozwoju i utrzymania systemów informatycznych, bezpieczeństwa sprzętu. Dokument opisujący zasady funkcjonowania Systemu Zarządzania Bezpieczeństwem Teleinformatycznym oraz Polityka Bezpieczeństwa Teleinformatycznego zostaną udostępnione Wykonawcy po podpisaniu Umowy.

ROZDZIAŁ V. Dokumentacja

1. Wykonawca jest zobowiązany do wytworzenia i dostarczenia Dokumentacji związanej z realizacją przedmiotu zamówienia, która będzie podlegała odbiorom. Wykonawca ma obowiązek aktualizować dostarczoną i odebraną Dokumentację, tak, aby uwzględniała każdą zmianę dokonywaną w ramach gwarancji (obowiązek ten nie dotyczy Dokumentacji Projektowej po wykonanym wdrożeniu, gdyż rolę dokumentacyjną przejmie Dokumentacja Powykonawcza Systemu). Dostarczona dokumentacja musi być dostępna w wersji papierowej i elektronicznej w języku polskim. Dopuszcza się język angielski w dokumentacji technicznej elementów, które nie są dziełem Wykonawcy, a dokumentacja producenta w języku polskim nie jest dostępna.

2. Dokumentacja musi się składać co najmniej z:

2.1 Harmonogramu Szczegółowego (HS). Wykonawca na podstawie Harmonogramu Ramowego (HR) określonego w zawartej umowie oraz wymagań przedmiotu zamówienia jest zobowiązany do opracowania Harmonogramu Szczegółowego realizacji umowy, który musi obejmować wszystkie elementy dostaw, cykle wytwarzania oprogramowania oparte o zwinną metodykę Agile, odbiory, wdrożenia, szkolenia, warsztaty i inne niezbędne elementy do poprawnej realizacji całego przedsięwzięcia. Harmonogram Szczegółowy nie może naruszać terminów określonych w Harmonogramie Ramowym.

2.2 Dokumentacji Projektowej (DP) zawierającej co najmniej:

2.2.1 Projekt Techniczny Systemu PUEUP (PTS). Wykonawca jest zobowiązany do przygotowania PTS i przedstawienia go do odbioru. PTS będzie ostatecznym dokumentem szczegółowo opisującym system skomponowany adekwatnie do potrzeb Zamawiającego we wszystkich warstwach infrastrukturalnych i aplikacyjnych. PTS musi prezentować architekturę wszystkich modułów systemu i aplikacji. Projekt musi obejmować: szczegółową specyfikację użytego oprogramowania, szczegółowy opis konfiguracji sieci, serwerów systemów operacyjnych, baz danych i użytych opcji, serwerów aplikacyjnych i aplikacji. Musi obejmować opis i rodzaj interfejsów komunikacyjnych do innych systemów. Musi on opisywać wszystkie komponenty składowe systemu PUEUP, rozlokowanie elementów, elementy konfiguracji, a także zależności i powiązania między nimi.

2.2.2 Projekt Funkcjonalny Systemu (PFS). Na podstawie zawartych w umowie wymagań funkcjonalnych Wykonawca opracuje PFS. PFS co najmniej na poziomie modułów musi opisywać przebieg głównych procesów realizowanych przez dany moduł, realizowanych funkcji, a także przepływ informacji między nimi. PFS musi zawierać: diagramy klas, diagramy UML przypadków użycia,

diagramy ERD, schematy bazy danych z zależnościami i opisem do poziomu encji, opisy procesów realizowanych za pomocą PUEUP w notacji BPMN, a także przewidywany model danych powiązany ze źródłami danych Zamawiającego wraz z opracowaniem procesu ich aktualizacji. PFS musi opisywać planowane migracje i integracje, w szczególności sposób realizacji, źródło, cel i zakres danych oraz metodę ich implementacji.

2.2.3 Dokumentację Testową (DTS). Dokumentacja testowa musi zawierać Plan Testów całego systemu PUEUP z podziałem na poszczególne jego warstwy. Dokumentacja testowa musi obejmować co najmniej scenariusze dla testów: wydajnościowych, niezawodnościowych, bezpieczeństwa, WCAG 2.0., zgodności RWD, integracyjnych i akceptacyjnych (w tym rozbudowywanych i nowych systemów infrastrukturalnych) oraz scenariusze testowania planów awaryjnych.

2.3 Dedykowanej Dokumentacji Projektowej dla Modułu e-Powiadomienia etap-1

o zawartości merytorycznej analogicznej jak dla Dokumentacji Projektowej.

2.4 Dokumentacji Powykonawczej Systemu (DPS) zawierającej co najmniej:

2.4.1 treści przedstawione w PTS zaktualizowane do stanu faktycznego po wdrożeniu PUEUP oraz ustalenia wynikające z przebiegu wdrożenia,

2.4.2 treści przedstawione w PFS zaktualizowane do stanu faktycznego po wdrożeniu PUEUP oraz ustalenia wynikające z przebiegu wdrożenia, uszczegółowione do poziomu atrybutów encji i sposobu jej reprezentacji we wdrożonym systemie,

2.4.3 repozytorium kodu źródłowego PUEUP (w tym wszelkich skryptów wykonywanych w powłoce systemu operacyjnego lub innych interpreterów lub kompilatorów) wraz z parametrami wejściowymi, parametrami kompilacji oraz opisem struktury i organizacji kodu,

2.4.4 wykaz certyfikatów zainstalowanych w systemie z wyszczególnieniem ich przeznaczenia, rodzaju, miejsca instalacji i okresu ważności.

2.5 Dokumentacji Administratora (DA) zawierającej co najmniej:

2.5.1 instrukcje i procedury eksploatacyjne, tj. procedury postępowania podczas bieżącej eksploatacji, administracji i konserwacji systemu (np. backup, odtworzenie, zarządzanie logami, zarządzanie użytkownikami i uprawnieniami, monitorowanie parametrów środowiska) niezbędne do zapewnienia prawidłowego działania systemu i poprawnej jego aktualizacji.

2.5.2 opis instalacji i konfigurowania wszystkich komponentów systemu,

2.5.3 opis integracji z innymi systemami,

2.5.4 opis zarządzania zmianami w systemie i sposób dokumentowania tych zmian.

2.5.5 numery części (part number), numery seryjne, etc. wszystkich urządzeń dostarczonych przez Wykonawcę,

2.5.6 hasła administratorskie dające maksymalne uprawnienia do wszystkich urządzeń i oprogramowania (hasła muszą być przekazane w bezpieczny sposób, w uzgodnieniu z Zamawiającym),

2.5.7 opis wraz ze schematami topologii sieci w warstwie fizycznej i logicznej zawierająca przynajmniej parametry komunikacyjne w warstwie fizycznej, informacje o adresacji, vpn’ach i v-lanach, przepływach (źródło, cel, port, protokół, polityka, itp.),

2.5.8 opis konfiguracji switch’y LAN, switch’y SAN, HSM’ów: konfiguracja (postać papierowa i elektroniczna gotowa do importu na urządzenia),

2.5.9 opis konfiguracji serwerów: dokładne parametry sprzętowe, opis konfiguracji systemu, wersje, układ dysków, partycjonowanie, konfiguracja interface’ów sieciowych, spis usług działających na serwerze i ich konfiguracja oraz przydzielone im zasoby, etc.

2.5.10 opis konifguracji macierzy i bibliotek: dokładne parametry sprzętowe, opis konfiguracji oprogramowania, wersje, układ dysków, partycjonowanie, konfiguracja interface’ów sieciowych, etc.,

2.5.11 opis licencji, numery i kucze aktywacyjne i numery licencji, okres wsparcia producenta,

2.5.12 opis konfiguracji (postać papierowa i elektroniczna gotowa do importu na serwery i inne urządzenia),

2.6 Dokumentacji Użytkownika Wewnętrznego (DUW) zawierającej co najmniej:

2.6.1 ogólną dokumentację opisująca zakres funkcjonalności komponentów systemu,

2.6.2 szczegółową, stanowiskową instrukcję użytkownika wewnętrznego zawierająca opis czynności użytkownika wewnętrznego dla danego stanowiska lub roli w module.

2.7 Opisów usług, sporządzonych na podstawie wzorów stanowiących Załącznik C do SOPZ.

2.8 Planów awaryjnych, sporządzonych dla całego systemu PUEUP, uwzględniających szczegółowy opis czynności, poleceń i sekwencji działań, które są niezbędne do wykonania w celu odtworzenia całego systemu po katastrofie. Plany awaryjne muszą

być zdekomponowane na poszczególne komponenty systemu, które można będzie wykonywać „w górę” od początku odtwarzania całego systemu PUEUP lub też od określonego poziomu awarii.

2.9 Dokumentacji Użytkownika Zewnętrznego (DUZ) zawierającej co najmniej:

2.9.1 multimedialne materiały informacyjno-promocyjne dostarczone w języku polskim, przeznaczone dla użytkowników zewnętrznych (Klientów UPRP) prezentujące funkcjonalność systemu PUEUP, w szczególności konta Klienta oraz udostępnionych e-usług systemu PUEUP.

2.9.2 multimedialne materiały szkoleniowe dostarczone w języku polskim, prezentujące „krok po kroku” sposób posługiwania się systemem PUEUP od strony użytkownika zewnętrznego (Klienci UPRP), a także sposób korzystania z udostępnionych e-usług systemu PUEUP. Przygotowane przez Wykonawcę i odebrane przez Zamawiającego materiały szkoleniowe muszą być przygotowane w formie szkoleń e-learningowych i muszą być zainstalowane i dostępne przez PUEUP.

2.10 Przyjęta i odebrana przez Zamawiającego Dokumentacja Projektowa będzie punktem odniesienia do kontroli zgodności i poprawności wdrażanych rozwiązań. W przypadku dostrzeżenia rozbieżności pomiędzy opisem przedmiotu zamówienia, a przyjętym w Dokumentacji Projektowej założeniu, o sposobie jego realizacji będzie decydował opis przedmiotu zamówienia zawarty w umowie.

2.11 Dokumentacja Powykonawcza Systemu przedstawiona do odbioru musi obejmować wszystkie elementy Modułu e-Powiadomienia zrealizowane w etapie-1 oraz w pełnym zakresie wdrożenia.

ROZDZIAŁ VI. Dostawa Sprzętu oraz Oprogramowania Standardowego

1. Zamawiający wymaga od Wykonawcy, aby rodzaje oraz ilości sprzętu teleinformatycznego i oprogramowania, dostarczonego przez niego w celu wykonania przedmiotu zamówienia, były właściwie dobrane, kompletne i wystarczające do jego realizacji w sposób zgodny z wymaganiami określonymi w SOPZ.

2. Zamawiający w Załączniku B do SOPZ zamieścił wykaz licencji oprogramowania wykorzystywanego obecnie przez Zamawiającego i podlegającego rozbudowie.

3. W przypadku konieczności zapewnienia większej liczby licencji dla oprogramowania standardowego niż podana i posiadana przez Zamawiającego Wykonawca jest zobowiązany do ich dostarczenia na własny koszt.

4. Jeżeli w okresie realizacji umowy wystąpi potrzeba zapewnienia licencji czasowych na dowolne oprogramowanie, Wykonawca jest zobowiązany do ich zapewnienia we własnym zakresie.

5. Dla licencji oprogramowania standardowego, dostarczonych przez Wykonawcę, Wykonawca zobowiązany jest do utrzymywania aktualnego wsparcia producenta (w tym prawa do aktualizacji do nowych wersji) przez cały okres obowiązywania Gwarancji na Sprzęt.

6. Zamawiający wymaga od Wykonawcy dostarczenia sprzętu serwerowego i licencji na oprogramowanie standardowe w ilościach nie mniejszych od wartości podanych w Załączniku D do SOPZ.

7. Zamawiający wymaga od Wykonawcy, aby dla PUEUP wartości parametrów ilościowych, takich jak:

7.1 liczba serwerów,

7.2 liczba i typ procesorów,

7.3 ilość pamięci RAM,

7.4 wielkość przestrzeni dyskowych,

7.5 minimalna moc obliczeniowa serwerowni,

użyte przez niego do wyliczenia ilości sprzętu teleinformatycznego i oprogramowania, dostarczanych przez niego w ramach realizacji przedmiotu zamówienia, umożliwiły realizację wymagań dla poszczególnych komponentów systemów dla wszystkich środowisk (produkcyjnego, testowego-zewnętrznego, testowego-wewnętrznego, deweloperskiego), przy założeniu odwzorowania pełnej architektury środowiska produkcyjnego na środowiskach testowych oraz możliwości wyskalowania zasobów środowiska testowego- wewnętrznego do parametrów odpowiadających środowisku produkcyjnemu na potrzeby przeprowadzenia testów (np. wydajnościowych), bez pomniejszania wydajności środowiska produkcyjnego.

8. W trakcie realizacji dostaw i przeprowadzania odbiorów ilościowych produktów Wykonawcę będą obowiązywać procedury odbioru zawarte w Załączniku E do SOPZ.

ROZDZIAŁ VII. Dostawa Oprogramowania Dedykowanego

1. Wymagania funkcjonalne i niefunkcjonalne

Zamawiający wymaga od Wykonawcy, aby przygotowany System spełniał szczegółowe wymagania funkcjonalne i niefunkcjonalne zawarte są w Załączniku F do SOPZ.

2. Wytwarzanie oprogramowania

2.1 Zamawiający wymaga od Wykonawcy, aby wytwarzanie oprogramowania i prowadzenie prac implementacyjnych zostało oparte o zwinne (ang. agile) metodyki wytwarzania oprogramowania wg modelu SCRUM. Takie podejście zapewni bezpośredni i stały udział Zamawiającego w kolejnych, ściśle określonych iteracjach (ang. Sprint) rozwoju oprogramowania, maksymalizując użyteczność i używalność systemu oraz umożliwi szybkie reagowanie na zmiany i maksymalne dostosowanie tworzonego systemu do potrzeb użytkowników.

2.2 Zamawiający zakłada podział procesu wytwarzania oprogramowania na okresowe Sprinty, w ramach których zespół będzie pracować nad osiągnięciem konkretnych celów zdefiniowanych na początku każdego Sprintu. Przed rozpoczęciem każdej iteracji, Wykonawca będzie konsultował z Zamawiającym sposób realizacji kolejnych funkcjonalności przeznaczonych do implementacji. W celu nadzoru nad implementacją wydzielona zostanie w ramach struktury Projektu dedykowana rola tzw. właściciela/opiekuna produktu (ang. Product Owner). Osoba posiadająca taką rolę będzie odpowiedzialna za bieżące specyfikowanie, ustalanie priorytetów, nadzór nad implementacją, testowanie i przekazywanie Zamawiającemu ukończonych w ramach każdej iteracji funkcjonalności PUEUP.

2.3 Przekazywane funkcjonalności będą dostarczane przez Wykonawcę jako wersje prototypowe, których działanie będzie weryfikowane w środowisku testowym, a także konsultowane z przedstawicielami użytkowników e-usług. Zakłada się, że Wykonawca Systemu dostarczy Prototyp Systemu, który podlegać będzie ocenie i akceptacji Zamawiającego i stanowić będzie podstawę do budowy docelowego rozwiązania. Wykonawca na podstawie zatwierdzonego Prototypu wytworzy oprogramowanie aplikacji Systemu, zgodne z wymaganiami określonymi w szczegółowym opisie przedmiotu zamówienia oraz uzgodnieniami poczynionymi w trakcie bieżącej realizacji umowy. Wytworzone oprogramowanie będzie poddane testom po stronie Wykonawcy, a po uzyskaniu pozytywnego wyniku tych testów przekazane do testów Zamawiającego.

2.4 Zamawiający wymaga od Wykonawcy, aby opracował i prowadził ustrukturyzowany rejestr funkcjonalności systemu (tzw. ang. Product Backlog) PUEUP. Rejestr ten zostanie sporządzony na podstawie przygotowanej przez Zamawiającego listy wymagań funkcjonalnych do systemu (Załącznik F do SOPZ) i będzie stanowił podstawę do specyfikowania prac implementacyjnych (zadań programistycznych) i wyznaczania kolejnych priorytetów implementacji.

2.5 W procesie wytwarzania Oprogramowania Dedykowanego Zamawiający wymaga od Wykonawcy używania komponentów Oprogramowania Standardowego w zakresie serwerów aplikacyjnych opartych wyłącznie o otwarte tryby licencjonowania kodu źródłowego OpenSource oraz wyłącznie takich, które zapewniają multiplatformowość (mogą być instalowane na systemach operacyjnych zarówno z rodziny Linux, jak i Windows w architekturze x86_64). W procesie wytwarzania oprogramowania

Wykonawca nie może implementować w systemie PUEUP żadnych elementów rozpowszechnianych na innych zasadach niż powyżej określone (np. płatnych, skompilowanych bibliotek, elementów wymagających stałej subskrypcji). Jednocześnie Wykonawca jest zobowiązany do przekazania wszelkich praw autorskich do kodu źródłowego wytworzonego Oprogramowania Dedykowanego (aplikacji, modułów PUEUP), dokumentacji i innych produktów wytworzonych na potrzeby realizacji systemu PUEUP na zasadach określonych w Umowie.

2.6 Zamawiający wymaga od Wykonawcy, aby System realizowany w ramach Projektu był zgodny z wymaganiami określonymi w Krajowych Ramach Interoperacyjności1, które przewidują:

• Zastosowanie rozwiązań opartych na modelu usługowym.

• Stosowanie formatów danych oraz protokołów komunikacyjnych i szyfrujących określonych w załącznikach 2 i 3 do rozporządzenia.

• Opracowanie i ustanawianie, wdrażanie i eksploatację, monitorowanie i przeglądanie oraz utrzymanie i doskonalenie systemu bezpieczeństwa informacji, zapewniającego poufność, dostępność i integralność informacji.

• Dostosowanie do potrzeb beneficjenta w zakresie wymiany informacji i jej automatyzacji, z uwzględnieniem podmiotów, systemów i rejestrów, z którymi odbywa się wymiana.

• Zapewnienie interoperacyjności systemów na poziomie organizacyjnym, semantycznym i technologicznym.

• Zapewnienie standardów w zakresie udostępnianie danych i informacji publicznych.

• Zapewnienie udostępniania danych do informacji dotyczącej poziomu dostępności systemów, w szczególności poprzez zamieszczanie informacji o standardach i rozwiązaniach.

• Standaryzację i udokumentowanie procesu zarządzania danymi, zgodnie z przyjętymi w tym zakresie normami.

• Standaryzację zasad wprowadzania i kontroli danych referencyjnych do systemów oraz standaryzacji procedur pozyskania i weryfikacji danych z różnych źródeł.

• Zapewnienie dostępności dla osób niepełnosprawnych (zgodnie ze standardem WCAG 2.0).

2.7 System PUEUP musi być oparty na otwartych standardach i neutralny technologicznie oraz posiadać łatwość rozbudowy. Ponadto rozwój systemu nie może być zależny od konkretnego dostawcy oprogramowania. Założenia te powodują, że w Systemie

1 Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2012 r., poz. 526)

konieczne jest zastosowanie ogólnie dostępnych rozwiązań oraz standardów. Poniżej przedstawiono główne standardy, z jakimi musi być zgodny system PUEUP. Pogrupowano je w następujące kategorie:

Interoperacyjność:

• XML (ang. Extensible Markup Language) - standard przyjęty przez organizację W3C dotyczący uniwersalnego formatu tekstowego służącego do opisu danych w formie elektronicznej,

• WSDL (ang. Web Services Description Language) – standard przyjęty przez organizację W3C definiujący format opisu interfejsu usług sieciowych,

• SOAP (ang. Simple Object Access Protocol) – standard przyjęty przez organizację W3C dotyczący protokołu wywoływania zdalnego dostępu do funkcji udostępnianych poprzez usługi sieciowe (ang. Web Services),

• ODBC (ang. Open DataBase Connectivity) – standard przyjęty przez organizację ISO/IEC (ISO/IEC 9075-3) - otwarty interfejs dostępu do baz danych,

Bezpieczeństwo:

• XMLsig (ang. XML-Signature Syntax and Processing) - standard przyjęty przez organizację W3C dotyczący podpisu elektronicznego dokumentów w formacie XML,

• WS-Security (ang. Web Services Security) - standard przyjęty przez organizację Oasis dotyczący zapewnienia bezpiecznej komunikacji przy wykorzystaniu usług sieciowych (ang. Web Services),

• X.509 – standard przyjęty przez organizację ITU dotyczący wykorzystania kryptografii w mechanizmach: PKI (ang. Public Key Infrastructure), SSO (ang. Single Sign-On) oraz PMI (ang. Privilge Management Infrastructure).

Formaty plików:

• *.txt - dokumenty w postaci niesformatowanego zbioru znaków zapisanych w standardzie Unicode UTF-8,

• *.rtf (ang. Rich Text Format Specification) - dokumenty w postaci sformatowanego tekstu jako pliki typu *.rtf,

• *.xml (ang. eXtensible Markup Language) - pliki z danymi zapisanymi w formacie

*.xml,

• *.pdf (ang. Portable Document Format) - dokumenty tekstowo-graficzne jako pliki typu *.pdf,

• *.doc - dokumenty w postaci sformatowanego tekstu jako pliki typu *.doc,

• *.docx - dokumenty w postaci sformatowanego tekstu jako pliki typu *.docx,

• *.odt (ang. Open Document Format for Office Application) - otwarty format dokumentów aplikacji biurowych,

• *.jpg, *.jpeg (ang. Joint Photographic Experts Group) - pliki typu *.jpg używane do prezentowania grafiki rastrowej,

• *.gif (ang. Graphics Interchange Format) - pliki typu *.gif używane do prezentowania grafiki rastrowej,

• *.tif, *.tiff (ang. Tagged Image File Format) - pliki typu *.tif używane do prezentowania grafiki rastrowej,

• *.png (ang. Portable Network Graphics) - pliki typu *.png używane do prezentowania grafiki rastrowej,

• *.wav (ang. wave form audio format) – pliki audio

• *.mp3 (ang. MPEG-1/MPEG-2 Audio Layer 3) – pliki audio

• *.ogg (ang. Ogg Vorbis Audio Format) – pliki audio

• *.ogv (Theora Video Format) - pliki audiowizualne z dźwiękiem lub bez

• *.mp4 (ang. MPEG-) – pliki audio i wideo Inne:

• XSD (ang. XML Schema Definition) - standard przyjęty przez organizację W3C do opisu definicji struktury dokumentów zapisanych w formacie XML,

• XSL (ang. Extensible Stylesheet Language) - standard przyjęty przez organizację W3C do opisu formatowania danych XML,

• Unicode UTF-8 (ang. Universal Multiple-Octet Coded Character Set, UCS transformation format UTF-8) - standard kodowania znaków.

3. Makieta systemu PUEUP i jej zastosowanie w realizacji projektu

W ramach prac przygotowawczych do uruchomienia projektu została przygotowana interaktywna Makieta symulująca działanie Systemu widzianego z perspektywy użytkownika zewnętrznego (zalogowanego i niezalogowanego) oraz wewnętrznego (pracownika UPRP) zawierająca proponowaną poglądową wizualizację systemu, mająca na celu ułatwienie zrozumienia wymagań funkcjonalnych oraz niefunkcjonalnych. Wygląd oraz funkcjonalności GUI docelowego systemu musi być wzorowane na wizualizacji przedstawionej w ramach Makiety, z ewentualnymi usprawnieniami funkcjonalności GUI/UX zaproponowanymi przez Wykonawcę. Zakres informacji prezentowanych na makiecie jest jedynie przykładowy.

Zamawiający udostępnia Makietę w postaci pliku jar stanowiącego Załącznik G do SOPZ. W celu uruchomienia Makiety należy:

• zainstalować JAVA JDK w wersji co najmniej 1.8, odpowiedniej dla używanego systemu operacyjnego,

• do wybranego katalogu skopiować plik model-1.0-SNAPSHOT.jar,

• uruchomić aplikację poprzez wydanie polecenia:

• java -jar target/model-1.0-SNAPSHOT.jar

Po wpisaniu komendy należy poczekać, aż się uruchomi cały projekt. Zwykle kilkanaście sekund. Następnie Makieta jest dostępna w przeglądarce pod adresem: xxxx://xxxxxxxxx:0000/. Aby uzyskać dostęp do obszarów wymagających zalogowania należy użyć login/hasło: admin/admin.

3.1. Makieta została wykonana przez Wykonawcę zewnętrznego, który przy tworzeniu makiety, korzystał z informacji merytorycznych dostępnych na stronie xxx.xxxx.xx oraz miał dostęp do następujących materiałów związanych z projektem:

• Studium wykonalności (xxxx://xxx.xxxx.xx/xxxxxxxxx-xxxxx-xxxxxxxxxxxxxxx- urzedu-patentowego-pueup/Text02,57,18974,7,index,pl,searchresult/)

• Fiszka projektowa (xxxx://xxxx.xx.xxx.xx/xxx/xxxxxxxxxxx/xxxxxxxxxxx-xxxx- 2017-r/posiedzenie-krmc-w-dniu-4/3390,Ministerstwo-Rozwoju.html)

• Prezentacja publiczna (xxxx://xxx.xxxx.xx/xxxxxxxxx-xxxxxxxxxxx-xxxxxxx- projektu-platforma-uslug-elektronicznych-urzedu-patentowego- pueup/Lead14,58,17277,7,index,pl,text/)

Wymienione powyżej materiały nie stanowią Specyfikacji Istotnych Warunków Zamówienia.

4. e-Usługi

Zamawiający wymaga od Wykonawcy, aby wdrożony system umożliwiał skorzystanie przez interesariuszy i Klientów UPRP z 7 głównych e-usług:

4.1. e-Usługa: Udostępnianie wglądu i wydawanie wyciągu z rejestrów

Dzięki tej usłudze możliwy będzie dostęp online do aktualnych wpisów w rejestrach prowadzonych przez UPRP oraz możliwa będzie w pełni elektroniczna obsługa wniosku o wydanie wyciągu z rejestru (zarówno aktualnego jak i pełnego). Klient posiadający indywidualne konto w systemie będzie miał możliwość rozpoczęcia realizacji usługi wydania wyciągu z rejestru poprzez wybór odpowiedniego formularza. Dzięki personalizacji formularz będzie wstępnie wypełniony przy wykorzystaniu danych zapisanych w koncie Klienta. Na podstawie wprowadzonych danych Klient otrzyma wyliczoną przez kalkulator wysokość należnej opłaty, którą będzie mógł przekazać elektronicznie (nastąpi wtedy automatyczne przekierowanie na stronę OPE oraz przekazanie szczegółów i kontekstu płatności). Po przesłaniu wniosku przez Klienta system udostępni w jego koncie urzędowe potwierdzenie przedłożenia (UPP) a także status płatności, jeżeli została ona uiszczona. Następnie wniosek zostanie automatycznie obsłużony w systemie EZD. Po pozytywnym, wspieranym przez system, zweryfikowaniu opłaty, realizowana będzie merytoryczna obsługa wniosku. Dla spraw, gdzie nie prowadzono rejestru w formie papierowej wyciąg musi być generowany automatycznie. Gotowy wyciąg będzie udostępniany Klientowi (w koncie Klienta).

4.2. e-Usługa: Powiadamianie o upływającym terminie ochrony

Dzięki tej usłudze Klient będzie powiadamiany wybranym przez siebie kanałem komunikacji o zbliżającym się terminie wygaśnięcia ochrony znaku towarowego (w drugim etampie także pozostałych przedmiotów ochrony) i możliwości jej przedłużenia przez wniesienie stosownych opłat. W przypadku, gdy Klient będzie posiadał konto w e- Profilu i będzie chciał przedłużyć ochronę znaku towarowego to w koncie otrzyma formularz z wypełnionymi już danymi (w celu ułatwienia i usprawnienia realizacji wniosku o przedłużenie ochrony znaku towarowego) oraz wyliczoną przez kalkulator opłat wysokość opłaty, którą będzie mógł przekazać elektronicznie (nastąpi wtedy automatyczne przekierowanie na stronę OPE oraz przekazanie szczegółów i kontekstu płatności). Usługa będzie uruchamiana w dwóch etapach najpierw dla znaków towarowych, a następnie dla pozostałych przedmiotów ochrony.

4.3. e-Usługa: Subskrypcja informacji

W ramach tej usługi, Klient będzie miał w pełni elektroniczny dostęp do nowoczesnej wyszukiwarki danych dotyczących przedmiotów ochrony, oraz możliwość subskrybowania w bazach danych UPRP interesujących Klienta informacji, które spełniają zadane przez Klienta kryteria. Klient przy pomocy intuicyjnego formularza

będzie wskazywał parametry zapytania. System informatyczny wyszuka informacje według zadanych kryteriów, a następnie zaprezentuje je klientowi. W ramach subskrypcji informacji dostępne będzie cykliczne uruchamianie wyszukiwania dla zadanych kryteriów lub śledzenie zmian dla wybranych wpisów w bazach oraz przekazywanie stosownych informacji Klientowi dotyczących wyniku sprawdzenia. Klient będzie mógł dokonać zmiany parametrów swojego zapytania, wskazując odpowiednie zmiany, a system informatyczny będzie wyszukiwał informacje zgodnie z nowymi kryteriami. Jednym z przypadków zmiany parametrów, może być usunięcie wszystkich filtrów, co spowoduje przesłanie Klientowi informacji o braku ustawień kryteriów wyszukiwania i zaprzestaniu subskrypcji przez XXXXX.

4.4. e-Usługa: Walidacja patentu europejskiego

Dzięki tej usłudze możliwa będzie w pełni elektroniczna obsługa wniosku o walidację Patentu Europejskiego. Klient posiadający indywidualne konto w systemie będzie miał możliwość rozpoczęcia realizacji usługi poprzez użycie dedykowanego formularza. Dzięki personalizacji formularz będzie wstępnie wypełniony przy wykorzystaniu danych zapisanych w koncie Klienta. Dodatkowo będzie także możliwość pobrania danych bezpośrednio do formularza z zewnętrznych systemów. Po przesłaniu wniosku przez Klienta system udostępni w jego koncie urzędowe potwierdzenie przedłożenia (UPP). Następnie wniosek zostanie automatycznie obsłużony w systemie EZD. Po obsłudze formalno-prawnej wniosku zostanie wygenerowane wezwanie do zapłaty. Należność Klient będzie mógł opłacić elektronicznie (nastąpi wtedy automatyczne przekierowanie na stronę OPE oraz przekazanie szczegółów i kontekstu płatności). Po obsłużeniu wniosku w systemie dziedzinowym zostanie wygenerowana (i udostępniona w ramach usługi opisanej w pkt 4.1) nowa karta rejestrowa.

4.5. e-Usługa: Zgłoszenie o udzielenie ochrony dla wynalazku, wzoru użytkowego, wzoru przemysłowego i znaku towarowego

Dzięki tej usłudze możliwa będzie w pełni elektroniczna obsługa zgłoszeń dotyczących:

• udzielenia prawa ochronnego na znak towarowy,

• udzielenia patentu na wynalazek,

• udzielenia prawa ochronnego na wzór użytkowy,

• udzielenia prawa z rejestracji na wzór przemysłowy, aż do otrzymania formalnego potwierdzenia zgłoszenia.

otrzyma wyliczoną przez kalkulator wysokość należnej opłaty, którą będzie mógł przekazać elektronicznie (nastąpi wtedy automatyczne przekierowanie na stronę OPE oraz przekazanie szczegółów i kontekstu płatności). Po przesłaniu wniosku przez Klienta system udostępni w jego koncie urzędowe potwierdzenie przedłożenia (UPP) a także status płatności, jeżeli została ona uiszczona. Następnie wniosek zostanie automatycznie obsłużony w systemie EZD wraz z wygenerowaniem formalnego potwierdzenia dokonania zgłoszenia, które po podpisaniu przez pracownika UPRP, zostanie udostępnione w koncie Klienta gdzie będzie również dostępna informacja o statusie przyjęcia zgłoszenia.

4.6. e-Usługa: Zmiany w rejestrach prowadzonych przez UPRP

Dzięki tej usłudze możliwa będzie w pełni elektroniczna obsługa spraw dotyczących:

• przedłużenia ochrony, gdy mija ustawowy okres ochrony znaku towarowego,

• zmiany uprawnionego,

• wpisu do rejestru informacji o zastawie cywilnym/rejestrowym,

• wpisu o udzielonej licencji,

• rezygnacji z ochrony (zrzeczenie).

Klient posiadający indywidualne konto w systemie będzie miał możliwość rozpoczęcia realizacji usługi poprzez wybór odpowiedniego formularza. Dzięki personalizacji formularz będzie wstępnie wypełniony przy wykorzystaniu danych zapisanych w koncie Klienta. Dodatkowo będzie także możliwość pobrania danych bezpośrednio do formularza z zewnętrznych systemów. Na podstawie wprowadzonych danych Klient otrzyma wyliczoną przez kalkulator wysokość należnej opłaty, którą będzie mógł przekazać elektronicznie (nastąpi wtedy automatyczne przekierowanie na stronę OPE oraz przekazanie szczegółów i kontekstu płatności). Po przesłaniu wniosku przez Klienta system udostępni w jego koncie urzędowe potwierdzenie przedłożenia (UPP) a także status płatności, jeżeli została ona uiszczona. Następnie wniosek zostanie automatycznie obsłużony w systemie EZD. Po automatycznym pozytywnym zweryfikowaniu opłaty wniosek zostanie obsłużony merytorycznie, a decyzja administracyjna zostanie udostępniona w koncie Klienta gdzie będzie również dostępna informacja o statusie sprawy. Następnie w module e-Rejestry zostanie wykonany wpis dokumentujący zmianę.

4.7. e-Usługa: Składanie wniosków związanych z obsługą spraw PWP

Dzięki tej usłudze możliwa będzie w pełni elektroniczna obsługa Klienta UPRP, w szczególności usługa umożliwi w pełni elektroniczne załatwienie spraw dotyczących:

• wydania dokumentu pierwszeństwa,

• publikacji informacji o zgłoszeniu ochrony patentowej we wcześniejszym terminie,

• zgłoszenia i obsługi sprzeciwu,

• wydzielenia zgłoszenia,

• przyspieszonej rejestracji (nadania numeru ochrony),

• spraw związanych z dokumentem patentowym/ świadectwem ochronnym (sprostowanie, wydanie duplikatu).

Klient posiadający indywidualne konto w systemie będzie miał możliwość rozpoczęcia realizacji usługi poprzez wybór odpowiedniego formularza. Dzięki personalizacji formularz będzie wstępnie wypełniony przy wykorzystaniu danych zapisanych w koncie Klienta. Dodatkowo będzie także możliwość pobrania danych bezpośrednio do formularza z zewnętrznych systemów. Tam gdzie jest to konieczne, na podstawie wprowadzonych danych Klient otrzyma wyliczoną przez kalkulator wysokość należnej opłaty, którą będzie mógł przekazać elektronicznie (nastąpi wtedy automatyczne przekierowanie na stronę OPE oraz przekazanie szczegółów i kontekstu płatności). Po przesłaniu wniosku przez Klienta system udostępni w jego koncie urzędowe potwierdzenie przedłożenia (UPP) a także status płatności, jeżeli została ona uiszczona. Następnie wniosek zostanie automatycznie obsłużony w systemie EZD. Po pozytywnym, wspieranym przez system, zweryfikowaniu opłaty wniosek zostanie obsłużony merytorycznie a odpowiedź udostępniana w koncie Klienta wraz z aktualizacją statusu sprawy.

5. Wymagania jakościowe dla Oprogramowania Dedykowanego

5.1. W celu zapewnienia wysokiej jakości dostarczanego oprogramowania Zamawiający wymaga, aby Wykonawca sprawdzał oprogramowanie poprzez wykonywanie testów jednostkowych, testów integracyjnych, testów funkcjonalnych, testów wydajnościowych oraz bezpieczeństwa.

5.2. Zamawiający wymaga od Wykonawcy aby kod źródłowy oprogramowania aplikacyjnego został opatrzony komentarzami zawierającymi krótki opis jego działania, definicje użytych zmiennych oraz numer wersji oprogramowania, w której dokonano ostatnich modyfikacji. Komentarze powinny umożliwiać zrozumienie kodu przez osoby z wykształceniem informatycznym, a także jasno i wyczerpująco dokumentować podejmowane działania.

5.3. Wykonawca musi sprawdzać w trybie ciągłym poprawność działania pojedynczych elementów (jednostek) programu poprzez implementację i wykonywanie testów jednostkowych. Wykonawca zaproponuje narzędzie do definiowania i implementacji testów jednostkowych zależnie od wykorzystywanej technologii, przy czym rekomenduje się stosowanie rozwiązań OpenSource.

5.4. W zakresie włączania (integracji) bieżących zmian w kodzie do repozytorium Zamawiający wymaga działania zgodnego z wzorcem ciągłej integracji (ang. continuous integration). W związku z tym Wykonawca musi:

• utworzyć i utrzymywać środowisko na potrzeby ciągłej integracji i testów automatycznych,

• przygotować procedury zautomatyzowanego budowania systemu na podstawie kodu źródłowego dostępnego w repozytorium kodu źródłowego,

• przygotować procedury automatycznego uruchamiania zbudowanego systemu na środowisku testowym,

• przygotować procedury uruchamiające zestawy skryptów testowych dla testów jednostkowych, integracyjnych oraz funkcjonalnych.

5.5. Przed przekazaniem Zamawiającemu kolejnych wersji Sytemu (w ramach poszczególnych sprintów) do testów Wykonawca wykona całościowe testy systemowe na podstawie zatwierdzonych przez Zamawiającego scenariuszy testowych z wykorzystaniem danych modelowych. W ramach testów systemowych muszą zostać wykonane:

• testy funkcjonalne modułów sprawdzające poprawność działania aplikacji zgodnie z wymaganiami funkcjonalnymi,

• testy integracji obejmujące weryfikację integracji pomiędzy poszczególnymi Modułami funkcjonalnymi Systemu, integrację pomiędzy Systemem a systemami wewnętrznymi Zamawiającego oraz testy integracji z systemami i serwisami zewnętrznymi,

• testy wydajnościowe systemu,

• testy bezpieczeństwa.

5.6. Raporty z wykonania w/w testów muszą być każdorazowo przekazywane przez Wykonawcę przed przystąpieniem do testów wykonywanych przez Zamawiąjącego.

5.7. Zamawiający wymaga, aby Wykonawca przygotował scenariusze akceptacyjne, które umożliwią prowadzenie automatycznych testów regresji, a tym samym ciągłą weryfikację Systemu. Wykonawca zaproponuje narzędzie do testów automatycznych (przy czym rekomenduje się stosowanie rozwiązań OpenSource) oraz przekaże opracowane skrypty Zamawiającemu do ponownego wykorzystania w analogicznym zakresie. W przypadku zastosowania narzędzi komercyjnych Wykonawca zobowiązany jest zapewnić Zamawiającemu niezbędne licencje na własny koszt.

6. Integracje z systemami wewnętrznymi i zewnętrznymi

6.1. Ideą przedsięwzięcia jest budowa zintegrowanego systemu informatycznego w podziale na moduły, które muszą być dostarczane i funkcjonować niezależnie od pozostałych. Przyjęto, że System będzie miał budowę modułową, a komunikacja pomiędzy modułami oraz integracja z systemami dziedzinowymi (wewnętrznymi) będzie odbywała się za pośrednictwem szyny usług. System będzie także komunikował się z systemami i serwisami zewnętrznymi za pomocą dedykowanych, zabezpieczonych interfejsów API.

6.2. W ramach realizacji zamówienia wykonawca musi dostarczyć i wdrożyć szynę integracyjną ESB. Szyna musi zostać zainstalowana w trybie wysokiej dostępności, co umożliwi klastrowanie i równoważenie obciążenia, w szczególności każdy komponent rozwiązania musi być dobrze skalowalny. Szyna musi obsługiwać różne rodzaje komunikatów, potrafić je transformować, odpytywać i filtrować itp. oraz umożliwiać tworzenie adapterów integracyjnych oraz posiadać gotowe adaptery dla:

• integracji opartej o protokół HTTP/HTTPS,

• integracji opartej o wywołania SOAP,

• integracji opartej o wywołania REST,

• integracji opartej o JMS,

• integracji opartej o RMI,

• integracji z relacyjnymi bazami danych za pomocą JDBC lub ODBC,

• integracji opartej o system plików,

• integracji opartej o protokoły FTP/SFTP/FTPS,

• poczty email.

6.3. Integracja platformy PUEUP z funkcjonującymi w UPRP systemami wewnętrznymi dziedzinowymi i kancelaryjnymi obejmuje następujące systemy:

• EZD – system do elektronicznego zarządzania dokumentacją umożliwiający wykonywanie w nim czynności kancelaryjnych (producent: Podlaski Urząd Wojewódzki),

• BackOffice – system do zarządzania procedurami udzielania i utrzymywania praw w zakresie znaków towarowych oraz wzorów przemysłowych (efekt współpracy z EUIPO, w ramach programu Cooperation Fund),

• Soprano – system do zarządzania procedurami udzielania i utrzymywania praw w zakresie wynalazków i wzorów użytkowych, EP oraz dodatkowych praw ochronnych (aplikacja jest efektem współpracy z EPO, w ramach projektu EPTOS),

• MAAT – System Gospodarki Własnej UPRP (producent: COMP Soft Sp. z o.o.),

• Phoenix/Madras – system do przechowywania elektronicznej wersji dokumentacji (aplikacja jest efektem współpracy z EPO, w ramach projektu EPTOS),

• System do zarządzania relacjami z klientami (CRM – Microsoft Dynamic 365, producent Microsoft),

• AD.

6.4. Dodatkowo, w ramach Projektu do automatyzacji procedur zgłoszeniowych zakłada się wykorzystanie informacji z serwisów zewnętrznych:

• TMView – wyszukiwarka znaków towarowych (EUIPO),

• DesignView – wyszukiwarka wzorów przemysłowych (EUIPO),

• TMclass – Zharmonizowana baza danych ułatwiająca wyszukiwanie nazw towarów i usług wg klasyfikacji nicejskiej (EUIPO).

6.5. Integracja platformy PUEUP z zewnętrznymi systemami teleinformatycznymi obejmuje następujące systemy:

• Portal RP – w zakresie prezentacji informacji o UPRP i usługach dostępnych na PUEUP,

• eID (E-podpis, Profil Zaufany, Krajowy Operator identyfikacji, Krajowy eIDAS Node)

– w celu uwierzytelniania użytkowników Systemu,

• Rejestr REGON (w celu wykorzystania informacji o podmiotach gospodarki narodowej do usprawnienia komunikacji Klienta z UPRP – pobieranie danych do formularzy).

6.6. Uwzględnia się również przekazywanie wybranych informacji z systemu PUEUP do następujących organizacji lub systemów zewnętrznych poprzez dedykowane API:

• SRP – System Rejestrów Państwowych,

• GUS – Główny Urząd Statystyczny,

• Portal: Dane Publiczne (xxx.xxxxxxxxxxxxx.xxx.xx),

• EPO, XXXXX, WIPO.

6.7. Poniżej przedstawiono projektowany Diagram integracji (schemat uproszczony) systemu PUEUP z systemami wewnętrznymi UPRP oraz zewnętrznymi.

Rys. Schemat integracji (uproszczony) systemu PUEUP z systemami wewnętrznymi UPRP oraz zewnętrznymi

Źródło: Opracowanie własne UPRP

6.8. W ramach integracji Wykonawca przygotuje i wdroży adaptery szyny integracyjnej ESB do komunikacji platformy PUEUP z systemami wewnętrznymi Zamawiającego, w tym w zakresie pozyskiwania danych biznesowych z systemów dziedzinowych do modułów e-

Wyszukiwarka i e-Rejestry, e-Powiadomienia, gdzie aktualizacja danych musi następować w cyklach dziennych z możliwością parametryzacji i ręcznego wymuszenia aktualizacji. W zakresie integracji z EZD komunikacja będzie wymagała rejestrowania i odbierania w PUEUP dokumentów oraz danych podmiotów z EZD, a także przekazywania wspomnianych danych do EZD. Synchronizacja między PUEUP i EZD musi być wykonywana na bieżąco (synchronicznie) z możliwością parametryzacji i ręcznego wymuszenia aktualizacji.

6.9. Modernizacja oraz dostosowanie systemów wewnętrznych na potrzeby integracji, w tym wystawienie odpowiednich interfejsów, pozostaje poza zakresem zamówienia i zostanie wykonana przez Zamawiającego, po określeniu przez Wykonawcę szczegółowej specyfikacji technicznej oczekiwanych interfejsów w systemach źródłowych.

6.10. Zamawiający wymaga, aby Wykonawca przygotował mechanizmy integracji systemu PUEUP z Bramką SMS oraz Bramką e-Mail.

6.11. Zamawiający wymaga, aby Wykonawca umożliwił podłączanie systemów zewnętrznych Klientów UPRP z platformą poprzez dedykowane interfejsy API. Zamawiający wymaga, żeby Wykonawca zaimplementował następujące interfejsy:

• dedykowany otwarty interfejs do komunikacji w zakresie składanych dokumentów elektronicznych i informacji o ich doręczeniu (możliwości implementacji kanału komunikacji bezpośrednio z systemami wewnętrznymi przedsiębiorców i kancelarii rzeczniowskich),

• dedykowany otwarty interfejs do pobierania informacji w zakresie udostępnianym przez moduły e-Baza wiedzy i e-Wyszukiwarka, łącznie z załącznikami, jeżeli takie występują (np. pliki graficzne, dźwiękowe, wideo). Wykonawca musi udostępnić on-line 5 zbiorów danych: wynalazki (w tym EP), wzory użytkowe, wzory przemysłowe, znaki towarowe, lista rzeczników i aplikantów.

• dedykowany otwarty interfejs do udostępniania informacji statystycznej UPRP, w tym przekazywanie danych statystycznych do GUS oraz serwisu XxxxXxxxxxxxx.xxx.xx.

Udostępniane dane muszą spełniać wymagania standardów dokumentów elektronicznych z rodziny ST.XX wydanych przez WIPO.

ROZDZIAŁ VIII. Płatności elektroniczne

1. Wykonawca jest zobowiązany do implementacji w systemie PUEUP mechanizmów odpowiadających za realizację płatności elektronicznych i potwierdzeń transakcji przekazywanych przez poszczególnych operatorów tych płatności.

2. Zamawiający w trakcie realizacji umowy, przekaże Wykonawcy specyfikacje techniczne opisujące możliwe sposoby integracji OPE, wybranych w odrębnym postepowaniu i wskazanych przez Zamawiającego do obsługi transakcji finansowych w ramach systemu PUEUP.

3. Architektura Modułu e-Płatności musi być przygotowana do zmiany OPE bez konieczności zmiany kodu oprogramowania wytworzonego w ramach PUEUP. Zmiana konfiguracji w tym zakresie musi być możliwa do przeprowadzenia samodzielnie przez Zamawiającego, na podstawie dokumentacji przygotowanej przez Wykonawcę, na zasadzie rekonfiguracji modułu e-Płatności.

4. Proces obsługi płatności on-line musi objąć wpłaty realizowane przez klientów UPRP w związku z udzieleniem praw lub utrzymaniem ich ochrony oraz wystawianiem raportów dziennych lub za wybrany okres. Po wygenerowaniu płatności przez klienta w systemie PUEUP, klient musi zostać przekierowany do wybranego OPE, a po zakończeniu płatności musi powrócić do systemu PUEUP wraz z informacją o rozpoczętej lub zrealizowanej płatności on-line.

5. Wykonawca musi przygotować PUEUP do obsługi wpłat i zwrotów z wykorzystaniem usług udostępnianiach przez OPE co najmniej w zakresie przelewów, kart płatniczych i płatności BLIK.

6. Moduł e-Płatności musi mieć możliwość przyjmowania i pobierania informacji generowanych przez OPE zarówno w układzie zbiorczym (zbiorcza informacja o transakcjach za określony okres) oraz jednostkowym (jedna informacja o jednej transakcji).

7. Moduł e-Płatności musi przekazywać szczegółowe informacje o pojedynczych płatnościach składających się na dane Zamówienie, co umożliwi obsługę płatności w systemach wewnętrznych UPRP. Moduł musi prezentować status płatności elektronicznej w koncie klienta oraz Panelu Pracownika UPRP.

ROZDZIAŁ IX. Aranżacja i instalacja sprzętu teleinformatycznego w UPRP

1. Zamawiający wymaga od Wykonawcy, aby dostarczony sprzęt został umieszczony i zainstalowany w udostępnionych pomieszczeniach serwerowni w UPRP, zgodnie z zaakceptowanym przez Xxxxxxxxxxxxx projektem aranżacji serwerowni opracowanym

przez Wykonawcę. Wymagania dotyczące projektu aranżacji serwerowni opisane zostały w Załączniku H do SOPZ.

2. Wykonawca musi spełnić wymagania Zamawiającego w zakresie zasilania szaf montażowych i urządzeń instalowanych w udostępnionych pomieszczeniach serwerowni w UPRP. Obwody zasilające muszą być wykonane zgodnie z projektem aranżacji, o którym mowa w punkcie 1 i wymaganiami dotyczącymi instalacji zasilającej serwerowni opisanymi w Załączniku H do SOPZ.

3. Zamawiający wymaga od Wykonawcy wykonania okablowania logicznego niezbędnego do realizacji przedmiotu zamówienia w udostępnionych pomieszczeniach serwerowni w UPRP. Okablowanie logiczne musi być wykonane zgodnie z projektem aranżacji, o którym mowa w punkcie 1 i wymaganiami dotyczącymi okablowania opisanymi w Załączniku H do SOPZ.

4. Zamawiający wymaga, aby Wykonawca zrealizował wszystkie wymagania dotyczące rozmieszczenia sprzętu w szafach montażowych pod kątem maksymalnych ilości wydzielanego tam ciepła. Wymagania oraz szczegółowe zalecenia dotyczące aspektów klimatyzacyjnych rozwiązania są opisane w Załączniku H do SOPZ.

ROZDZIAŁ X. Szkolenia i warsztaty

Autoryzowane szkolenia:

1. Wykonawca zobowiązany będzie do zapewnienia pracownikom Zamawiającego autoryzowanych szkoleń produktowych (certyfikowanych przez producenta rozwiązania) niezbędnych do obsługi i utrzymania dostarczanego sprzętu i oprogramowania, które Wykonawca wyspecyfikuje w swojej Ofercie.

2. Szkolenia będą obejmowały co najmniej zagadnienia z zakresu administracji, konfiguracji oraz zarządzania zaoferowanego sprzętu i oprogramowania zgodnie z zakresem wskazanym w pkt 4.

3. W każdym szkoleniu (jeżeli nie jest osobno podane) weźmie udział 2 administratorów w grupie szkoleniowej nie większej niż 15 osób. Zamawiającego dla każdego rodzaju oferowanej technologii w ramach poszczególnych systemów/obszarów.

4. Wymagania dotyczące szkoleń dla poszczególnych systemów/obszarów w zakresie infrastruktury i oprogramowania standardowego:

4.1. Przełączniki aktywne FC i przełączniki aktywne Gigabit Ethernet. Czas trwania: minimum 2 dni

Merytoryczna zawartość szkolenia:

• Wprowadzenie do sieci komputerowych.

• Podstawy routingu i przełączania.

• Skalowanie sieci komputerowych.

• Dostęp do sieci rozległych (WAN).

4.2. Zapory sieciowe klasy NGFW. Czas trwania: minimum 2 dni

Merytoryczna zawartość szkolenia:

• Bezpieczeństwo Sieci.

• Bezpieczeństwo operacyjne.

• Zagrożenia i słabe punkty.

• Aplikacje, dane i bezpieczeństwo.

• Kontrola dostępu i zarządzanie tożsamością.

4.3. Macierz dyskowa i macierz dyskowa do tworzenia kopii zapasowych. Czas trwania: minimum 2 dni

Merytoryczna zawartość szkolenia:

• Administracja i implementacja zaoferowanych macierzy dyskowych.

• Omówienie narzędzi administracyjnych.

• Omówienie narzędzi monitorujących.

• Konfiguracja interfejsów FC.

• Konfiguracja interfejsów sieciowych do zarządzania.

• Konfiguracja grup dyskowych.

• Konfiguracja jednostek LUN.

• Mapowanie jednostek LUN do serwerów.

• Konfiguracja ustawień macierzy takich jak: tiering, thin provisioning, kopie migawkowe.

• Konfiguracja zasobów NFS, CIFS, FTP.

• Monitorowanie wydajności.

• Nadawanie uprawnień użytkownikom.

• Optymalizacja wydajności.

• Rozwiązywanie problemów.

4.4. Sprzętowy moduł bezpieczeństwa (HSM). Czas trwania: minimum 2 dni Merytoryczna zawartość szkolenia:

• Architektura rozwiązania HSM.

• Przypadki oraz schematy użycia.

• Licencjonowanie.

• Instalacja oraz konfiguracja systemu.

• High Availability.

• Metody backupu.

• Audyt oraz logowanie.

• Narzędzia HSM (HSM Tools).

• Rozwiązywanie problemów.

4.5. Oprogramowanie platformy wirtualizacji.

Akredytowane szkolenie z zakresu systemu wirtualizacji – podstawowe.

Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Wprowadzenie do systemu wirtualizacji.

• Tworzenie maszyn wirtualnych oraz konfiguracja.

• Konsola zarządzająca.

• Konfiguracja oraz optymalizacja sieci.

• Konfiguracja i zarządzanie pamięcią masową.

• Zarządzanie maszynami wirtualnymi.

• Monitoring i zarządzanie zasobami.

• Klaster wysokiej dostępności.

• Aktualizacja systemu wirtualizacji.

4.6. Akredytowane szkolenie z zakresu systemu wirtualizacji – rozszerzone.

Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Konfiguracja oraz optymalizacja sieci.

• Skalowalność sieci.

• Pamięci masowe – skalowalność.

• Optymalizacja pamięci masowych.

• Optymalizacja CPU.

• Optymalizacja pamięci.

• Optymalizacja maszyn wirtualnych i klastrów.

• Bezpieczeństwo w środowisku wirtualizacji.

4.7. Serwerowe systemy operacyjne (SSO) - poziom podstawowy. Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Instalacja i konfiguracja SSO

• Metody magazynowania danych w SSO

• Implementacja usługi sieciowych

• Implementacja wirtualizacji

• Implementacja klastrów pracy awaryjnej

• Implementacja klastrów wysokiej dostępności

W szkoleniu wezmą udział 3 osoby ze strony Zleceniodawcy.

4.8. Serwerowe systemy operacyjne (SSO) – poziom zaawansowany. Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Zaawansowane askpkty konfiguracji SSO

• Metody magazynowania danych w SSO

• Implementacja usługi sieciowych

• Implementacja wirtualizacji

• Implementacja klastrów pracy awaryjnej

• Implementacja klastrów wysokiej dostępności

W szkoleniu wezmą udział 3 osoby ze strony Zleceniodawcy.

4.9. Oprogramowanie do tworzenia kopii zapasowych. Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Omówienie systemu do obsługi środowisk wirtualizacyjnych.

• Obsługa hypervisorów.

• Metody tworzenia kopii zapasowych.

• Omówienie kompresji i deduplikacji.

• Omówienie narzędzi monitorujących.

• Wdrażanie systemu backupu.

• Odzyskiwanie z backupu.

• Odzyskiwanie z backupu taśmowego.

• Odtwarzanie środowisk wirtualnych i fizycznych – DR.

• Optymalizacja infrastruktury backupowej.

• Monitorowanie infrastruktury backupowej.

• Rozwiązywanie problemów.

4.10. Oprogramowanie bazodanowe – poziom podstawowy.

Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Wprowadzenie do administracji Systemem BazoDanowym (SBD)

• Instalacja i konfiguracja SBD

• Praca z bazami danych

• Tworzenie kopii zapasowej

• Odtwarzanie baz danych SBD

• Importowanie i eksportowanie danych

• Monitorowanie SBD

• Zarządzanie bezpieczeństwem w SBD

• Audyt dostępu do danych

• Obsługa bieżąca bazy danych

W szkoleniu wezmą udział 4 osoby ze strony Zleceniodawcy.

4.11. Oprogramowanie bazodanowe – poziom zaawasowany. Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Zaawansowane aspekty administracji Systemem BazoDanowym (SBD)

• Instalacja i konfiguracja SBD

• Optymalizacja i tuning SBD

• Polityki tworzenia kopii zapasowej

• Odtwarzanie baz danych SBD

• Importowanie i eksportowanie danych

• Zaawansowae monitorowanie SBD

• Zaawansowane zarządzanie bezpieczeństwem w SBD

• Audyt dostępu do danych

W szkoleniu wezmą udział 4 osoby ze strony Zleceniodawcy.

4.12. Oprogramowanie Serwerów Aplikacyjnych. Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Wprowadzenie do administracji Serwerem Aplikacyjnym (SA)

• Instalacja i konfiguracja SA

• Komunikacja z bazami danych

• Tworzenie kopii zapasowej

• Deployment i odtwarzanie SA

• Integracja i zarządzanie komunikacją z ESB

• Importowanie i eksportowanie danych

• Monitorowanie SA

• Zarządzanie bezpieczeństwem w SA

• Audyt dostępu do SA

• Obsługa bieżąca SA

W szkoleniu wezmą udział 4 osoby ze strony Zleceniodawcy.

4.13. System klasy SIEM

Czas trwania: minimum 3 dni

Merytoryczna zawartość szkolenia:

• Korzystanie z narzędzi administracyjnych

• Tworzenie hierarchii sieci

• Zaktualizowane narzędzia administracyjne

• Zarządzanie użytkownikami

• Zarządzanie danymi

• Gromadzenie rejestrów dzienników i przepływu

• Zbieranie danych dzienników serwerowych systemów operacyjnych

• Zarządzanie niestandardowymi źródłami dzienników

• Stosowanie reguł

• Tworzenie reguł

• Zarządzanie zdarzeniami „false positive” (fałszywe alarmy)

• Korzystanie z map referencyjnych w regułach

5. Zamawiający wymaga, aby szkolenia, o którym mowa w pkt. 4 zapewniły transfer wiedzy wymaganej do obsługi i utrzymania Systemów Infrastrukturalnych. Transfer wiedzy musi zostać zapewniony w postaci szkoleń produktowych obejmujących tematykę wdrożonych rozwiązań i technologii.

6. Terminy szkoleń muszą zostać uwzględnione w Harmonogramie Szczegółowym.

7. Wykonawca każdorazowo przedstawi Zamawiającemu na co najmniej 14 dni przed planowanym terminem szkolenia:

7.1. Termin i miejsce szkolenia

7.2. Zakres szkolenia

7.3. Agendę

7.4. Kwalifikacje wykładowcy

7.5. Materiały szkoleniowe.

8. Akceptacja przez Zamawiającego warunków określonych w pkt 7 stanowi warunek rozpoczęcia szkoleń i zostanie potwierdzona drogą elektroniczną przez osobę wskazaną w umowie do kontaktu ze strony Zamawiającego.

9. Czas szkolenia nie może być krótszy niż liczba dni wskazana w pkt 4. Każdy dzień szkolenia musi trwać 8 godzin zegarowych.

10. Szkolenia muszą być prowadzone w języku polskim.

11. Wykonawca w ramach wynagrodzenia zapewni wykładowcę posiadającego odpowiednie kwalifikacje do przeprowadzania autoryzowanych szkoleń.

12. Wykonawca zobowiązuje się do zapewnienia miejsca szkolenia wraz ze stanowiskiem komputerowym dla każdego uczestnika szkolenia oraz wszelkie niezbędne oprogramowanie.

13. Każdy z uczestników szkolenia otrzyma komplet materiałów w języku polskim w formie elektronicznej lub papierowej. Zamawiający dopuszcza przekazanie materiałów szkoleniowych w języku angielskim jedynie w przypadku, gdy producent nie udostępnia materiałów w języku polskim.

14. Wykonawca w trakcie szkolenia zapewni salę szkoleniową na terenie Warszawy oraz wyżywienie (jeden gorący posiłek oraz kawa, herbata i zimne napoje każdego dnia podczas trwania szkolenia).

15. Każdy z uczestników otrzyma imienny certyfikat producenta rozwiązania, którego dotyczyło szkolenie.

16. Wszelkie koszty związane ze wszystkimi aspektami szkoleń ponosi Wykonawca.

17. Zamawiający przekaże Wykonawcy listę uczestników szkolenia, najpóźniej na 5 Dni Roboczych przed rozpoczęciem każdego szkolenia.

18. Wykonawca jest zobowiązany do sporządzania list obecności uczestników szkolenia.

19. W trakcie realizacji i przeprowadzania odbiorów szkoleń Wykonawcę będą obowiązywać procedury odbioru zawarte w Załączniku nr E do SOPZ.

Warsztaty:

20. Wykonawca zobowiązany będzie do przeprowadzenia warsztatów dla:

20.1. Minimum 10 administratorów (1 grupa). Zakres warsztatu musi obejmować co najmniej zagadnienia opisane w Dokumentacji Administratora (DA), o której mowa w Rozdziale V.

20.2. 50 użytkowników wewnętrznych Systemu (dwie grupy po 25 osób). Zakres warsztatu musi obejmować co najmniej zagadnienia opisane w Dokumentacji Użytkownika Wewnętrznego (DUW), o której mowa w Rozdziale V.

21. Terminy warsztatów muszą zostać uwzględnione w Harmonogramie Szczegółowym.

22. Warsztaty zostaną przeprowadzone w siedzibie Zamawiającego.

23. Wykonawca przygotuje dla każdego z uczestników materiały szkoleniowe w języku polskim w wersji papierowej lub elektronicznej oraz sporządzi listę obecności.

24. Czas warsztatu dla każdej grupy nie może być krótszy niż 2 dni, 8 godzin dziennie.

25. Każdy z uczestników otrzyma imienne zaświadczenie ukończenia warsztatu.

26. Warsztaty muszą zostać przeprowadzone w Fazie IV.

27. W trakcie realizacji i przeprowadzania odbiorów warsztatów Wykonawcę będą obowiązywać procedury odbioru zawarte w Załączniku nr E do SOPZ.

Szkolenia e-learningowe

28. Wykonawca zobowiązany jest do przygotowania dwóch szkoleń e-learningowych (oprogramowanie) dotyczących dostarczanego Systemu dedykowanych dla:

28.1. Administratorów Systemu w zakresie obejmującym co najmniej zagadnienia opisane w Dokumentacji Administratora (DA), o której mowa w Rozdziale V.

28.2. Użytkowników zewnętrznych Systemu w zakresie obejmującym co najmniej zagadnienia opisane w Dokumentacji Użytkownika Zewnętrznego (DUZ), o której mowa w Rozdziale V.

29. Szkolenia e-learningowe muszą spełniać następujące wymagania ogólne:

29.1. pozwalać na bezterminowe przeszkolenie nieograniczonej liczby użytkowników,

29.2. być w całości w języku polskim,

29.3. w przypadku wykorzystywania multimedialnych filmów ich format musi być możliwy do odtworzenia przy pomocy standardowych narzędzi systemu (odtwarzacz

multimedialny, przeglądarka internetowa) oraz z możliwością przerwania w dowolnym momencie i dokończenia później,

29.4. być podzielone na bloki tematyczne,

29.5. zawierać wiedzę niezbędną do poznania przez użytkowników nowego Systemu i wszystkich jego funkcjonalności,

29.6. składać się z dwóch elementów: wykładów i ćwiczeń:

29.6.1. wykłady mają być elementem pasywnym, w których użytkownik nie wykonuje żadnych akcji, a jedynie jest biernym uczestnikiem szkolenia,

29.6.2. ćwiczenia mają mieć formę interaktywnego przewodnika, w których użytkownik musi wykonać zaplanowane akcje zgodnie ze wskazówkami lektora,

29.7. dostarczone w wersji z lektorem oraz z wyświetlanymi napisami. Obie wersje mają przekazywać ten sam zakres informacji,

29.8. być zgodne ze standardem SCORM oraz być zoptymalizowane pod kątem platformy Moodle w najnowszych dostępnych wersjach na moment finalnego odbioru projektu,

29.9. poprawnie uruchamiać się i działać na przeglądarkach internetowych wymienionych w wymaganiach niefunkcjonalnych, przy czym uruchomienie kursu nie może wymagać instalowania na komputerach użytkowników końcowych żadnych apletów i pluginów (w tym JAVA, Flash Player) z wyjątkiem materiałów szkoleniowych posiadanych przez Zamawiającego i podlegających migracji.

30. Wykonawca przy udziale pracowników Zamawiającego dokona instalacji oprogramowania na platformie Zamawiającego;

31. Wykonawca dokona niezbędnych modyfikacji oprogramowania, w przypadku, gdy od tego zależeć będzie jego poprawne działanie na platformie Zamawiającego.

ROZDZIAŁ XI. Wdrożenie Oprogramowania Standardowego

1. Zestawienie Systemów Infrastrukturalnych objętych rozbudową lub wdrożeniem oraz ich parametrów technicznych zawiera Załącznik D do SOPZ.

2. Zamawiający wymaga od Wykonawcy, aby rozbudował i wdrożył Systemy Infrastrukturalne w sposób, który będzie minimalizował wpływ na działanie środowiska infrastrukturalnego UPRP. Prace, które mogłyby wpływać na ciągłość działania systemów biznesowych, muszą być realizowane poza godzinami pracy UPRP.

3. Zamawiający wymaga od Wykonawcy opracowania dla każdego rozbudowywanego i nowo wdrażanego Systemu Infrastrukturalnego Planu Testów dla wdrożenia wraz ze scenariuszami testowymi. Zamawiający będzie weryfikował poprawność wdrożenia Systemów Infrastrukturalnych na podstawie wyników testów akceptacyjnych przeprowadzonych zgodnie Planami Testów wdrożenia zatwierdzonymi przez niego na etapie odbioru Dokumentacji Projektowej.

4. W trakcie realizacji rozbudowy i wdrożeń Wykonawcę będą obowiązywać procedury odbioru zawarte w Załączniku E do SOPZ. Odbiór rozbudowy i wdrożenia poszczególnych systemów infrastrukturalnych będzie potwierdzany wynikiem testów akceptacyjnych dla każdego systemu. Pozytywny wynik testów akceptacyjnych wszystkich planowanych do rozbudowy i wdrożenia systemów infrastrukturalnych warunkuje przystąpienie do Odbioru Instalacji Sprzętu i Oprogramowania Standardowego.

ROZDZIAŁ XII. Wdrożenie Oprogramowania Dedykowanego

1. Wdrożenie będzie rozumiane jako dostosowanie dostarczonych Modułów i komponentów funkcjonalnych systemu PUEUP do potrzeb Zamawiającego w zakresie zapewniającym sprawne działanie e-usług przewidzianych Projektem. Ponadto, wdrożenie będzie obejmowało integrację Systemu ze wskazanymi systemami informatycznymi i usługami wewnętrznymi i zewnętrznymi oraz uruchomienie dedykowanych interfejsów API umożliwiających wykonanie wszystkich funkcji realizowanych przez System.

2. Zamawiający wymaga od Wykonawcy, aby przeprowadził wdrożenie Systemu zgodnie z etapami określonymi w Projekcie Technicznym Systemu. Wdrożenie produkcyjne musi zostać poprzedzone instalacją wersji testowej zapewniającej pełny zakres funkcjonalny, który zostanie przetestowany na danych modelowych, a następnie na danych rzeczywistych. Dla zapewniania realizacji wersji produkcyjnej systemu konieczne będzie wykonanie migracji danych (Moduł Rozliczeń, e-Baza wiedzy) oraz importu danych niezbędnych do prawidłowego eksploatowania Systemu (e-Wyszukiwarka i e-Rejestry) z dotychczas użytkowanych przez Zamawiającego systemów bądź źródeł danych

wytworzonych w ramach realizacji Projektu. Przygotowanie danych do migracji leży po stronie Wykonawcy. Wykonawca ponosi odpowiedzialność za powodzenie oraz skuteczność procesu migracji oraz poprawność zmigrowanych danych do Systemu i jest zobowiązany usunąć wszelkie skutki wynikające z błędów migracji.

3. Zamawiający wymaga od Wykonawcy, aby przeprowadził migracje oraz import danych w taki sposób, aby możliwe było zachowanie ciągłości działania procesów biznesowych wspieranych zarówno przez systemy migrowane, jak i systemy z nimi współpracujące. Zamawiający wymaga także, aby planując migrację Wykonawca podzielił ją na trzy etapy: Etap Planowania, Etap Migracji Testowej, Etap Migracji Produkcyjnej. Akceptacja przez Zamawiającego wyników testów akceptacyjnych przeprowadzonych na Etapie Migracji Testowej jest warunkiem przejścia do Etapu Migracji Produkcyjnej.

4. Wszystkie powyższe działania muszą zostać zrealizowane przed wyznaczonym terminem uruchomienia wersji produkcyjnej PUEUP. Zamawiający wymaga także stałego uczestnictwa przedstawiciela Wykonawcy we wdrożeniu w celu umożliwienia bieżącego zgłaszania i korygowania ewentualnych usterek w działaniu Systemu.

ROZDZIAŁ XIII. Digitalizacja rejestrów

1. Zdigitalizowane przez Wykonawcę rejestry muszą być obsługiwane przez dostarczony przez Wykonawcę moduł e-Rejestry.

2. Dla spraw gdzie nie prowadzono rejestru w formie papierowej, moduł e-Rejestry musi zawierać dane na bieżąco importowane z systemów dziedzinowych (nie rzadziej niż raz dziennie).

3. Dla spraw gdzie prowadzono rejestry w formie papierowej, Moduł e-Rejestry musi zawierać skany rejestrów papierowych oraz związane z nimi zaindeksowane dane powstałe w wyniku digitalizacji złożonej, a także informacje o ewentualnych zmianach w rejestrze importowane na bieżąco z systemów dziedzinowych.

4. W ramach Umowy należy dostarczyć moduł e-Rejestry, a także zeskanować (digitalizacja prosta i digitalizacja złożona) wskazane przez UPRP rejestry praw wyłącznych oraz dostarczyć indeksy danych dla zeskanowanych rejestrów.

5. Digitalizacja prosta obejmuje zeskanowanie stron rejestrów praw wyłącznych, bez potrzeby ręcznego przepisywania danych zawartych w rejestrach.

6. Digitalizacja złożona obejmuje zeskanowanie stron rejestrów praw wyłącznych oraz przepisanie danych zawartych w rubrykach od C do H rejestru.

7. Digitalizacja złożona dotyczy jedynie kart rejestru znaków towarowych i wzorów przemysłowych w zakresie praw pozostających w mocy (należy pominąć sprawy gdzie dokonano wpisu informacji o ostatecznym wygaśnięciu lub unieważnieniu ochrony – co do zasady wpis w ostatniej rubryce rejestru). W szczególności wymagane jest przepisanie wszelkich informacji dotyczących:

• zajęć (np. wnioski o wpis zajęcia, decyzje o umorzeniu postępowania, decyzje o odmowie dokonania wpisu zajęcia, decyzje o wpisie zajęcia, decyzje o wykreśleniu zajęcia)

• zastawów,

• licencji,

• wniosków o unieważnienie,

• oddaleń wniosku w postępowaniu spornym,

• umorzeń postępowania spornego,

• decyzji o unieważnieniu w części,

• decyzji stwierdzających wygaśnięcie w części w postępowaniu spornym,

• sprzeciwów,

• decyzji o uchyleniu i umorzeniu postępowania,

• informacji o przedłużeniu ochrony znaków towarowych,

• informacji o używaczu uprzednim,

• informacja o regulaminie używania znaku towarowego.

Przepisane dane muszą być zaindeksowane, tak by możliwe było ich sprawne wykorzystanie w codziennej pracy w module eRejestry.

8. Digitalizacja prosta zostanie wykonana dla nie więcej niż 422 266 stron rejestrów prowadzonych przez UPRP, natomiast digitalizacja złożona dla nie więcej niż 40 000 stron rejestrów prowadzonych przez UPRP.

9. Indeksy, wyniki digitalizacji prostej oraz digitalizacji złożonej muszą być dostarczone w formacie pozwalającym na przeniesienie ich do modułu e-Rejestry lub innej bazy danych stworzonej przez Wykonawcę (na potrzeby udostępniania danych o przedmiotach własności przemysłowej w ramach wyszukiwarki UPRP). Wykonawca musi zapewnić czytelną prezentację zdgitalizowanych rejestrów w module e-Rejestry odpowiadającą kryteriom jakościowym ustalonym dla całego systemu.

10. Każda zeskanowana strona rejestru zostanie zaindeksowana przez wskazanie kategorii ochrony, numeru prawa wyłącznego i numeru zgłoszenia.

11. Wykonawca musi wprowadzić zdigitalizowane rejestry do modułu e-Rejestry lub innej bazy danych stworzoną przez Wykonawcę (na potrzeby udostępniania danych o przedmiotach własności przemysłowej w ramach wyszukiwarki UPRP).

12. Dodatkowo Wykonawca musi wprowadzić, do modułu e-Rejestry lub innej bazy danych stworzonej przez Wykonawcę (na potrzeby udostępniania danych o przedmiotach własności przemysłowej w ramach wyszukiwarki UPRP), udostępnione przez Zamawiającego, zeskanowane uprzednio w ramach innego projektu, 234 rejestry patentowe oraz 102 rejestry wzorów użytkowych.

13. Szczegółowe informacje dotyczące skanowania i indeksowania istniejących rejestrów zawarte zostały w poniższej tabeli.

kategoria ochrony

znaki towarowe

wzory przem.

patenty krajowe

patenty euro.

wzory użytkowe

oznaczenia geogr.

topografie ukł. sc.

dod. prawa ochr.

Łącznie

ile papierowych ksiąg rejestrowych jest łącznie na

04.10.2017

568

383

134

118

1250

ile stron na papierową księgę

rejestrową

(średnio)

510

502

495

501

495

2503

ile papierowych ksiąg rejestrowych zeskanowano

uprzednio

234

102

336

ile stron do skanowania 04.10.2017

289680

23594

73755

67134

7920

150

462266

14. Dodatkowo Wykonawca musi powtórnie zdigitalizować papierowe karty rejestrowe, które wytworzone zostaną przed uruchomieniem rejestrów elektronicznych. Wykonawca musi uwzględnić ponowne zeskanowanie i zaindeksowanie kart rejestrowych w przypadku wpisów w rejestrze, które zostały dokonane po ich zeskanowaniu przed odbiorem modułu e-Rejestry.

15. Digitalizując karty rejestrowe Wykonawca wskaże różne wersje kart rejestrowych (oraz zakresy stron rejestrów, dla których były stosowane) i przygotuje formatki kart rejestrowych (układ rubryk i nagłówków z uwzględnieniem zmian w nazewnictwie) na potrzeby wyświetlania danych w e-Rejestrach (dane w e-Rejestrach muszą być wyświetlane w historycznym układzie rubryk).

16. Dla każdej sprawy, która jest wpisana na więcej niż jednej stronie rejestru, Wykonawca dostarczy jeden plik zawierający skan wszystkich stron rejestru dla danego numeru rejestru.

17. Każdy plik zawierający wyniki digitalizacji musi być nazwany ze wskazaniem kategorii ochrony oraz numeru rejestru, którego dotyczy (np. skanPat123456 dla patentu o numerze rejestru 123456).

18. Wymagane jest by dostarczone wyniki digitalizacji prostej były w rozdzielczości co najmniej 300 dpi, a jakość skanowania nie może być niższa niż 99,9% poprawności odwzorowania. Dla wyników digitalizacji złożonej jakośc rozpoznawania wszystkich stron nie może być niższa niż 98% poprawnie przepisanych znaków z pominięciem znaków interpunkcyjnych (obliczenia dla wyodrębnionych słów, bez modyfikatorów typu indeksy, przeniesienia, etc).

19. Wyniki digitalizacji muszą być dostarczone jako pliki w formacie PDF, a także jako pliki w formacie PDF/A, gdzie 100% plików musi mieć możliwość eksportowania i kopiowania warstwy tekstowej.

20. Przed przekazaniem rezultatów digitalizacji do odbioru UPRP, Wykonawca zapewni weryfikację jakości zeskanowanych rejestrów oraz zaindeksowanych danych. Raporty z wykonania w/w weryfikacji muszą być przekazane przez Wykonawcę przed odbiorem przez Xxxxxxxxxxxxx.

21. Digitalizacja prosta rejestrów musi odbywać się w pomieszczeniu udostępnionym przez Zamawiającego na terenie UPRP. Digitalizacja złożona rejestrów na podstawie skanów wytworzonych w procesie digitalizacji prostej nie musi odbywać się na terenie UPRP. UPRP uzgodni z Wykonawcą szczegółowe zasady przekazywania rejestrów do skanowania biorąc pod uwagę, iż UPRP musi na bieżąco udostępniać rejestry papierowe Klientom (pożądane jest, aby rejestry były zwracane przez Wykonawcę następnego dnia po ich przekazaniu przez UPRP).

22. Wykonawca przekazywał będzie UPRP do odbioru zdigitalizowane księgi rejestrowe w cyklach miesięcznych. Po sprawdzeniu zdigitalizowanych rejestrów UPRP raz na kwartał dokona odbioru pracy przekazanej przez Wykonawcę w poprzednim kwartale.

23. Wykonawca jest zobowiązany digitalizować i przekazywać jednorazowo do odbioru raz na miesiąc nie mniej niż 20 oraz nie więcej niż 100 zeskanowanych i zindeksowanych ksiąg rejestrowych (księga rejestrowa zawiera, co do zasady, około 500 kolejnych stron rejestru w formacie A3, około 30 000 najstarszych stron rejestru znaków towarowych jest w formacie 42x45 cm).

24. W pierwszej kolejności należy zdigitalizować rejestr topografii układów scalonych, rejestr oznaczeń geograficznych oraz rejestr dodatkowych praw ochronnych - te rejestry zawierają symboliczną ilość stron.

25. W dalszej kolejności należy zdigitalizować rejestr wzorów użytkowych oraz rejestr wzorów przemysłowych, a następnie rejestr patentowy oraz jego wyodrębnioną część dla patentów europejskich.

26. Ponieważ ponad 70% wszystkich zmian w rejestrach dokonywanych jest w rejestrze znaków towarowych, rejestr znaków towarowych musi być digitalizowany jako ostatni, począwszy od najstarszych spraw, co pozwoli zmniejszyć ilość spraw wymagających powtórnej digitalizacji.

27. Wyniki digitalizacji nie są podpisywane w module e-Rejestry. Pracownik ma możliwość wybrania/zatwierdzenia, które zdigitalizowane rejestry są udostępniane klientom (musi być możliwość wyboru zakresów numerów stron rejestrów, które mogą być udostępniane klientom).

28. Klientom udostępniane są zatwierdzone skany rejestrów. Udostępniane są też podpisane w module e-Rejestry: nowe karty rejestrowe oraz zmiany w rejestrach. Informacje z modułu e-Rejestry mogą być dostępne dla Klientów tylko, jeśli zostały zatwierdzone do udostępnienia lub podpisane w module e-Rejestry.

29. Zdigitalizowane karty rejestrowe muszą być ładowane przez Wykonawcę do e-Rejestrów i muszą wyświetlać się pracownikom UPRP w formie pozwalającej na przeglądanie skanów, porównywanie skanów z odpowiadającymi im danymi z baz danych UPRP oraz ewentualną modyfikację danych, jeśli stwierdzone zostaną rozbieżności między skanem a danymi z baz danych UPRP.

Prawo opcji:

30. Zamawiający w ramach realizacji przedmiotu Umowy zastrzega sobie możliwość skorzystania z Prawa opcji w zakresie usługi digitalizacji dodatkowych 107 587 stron rejestrów, które powstaną do końca roku 2019. Digitalizacja prosta zostanie wykonana dla nie więcej niż 97 587 stron rejestrów prowadzonych przez UPRP, natomiast digitalizacja złożona dla nie więcej niż 10 000 stron rejestrów prowadzonych przez UPRP.

31. Zamawiający przewiduje możliwość wykorzystania Prawa opcji jedynie w przypadku posiadania przez Zamawiającego środków finansowych, uzasadnionej potrzeby zakupu i stworzenia nowych kart rejestrowych.

32. Zakres usług oraz procedura odbioru w ramach Prawa opcji są takie same jak dla digitalizacji rejestrów określonej w zamówieniu podstawowym.

33. Szczegółowe informacje dotyczące skanowania i indeksowania rejestrów, które powstaną do końca 2019 roku zawarte zostały w poniższej tabeli.

kategoria ochrony

znaki towarowe

wzory przem.

patenty krajowe

patenty euro.

wzory użytkowe

oznaczenia geogr.

Topografie ukł. sc.

dod. prawa

ochr.

Łącznie

ile nowych papierowych ksiąg rejestrowych do końca

2019 roku?

124

ile nowych stron do skanowania do końca

2019

27540

3012

6930

22545

2475

62567

ile stron do powtórnego skanowania (wpisane zmiany po pierwotnym

skanowaniu)

25000

5000

45020

Ile stron do skanowania do końca

2019

52540

8012

11930

27545

7475

107587

Pozostałe wymagania:

34. Wykonawca oświadcza, że osoby wskazane przez Wykonawcę do realizacji usługi Digitalizacji (lub Podwykonawcę, gdy dotyczy) będą zatrudnione na podstawie umowy o pracę, gdyż wykonywane przez nie czynności (usługi skanowania i indeksowania rejestrów papierowych), przy realizacji Umowy, polegają na wykonywaniu pracy w sposób określony w art. 22 § 1 ustawy z dnia 26 czerwca 1974 r. – Kodeks pracy (Dz.U. z 2016 r. poz. 1666, z późn. zm.).

35. Zamawiający wymaga udokumentowania faktu zatrudnienia osób wskazanych w pkt 34 poprzez przedstawienie przez Wykonawcę, w terminie 7 dni od dnia zawarcia Umowy, dokumentacji potwierdzającej spełnienie oświadczenia z pkt 34. Wykonawca przedłoży Zamawiającemu, w celu potwierdzenia spełnienia wymogu zatrudnienia na podstawie umowy o pracę przez Wykonawcę lub Podwykonawcę osób wykonujących czynności skanowania i indeksowania rejestrów papierowych, poświadczoną za zgodność z oryginałem odpowiednio przez Wykonawcę lub Podwykonawcę kopię umowy/umów o pracę osób wykonujących w trakcie realizacji Umowy, czynności których dotyczy

oświadczenie Wykonawcy lub Podwykonawcy (wraz z dokumentem regulującym zakres obowiązków, jeśli został sporządzony). Kopia umowy/umów powinna zostać zanonimizowana w sposób zapewniający ochronę danych osobowych pracowników, zgodnie z przepisami ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych. Informacje takie jak: imię i nazwisko, data zawarcia umowy, rodzaj umowy o pracę i wymiar etatu powinny być możliwe do zidentyfikowania.

36. Zamawiający w trakcie realizacji umowy, w przypadku powzięcia wątpliwości lub wiedzy o niewykonywaniu obowiązku zatrudnienia na podstawie umowy o pracę ma prawo do kontroli spełnienia przez Wykonawcę powyższego wymagania. Na każde wezwanie Zamawiającego, w wyznaczonym w tym wezwaniu terminie, Wykonawca przedłoży Zamawiającemu, w celu potwierdzenia spełnienia wymogu zatrudnienia na podstawie umowy o pracę przez Wykonawcę osób wykonujących wskazane czynności poprzez złożenie kopii umowy o pracę.

ROZDZIAŁ XIV. Dedykowana Asysta Techniczna

1. W ramach usług Dedykowanej Asysty Technicznej Wykonawca zobowiązuje się świadczyć na rzecz Zamawiającego dodatkowe prace nieobjęte przedmiotem Umowy oraz usługami Gwarancji w liczbie 6 000 roboczogodzin. Dedykowana Asysta Techniczna będzie realizowana w obszarze konfiguracji i zarządzania infrastrukturą oraz rozwoju oprogramowania.

2. Zlecane pracę będą dotyczyły w szczególności:

2.1. rozwiązywania problemów powstałych w trakcie instalacji, konfiguracji oraz eksploatacji PUEUP wynikających z przyczyn innych niż objęte Gwarancją,

2.2. integracji wdrażanej PUEUP z systemami zlokalizowanymi w UPRP, a nie objętymi przedmiotem Umowy,

2.3. wsparcia przy procesie aktualizacji środowiska PUEUP,

2.4. wsparcia w procesach optymalizacji wykorzystywanych zasobów PUEUP, w tym budowy odpowiednich scenariuszy do zmiany rozlokowania obiektów logicznych i ich realizacji,

2.5. wsparcia w zakresie rozszerzania stopnia wirtualizacji PUEUP,

2.6. wsparcia w zakresie poprawnego przydziału zasobów dla nowo wdrażanych systemów,

2.7. wsparcia w zakresie rekonfiguracji lub opracowywania nowych rozwiązań technicznych dla poprawy wydajności wdrożonych lub budowanych komponentów,

2.8. wsparcia w zakresie opracowywania koncepcji i analiz technicznych,

2.9. analizy biznesowej,

2.10. analizy systemowej,

2.11. opracowywania i wdrażania nowych interfejsów aplikacyjnych,

2.12. realizacji zmian w funkcjonującym oprogramowaniu wynikających z przyczyn innych niż objęte Gwarancją,

2.13. dodatkowych warsztatów dla pracowników Zamawiającego i użytkowników zewnętrznych z obsługi systemu.

3. Przez okres trwania Dedykowanej Asysty Technicznej Wykonawca zobowiązany jest przyjmować Zapytania Zamawiającego dotyczące realizacji usług w ramach Dedykowanej Asysty Technicznej.

3.1. Zapytania składane będą w następujący sposób:

3.1.1. za pomocą aplikacji serwisowej (interfejsu serwisowego) lub

3.1.2. przez przesłanie Zapytania pocztą elektroniczną na uzgodniony z Zamawiącym adres lub

3.1.3. przez przesłanie Zapytania faksem na numer uzgodniony z Zamawiającym numer.

3.2. Zapytanie składane przez Zamawiającego musi zawierać:

3.2.1. opis prac jakie Zamawiający chce zamówić,

3.2.2. określenie oczekiwań Zamawiającego co do Produktów i prac oraz sposobu ich wykonania i prowadzenia,

3.2.3. termin zakończenia prac,

3.2.4. inne kwestie istotne dla Zamawiającego.

3.3. W razie otrzymania przez Wykonawcę Zapytania, zobowiązany jest on niezwłocznie, jednak nie później niż w terminie 5 dni roboczych od dnia złożenia Zapytania przez Zamawiającego, do potwierdzenia warunków tam określonych (Odpowiedź na Zapytanie), a jeżeli to niemożliwe – do przedstawienia własnej propozycji, przesyłając w tym celu Zamawiającemu Ofertę Zamówienia, zawierającą x.xx. zakres i sposób prowadzenia prac i wykonania Produktów, termin ich wykonania oraz maksymalną czasochłonność takich prac.

3.4. Jeżeli Xxxxxxxxxxx zaakceptuje propozycje Wykonawcy zawarte w Odpowiedzi na Zapytanie, Zamawiający złoży stosowne Zamówienie – prace w takim przypadku rozpoczną się niezwłocznie, nie później niż w terminie 3 dni roboczych. W

uzasadnionych przypadkach Strony mogą podjąć decyzję o wydłużeniu terminu rozpoczęcia prac.

3.5. Odesłanie przez Xxxxxxxxxxxxx potwierdzenia przyjęcia Oferty Zamówienia oznacza złożenie przez Zamawiającego Zamówienia na warunkach wskazanych w Ofercie Zamówienia.

3.6. Brak ustosunkowania się przez Zamawiającego do Oferty Zamówienia oznacza odrzucenie Oferty Zamówienia przez Zamawiającego.

3.7. Po realizacji Zamówienia Wykonawca zgłosi je do odbioru zgodnie z procedurami opisanymi w Załączniku nr E do SOPZ.

3.8. Z chwilą dokonania Odbioru Zamówienia, Wykonawca przekazuje Zamawiającemu wszelkie prawa autorskie do wytworzonych Produktów oraz obejmie Produkty wykonane / dostarczone w ramach Zamówienia Gwarancją, bez zmiany wysokości wynagrodzenia przysługującego Wykonawcy z tego tytułu, na zasadach określonych w Umowie.

Prawo opcji:

4. Zamawiający w ramach realizacji przedmiotu Umowy zastrzega sobie możliwość skorzystania z Prawa opcji w zakresie usługi dodatkowych do 3 000 roboczogodzin w ramach Dedykowanej Asysty Technicznej.

5. Zamawiający przewiduje możliwość wykorzystania Prawa opcji jedynie w przypadku posiadania przez Zamawiającego środków finansowych, uzasadnionej potrzeby zakupu i wykorzystania pełnej puli roboczogodzin określonych w zamówieniu podstawowym.

6. Zakres usług oraz procedura odbioru w ramach Prawa opcji są takie same jak dla Dedykowanej Asysty Technicznej określonej w zamówieniu podstawowym.

ROZDZIAŁ XV. Fazy realizacji PUEUP

1. Wykonawca jest zobowiązany do wykonania przedmiotu zamówienia w terminach określonych w Harmonogramie Ramowym.

2. Harmonogram Ramowy definiuje tylko główne czynności i terminy realizacji PUEUP. Określa następujące fazy i terminy wykonania poszczególnych prac:

2.1. Xxxx X – do 6 miesięcy od dnia podpisania Umowy, przy czym:

2.1.1. projekt dokumentacji technicznej dla Modułu e-Powiadomienia etap 1 (dla znaków towarowych) – do 2 miesięcy od dnia podpisania Umowy,

2.1.2. wdrożenie Modułu e-Powiadomienia etap 1 (dla znaków towarowych) – do dnia 09.11.2018 r.,

2.1.3. wykonanie Dokumentacji Projektowej – do 6 miesięcy od dnia podpisania Umowy.

Faza kończy się podpisaniem przez obie Strony Protokołu Odbioru Fazy I.

2.2. Xxxx XX – do 3 miesięcy od dnia podpisania Protokołu Odbioru Fazy I, przy czym:

2.2.1. Dostawa sprzętu i oprogramowania do 2 miesięcy od dnia podpisania Protokołu Odbioru Fazy I,

2.2.2. Wdrożenie i konfiguracja sprzętu i oprogramowania do 3 miesięcy od dnia podpisania Protokołu Odbioru Fazy I.

Faza kończy się podpisaniem przez obie Strony Protokołu Odbioru Xxxx XX.

Od dnia odbioru Xxxx XX rozpoczyna się 5-letni okres gwarancji na dostarczony sprzęt i oprogramowanie.

2.3. Xxxx XXX – do 11 miesięcy od dnia podpisania Protokołu Odbioru Fazy I, przy czym:

2.3.1. Prototypu Systemu – do 4 miesięcy od dnia podpisania Protokołu Odbioru Fazy I,

2.3.2. Zgłoszenie gotowości do testów akceptacyjnych – do 7 miesięcy od dnia podpisania Protokołu Odbioru Fazy I,

2.3.3. Odbiór testów akceptacyjnych – do 8 miesięcy od dnia podpisania Protokołu Odbioru Fazy I,

2.3.4. Poprawa błędów ujawnionych w trakcie audytu (przeprowadzanego przez zewnętrznego wykonawcę) i odbiór oprogramowania Systemu – do 11 miesięcy od dnia podpisania Protokołu Odbioru Fazy I.

Faza kończy się podpisaniem przez obie Strony Protokołu Odbioru Xxxx XXX.

2.4. Faza IV – faza stabilizacji Systemu - od 3 miesięcy od dnia podpisania przez Strony Protokołu Odbioru Fazy III, przy czym zgłoszenie do odbioru Dokumentacji powykonawczej i przeprowadzenia Warsztatów - do 2 miesięcy od dnia podpisania przez Strony Protokołu Odbioru Xxxx XXX.

Faza kończy się podpisaniem przez obie Strony Protokołu Odbioru Fazy IV (Odbiór końcowy). Od dnia odbioru końcowego rozpoczyna się 5-letni okres gwarancji na Oprogramowanie Dedykowane Systemu.

3. Harmonogram Ramowy zostanie uszczegółowiony przez Wykonawcę w porozumieniu z Zamawiającym w ciągu 45 dni od dnia podpisania Umowy, jako odrębny produkt – Harmonogram Szczegółowy. Harmonogram Szczegółowy nie może przekraczać terminów zawartych w Harmonogramie Ramowym. Na wniosek Zamawiającego lub Wykonawcy Strony mogą podjąć decyzję o zmianie Harmonogramu Szczegółowego. Zmiana Harmonogramu Szczegółowego nie stanowi zmiany Umowy.

4. Ponadto, w ramach realizacji Umowy Wykonawca zobowiązany będzie do:

4.1. Przeprowadzenia szkoleń dla administratorów Zamawiającego z dostarczanej infrastruktury i oprogramowania standardowego – do 8 miesięcy od dnia podpisania Umowy.

4.2. Świadczenia gwarancji:

4.2.1. Dla Sprzętu i Oprogramowania Standardowego 5 lat od dnia podpisania przez obie Strony Protokołu Odbioru Fazy II,

4.2.2. Dla Oprogramowania Dedykowanego 5 lat od dnia podpisania przez obie Strony Protokołu Odbioru Fazy IV.

4.2.3. Świadczenia usług asysty technicznej od dnia podpisania Umowy do końca terminu obowiązywania 5-letniej gwarancji na Oprogramowanie Dedykowane lub do wyczerpania pełnej puli roboczogodzin.

4.2.4. Digitalizacji rejestrów w terminie od dnia podpisania umowy do dnia podpisania przez strony Protokołu Odbioru Xxxx XXX.

5. W ramach Prawa opcji Wykonawca zobowiązany będzie do:

5.1. świadczenia usług asysty technicznej w zakresie i terminach określonych dla usług asysty technicznej w zamówieniu podstawowym.

5.2. digitalizacji dodatkowych rejestrów w zakresie i w terminach określonych dla usług digitalizacji w zamówieniu podstawowym.

ROZDZIAŁ XVI. Wymagania prawne

1. Wykonane i dostarczone przez Wykonawcę oprogramowanie aplikacyjne PUEUP musi zapewnić zgodność z wymaganiami prawnymi, a w szczególności z poniższymi aktami

prawnymi, w wersjach obowiązujących na dzień podpisania protokołu odbioru końcowego:

1.1. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (t.j. Dz. U. z 2017 r, poz. 570 z późn. zm.);

1.2. Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (t.j. Dz. U. 2015, poz. 971);

1.3. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2016 r. poz. 113 x.x. x xxxx. zm);

1.4. Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz.U. z 2005 Nr 217, poz. 1836);

1.5. Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz. U. z 2017r., poz.1257);

1.6. Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym. (Dz.U. 2013 r. poz. 262 z późn. zm.);

1.7. Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (t.j. Dz. U. z 2017 r., poz. 1219);

1.8. Ustawa z dnia 10 grudnia 2003 r. o czasie urzędowym na obszarze Rzeczypospolitej Polskiej (D.U. z 2004 r. Nr 16, poz. 144);

1.9. Ustawa z 6 września 2001 r. o dostępie do informacji publicznej (Dz. U. 2016 r. poz. 1764 z późn. zm.);

1.10. Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. 2016 r. poz. 922 t.j. z późn. zm.) oraz Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony danych osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE nazywanym ogólnym rozporządzeniem o ochronie danych osobowych (RODO);

1.11. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych

oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 Nr 100, poz.1024);

1.12. Rozporządzenie Prezesa Rady Ministrów z dnia 12 stycznia 2017 r. w sprawie rejestrów prowadzonych przez UPRP Rzeczypospolitej Polskiej (Dz.U. z 2017 r., poz. 115);

1.13. Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz.U. z 2016 r., poz. 1579);

1.14. Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 910/2014 z dnia 23 lipca 2014 r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylającym dyrektywę 1999/93/WE (Dz. Urz. UE L 257 z 28.08.2014, str. 73) wraz z aktami wykonawczymi do rozporządzenia (eIDAS);

1.15. Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (t. j. Dz.U. z 2016, poz. 1506 z późn. zm.);

1.16. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. z 2006 r. Nr 206 poz. 1517);

1.17. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. z 2006 r. Nr 206 poz. 1519);

1.18. Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz. U. z 2005 r. Nr 205 poz. 1692 z późn. zm.);

1.19. Ustawa o ochronie baz danych z dnia 27 lipca 2001 r. (Dz. U. z 2001 r. Nr 128 poz. 1402 z późn. zm.);

1.20. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz. U. z 2006 r. Nr 206, poz. 1518);

1.21. Rozporządzeniem Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien

spełniać system teleinformatyczny służący do uwierzytelniania użytkowników (Dz.U. z 2016 r., poz. 1627);

1.22. Ustawa z dnia 30 czerwca 2000 r. Prawo własności przemysłowej (t.j. Dz. U. z 2017 r., poz.776);

1.23. Rozporządzenie Prezesa Rady Ministrów z dnia 17 września 2001 r. w sprawie dokonywania i rozpatrywania zgłoszeń wynalazków i wzorów użytkowych (Dz. U. z 2001 r. Nr 102, poz. 1119 z późn. zm.);

1.24. Rozporządzenie Prezesa Rady Ministrów z dnia 28 października 2016 r. w sprawie dokonywania zgłoszeń wynalazków, produktów leczniczych, produktów ochrony roślin, wzorów użytkowych, wzorów przemysłowych, znaków towarowych, oznaczeń geograficznych i topografii układów scalonych oraz prowadzenia korespondencji w postaci elektronicznej (Dz. U. z 2016 r., poz. 1805);

1.25. Rozporządzenie Prezesa Rady Ministrów z dnia 12 stycznia 2017 r. w sprawie rejestrów prowadzonych przez Urząd Patentowy Rzeczypospolitej Polskiej (Dz. U. z 2017 r., poz. 115);

1.26. Rozporządzenie Rady Ministrów z dnia 29 sierpnia 2001 r. w sprawie opłat związanych z ochroną wynalazków, wzorów użytkowych, wzorów przemysłowych, znaków towarowych, oznaczeń geograficznych i topografii układów scalonych (Dz. U. z 2001 r. Nr 90, poz. 1000 z późn. zm.);

1.27. Rozporządzenie Prezesa Rady Ministrów z dnia 8 grudnia 2016 r. w sprawie dokonywania i rozpatrywania zgłoszeń znaków towarowych (Dz. U. z 2016 r., poz. 2053);

1.28. Rozporządzenie Prezesa Rady Ministrów z dnia 30 stycznia 2002 r. w sprawie dokonywania i rozpatrywania zgłoszeń wzorów przemysłowych. (Dz. U. z 2002

r. Nr 40, poz. 358 z późn. zm.);

1.29. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2015/2436 z dnia 16 grudnia 2015 r.;

1.30. Rozporządzenie Rady Ministrów z dnia 8 stycznia 2002 r. w sprawie szczegółowego zakresu działania Urzędu Patentowego Rzeczypospolitej Polskiej (Dz. U. z 2002 r. Nr 8, poz. 59, z późn. zm.);

1.31. Rozporządzenie Rady Ministrów z dnia 23 lipca 2002 r. w sprawie wynalazków i wzorów użytkowych dotyczących obronności lub bezpieczeństwa Państwa (Dz.

U. z 2002 r. Nr 123, poz. 1056), Rozporządzenie Prezesa Rady Ministrów z dnia

7 czerwca 2004 r. w sprawie nadania statutu Urzędowi Patentowemu Rzeczypospolitej Polskiej (Dz. U. z 2004 r. Nr 140, poz. 1484, z późn. zm.);

1.32. Rozporządzenie Prezesa Rady Ministrów z dnia 9 września 2016 r. w sprawie składania i rozpatrywania wniosków o udzielenie dodatkowego prawa ochronnego dla produktów leczniczych i produktów ochrony roślin (Dz. U. z 2016 r. poz. 1482);

1.33. Rozporządzeniem Prezesa Rady Ministrów z dnia 30 września 2016 r. w sprawie wzorów dokumentów patentowych, dodatkowych świadectw ochronnych, świadectw ochronnych, świadectw rejestracji oraz dowodów pierwszeństwa wydawanych przez Urząd Patentowy Rzeczypospolitej Polskiej (Dz. U. z 2016 r. poz. 1659);

1.34. Ustawa z dnia 5 lipca 2002 r. o ochronie niektórych usług świadczonych drogą elektroniczną opartych lub polegających na dostępie warunkowym (Dz. U. 2015

r. poz. 1341 z późn. zm.);

1.35. Przepisy prawne związane z Krajowym Schematem Identyfikacji Elektronicznej.

1.36. Ustawa z dnia 14 marca 2003 r. o dokonywaniu europejskich zgłoszeń patentowych oraz skutkach patentu europejskiego w Rzeczypospolitej Polskiej (Dz. U. z 2016 r. poz. 2)

1.37. Porozumienie nicejskie dotyczące międzynarodowej klasyfikacji towarów i usług dla celów rejestracji znaków, podpisane w Nicei dnia 15 czerwca 1957 r., zrewidowane w Sztokholmie dnia 14 lipca 1967 r. i w Genewie dnia 13 maja 1977 r. oraz zmienione dnia 28 września 1979 r. (Dz. U. z 2003 r. Nr 63, poz. 583) – w kontekście wymagań dla formularzy.

ROZDZIAŁ XVII. Odbiory produktów i prac realizowanych w ramach Umowy

Odbiory wszystkich elementów dostarczonych i wytworzonych w ramach projektu (modułów, oprogramowania, dokumentacji, szkoleń, rezultatów asysty technicznej, itp.) oraz poszczególnych etapów jego realizacji będą realizowane zgodnie z procedurami odbiorowymi opisanymi w Załączniku E do SOPZ.

ROZDZIAŁ XVIII. Warunki równoważności

1. Jeżeli Zamawiający określił w SIWZ wymagania z użyciem nazw własnych produktów lub marek producentów, w szczególności w obszarze specyfikacji przedmiotu zamówienia, to

należy traktować wskazane produkty jako rozwiązania wzorcowe. W każdym takim przypadku Zamawiający oczekuje dostarczenia produktów wzorcowych lub równoważnych, spełniających poniższe warunki równoważności.

2. W przypadku dostarczania sprzętu, oprogramowania, szkoleń lub innych produktów równoważnych względem wyspecyfikowanych przez Zamawiającego w SIWZ, Wykonawca musi na swoją odpowiedzialność i swój koszt udowodnić, że dostarczane produkty spełniają wszystkie wymagania i warunki określone SIWZ, w szczególności w zakresie:

2.1. warunków licencji / sublicencji w każdym aspekcie licencjonowania / sublicencjonowania, które nie mogą być gorsze niż dla produktu wymienionego w SIWZ,

2.2. funkcjonalności równoważnej produktu, która nie może być gorsza od funkcjonalności produktu wymienionego w SIWZ,

2.3. sprzętu i oprogramowania, które muszą być kompatybilne i w sposób niezakłócony współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego,

2.4. sprzętu i oprogramowania, które nie mogą zakłócić pracy środowiska systemowo- programowego Zamawiającego,

2.5. sprzętu i oprogramowania, które muszą w pełni współpracować z systemami Zamawiającego, opartymi o dotychczas użytkowane oprogramowanie,

2.6. sprzętu i oprogramowania, które muszą zapewniać pełną, równoległą współpracę w czasie rzeczywistym i pełną funkcjonalną zamienność produktu równoważnego z produktem określonym w SIWZ,

2.7. warunków i zakresu usług gwarancji, serwisu pogwarancyjnego, asysty technicznej i konserwacji produktu równoważnego, muszą być nie gorsze niż dla produktu wymienionego w SIWZ.

3. W przypadku zaoferowania przez Wykonawcę produktu równoważnego Wykonawca dokona wspólnie z Zamawiającym instalacji i testowania produktu równoważnego w środowisku sprzętowo-programowym Zamawiającego.

4. W przypadku zaoferowania przez Wykonawcę oprogramowania równoważnego Wykonawca dokona transferu wiedzy w zakresie utrzymania i rozwoju rozwiązania opartego o zaproponowane produkty.

5. W przypadku, gdy zaoferowany przez Wykonawcę produkt równoważny nie będzie właściwie współdziałać ze sprzętem i oprogramowaniem funkcjonującym u

Zamawiającego lub spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo-programowego u Zamawiającego, Wykonawca pokryje wszystkie koszty związane z przywróceniem i sprawnym działaniem infrastruktury sprzętowo- programowej Zamawiającego oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe działanie środowiska sprzętowo-programowego Zamawiającego również po usunięciu produktu równoważnego.

6. Wraz z produktem równoważnym Wykonawca jest zobowiązany do dostarczenia niżej wymienionego oświadczenia i następujących dokumentów:

6.1. oświadczenia dotyczącego zastosowania produktu równoważnego,

6.2. pełnego postanowienia licencji / sublicencji produktu równoważnego,

6.3. pełnego wykazu funkcjonalności produktu równoważnego,

6.4. pełnych warunków i zasad świadczenia usług gwarancji, serwisu pogwarancyjnego, asysty technicznej i konserwacji dla produktu równoważnego,

6.5. wykazu miejsc użycia produktu równoważnego.

7. Oprogramowanie równoważne dostarczane przez Wykonawcę nie może powodować utraty kompatybilności oraz wsparcia producentów innego używanego i współpracującego z nim oprogramowania.

8. Oprogramowanie równoważne zastosowane przez Wykonawcę nie może w momencie składania przez niego oferty mieć statusu zakończenia wsparcia technicznego producenta. Niedopuszczalne jest zastosowanie oprogramowania równoważnego, dla którego producent ogłosił zakończenie jego rozwoju w terminie 3 lat licząc od momentu złożenia oferty. Niedopuszczalne jest użycie oprogramowania równoważnego, dla którego producent oprogramowania współpracującego ogłosił zaprzestanie wsparcia w jego nowszych wersjach.

Document Metadata

Table of Contents

ZAMAWIAJĄCY: URZĄD PATENTOWY RZECZYPOSPOLITEJ POLSKIEJ

Document Metadata