T 1489/21 (Signature request validation/CRYPTOMATHIC) 18-10-2023

1. The following numbering of the features of claim 1 of the main request is used hereafter:

Feature lA:

A method of generating a signature on behalf of a user having a first and second user device, the method comprising

Feature lB:

receiving a request from said first user device to create a signature for a first message M;

Feature lC: generating a validation challenge using a second message M'

Feature lD: which is based on the first message M and a first secret shared with said user, wherein said validation challenge is generated by encrypting said second message M' using said first shared secret;

Feature lE: sending said validation challenge to said user to enable said second user device to

Feature lF: regenerate said second message M';

Feature lG: receiving a validation code from said second user device, said validation code confirming the request to create a signature and said validation code being generated following confirmation from the user that the second message M' as displayed on the second user device corresponds to the first message M,

Feature lH: wherein the second message M' displayed on the second user device is generated by decrypting said validation challenge using said first shared secret; and

Feature 1I: generating the signature for the user for the first message M.

2. Main request - Article 123(2) EPC

The opponent argued that feature 1G was not supported by the application documents as originally filed since it did not define that the validation code was user specific. According to the opponent, page 7, lines 23 to 25, page 9, lines 30 to 33, and page 17, lines 18 to 20 of the originally filed description described that the validation code must be created using information which was specific to the user, such as a second shared secret, and no other ways of generating the validation code were described anywhere in the description. According to the opponent, the omission in claim 1 of the feature that the validation code was created using information which is specific to the user amounted to an inadmissible intermediate generalisation. The opponent further argued that claim 1 as originally filed could not be seen as a support for the omission of this feature since feature 1G of present claim 1 of the main request defined the generation of the validation code in more specific terms, namely by defining that the generation of the validation code was triggered by, or linked to, the confirmation from the user that the second message M' as displayed on the second user device corresponded to the first message M. Further, the opponent argued that, even if originally filed claims 9, 28 and 37 defined the notion of receiving confirmation that the second message M' as displayed corresponded to the first message M, these claims did not provide a basis for the causal link that the validation code was generated as a result of the user having confirmed that M' corresponded to M.

However, the board agrees with the proprietor that feature 1G is supported by the application documents as originally filed. In that respect, figure 1a, which is a flowchart of the steps performed by the devices to implement the invention (see page 12, lines 9 and 24) shows that the validation code is created by the validation device in step S118 following receipt by the validation device in step S116 of the acceptance of message M', as defined by feature 1G. Further, the sentence on page 14, lines 1 and 2, describes that step S116 of figure 1a represents approval by the user and step S118 generation of the validation code. The feature that the validation code must be created using information specific to the user is thus not present in the description of the invention according to figure 1a. Similarly, figures 2b and 2c show an implementation of the invention (see page 12, line 13) in which the validation code is generated in step S216 when the user approves M', as described in page 17, lines 7 to 9. Here too, the feature that the validation code must be created using information specific to the user is not present in the description of the invention according to figures 2b and 2c.

Therefore the board holds that claim 1 meets the requirements of Article 123(2) EPC.

3. Main request - Article 54 EPC

The opponent argued that D1 disclosed all the features of claim 1.

As to features 1A and 1B, the opponent argued in substance that in D1 the transaction confirmation code (figure 1, 142) sent from the second user unit (figure 1, 106) to the server (figure 1, 104) represented a signature on behalf of the user since it was a signature of the received transaction information (figure 1, 136) with a key (see the "seed" in paragraph [0019]) associated with the second user unit. Further, according to the opponent, this signature was created upon request from the user since it was generated in response to a transaction request sent from the user to the server. However, the board agrees with the proprietor that D1 discloses a method for verifying a transaction, e.g. a bank transaction, requested by a user from a server (see paragraph [0012]). During verification of the transaction, a signature (figure 1, 142) is generated but it is a signature to confirm the requested transaction and at the user's request. Thus, the signature 142 in figure 1 cannot be considered a signature on behalf of the user but rather is similar to the validation code defined in feature 1G of claim 1. Therefore, the board holds that features 1A and 1B are not disclosed in D1. Since D1 does not disclose a user's request to create a signature, feature 1G is also not disclosed in D1.

