T 0913/10 (Distinct administrator roles/ORACLE) 19-02-2014

The invention

1. The application generally relates to the security of da­ta­base systems. More specifically, it is con­cerned with measures to protect data stored in a database against unauthorized access while securing the possi­bility for the database administrator (DBA) to maintain the database.

1.1 According to the application it was known in the art to encrypt and decrypt sensitive data at the user's end and to store only encrypted data in the database. This made it impossible for a malevolent DBA to access the sensitive data in plain text but required that user applications had to be able to encrypt and decrypt information (see original application, p. 2, 2nd par.).

1.2 The application proposes to manage encryption within the database but to split the database administration tasks over different administrators so that access to sensitive data by any of them can be prevented.

1.3 Specifically, the application refers to a "database ad­ministra­tor" (DBA), a "security administrator", and a "user administrator" (hence­forth: SA and UA), and illus­trates their responsibilities in broad terms and by example: The DBA may be "performing services such as data back­up, data recovery, storage allocation, and the like", the SA "manages the encryption system" which "encryp­tion in­cludes, but is not limited to managing [a] key­file and specifying which columns of tables in [the] data­base ... are encrypted", and the UA "grants privi­leges to user[s] ... for accessing [the] data­base" (p. 5, lines 23-30).

1.4 The application discloses that "within the database system" the three administrators "are distinct roles" and that "[a] person selected for any one of these roles may not be selected to perform any of the other roles". Figure 1 of the application which, according to the description (p. 5, lines 7-8) illustrates a data­base system according to an embodiment of the invention depicts the three administrators with people icons. The application proposes that the three adminis­tra­tors "are not authorized users and, there­fore, are prevented from decrypting and receiving en­crypted data stored within the database" (p. 10, lines 6-9).

1.5 The application further discloses that the database contains metadata storing encryption parameters which include, inter alia, key identifiers referring to the key with which individual database columns are encryp­ted. The keys themselves and their key identifiers are held in a keyfile. Accor­ding to figure 1 the keyfile is part of the database system but accessible from the database server and separate from the data­base.

The prior art

2. Document D2 discloses a database system comprising se­veral databases, especially one called O-DB storing the actual data records in encrypted form and one called IAM-DB storing what is called a "data element protec­tion catalogue". In the O-DB, every data element is linked to a data element type - the column of a data­base (see the table on p. 5) - and the IAM-DB con­tains, for each indivi­dual such type, "one or more pro­tection attributes" which "state rules of how to pro­cess the corresponding data element values", espe­cially when "a user wants to read a certain data element", notably an "authorised" one (p. 4, lines 1-13; p. 5, line 29 - p. 6, line 16, p. 10, lines 3-8 and 15-32). For instance, the IAM-DB may define the "degree of en­cryp­tion" for individual data elements (p. 14, line 21 - p. 15, line 12). It is also dis­closed that the data ele­ment protec­tion cata­logue may make "callings to in­for­mation stored in some other place" (see p. 5, lines 8-12). It is dis­closed that the data element protection catalogue may itself be encrypted (see p. 7, lines 23-25) and it is further dis­closed that the IAM-DB may only be accessed by an "autho­rised IAM opera­tor", "i.e. a person respon­sible for security", and that O-DB and IAM-DB are pre­ferably physically se­pa­rated from each other (p. 10, lines 20-26, p. 20, lines 26-28).

The decision under appeal and the central contentious issue

3. The decision under appeal found that D2 disclosed all features of the then claimed matter except two (rea­sons 2.2). One of them related to a "message digest" which is no longer contained in any of the pre­sent in­dependent claims and therefore not pertinent for this appeal. Regarding the other, the decision sta­ted that D2 did not disclose "that all administra­tors are per­sons having not interchangeable roles" but it was found that this feature "is not of a technical nature" and that "[t]he distribution of roles to persons does not in­volve any technical consideration" and does not imply any "security consideration in the sense of a technical secure machine" (reasons 2.4).

