T 1512/10 (Digital DNA / LOGIN PEOPLE) 29-10-2015
Download and more information:
Method of validating a trusted computer system
Novelty - (yes)
Inventive step - (yes)
I. The appeal is against a decision to refuse European patent application 04 368 072.7 "according to the state of the file", as foreseen under the Guidelines for Examination at the EPO in the applicable version dated April 2009, C-VI, 4.5. For its reasons the decision exclusively referred to the communication of the examining division dated 14.10.2009, according to which the independent claim 1 was not clear (Article 84 EPC 1973) and the subject-matter of claims 1 and 12 was not novel (Article 54 EPC 1973). The following prior art document was cited during the first instance procedure:
D1 = EP 1 182 534 A2
II. A notice of appeal was received on 03.05.2010, the appeal fee being paid on the same day. A statement of the grounds of the appeal was received on 03.07.2010.
III. The appellant requested that the decision under appeal be set aside and a patent granted on the basis of the claims that were the object of the refusal.
IV. The board issued a summons to oral proceedings, as it considered such proceedings to be expedient (Article 116(1) EPC). In an annex to the summons, the board set out its preliminary, negative opinion on the appeal.
V. On 28.09.2015, the appellant filed an auxiliary request. In the course of the oral proceedings, the appellant filed several new requests. The claim set filed during the oral proceedings for the final single request, replacing all previous requests, contains claims numbered 1-11.
The further text on file is:
description pages
1, 2 and 5-23 as originally filed
3 and 4 as received on 18.09.2007
drawing sheets 1-5 as originally filed.
VI. The appellant requests that the decision under appeal be set aside and a patent be granted on the basis of claim 1 of the last request filed during the oral proceedings on 29.10.2015, with dependent claims, description and drawings to be adapted.
VII. Claim 1 reads as follows:
Process for securing the access to the resources of an Information Handling System (I.H.S.), said I.H.S. comprising a set of hardware components including information representative of the manufacturer, model and serial number of said hardware components, said I.H.S. further comprising an Operating System (O.S.} used for running applications and providing an Application Programming Interface (API} for accessing said information representative of the manufacturer, model and serial number of said hardware components, said process involving the steps of initiating a preliminary qualification process based on the detection of the components of said system, followed by the generation of a reference qualification signature;
a validation process subsequent to said qualification process comprising, prior to any transaction with or access to a remote server, a further detection of the components for the purpose of generating a new signature to be compared with said reference qualification signature,
characterized in that
said qualification process involves the steps of:
- detecting a set of components present within said system by using said Application Programming Interface for accessing said information representative of the manufacturer, model and serial number of said hardware components, and
- generating for each hardware component a Component Identification Data (CID) by concatenating said information representative of the manufacturer, model and said serial number, so as to complete a system qualification file (SQF) listing said components with corresponding Component Identification Data (CID);
- encrypting said system qualification file in order to create a reference qualification signature (RQS);
- transmitting and storing said reference qualification signature (RQS) on said remote server;
said validation process involves
- performing a new identification and detection of the hardware components and a subsequent generation of a new system qualification file;
- encrypting said new system qualification file in order to generate a checking signature;
- comparing said checking signature with said reference qualification signature (RQS) stored within said remote server and, in response to said comparison, allowing or denying access to said transaction with or said access to said remote server.
VIII. At the end of the oral proceedings, the chairman announced the board's decision.
1. The procedure before the first instance
1.1 The appealed decision is a decision "according to the state of the file", which for its reasons exclusively refers to the communication of the examining division dated 14.10.2009. The board holds that the reasoning in that communication is complete and the examining division therefore did not commit a procedural violation by basing its decision entirely on that communication. It is noted that this fact has not been contested by the appellant.
1.2 The appellant has also not contested that he effectively did request a decision "according to the state of the file" as foreseen under the Guidelines for Examination at the EPO dated April 2009, C-VI, 4.5, even if in his letter received on 26.01.2010, the appellant had requested a decision "based on the lastly filed set of claims", which is not one of the formulations mentioned in said passage of the Guidelines. The board from its side considers that the appellant's request was unambiguous.
2. Clarity; Article 84 EPC 1973
The board had raised several clarity issues in its summons to oral proceedings but is satisfied that the issues have been resolved in the present amended claim 1 because of the deletion of the wording responsible for the clarity objections, viz. "Component Identification Data, based on the information used by an operating system (OS) for installing the drivers corresponding to said components".
3. Closest prior art
3.1 In the reasons for the appealed decision, D1 is considered to be the closest prior art. This document discloses (see paragraphs 11-14, 19-20, 33-42, 66-69 and 84-86) a computer apparatus comprising a receiver for receiving an integrity metric for a computer entity via a trusted device, i.e. a dedicated piece of hardware, associated with the computer entity, the integrity metric having values for a plurality of characteristics associated with the computer entity, and a controller for assigning a trust level to the computer entity from a plurality of trust levels, wherein the assigned trust level is based upon the value of at least one of the characteristics of the received integrity metric.
3.2 The board considers D1 not to be a suitable starting point for the assessment of inventive step, mainly because the assignment of a trust level to the computer apparatus takes place at boot time, before the operating system is loaded into memory (see e.g. D1, paragraphs 26 and 30). This obviously has the advantage (see also D1, par. 35, last sentence) that the process will be unaffected by a corruption of the operating system, e.g. due to a virus infection. Even if a skilled person were willing to give up the security offered by a dedicated device, e.g. to simplify the system or to save costs, it is more likely that he or she would opt for one of the alternatives mentioned in D1 itself (par. 29), i.e. (1) splitting the functions of the trusted device into multiple devices on the motherboard, (2) integrating those functions into one or more of the existing standard devices of the platform, e.g. the main processor, or (3) implementing the trusted device as a removable device (a "dongle").
3.3 The skilled person will not naturally be tempted to implement a solution that does not rely on a trusted hardware device but instead uses Application Programming Interface (API) calls offered by the operating system, not only (1) because of the possibility that the operating system may get infected by malware but also (2) because a reliance on API calls makes the security dependent on the use of one or more specific operating systems specially designed to provide said API calls.
3.4 Even if a skilled person were to envisage a solution on the basis of API calls, he or she would likely find that no available operating system offers API calls that provide a record of the history of a component or offers an API call based on such history (see D1, par. 35). This means that the skilled person would need to modify an existing operating system, which would not be an easy task. The skilled person would therefore have even less incentive to pursue this avenue.
3.5 The board therefore considers that D1 is too remote from the subject-matter of the present claim 1 even to serve as a suitable starting point for the assessment of inventive step.
3.6 Instead, as stated in the summons (7.2), the board considers that common general knowledge constitutes very relevant prior art in the present case. The idea of uniquely identifying a computer system by means of an identification of its components (called "digital DNA" by the appellant) was indeed well known before the priority date of the present application. It is not merely disclosed in specialised literature such as D1 but it is for example well known that Microsoft Windows XP, one of the operating systems which was installed most frequently in 2001, requires a product re-activation each time when the system's hardware components are significantly changed, as determined by a change in the so-called "hardware hash component values".
4. Novelty and inventive step; Articles 54 and 56 EPC 1973
4.1 The essential difference between the above mentioned well known re-activation process and the subject-matter of claim 1 is that Windows XP only checks at login time whether the hardware on which it runs has substantially changed, whereas in the claimed process validation takes place prior to any transaction with or access to a remote server.
4.2 This difference could conceivably solve the problem of guaranteeing to Windows XP that transactions with a remote server cannot take place after a substantial hardware change. However, exchanging any of the components which enter into the calculation of the hardware hash in Windows XP would require switching off the PC and restarting it after the change has taken place. This means that hardware changes only need to be checked by Windows XP after the PC has started and the user has logged in (either explicitly or automatically) in Windows. No reason exists for the skilled person to perform such a check more frequently. In particular, for the purpose of validating a Windows XP license, there is no need to detect a hardware change prior to each transaction with or access to a remote server. One therefore needs to look for a different problem that is solved by the distinguishing features of claim 1.
4.3 The board considers that there are in fact two problems solved by the features distinguishing the subject-matter of claim 1 from said well known prior art. The first problem, solved by the feature according to which validation takes place prior to any transaction with or access to a remote server, is to introduce access control to the remote server instead of or in addition to license validation.
4.4 The second problem, solved by using API calls for accessing information representative of the manufacturer, model and serial number of the hardware components, is to simplify detection of hardware changes.
4.5 For the purpose of assessing inventive step, it is sufficient in the present case to look at the first problem. According to the board, this problem will not occur naturally to a skilled person looking at a system which detects hardware changes for the purpose of preventing abuse of a software license. As a rule, such a person would rather try to improve copyright-protection mechanisms. In this respect, having a remote server detect hardware changes instead of the copyright-protected software would actually be a step backward, since the license validation would fail if the server was unavailable. And having the remote server detect hardware changes in addition to the copyright-protected software, in order to provide secure access control to the remote server, would not come to the skilled person's mind, as it is quite unrelated to the product activation of Windows XP, which is a pure copyright protection mechanism.
4.6 There is therefore no reason why the skilled person would adapt said well known process in such a way that it corresponds to the subject-matter of the present claim 1.
4.7 The subject-matter of the present claim 1 is consequently new and inventive (Articles 54 and 56 EPC 1973).
For these reasons it is decided that:
1. The decision under appeal is set aside.
2. The case is remitted to the examining division with the order to grant a European patent with claim 1 dated 29.10.2015 and dependent claims, description and drawings to be adapted.