As to features 1C and 1H, the opponent held that D1 implicitly disclosed that the transaction information (figure 1, 136) was sent from the server to the second user device and (which could be considered as a validation challenge in the sense of claim 1) was encrypted with a secret shared with the user's second device. In that respect, the opponent first argued that, since D1 related to a bank transaction scheme, it was implicit that every communication between the server and the user devices had to be encrypted. However, the board notes that D1 teaches that the user requesting the bank transaction is authenticated by the server (see paragraph [0019]) and that the transaction confirmation code is cryptographically generated using a seed key provided by the server (see paragraph [0027]), but that D1 is completely silent about other cryptographic measures, although it does mention in paragraphs [0002] to [0004] that security is an important concern. The skilled person would thus not consider that the transaction information sent from the server to the second user device must be encrypted. Further, the opponent argued that D1 disclosed in paragraph [0022] that the server might send the validation challenge over a wi-fi connection to the second user device, which was per se an encrypted communication channel. However, the board agrees with the proprietor that a bank server is usually not directly connected to a user's wi-fi network, and that even if it were, the wi-fi password cannot be considered a shared secret in the accepted cryptographic sense since it may be distributed to devices other than the second user device. Therefore, the board holds that the skilled person would not consider it implicit that the transaction information sent from the server to the second user device in D1 is encrypted. Features 1C and 1G are thus not disclosed in D1.

For these reasons, the board holds that claim 1 of the main request (claims as granted) is novel over the disclosure of D1 (Article 54 EPC).

4. Main request - Article 56 EPC

4.1 D1 as closest prior art

4.1.1 Claim 1

The opponent argued that the subject-matter of claim 1 was not inventive over D1.

The subject-matter of claim 1 differs from D1 at least in that the request sent from the first user to the server is a request for signature of a message M and in that the validation challenge sent from the server to the second user device is encrypted with a shared secret.

The proprietor formulated the objective technical problem as how to ensure that the transaction in D1 takes place. The opponent argued that the two above-mentioned differences were juxtaposed in the claim, so that partial problems should be formulated. However, the board agrees with the proprietor that this argument was brought forward for the first time in oral proceedings and should not be admitted into the proceedings.

The board agrees with the proprietor that the skilled person would not get any hint from D1 to add a request for signature of a message to the process of D1. D1 is concerned with the verification of electronic business transactions (see paragraphs [0001] and [0012]) and does not mention the user requesting a signature on a message that it sends to the server. Contrary to what the opponent argued, a digital signature is not always required for a bank transaction such as the one described in D1. In D1, the transaction is secured by authenticating the user. Moreover, the process of D1 does not require encryption in the communication channel from the server to the second user device. On the contrary, paragraph [0024] explains in substance that if the non-encrypted transaction information is tampered with by a third party, the user simply cancels the transaction. Furthermore, the seed used for signing the transaction information (figure 1, 142) is not transmitted to the second user device together with the transaction information, such that encryption on the channel transmitting the transaction information is also not required to protect the seed from eavesdropping.

The board also agrees with the proprietor that the skilled person would not consider combining D1 with D8 and that even such a combination would not lead to the subject-matter of claim 1. Firstly, D1 is directed to the verification of a transaction requested by a user, whereas D8 deals with the digital signature of data upon request by a user. Secondly, D8 does not disclose several technical features of claim 1 of the present main request. In that respect, D8 discloses a method for signing a message by a signature server upon request by a user. In a first embodiment, a physical secure token (see figure 1, 190) receives a one-time password from an authentication server (figure 1, 120), distinct from the signature server, through a secure tunnel (see page 23) and the user enters the one-time password into their workstation (figure 1, 101), for transmission to the signature server (figure 1, 110). In a second embodiment of D8, the token is replaced by a mobile phone which receives the one-time password from the authentication server by SMS (see page 14, first full paragraph, and page 15, first full paragraph), which is by definition a non-encrypted communication channel. The one-time password received by the physical token or the mobile phone may be based on a hash of the message to be signed. However, a user is not able to identify the message from its hash value (see page 16, lines 4 to 6). In a single passage in page 18, lines 4 to 9, pointed out by the opponent, D8 mentions that one possible way of achieving WYSIWYS ("What You See Is What You Sign") is to let the certifying apparatus confirm essential parts of the data supplied by the user for certification. The board agrees with the proprietor that the skilled person would realise that only a certifying apparatus in the form of a mobile phone would be adapted to display and present to the user the essential part of the message to be signed. In that case however, according to D8, the message to be signed, or the essential parts of it, would be transmitted by SMS, and thus non-encrypted, from the authentication server to the mobile device, contrary to the requirements of features 1C, 1D and 1H of claim 1. More importantly, D8 does not disclose that the mobile phone generates and sends a validation code to the signature server following confirmation from the user, as required by feature 1G of claim 1. Rather, D8 teaches in all embodiments that a validation code is keyed into the user's workstation (figure 1, 101) for transmission to the signature server (see page 14, lines 17 to 27).

