T 0741/11 (Transparent access to encrypted database columns/ORACLE) 17-09-2014

The invention

1. The application generally addresses the problem of fa­cilitating the handling of database systems with column-wise encrypted data (see original application, p. 2, lines 8-10). In such databases systems­ indivi­du­al columns may or may not be encrypted and, if they are, different encryption para­meters (e.g. hashing and en­cryption algorithms, encryption key) may be used for different columns (see original application, e.g. pars. 0042-0045).

1.1 Encryp­tion and decryption are handled in a "transpa­rent" manner with respect to "the application develo­per" or ­"the user" (par. 0006), ­­to "applications that access" the database (par. 0041) or to "the cli­ent" (par. 0027, present claim 1 of all requests). Trans­parency is specifi­cally disclosed to mean that a command accessing a database column need not reflect whether the column is encrypted or not and, even if so, need not contain explicit en­cryp­tion and decryption commands­­ (see also par. 0005). When execu­ting a command, the database ser­ver will determine the need for encryption and/or de­cryp­­tion and perform the ne­cessary operations auto­ma­tically.

1.2 The claimed invention according to all requests refers, in particular, to a "command state­ment" which the ser­ver receives from a client (fig. 1) and parses to cre­ate a parse tree. The server examines the parse tree to determine whether it refers to an en­cryp­ted database co­lumn and, if so, automatically "trans­form[s] ... ele­ments of the parse tree to include ... cryptogra­phic operators"; this transformation effec­tive­ly determines the database operation to be exe­cuted (see par. 0053 and fig. 2).

The prior art

2. The application discusses a prior art solution to the problem of providing transparent access to a column-wise encrypted database which is based on "views" and "triggers" (par. 0006). This solution is based on the idea of providing an unencrypted database "view" to "hide the cryptographic functions" from the user and the use of "triggers" so that an update to this view causes the data in the base table to be encrypted im­pli­citly. Dis­a­dvantages of this solution are discussed.

3. D2 refers to the problem of dealing with sensitive in­for­mation in a "[m]odern database system" (p. 1, line 16).

3.1 As a solu­tion, it discloses a database system in which encryption is handled "automatically and transparently to a user" (p. 2, lines 20-21). Specifically, if it is requested to store data in a database column which has been "de­sig­nated ... as an encrypted column", "the sys­tem" - i.e. the database server (p. 5, lines 7-9, fig. 1) - auto­matically en­crypts the data", using the appro­priate key retrieved from a key­file in the data­base sys­tem (p. 2, lines 21-26; p. 9, lines 7-18) and possi­bly based on further en­cryption pa­rameters such as en­cryption mode, key length, and inte­grity type retrieved from column "meta­data" (p. 3, lines 25-31). If it is reques­ted to re­trieve data from an encrypted database column, "the system allows the ... user to decrypt the encrypted data" using the appropri­ate key, provided the user is authorized accor­dingly (p. 2, lines 27-31; p. 9, line 20 - p. 10, line 9). D2 refers to "requests" which the database server "receives" from the clients but does not dis­close their specific form or format­s.

3.2 The focus in D2 lies on the protection of sensitive data against a malicious database administrator by distributing administration tasks across three distinct administrator "roles" (see p. 6, lines 1-3). Specifi­cally, it is disclosed that a "security adminis­tra­tor ... manages the encryption system through database server" by, inter alia, "specifying which columns in the database are encrypted" (see p. 5, lines 26-28 and fig. 1) and "select[ing] the mode of encryption" and "establishing encryption parameters" (p. 3, lines 3-4 and 25-28). It is disclosed that the administrators are not "authorized users" and thus "prevented from decryp­ting and receiving encrypted data" (p. 10, lines 6-9).

4. D3 is an excerpt of a standard textbook on databases relating to "query compila­tion" (p. 788, sec. 16.1, 1st sentence): It is dis­closed that a "text written in a language such as SQL" (sec. 16.1.1, 1st sentence), i.e. a database command, is parsed into a parse tree and then transformed into an "expression in relational al­gebra" (see par. below fig. 16.1). This expression, the "initial logical query plan", is fur­ther trans­formed so as to yield an "im­prove[d]" or "pre­ferred logical query plan" (loc. cit. and fig. 16.1).

D2 as a starting point for assessing inventive step.

5. The appellant argued that D2 was fundamentally diffe­rent from the claimed invention. These differences were, in fact, so significant that D2 should be con­si­dered as an accidental anticipation from a different field than that of the invention. D2 thus was unsui­table as a starting point for assessing inventive step of the present invention and, if used nonetheless, taught away from it.