3.1 In their analysis of D2, the examining division had made reference to "the pro­gram driving the database O-DB and processing requests from users" to establish that D2 disclosed the database administrator (see de­cision, reasons 1.1, lines 2-3). The appellant argued that the decision was incorrect in equating the "da­ta­base administrator" of claim 1 with a program (see e.g. grounds of appeal, point 5.1; see also the state­ment of Rick Wessman, penult. par.) and inconsistent for, ­at the same time, interpreting the security ad­mi­nistrator as a person (point 5.3).

3.2 During oral proceedings the appellant conceded that the allocation of people to "roles" within the database sys­tem might be considered a non-technical activity but insisted that roles were not persons but system-defined and that this implied that "roles [were] of a technical na­ture" (see e.g. grounds of appeal, points 6 and 6.2).

3.3 Independent of what precisely the examining divi­sion may have had in mind when relating the claimed DBA to a program it is clear that the decision turns on what the correct interpretation of the terms "role" and "ad­mi­nis­trator" in the claims and in view of the application as a whole is. The board agrees with the decision that the inventive step assessment of the claimed invention depends on this question. In the following, hence, the board will address this question first.

Construction of the claims

4. The board tends to agree with the appellant (see grounds of appeal, points 2-3) that the term "role" is used, in the context of computing systems such as ope­ra­­ting or database sys­tems, to denote a set of pri­vi­le­ges or per­missions which can be allocated to one or more users. For example, in operating systems it is known to have a privileged administrator role and a less-privi­leged user role. The appellant refers to this as the "conventional two-level hierarchy" (see grounds of appeal, e.g. point 8).

5. However, the board is of the opinion that there are other possible and reasonable interpretations of this term in the relevant technical field. Specifically, the term "role" is also used to describe privi­le­ges and respon­si­bi­­lities in an organisation. Hence, the term role as such also does not imply any system support by or in a compu­ting sys­tem, let alone any specific such support. For instance an IT expert may, as part of his job, take over the responsibility for database adminis­tration in a company and, in this sense, the "role" of database adminis­trator, or this administrator role may ro­tate amongst staff of the IT department. D3 supports this view by stating, in its first substantial para­graph, that "[t]he DBA role naturally divides into three major acti­vi­ties: ongoing maintenance of pro­duction data­ba­ses, ..., planning, design, and develop­ment of new da­ta­­bases applications, or major changes to existing applica­tions, ... and management of an organi­sation's data and metadata. One person may perform all three roles, but each is profoundly different".

5.1 The appellant concedes that the term "role" may be overloaded but insists that the invention clearly in­volves system support for the three administrator roles" (see the statement of Rick Wessman, 3rd and 5th pars.). In an attempt to establish this, the claims now state that the three administrators "are distinct roles within the database system".

5.2 At least as regards the main request, the board is not convinced that this language excludes the possibility of construing the adminis­tra­tor roles as referring to persons separate from the com­puting system, in view of the fact that figure 1 of the appli­cation depicts the administrators as persons and as part of the database system. Claim 1 of the 1st auxiliary request specifies that a request to retrieve data is not granted if it is received from "the data­base administrator" or "the se­cu­­rity adminis­tra­tor". For the purpose of this de­ci­sion the board accepts that the skilled person would read this as implying that the DBA and the SA have "com­puter iden­ti­ties" different from each other and from other users which the system can identify and distinguish. For the sake of argument, the board also accepts this understanding for claim 1 of the main request.

6. Beyond that, however, the independent claims remain vague.

6.1 They specify that the database system "is managed by" a DBA, that the users "are managed by" a UA, and that the keyfile "is managed by" a SA without specifying exactly what this "managing" implies. The claims however leave unde­fined not only the powers of the individual admini­s­­tra­tors, but also - and in particular - the limits of these powers.

6.2 The appellant argues that the privileges granted to the SA are taken away from the DBA. The skilled person would understand this from the conventional meaning of roles in database systems. Specifying this explicitly would require a "negative limitation" which was "gene­rally regarded as undesirable" by the EPO, as expressed in the Guidelines for Examination C-III 4.20, and it would be "pointless" - in view of the security problem addressed by the application - "to define separate roles within the sy­stem ... and then to give [one] all the privileges of the [other]" (see grounds of appeal, point 9.6).