For these reasons, the board holds that the subject-matter of claim 1 involves an inventive step(Article 56 EPC) having regard to the disclosure of D1 as closest prior art, alone or in combination with D8.

4.1.2 Claim 4

The opponent argued that independent claim 4 was not inventive over D1.

The board agrees with the opponent that claim 4 does not require that the signature be generated "on behalf of a user", contrary to claim 1. Therefore, the signed transaction information in D1 (figure 1, 142), which is generated in both the second user device and the server, represents a signature which is created in response to a signature request from a signature creation device, namely the server (figure 1, 104). According to the opponent, the only difference between the subject-matter of claim 1 and D1 would thus be that the validation challenge, namely the transaction information in D1, is encrypted at the server and decrypted before being displayed to the user.

However, the board agrees with the proprietor that there are other differences. In D1, the transaction information which is presented to the user on the second unit for confirmation is the data which should be signed in the server. In contrast, the validation challenge in claim 4 is created using data, namely a second message M' based on the first message M, which is not the message M to be signed. Moreover, in D1 the signed transaction information (figure 1, 142) sent to the server is not a validation code confirming a request to create a signature, as required by claim 4, but is the requested signature itself. Furthermore, as argued by the proprietor in the written proceedings, the security of the signature in claim 4 is increased with respect to D1 since it is not generated in the validating device itself. The skilled person would not be prompted to implement the above-mentioned distinguishing features in the process of D1 relating to the creation of the signed transaction information.

For these reasons, the board holds that the subject-matter of claim 4 involves an inventive step (Article 56 EPC), having regard to D1.

4.2 D8 as closest prior art

The opponent argued that the subject-matter of claim 1 was not inventive over D8.

As stated in point 4.1.1 above, D8 does not disclose at least features 1C, 1D, 1G and 1H of claim 1, and D1 does not disclose at least features 1A, 1C and 1D of claim 1. Due to these numerous differences between D8, D1 and the subject-matter of claim 1 as detailed in point 4.1.1, the board agrees with the proprietor that the skilled person would not consider combining D8 with D1 and that, even if such a combination were contemplated, it would not lead to the subject-matter of claim 1.

Therefore, the board holds that the subject-matter of claim 1 involves an inventive step (Article 56 EPC) having regard to the disclosure of D8 as closest prior art, alone or in combination with D1.

5. Main request - Article 83 EPC

The opponent argued that, since the validation code was not defined in claim 1 as being specific to the user, this claim covered embodiments which did not achieve the object of the invention, namely to provide a secure electronic signature at the wilful act of the user as stated in paragraph [0002] of the patent. According to the opponent, an intruder could falsify the validation code, such that the security required would not be achieved, contrary to the requirements of Article 83 EPC.

However, the board agrees in substance with the proprietor that the feature that the validation challenge is decrypted by the second user device using a secret shared with the server implies that only the user who has requested the signature receives the validation challenge. This is sufficient to attest that the signature will be generated at the wilful act of the user.

Moreover, as stated in point 18 of the impugned decision, the absence in feature 1G of encryption of the validation code which could render the validation code specific to the user does not result in insufficiency of disclosure as to how a validation code to be transmitted to the server is issued in the second user device, but simply leads to transmission which is less secure than with encryption.

The board thus holds that the requirements of Article 83 EPC are met.

6. Conclusion

The grounds of opposition under Article 100(a), (b) and (c) EPC do not prejudice maintenance of the patent as granted.