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.