T 1948/15 (Mutual device authentication/FUJITSU) 30-01-2018

Reasons for the Decision

Decision in the appellant's absence

1. According to Article 15(3) RPBA, the board is not obliged to delay any step in the proceedings, including its decision, by reason only of the absence at the oral proceedings of any party duly summoned. Therefore, and likewise in accordance with Article 15(3) RPBA, the board here treats the appellant as relying only on its written case. The reasons given below are based on the board's preliminary opinion, while taking account of the appellant's submission dated 29 December 2017.

The invention

2. The application generally concerns the safety of computing transactions, in particular of electronic commerce transactions initiated from a ­­mobile telephone. The claims refer more generally to an "infor­ma­tion pro­cessing apparatus" which, as the description states, could also be any PC, fax machine, refrigerator or micro­­wave oven (see original application, page 1, lines 16-21).

2.1 When the information processing apparatus has initi­a­ted a "transaction" (e.g. after a customer presses a BUY button on the web page of an online shop, see figure 6 and page 45, lines 8-23), a "safety judg­ment subroutine" is entered, which checks a number of "creden­tials" be­fore the transaction is cleared. This safety judgment sub­routine involves three devices: an "informa­tion pro­cessing apparatus for pro­­cessing a trans­action" (e.g. the mobile telephone), a "first authen­tication appa­­ra­tus" (or "safety judgment center", see figure 1) and a "se­­cond authentication server" (or "cer­ti­­ficate autho­ri­ty", see figure 1).

2.2 The safety judgment subroutine validates three different credentials relating to the information processing apparatus or its user: bio­me­tric information of the user, a certificate authenticating the public key of the information processing apparatus, and the "safety posture" of the information processing apparatus. When the bio­metrics and the certificate are validated and the safe­ty posture is verified to be high enough in view of "the degree of security of the transaction informa­tion" (e.g. the higher the value of a transaction, the higher the required security level), the safety test is determined to be successful and the transaction is cleared. "Trans­action informa­tion", typically compri­sing "order information" such as price and product in­for­mation, will then be transmitted to the shop compu­ter (see figure 12, No. 122).

2.3 The biometric measurement of the user is made at the information processing apparatus: typically, a fingerprint is taken, but alternatives are also disclosed (see page 37, lines 6-19). This data is verified (as be­ing "pro­per") by the infor­ma­tion processing apparatus or one of the authenti­ca­tion apparatuses (see page 47, paragraph 2). Then, also at the infor­mation processing appa­ratus, "environment information" is "collected". This in­formation relates to the information processing apparatus itself (device name and version), to peripheral equip­ment connected to it ­and to software installed on it. The environment information is used to assess, at the "first authentication apparatus", the security level of the information processing appara­tus.

2.4 The transaction information (e.g. the order and payment information) is digitally signed (encryp­ted) using the secret key issued to the information processing apparatus. The first authen­tication apparatus validates the trans­action information by decrypting the signature with a public key issued to the information processing appar­atus. This public key is obtained from a certificate signed by the second authentication apparatus, i.e. the cer­tificate authority, which in turn is va­li­dated via the certificate authority's public key.

2.5 The application also discloses that, once the first authentication apparatus has successfully authenticated the information processing apparatus, the information processing apparatus may, in turn, have to authenticate the first authentication apparatus in essentially the same way (see figure 11 and 24 to 27, as well as page 3, lines 14-15, and page 76, especially lines 6-7).

The prior art

3. D1 discloses a network server establishing whether a workstation requesting a network service is a sufficiently "trusted" platform or not. Online shopping is not specifically mentioned, but in its background section D1 discusses "Web sites" which "attempt to verify the security of the client host [...] before allowing trans­actions from that host" and, more specifically, "bank­ing applications" (page 3, lines 7-10). The network ser­ver decides whe­ther to process the re­quest from the workstation "based on the user cre­den­tials and/or the workstation creden­tials" in view of a given "security policy" or which "level of network service" may alternatively "be supplied to the workstation" (see page 4, lines 25-29; page 6, paragraph 1).

3.1 When a workstation requests some service at a server, a "workstation assess­ment service" examines it so as to determine its "actual or potential vulnerabilities" or "security risks" (see page 11, lines 33-35; page 12, lines 33-35; page 15, lines 6-12). D1 does not detail the "workstation credentials" on which this assessment is based, but refers in general to "workstation integrity information" and "workstation security posture" (page 9, line 1; page 20, line 1). Based on the assessment, a "score" is compu­ted. In the system of D1, different "levels of service" are defined, each requiring the workstation to have at least a mini­mal score. That is, in view of the security score, a requested level of service may not be granted. Proposals may be made as to how to repair a detected vulnerability, and sometimes a suitable tool may be able do this automatically (page 15, lines 33-35; page 8, lines 2-3).

3.2 After the workstation credentials, the system assesses user credentials, such as passwords, biometrics and smart cards (page 2, lines 9-11 and last paragraph; page 3, lines 1-2). D1 teaches that checking user credentials only after successfully checking workstation credentials has the benefit of reducing the risk that user credentials are stolen (page 13, lines 27-30).