6.3 The board disagrees with these arguments. Firstly, it is noted that overlapping privileges are not excluded by the existence of different system-defined roles: For instance the conventionally known system administrator has strictly more privileges than an ordinary user. Se­condly, the cited section in the Guidelines - apart from the fact that they do not bind the boards - does not express an outright prohibition of negative limi­ta­tions but allows them under certain conditions. Third­ly, the board disagrees that having overlapping roles would be "pointless": For example, manage­ment of the security features of a system might be gi­ven to an SA so as to relieve the DBA from this part of the work without requiring the DBA to give up this res­ponsibi­li­ty entirely. The SA role might thus serve to manage the workload without any intended security gain.

6.4 Finally, even the security concern does not, in the board's view, make entirely pointless a separation of respon­si­bilities without system enforcement. For in­stance, infor­ma­tion or access rights may be spread over different people with the obligation not to share them under a threat of disciplinary sanctions in case of a breach of these obligations, but compliance with these obligations may not be enforced by the system. Still short of enforcing the obligations, the system might automatically remind users about the limits of their rights and/or log user's actions so as to be able to prove any misconduct that may have happened.

7. In view of the foregoing the board adopts the interpre­ta­tion that the three administrators as claimed are de­fined by the different sets of tasks they have to per­form and the administrator roles correspond to some kind of distin­guishable computer identities. The pre­cise scope of the sets of tasks is not defined or whe­ther different sets of tasks overlap with each other, nor is it claimed how it may be en­forced, if at all, that no administrator exceeds its competences.

7.1 The board dismisses the appellant's suggestion that these terms must be interpreted in a more limited way based on a conventional use of the term in the art, stressing that the interpretation of the claims must be based on what is explicitly or implicitly disclosed in the application but cannot take into account what is merely obvious for the skilled person when reading the claims or the application.

7.2 Under these circumstances the board concludes that no­thing in the claims or in the description can dispel the reasonable possibility that the definition of tasks to be distributed over three administrators is merely an organisational and hence non-technical issue, not­withstanding that it relates to a technical entity such as a database system, and that the claims must hence be assessed further based on this interpretation.

Inventive step, Article 56 EPC 1973

Main request

8. The system of D2 allows the identification of at least an "authorized IAM operator" and "authorized users" (see p. 10, lines 7 and 25). No further operators or users are explicitly disclosed (difference 1). The IAM operator is "respon­sible for security" and in parti­cu­lar the IAM-DB containing the data element protection cata­logue. D2 does not mention a key list, what it might contain or where it might be stored. Especially, D2 does not disclose that the data element protection catalogue con­tains or re­lates to the keys used for decryption of the user data (difference 2).

8.1 Regarding the latter, difference 2, the board considers that de­cryp­tion is a necessary part of the processing required when a user requests to access an encrypted data element. Moreover, it is an obviously security-related operation. Noting further that the data element protection catalogue defines the "degree of encryp­tion" (see p. 14, line 26), the board deems it obvious as a matter of data organisation that the decryption keys are held in a keyfile in the database system which is contained in or accessible through the data element protection catalogue. The board considers it obvious, too, that the data element types refer to the keys by reference and hence that "key identifier[s]" are used and appear in the keyfile. Finally, encryption of a keyfile is considered obvious from the disclosure that the data element protection ca­­talogue may be encrypted as a whole.

8.2 Regarding the former, difference 1, the board notes that according to established jurisprudence of the boards of appeal, where the claim refers to an aim to be achieved in a non-technical field, this aim may le­gitimately appear in the formulation of the problem as part of the framework of the technical problem that is to be solved, in particular as a constraint that has to be met (see T 641/00, OJ EPO 2003, 352; headnote 2, 2nd sentence). The board thus considers that the objective technical problem addressed by difference 1 is to modify D2 so as to support the distribution of tasks amongst the DBA ("manage the database system"), the SA ("manage the keyfile") and the UA ("manage the users").

8.3 The appellant argued during oral proceedings that the required distinction between three administrator roles were incompatible with the system of D2. Since all processing of accessed user data had to be processed accor­­ding to the data element protection catalogue under the control of the IAM operator, it would be impossible to prevent the IAM operator from accessing sen­sitive user data (as explicitly required by the inde­pendent claims of the auxiliary request). The appellant also suggested that user management had to be construed as part of the data element protection according to D2 and could not easily be defined as a separate responsibili­ty within the system of D2.

