The application under consideration concerned a method for submitting a report on a business activity after receipt of a complaint. The decision adds another brick to the impressive wall of “technical or not” decisions.
[5.3] The method of claim 1 (final two paragraphs) enables a proof that the user has transmitted specific data:
(a) the receiver of the complaint data (i.e. the second server) feeds back a confirmation code to the source of the data;
(b) the user’s authorship is verified by checking that the confirmation code works as a key to decrypt an encrypted version of the complaint data.
Providing confirmation feedback from the receiver to the sender is a general aspect of usual acknowledgements of receipt. The application presents confirmations in the form of a decryption key or in the form of a code or number as largely equivalent means of proof […].
Decryption is a mathematical method which serves a technical purpose in a technical system where cryptography is used for data security.
However, in claim 1, the decryption operation is used for proving the authorship of a document, which is a non-technical, legal problem. Therefore, the intrinsically non-technical, mathematical method of decryption cannot derive a technical character from the problem solved (T 1227/05 [3.1]). Thus, providing and using the decryption key for fulfilling a legal verification task does not enter into the examination for an inventive step.
It is not always easy for outsiders like me to understand the borderline between what is considered technical and what is not. Moreover, the Boards appear not to agree with each other. In T 1326/06, for instance (reported and translated here), Board 3.5.06 had found that “methods for encrypting/decrypting or signing electronic messages have to be considered to be technical methods, even if they are essentially based on mathematical methods.”
Should you wish to download the whole decision, just click here.
The file wrapper can be found here.
2 comments:
Without looking at the decision I would bet a substantial amount of money this was issued by 3.5.01
It is unsurprisingly. The decision and reasoning are completely in line with what 3.5.01 have refused with an increasingly harsh line over the past 18 months.
I'm not convinced that T1326/06 is really that contradictory in this case. The crux of the argument here is that the underlying task is non-technical and therefore the maths behind the solution lack technical character. In T1326/06 the task "safe exchange of messages" was deemed technical and therefore the mathematical method have technical character.
Post a Comment