3.3 This process is referred to as an "extend[ed] log-in process" (abstract and page 7, lines 25-31). On the basis of the security assessment, the network service decides whether to process the service request. Optionally, it may decide to provide a "degraded level of service" which is con­­sistent with the perceived security vul­ne­ra­bility of the workstation (see page 4, first and pen­ultimate paragraphs; page 6, paragraph 1; page 19, line 33, to page 20, line 2).

The decision and the appeal

4. Apart from a few clarity objections made in a section entitled "Further Remarks" regarding the claim language, the decision under appeal turns on inventive step over D1.

5. The examining division summarised the differences between claim 1 of the then requests in the following three groups (reasons 1.2). In the claimed invention, but not in D1,

1. secure transmission was based on asymmetric encryption and a trusted third party,

2. the assessment of whether environment information is "proper" was made with reference to a database, and

3. not only was the information processing apparatus (mobile phone) authenticated by the first authentication apparatus (center server) but also vice versa and both in the equivalent ways.

The use of biometric authentication was not accepted as a further difference (reasons 2), following the decision in appeal case T 1121/10 relating to the earlier application of which this is a divisional application.

5.1 These differences were said to improve security, one way or another, but not to interact synergistically so that their inventive merit could be considered separately (reasons 1.3 and 1.4). It was then argued:

1. that the use of asymmetric encryption and PKI infrastructures according to difference 1 was "notorious" (reasons 1.5, paragraph 1),

2. that the use of a database according to difference 2 was an obvious choice (reasons 1.5, paragraph 2), and

3. that the decision "which entities to trust and which not to trust" and so which "requir[ed] authentica­tion" was a non-technical requirement; that there­fore the objective technical problem solved by this feature could legitimately be formulated as: "also [authenticating] the first authentication appara­tus" (see reasons 1.3, item 3); and that it was "the most straightforward choice" to implement this requirement by re-using the existing authentication mechanism (reasons 1.5, paragraphs 3 and 4).

5.2 The appellant did not challenge this grouping of differences or the assertion that differences 1 and 2 were obvious to the skilled person. Moreover, as regards difference 3, the appellant primarily challenged the assumption that the authentication of the center server was a given requirement but not that, if it was a given, the symmetric implementation itself was obvious (see the grounds of appeal, in particular page 4, last two paragraphs, and page 5, paragraphs 4 to 6). The appellant did, however, explain why two particular features of that implementation solved technical problems in a non-obvious manner (see the grounds of appeal, page 5, paragraph 9 et seq., page 7, penultimate paragraph et seq., and the discussion below).

Article 56 EPC 1973

Main request

6. In view of the above, the central contentious point in this appeal is whether mutual authentication of the two apparatuses would have been obvious to the skilled person in view of D2 and, if so, why.

7. The examining division referred to "the entity responsible for the security policy of the system in general" as the skilled person in question.

7.1 The appellant challenged this notion by saying that there was "no entity responsible for the security policy on the internet" (see grounds of appeal, page 5, paragraph 1).

7.2 However, the above-mentioned "system in general" does not refer to the Internet as a whole. Rather, both D1 and the invention disclose transaction systems which use a network such as the Internet as a platform. Obviously, in the board's view, a person or a team of persons is responsible for setting up such a transaction system, for instance an individual service provider such as a bank, possibly in co-operation with the providers of client software and hardware. The board agrees with the examining division that it is the task of these persons to identify and define security requirements of the system, and to design it so as to satisfy those requirements.

8. The examining division took the view that "stipulating which entities to trust" did "not require any technical knowledge but rather knowledge which is non-technical in nature, such as who has access to the entity resources and how trustworthy these people are, as well as how easy it would be for a malicious entity to gain access to the entity's resources (e.g. how secure is the building in which this entity is located)".

8.1 The board agrees with the appellant that there are reasons to be sceptical about these statements in their generality. While non-technical considerations may play a role - even a major one - in determining which parties to trust, the board is unable to see why an assessment of how well a system's resources are protected against a malicious entity is not a technical issue. The invention proposes that a transaction should be permitted only if, inter alia, "environment information" about the software or hardware constitu­ting the first authentication apparatus is found to be "proper". Again, even acknowledging that the claims do not specify how that decision is made in an individual case, the board is unable to see why the fact that the software and hardware equipment of the center server is security-relevant is not a technical issue.

8.2 The board therefore agrees with the appellant that the claimed mutual authentication is a technical feature rather than a non-technical requirement of the claimed invention, and it accepts that the claimed invention solves the objective technical problem proposed by the appellant (see the decision under appeal, page 12, paragraph 3): how to improve the security of the system of D1.

8.3 The appellant correctly observes that D1 does not disclose or suggest the need to address possible vulnerabilities of the server. It takes this line to argue that D1 too does not motivate the skilled person to consider authenticating the server (see grounds of appeal, page 5, paragraph 6). The board takes this argument to mean that the skilled person, setting out to solve the above-mentioned problem, could, but would not, consider improving security in the claimed manner.