5.1 Specifically, the appellant argued that D2 was "not a command-based system", whereas it was central for the invention to operate and transform database commands. The system of D2, so the argument, was a "simple re­quest based system in which a user [could] only store and retrieve data from a database" (see letter of 20 May 2014, point 3.8). The requests of D2 were not "commands" but only means to trigger one of two pre­programmed processes. In support for this interpre­ta­tion, the appellant referred, in particular, to figures 1, 6, and 7 of D2.

5.2 The appellant also argued that the "use of parsable commands [was] only known in systems directed towards providing user operating through a client with a high level of functionality" (see letter of 20 May 2014, point 3.9) whereas "[t]he purpose of D2 [was] to in­crease the security of the user's data" which came "at the expense of reduced functionality" (point 3.12). D2 thus directly taught the skilled person away from pro­vi­­ding increased functionality using parsable commands.

6. The board does not share this interpretation of D2.

6.1 It is conceded that the main focus of D2 is on database security. However, the security problem addressed in D2 is formulated in the context of unspecified "[m]odern database systems". Also, it is not disclosed that the proposed solution requires any changes in the database architecture beyond, obviously, the distribution and separation of privileges amongst the roles of the admi­nistrators and users. Nor does D2, in the board's view, imply that such changes were required.

6.2 D2 discusses database access only in generic terms by talking about requests to "store" and "receive data". In the board's understanding this does not, however, limit the ways in which requests may be expressed: af­ter all, storing and receiving data are the funda­men­tal operations on any database (i.e. wri­ting or rea­ding). A more complex operation such as updating the values in a column by multiplying them by a constant value can easily be reduced to ("receiving") reading data from the data­base, processing it, and writing it back to ("storing" it in) the database. The brevity of D2 re­gar­ding the form of the requests and the interface with which they are issued are, in the board's understan­ding, due to the fact that they are not rele­vant in D2 for ­the se­cu­ri­ty issue at stake and for presenting the proposed so­lution. While this brevity obviously leaves undefined many features of the database system, the board does not agree that it establishes a prejudice against spe­cific forms of requests or interfaces.

6.3 Specifically, the board disagrees that D2 teaches away from using the proposed security architecture in a database system using SQL, i.e. an expressive "command-based" system in the appellant's terms.

7. The appellant argues that other documents cited in the European or the International phase should have been used instead of D2 as a starting point for assessing the inventive step. These documents corresponded to the prior art based on "triggers" and "views" as discussed in the application (and summarized above, point 2) and on which the invention is meant to improve. These do­cu­ments were neither specifically discussed during the appeal procedure, nor does the board consider this to be necessary: since the board deems D2 to be a suitable starting point for assessing inventive step and is in a position to come to a conclusion on inventive step in view of D2, it may be left open whether there are other, even possibly more suitable starting points for this assessment.

Inventive step, Article 56 EPC 1973

8. The independent claims refers to "commands" which are "parsed". The skilled person would understand this to imply that the commands are expressions in some sort of database query language. D2 refers to "requests" to store and to retrieve data but leaves open how these requests are generated and in which form. Moreover, as the appellant points out, D2 is silent as to "whether or not the client has to expli­cit­ly spe­cify the crypto­gra­phic functions of the server on sto­ring or retrie­ving data from the data­base" (see grounds of appeal, reasons 6.7).

8.1 Claim 1 of the main request thus differs from D2 by the following features:

a) Database requests are expressed as "commands" which can be - and are - parsed, and

b) the parse trees (or rather: elements thereof) ob­tained from a database command are "automati­cally transform[ed] ... to include one or more crypto­gra­phic operators" such as "a decrypt operator [or] an encrypt operator".

8.2 The board agrees with the appellant that these features can be seen to solve the problem of "how to facilitate client interaction with a column-by-column encrypted database" (see grounds of appeal, point 7.7).

Re. difference a)

9. The board considers that it was common practice well be­fore the present priority date to interact with da­ta­bases via "requests" in the form of "commands" in some database query lan­guage such as SQL. It was further commonly known that such commands had to be parsed (see also the textbook excerpt D3 which establishes this). During oral proceedings, the appellant confirmed that such command-based database systems were conventional at the time. As argued above, however, the board does not share the appellant's opinion that D2 is incompa­tible with such a command-based system. To the contra­ry, the board consi­ders it to be an entirely ob­vious option for the data­base in D2 to be command-based.