8.4 The board disagrees. The determination of whether a user - or, indeed, the IAM operator - is authorized pre­cedes any data access and is thus naturally ­in­de­pen­dent of any data element protection. Also, an autho­rized IAM operator managing the data element protection catalogue is not auto­ma­tically an authorized user which would as such be allowed to access the data elements.

8.5 If the IAM operator of D2, as being the obvious "res­pon­­sible" for a "keyfile", is identified with the re­quired SA, this boils down to the requirement of having addi­tio­nal roles for the database management (beyond security issues, e.g. as regards the O-DB) and for user manage­ment. Since D2 can already distinguish between users and the IAM operator, the board deems that it would have been straight­for­ward for the skilled person to add support for the identification of fur­ther "admi­ni­s­trators" as required.

8.6 Therefore, the board comes to the conclusion that the subject matter of claim 1 according to the main request is an obvious implementation of an organisational require­ment within the system of D2 and thus lacks an inventive step in the sense of Article 56 EPC 1973.

1st auxiliary request

9. The independent claims of the auxiliary request make reference to a request to retrieve data from an encryp­ted column and specify that this request is granted in that decryption of the encrypted data is allowed if the request is from an authorized user but prevented if it is from "the database administrator" or the "security ad­mi­nistrator".

9.1 The primary effect of these features is to make sure that data is only decrypted by the pertinent authorized user which, per se, the board deems to be known from D2 (see p. 10, lines 3-8) but which is also obvious from the nature and purpose of encryption.

9.2 The system of D2 is capable of distinguishing between an autho­rized IAM operator and authorized users. While it is not disclosed in D2 how this distinction is made it would be an obvious option, in the board's view, to implement the IAM operator as a special "user" with the re­quired privileges. Moreover, the board considers it obvious that all three adminis­trators required by the above problem are mapped to different users within the system of D2. In the board's view it would be an obvi­ous option not to give authorization to these spe­cial users to read individual users' data if it were desired to prevent them to read such data.

9.3 The board therefore concludes that also claim 1 of the 1st auxiliary request lacks an inventive step over D2, Article 56 EPC 1973.

The further auxiliary request

10. Article 13 (1) RPBA gives the board discretion not to admit any amendment to a party's case after it has filed its grounds of appeal, in view of inter alia the complexity of the new subject-matter, the current state of the proceedings and the need for pro­ce­dural economy.

10.1 The further auxiliary request was not only filed after the grounds of appeal but indeed after several hours of dis­cussions about the main and 1st auxiliary request during the oral proceedings.

10.2 The incorporation of the additional features of claims 3 and 4 into claim 1 of the 1st auxiliary request is meant to specify in more detail the tasks of the SA and thus to clarify the intended meaning of "managing the keyfile". The board appreciates that this means to address the board's concern that the precise respon­si­bilities of the SA were not defined in the indepen­dent claims of the other requests (see above point 6.1).

10.3 However, the additional features only specify the tasks of the SA in positive terms but neither implies any limi­tation of the powers of the DBA nor any system support for enforcing the distribution of tasks between amongst the administrators (see also point 6.1). Prima facie at least the amendment is thus insufficient to change the board's interpretation that the claims do not imply such system support (see point 7) and hence to change the board's position on inventive step in this respect.

10.4 Since D2 does not disclose a keyfile, let alone its processing, the additional features appear not to be known from D2. It is a priori possible that at least some of these features, separately or in combination, might be found to establish an inventive step over D2 alone, even though this point was not specifically argued by the appellant. Even if so, however, it would prima facie appear this would have to be for reasons substantially different from those that were discussed during the appeal proceedings up to this point. More­over, even if it were found that the amended claim was inventive over D2 alone, it would then become ne­cessary to consider the available prior art documents other than D2. Thus, the further request constitutes a substantial change of the appellant's case which, if ad­mitted, would raise questions which the board deems to be inappropriately complex at this late stage of the procedure.

10.5 Thus the board exercises its discre­tion under Articles 13 (1) RPBA and does not admit the further auxiliary request.

11. There being no admissible and allowable request, the appeal has to be dismissed.