8.4 However, the board considers that security architects do not blindly try to "improve system security", but consider what potential vulnerabilities there are and address those.

8.5 If there were no actual or potential security problem with the servers, mutual authentication would be pointless. In fact, though, such security problems were known before the priority date of the present application. The board considers that this statement needs no documentary proof and made a statement to that effect in its preliminary opinion (see point 9.6), which the appellant did not challenge.

8.6 D1 discloses that sensitive data may be stolen when a workstation (i.e. a client computer) has been compromised (see page 3, paragraph 1). In principle, this risk is symmetric: for instance, malware running on a server might steal a client user's biometric data. While in many cases "servers" might be less prone to attacks than clients, the skilled person would be aware that this is not always the case. More specifically, the skilled person would have known at the priority date that any Internet node could be set up to run a "server program" so that the existence of a "network service" on the Internet did not allow any conclusion about the security of that service.

8.7 In that light the board takes the following view: The skilled person setting out to increase the security of the system of D1 would first assess the risks of that system. He would then realise, without exercising inventive skill, that servers might also be compromised and that therefore their security might have to be assessed, too. The board agrees with the examining division that, with this insight, it would have been obvious for the skilled person to task the "information processing apparatus" with authenticating the server in the same manner as it was known for the latter to authenticate the former.

9. The appellant explained that it was technically advanta­geous - in terms of security and time efficiency - if the "terminal" was authenticated before the "server", because "the terminal tend[ed] to have lower safety than the server" and because it was computationally more demanding to "confirm[] the safety of the ser­ver" (see grounds of appeal, e.g. paragraphs 1 and 11). The appellant also argued (see its letter of 29 December 2017, page 1, last paragraph) that "it would be clear to the skilled person in the art [...] that the first authentication apparatus has a larger hardware and software resources (and provides more functions) than the information processing apparatus", such that there would be "a clear distinction between the 'information processing apparatus' and the 'first authentication apparatus' as regards their relative security or the relative cost of establishing their security".

9.1 The board disagrees.

9.1.1 Firstly, the board doubts that, in general, terminals are less safe than servers and that it is computationally more demanding to confirm server safety. If, for example, the "information processing apparatus" is a preconfigured hardware token and the server runs on a private PC, it may well be argued that the former is less vulnerable than the latter.

9.1.2 And secondly, the board notes that the claims give no hint as to the "hardware and software resources" or the "functions" provided by the two apparatuses. Also, the amendment (to all present requests) whereby the transmission from the "second authentication apparatus [...] to [the] first authenticat[ion] apparatus" took place "when communicating with the first authentication apparatus" (see the appellant's letter of 29 December 2017, page 2, paragraph 2) does not add information in this regard.

9.1.3 The board thus concludes that the claims, even in the light of the description, do not allow any conclusion regarding the relative security, or the relative cost of establishing the security, of the two apparatuses.

9.2 Moreover, the board takes the view that the order of steps cannot be inventive. Firstly, since there are only three possibilities for the order of two authentication steps (A before B, B before A, or both in parallel), the skilled person would, without exercising inventive skill, select any of these alternatives after weighing up their relative advantages and disadvantages. Secondly, none of the advantages of the claimed order are discussed in the application, and, as just explained, no potential advantage of the claimed order can be derived from the relative security of the two apparatuses (see the appellant's letter of 29 December 2017, page 1, paragraph 2). And thirdly, the claimed efficiency advantage is relevant only if authentication fails, and it is thus immaterial for the typical and more frequent case where a transaction is eventually allowed.

9.3 Hence, the board does not accept that the claimed order of the authentication procedures establishes an inventive step over D1.

10. Thus, the appellant's submission of 29 December 2017 has not swayed the board's preliminary opinion that the independent claims of the main request do not comply with Article 56 EPC 1973.

Auxiliary request 1

11. The independent claims of the first auxiliary request specify that the information processing apparatus validates the biometric information and sends only a success flag to the first authentication apparatus (see the grounds of appeal, in particular page 3, paragraph 5, and page 7, penultimate paragraph; description page 46, lines 18-22, and figure 7, S73-S75 and S77).

11.1 Firstly, the board takes the view that sending a "success flag" is essentially redundant in this situation. In an equivalent manner, the information processing apparatus could terminate the entire process if (and only if) the biometric data could not be validated, and could dispense with the success flag altogether.

11.2 Secondly, it is considered obvious to store the biometric information at the device at which the user has provided it, and to validate it locally as well. Inter alia, there are known login procedures which rely on locally obtained biometric information and validate it locally, too (see also D2, page 2, lines 4-7).

11.3 The board thus considers that the features added to claim 1 of the auxiliary request do not change the inventive step assessment of the main request.

Auxiliary requests 2 and 3

12. The small clarifications made in the claims of the second and third auxiliary requests leave the substance of the claims unchanged. The inventive step assessment of the main and first auxiliary requests thus applies to these requests as well.