Re. difference b)

10. The board notes that D3 also dis­clo­ses that the parse tree is checked and that, in that process, "each attri­bute" is "resolve[d]" by "atta­ching it to the relation to which it refers" (see p. 794, point 2, lines 6-9). In the board's view, this does not unambiguously dis­close a "transfor­ma­tion" of the parse tree to include that additional information. The trans­formations actu­ally disclosed are from parse trees into expressions of rela­­tio­nal algebra and between such ex­pressions (p. 795, 16.2). D3 thus does not dis­close diffe­­rence b).

10.1 With regard to D2, the board is not con­vinced by the appellant's argument that "from reading D2 the skilled person would undoubtedly think that the cryptographic functions should be explicitly included in the cli­ent ... re­quests". Specifically, the passage cited by the appellant referring to "a user ha[ving] designated the column as an encrypted column" does not im­ply that the client request has to "include a desig­na­tion of en­cryption" (see grounds of appeal, point 6.8). As argued in the summons (point 11), the board tends to consider that the skilled person would understand D2 to mean that cryptogra­phic functions are not part of the data­base storage and retrieval requests issued by the client.

10.2 However, arguendo, let it be assumed to the appellant's benefit, that D2 taught or suggested that the crypto­gra­phic functions were explicitly specified in the da­ta­base requests. In this case the user would have to keep track of which database columns are encrypted and how, and which are not. More­over, the required commands would be com­plex to write and difficult to read: See, for instance, the command disclosed in the application (p. 9, lines 10-13). In this situation the board con­siders it to be an ob­vious de­sirable to simplify the users' task by relie­ving them from having to specify the cryptographic operators explicitly.

10.3 An obvious and common solution to this type of problem is to change the semantics of the commands in question by leaving certain parameters implicit. In the present case one would, for example, define a command rea­ding "store v in column c" to mean "if c is an encrypted column then encrypt v and store the result in c, other­wise store v directly". The board considers that modify­ing the semantics of commands in itself does not solve any technical problem (see T 1539/09, headnote).

10.4 Beyond that, the board deems it to be common practice in the art of programming languages to simplify commands by lea­ving certain parameters impli­cit and have the com­pi­ler add the missing information. For illustration note that in C the required type conver­sion from an integer (say, 1) to a floating point num­ber (say, 2.5) in a mixed-type addition such as 1+2.5 is left implicit and gene­rated "transparently" by the compiler ("implicit type conversion").

10.5 If, as is the case according to D2, the cryptographic parameters are known to the server - in a keyfile or column metadata - it would have been obvious to the skilled person that they can be retrieved automatically if nee­ded and thus that they need not be specified exp­li­cit­ly in commands.

11. It remains to be considered whether it would have been obvious for the skilled person to implement, in the system of D2, the handling of commands which did not specify the cryptographic operations but left it for the server to add, in the manner claimed.

11.1 In a database command the column names are what is called "identifiers" in programming language termino­logy. The parser performing a syntactic analy­sis of the given command recognizes identifier names. However, fur­­ther informa­tion about an identifier often cannot be determined during parsing: for instance the type of an identifier may have been declared in a different command. The same applies to the names of database columns: different databases may have columns with the same name (see also D3, p. 793 ff., sec. 16.1.3, esp. point 2, lines 6-9), and whether a column is encrypted is part of the database defini­tion rather than the command. As a consequence, iden­ti­fiers are commonly processed after parsing in a phase referred to as semantic analysis. During this phase, the parse tree is commonly annotated ("attribu­ted", "de­corated") with the derived semantic informa­tion. The board considers that this "automa­ti­cally trans­form[s] elements of the parse tree" as claimed.

11.2 Whether or not a database column identifier refers to an encrypted database column or not, and if so, what cryptographic parameters are to be used, are, in the board's view, obvious semantic "attributes" of column identifiers which can, as the skilled person would have noted, naturally be determined during the semantic analysis just described.

12. The appellant argued that "although these techniques may be generally known for the given example of an arithmetic compiler, there is no teaching that would lead the skilled person to implement such techniques in the specific field of encryption" (see letter of 20 May 2014, point 3.11). The board points out, how­ever, that the example was expressly given as a mere illus­trat­ion for a technique which the board deems to belong to the general knowledge in compiler technology. Par­sing and semantic analysis of commands is largely a matter of command and language structure and is independent of whether the operations represented by the commands re­late to arithmetic, database management or encryp­tion. During oral proceedings, the board stressed that it con­sidered the claimed technique of transforming a parse tree to belong to the common knowledge in the art of parsing and compiling, and the appellant did not challenge the board on this point.

