[%TAGS (074db819ec% %074db819ec) %]

(074db819ec% subtitle %074db819ec)


(074db819ec%|loc%074db819ec)chronological(074db819ec% END %074db819ec) (074db819ec%|loc%074db819ec)Thread(074db819ec% END %074db819ec) 
(074db819ec% IF user.email && action == 'arc' %074db819ec)
(074db819ec%|loc%074db819ec)Reply to sender(074db819ec%END%074db819ec) (074db819ec%|loc%074db819ec)to list(074db819ec%END%074db819ec)

(074db819ec% IF user.email == 'srctran@world.std.com' || is_owner %074db819ec) (074db819ec% END %074db819ec)
(074db819ec% END %074db819ec)

James asks about a recent EPO patent on e-voter registration:
>(i)  what was the technical problem ?

First state your particular definition of "technical" for anyone to
try and answer your question.  By why even bother, when you second
question is a much better approach:

>(ii) in an age where the management of public-key identification is an
>off-the-peg well-understood technology, what was the non-obvious
>inventive step in the solution ?

As I have argued for ten years, novelty and obviousness are a much easier
and more more objective way to kill the vast majority of crappy software
patents.  I would be interested in seeing the (non-patent) prior art
cited by the EPO for their examination of this patent - I suspect this
list of prior art will be inadequately short.

By relying on established novelty and obviousness/inventive-step analyses,
you can avoid the need to rely on the ill-defined/metaphysical use of
words such as "technical".

Greg Aharonian




(074db819ec%|loc%074db819ec)Archive powered by(074db819ec%END%074db819ec) MhonArc 2.6.16.

(074db819ec%TAGS [% %]%074db819ec)