Tou prvni citaci musite myslet bod 13a. FFII tvrdi, ze toto omezeni nema zadny ucinek. Aby totiz bylo reseni technicke, je treba, aby resilo technicky problem. Bod 13a pouze tvrdi, ze k tomu nestaci zduvodneni, ze neco bezi na pocitaci. FFII ale namita, ze reseni technickeho problemu neni problem zduvodnit jinak. Napr. novy skvely video kodek muze resit technicky problem pomalosti procesoru zarizeni, na kterem ma byt implementovan, pro prehravani v teto kvalite (neco v podobnem duchu pry uz nekde EPO pouzila). K bodu 13c (vami oznacovanem jako 16) snad jen to, ze vetsina tzv. softwarovych patentu dosud udelenych EPO nepopisuje jen cisty algoritmus, ale je to obalene prave do nejake metody. Definice slov technicky nebo technicky problem nikde uspokojive neni, takze v tomhle smernice zadne nove vyjasneni neprinasi.
Clanek 5(2) je prave ten s tim naprosto nesmyslnym obratem (volne prepsano) ,,nelze patentovat programy, mimo pripad [...]'', kde [...] je podminka, ktera je vzdy pravdiva. Muzu si narokovat nejaky postup, pokud si ten postup narokuji.
Ja netvrdim, ze tento scenar pripoustejici patentovatelnost, je ten jediny spravny vyklad direktivy. Avsak upozornuji na to, ze FFII tvrdi, ze tam je mozno takovy vyklad videt, a upozornuji na historickou skutecnost, ze EPO toho zatim vzdycky vyuzila (viz. EPC, TRIPS). Pokud je opravdu cilem direktivy udelat jasno a harmonizovat, mel by z ni byt vyklad zrejmy a jednoznacny. A asi by se ani nemel opirat jen o body vychodiska.