13. In summary, the board comes to the conclusion that the subject matter of claim 1 of the main request lacks an inventive step, Article 56 EPC 1973, over D2 in view of common know­ledge in the field of parsing and compilation.

First auxiliary request

14. The independent claims of the auxiliary request com­prise the additional features that the server deter­mines, based on the parse tree, whether the command "in­cludes an explicit command to change an encryption algorithm for the column" and, if so, decrypts the column using "a previous algorithm" and encrypts it using the new encryption algorithm.

14.1 In the board's understanding these features primarily express the requirement that a command to change the encryption algorithm for a column is provided at all. The last two lines of claim 1 (or, correspondingly, the last four lines of claim 9) merely state that this command is executed. That prior to execution this command is "determined" by "examining the parse tree" is considered to be common practice in the art.

14.2 The board considers it obvious that the security ad­mi­nis­trator of D2, responsible for selecting mode and para­me­ters of encryp­tion (p. 3, lines 3-4 and 25-29), may have to change the encryption algorithm for a co­lumn for various rea­sons, for instance if the security of an encryption algorithm has been compromised.

14.3 The appellant argued that D2 disclosed a strict sepa­ration of tasks between users and the security admini­strator and that the security administrator performed its duties directly at the server and not through a cli­ent. It would therefore not be obvious from D2 to provide a command for changing the encryption algo­rithm. More­over, the appellant argued that the term "client" in the present application was disclosed as synonymous with "user" which would clearly exclude the security ad­ministrator. Claim 1 thus had to be con­strued as equipping the end user with the capability of changing the encryption algorithm which was speci­fically discou­raged in D2 in which the management of encryption was the exclusive task of the security admi­nistrator.

14.4 The board disagrees. Firstly, it is noted that the term "client" is expli­cit­ly disclosed in the application to be a "node on a net­­work" (par. 0024) and thus does not denote the "user" but a terminal from which the user accesses the system. Secondly, the system administrator according to D2 is also a user: D2 dis­closes that the security ad­mi­ni­stra­tor may issue re­quests like a normal user even though it will be found not to be authorized for rea­ding en­crypted data (p. 10, lines 5-9). Thirdly, D2 lacks any detail as to how - i.e. via which kind of interface - the security administrator performs its primary duties.

14.5 The board considers it as an obvious option to provide commands also for the tasks of a security administrator and sees nothing in D2 that would prohibit or just discou­rage this: the separation of powers according to D2 could be implemented by simply not authorizing the exe­cu­tion of the command for changing the encryption al­go­rithm when issued by an end user; a suitable autho­ri­­zation me­chanism is already available in D2 (loc. cit. and p. 9, lines 25-26).

14.6 Furthermore, the board considers it obvious to enable the security administrator to perform its tasks not only directly at the server but also from a client terminal, independent of whether the terminal is ex­clu­sive to the security administrator or shared with end users.

14.7 Thus the board comes to conclusion that the additional feature of the first auxiliary request consti­tutes the ob­vi­ous implementation of an obvious new command. Hence, the independent claims of the auxil­ia­­ry request also lack an inventive step, Article 56 EPC 1973.

Second auxiliary request

15. The appellant argued that the amendments were origi­nally disclosed in the application on page 6, lines 5-7 and 24-25, page 7, line 28 - page 8 line 24 and in figures 1 and 2.

15.1 The board is not convinced that these passages disclose the last two of these amendments, namely the new features

F) "sending the transformed command to a database in­terface of the server" and

G) "the database interface using the transformed command to perform the operations of" decryp­ting ... and encrypting,

nor is it aware of any other basis in the original application.

15.2 These features are meant to clarify that the command parser and transformer running on the server act as "middle-ware" between two interfaces, a "command interface" and a "database interface" so that the database interface need not be changed in order to make transparent to the user how encryption of database content is handled. This architecture was depicted in figure 2.

15.3 The board considers that the terms "database" and "da­tabase interface" are, in themselves, rather broad terms. The database could refer to the mere collection of data or to the data collection in combination with pertinent software for database access and/or adminis­tra­tion. Likewise, the database interface could merely enable access to the raw data or also to further support functionality.

15.4 The board notes that the application uses the term "da­tabase interface" only in relation to figure 2 which depicts it with reference number 210 (pars. 0028 and 0032). It does not however define the "database inter­face" nor does it, in particular, dis­close what the da­tabase interface is arranged to do or how: All it says is that "[d]atabase interface 102 in­cludes me­chanisms for accessing database 106", which "accessing opera­tions can include retrieving data from database 106 and storing or updating data within database" (par. 0032). Hence, the board considers that feature G, accor­ding to which the database interface performs de­cryption and encryption, is not disclosed in the appli­cation as originally filed.

15.5 Moreover, figure 2 contains an arrow pointing from the command transformer 206 to the database interface 102 but the meaning of this arrow is nowhere specifically discussed (see pars. 0028-0032). While it appears to relate to some kind of data flow between the command transformer and the database interface, it remains open whether the entire "transformed command" is actually transferred to the database interface, as feature F requires, or only relevant parts of it. Therefore, also feature F is not, in the board's judgment, disclosed in the application as originally filed.

15.6 As a consequence, claim 1 of the second auxiliary re­quest does not conform with Article 123 (2) EPC.

15.7 In passing, the board notes that the precise se­pa­ra­tion of tasks between the server and the database interface appears not to be disclosed in the application as filed and for that reason the appellant's "middle-ware" argument (see point 15.2) fails not only for present claim 1 but appears not to have a basis in the entire application as originally filed.

16. In response to this objection, the appellant requested the board to consider, as a potential further request, a claim corresponding to claim 1 of the second auxilia­ry request without the additional features F and G.

16.1 The board is satisfied that a so-amended claim does not go beyond the appli­cation as originally filed, Article 123 (2) EPC.

16.2 However, the remaining additions are insufficient to change the board's assessment of claim 1 as to the inventive step. The board con­siders it implicitly disclosed in D2 that the client request is received at the server via a suitable in­ter­face, i.e. a "client in­terface at" the ser­ver. That the request is received in the form of a "command", which is "parsed" and then "transformed" has already been dis­cussed above with regard to the main request and found not to be inventive over D2. Finally, the specifi­cally claimed commands "for performing reference ope­ra­tions on the database and update operations" are consi­dered to be common-place operations which the skilled person would support in a conventional database as a matter of course and which, as argued above, do not conflict with the security architecture of D2.

16.3 Therefore, also claim 1 of the second auxiliary re­quest without feature F and G lacks an inventive step over D2, Article 56 EPC 1973.

Third auxiliary request (filed as "second" on 20 May 2014)

17. Claim 1 of the third auxiliary request incorporates into claim 1 of the first auxiliary request the features of original claim 2.

17.1 The appellant argued that the new features estab­lished that both kinds of commands could be executed on re­quest from "the same source" (see letter of 20 May 2014, point 7.1) or indeed, as the appellant clari­fied during oral procee­dings, from the same person. This aspect was relevant, so the argument, because D2 dis­closed (loc. cit.) that the selection of encryption algorithm and parameters was the exclusive right of the security administrator who, however, was not allowed to access encrypted database content, so that D2 speci­fically taught away from both commands coming "from the same source".

17.2 The board considers it to be clear - also in view of original claims 1 and 2 - that "the database operation" mentioned by the added features refers to the trans­formed database access command rather than the command to change the encryption.

17.3 The board also notes that the wording of amended claim 1 does not imply there to be a single complex command which contains subcommands for database access and for changing the encryption, let alone that both these ope­rations may actually be authorized and executed in re­sponse to a single such complex command. In response to the board's question during oral proceedings, the appellant con­firmed this interpretation.

17.4 The board thus considers that claim 1 only establishes that the server is equipped to handle both kinds of commands but does not exclude that they are issued from different persons at possibly different clients at different points in time. In this respect, the board disagrees with the appellant and considers that the amendment does not add anything substantial to claim 1 of the first auxiliary request.

17.5 As a consequence, claim 1 of the third auxiliary re­quest also lacks an inventive step, Article 56 EPC 1973.

Remark

18. A central argument by the appellant was that the inven­tion contradicted the security architecture of D2 be­cause it allowed end users to access encrypted database content and to perform security management functions. This argument already failed in the present case be­cause the claims, in the board's judgment, are con­sis­tent with ­­­the security architecture of D2, i.e. access and security management functions being assigned to different roles. Moreover, the appellant was unable to propose, and the board equally did not see, any potential amendment of the claims which would have a basis in the application as filed and would not be consistent with the security architecture of D2. Therefore, it was not and did not have to be decided what impact on the inventive step analysis the alleged deviation from the security architecture of D2 might have had.