T 2146/09 (Automatic database repair/MICROSOFT TECHNOLOGY) 22-09-2015

1. The appeal is admissible.

Main request

2. It is pointed out in paragraph [0004] of the published application that "[t]raditionally maintenance and repair of a databases [sic] has fallen to database managers and the like having a well-developed skill set and deep knowledge of database systems, or at least to individuals who are familiar with and regularly use database systems - by and large persons relatively skilled with regard to database technologies. On the other hand, typical consumer and business end-users of operating systems and application programs rarely work with databases and are largely ill-equipped to deal with database maintenance and repair issues".

Hence, (see paragraph [0005]), a database-implemented file system for an operating system "creates a scenario where these lesser-skilled end-users will be faced with database maintenance and repair issues they will largely be unable to resolve.

Thus a business/consumer database-implemented operating system file system, or 'database file system' (DBFS) for short, must be able to detect corruptions and recover its databases to a transactionally consistent state and, in the cases of unrecoverable data loss, the DBFS must then guarantee data consistency at the level atomic change units to said data are maintained (i.e., at the 'item' level for an item-based DBFS)" (emphasis added).

2.1 The present application seeks to solve the above problem by providing a data reliability system (DRS) for a DBFS which can respond to and correct data corruptions "automatically and with little or no direct involvement by the end-user" (cf. paragraph [0007] of the published application).

2.2 In particular, claim 1 according to the main request is concerned with an automated data reliability system, DRS, for a database-implemented operating system file system, DBFS. It comprises the following features itemised by the Board:

(a) the DBFS is logically coupled to a DBFS store comprising a plurality of pages;

the DRS comprises means for:

(b) responding to a set of data corruptions and attempting a first level of recovery to repair a corrupted page at a page level for all page types,

(i) wherein if said corrupted page exists in the most recent snapshot of said DBFS store and if a valid transaction log is available, the corrupted page is found and copied from said snapshot of said DBFS store and said transaction log is applied to said corrupted page by rolling forward the transactions that apply to said page; and

(c) attempting a second level of recovery for page corruptions if the corrupted page could not be repaired at the first level of recovery,

(i) said attempting a second level of recovery comprising addressing index page corruptions,

(ii) wherein in case of recoverable indexes failures the index is attempted to be repaired using offline index rebuild with the database being online and the index being offline.

Article 83 EPC

3. In the contested decision, the Examining Division noted that the description of the present application contained one detailed embodiment which described one way to carry out the alleged invention and which had to be used in order to interpret the claims. In the Examining Division's view, the applicant had taken this detailed embodiment as a basis for the main request then on file. As the requirements of Article 83 EPC implied that a skilled person had to be able to carry out the invention over the full range claimed, the Examining Division concluded that in the present case the skilled person should, at the very least, be able to carry out the detailed embodiment on which claim 1 was based.

4. The detailed embodiment described in the present application illustrates a way to carry out the invention in the software environment defined by the operating system developed by the appellant (see paragraphs [0001] and [0005]), and thus refers to some specific routines (see paragraphs [0044] and [0046]) used within the framework of that particular operating system. The subject-matter of claim 1, however, covers more general implementations of the invention and is not limited to any particular software environment.

4.1 The Examining Division's refusal of the application is essentially based on the conclusion that Article 83 EPC could not be fulfilled because the detailed embodiment of the invention, which provided the sole basis for the independent claim, could not be implemented without knowledge of all its specific routines.

4.2 The Examining Division's interpretation of Article 83 EPC appears to be unnecessarily restrictive, as it would penalize an applicant for giving details of an embodiment which may not be readily available to the notional skilled person. For instance, an application which contains a claim covering a particular embodiment of an electronic circuit described in detail with reference to some proprietary electronic components not generally available to the public would inevitably not comply with Article 83 EPC, although the functions performed by the proprietary components may be clear from the description and it may be assumed that alternative components for performing the same functions are available to the skilled person.

4.3 In the Board's opinion, the question to be asked in relation to Article 83 EPC is not if the skilled person is able to implement a specific detailed embodiment of the invention disclosed in the application, but rather if the application contains sufficient information for the person skilled in the art to carry out the invention.

This is in line with the established jurisprudence of the boards of appeal according to which there is no requirement under Article 83 EPC to the effect that a specifically described example of a process must be exactly repeatable. As long as the description of the process is sufficiently clear and complete, i.e. the claimed process can be put into practice without undue burden by the skilled person taking common general knowledge also into consideration, there is no deficiency in this respect (see e.g. T 281/86, OJ EPO 1989, 202, reasons 6).

4.4 Before dealing with the question of Article 83 EPC, it is therefore appropriate to examine what is the actual underlying teaching of the claimed invention.

5. Claim 1 according to the main request relates to an automated data reliability system (DRS) for the file system of an operating system, whereby the file system is implemented as a database. As specified in the claim, this implies that the file system is organised as a database with data pages, an index, index pages and a transaction log. The database is periodically backed up to create "snapshots", and changes made to the files between periodic snapshots are recorded in a transaction log.

5.1 The gist of the invention consists essentially in addressing data corruptions by attempting a first level of recovery at the page level and, if this fails, by attempting a second level of recovery, which in the case of index page corruptions is based on the offline index rebuild to be performed while keeping the database online.

5.2 As specified in claim 1, the first level of recovery consists in retrieving the corrupted page from the most recent snapshot and in applying the transaction log by rolling forward the transactions that apply to the retrieved page. The second level of recovery, which is attempted when the first level of recovery fails, consists, in case of index page corruptions, in the offline rebuild of the index. As explained by the appellant, the purpose of keeping the database online while rebuilding the index is that the database remains accessible, although access can be slower.

5.3 It is true, as pointed out in the contested decision, that the description (see paragraphs [0044] and [0046]) identifies some particular routines which are used in the exemplary embodiment of the invention and which do not appear to be generally known in the art. However, as argued by the appellant, the invention is sufficiently disclosed for the purpose of Article 83 EPC as long as it is sufficiently clear what functions the routines are expected to perform in the context of the described embodiment, and provided that the skilled person can be expected to know how to implement them.

5.4 Moreover, the routine defined in paragraph [0044] refers to database repair in emergency mode, a feature that is not in the present claim 1. As to paragraph [0046], it relates to steps which are taken after a page level restoration has failed, and explains in particular how to identify the corrupted page and the corrupted items before general repair measures are taken. Also this latter aspect of the invention is not explicitly mentioned in claim 1.

5.5 In order to carry out the automated data reliability system specified in claim 1, the skilled person needs to know how to detect data corruptions at a page level, how to take a snapshot of a database, namely how to make a backup from which a corrupted page can be retrieved, and how to roll forward the pending transactions to be applied to a backed up page. As for the second level of recovery, the skilled person has to be able to rebuild an index offline while maintaining the database accessible to the user.

5.6 Since database backups, transaction logs and index rebuild can be regarded as standard "tools" of database management and recovery, in the Board's opinion, the skilled person would be able to implement and employ them also in the particular environment of a database-implemented file system for an operating system.

5.7 Hence, the Board considers that the person skilled in database management and repair would have the necessary background knowledge and skills to develop the software routines required to carry out the steps recited in claim 1.

6. In the contested decision, the Examining Division further objected that claim 1 included the possibility of rebuilding a clustered index leaf page by means of rebuilding the index, which was however not disclosed in the application.

6.1 According to paragraph [0025] of the published application, "a data page is considered to be any page that has user data on it, which includes clustered index leaf pages" whereas index pages "contain just index information, and they include both non-clustered index pages as well as non-leaf pages of a clustered index" (emphasis added).

6.2 Hence, it is clear from the description that the index rebuild used to repair index failures in the second level of recovery does not concern index pages with user data, namely clustered index leaf pages.

7. As correctly observed by the Examining Division in the contested decision, the second level of recovery recited in claim 1 is not restricted to addressing index page corruptions. In fact, as specified in claims 2 and 3, both dependent on claim 1 and essentially corresponding to claims 2 and 3 considered in the contested decision, the second level of recovery comprises addressing data page corruptions and corruptions in a log file.

In the Examining Division's view, also these aspects of the invention could not be carried out by a skilled person, since the corresponding embodiment in the description relied on undisclosed routines or proprietary technology.

7.1 If this were indeed the case, this deficiency could be easily overcome by deleting dependent claims 2 and 3. In fact, a lack of disclosure of a particular embodiment of an invention specified in a dependent claim does not necessarily imply that also the invention defined in the independent claim violates Article 83 EPC.

For instance, the independent claim could be directed to an electronic device with some particular functions which are sufficiently explained in the application, while a dependent claim could specify an unrealistically low power consumption, which is not warranted by any of the disclosed features, or a further insufficiently disclosed functionality.

8. On the other hand, the second level of recovery from data page corruptions referred to in claim 2 is explained in paragraph [0046]. It consists essentially in identifying the corrupted page and the corresponding affected file system items, and in recovering them from a page backup as far as possible.

For instance, the practical example given in paragraphs [0053] and [0054] shows that, as a remedy of last resort, the user may be prompted to restore lost data from backup media.

8.1 As to addressing page corruptions in a log file, it is specified in paragraph [0008] of the application that "[f]or various embodiments of the present invention, the DRS comprises the following features: (1) [...] and (2) attempting a second level of recovery (rebuild or restore) for: (a) index page corruptions (clustered and non-clustered); (b) data page corruptions; and (c) page corruptions in the log file."

Log pages are defined in paragraph [0025] (last sentence) as pages that belong to the transaction log. The DRS will attempt an emergency repair when they are corrupted.

According to paragraph [0035], "[i]f an error occurs during transaction rollback", namely at the first level of recovery, "the DRS will take the database off-line, mark it suspect, and restart the database in order to invoke crash recovery".

Furthermore, according to paragraph [0043] "[f]or a system, log, or unknown page repair - that is, if a log corruption occurs or if there are failures that the DRS cannot correct (e. g. data or index), then DRS will present the user with the following options: (a) to restore the entire database (store); or (b) to recover the database in emergency mode".

8.2 Paragraph [0044] provides some details as to how to recover from a corrupt transaction log and unrecoverable database situations.

In particular, "if the database cannot be recovered and there is no usable backup, the following set of actions, illustrated in Fig. 7, will bring the database back online for certain DRS embodiments of the present invention: (a) at step 702, set the database to emergency mode; (b) at step 704, run 'DBCC CHECKDB (database, REPAIR_ALLOW_DATA_LOSS)' which has special meaning in emergency mode that (i) forces database recovery to proceed past errors (getting as much data as possible from the log but leaving a transactionally inconsistent database), (ii) throws away the corrupt log files and creates new ones, (iii) runs full database repair to bring the database to a structurally consistent state (an 'atomic', one-way operation that cannot be rolled-back or undone, and which is the only possible way of recovering the database in such a situation without manually editing files; and (c) now that the database is physically consistent, the DSR [sic] runs the CC on the entire store at step 706" (emphasis added).

8.3 Although the exact meaning of certain steps of the second level of recovery disclosed in the application, such as 'forcing database recovery to proceed past errors', may be questionable, the Board considers that they can be interpreted in the context of the invention in a way that would make their implementation possible not only with the help of the specific routines referred to in the application, but also on the basis of database management tools generally available to the skilled person.

9. The same considerations relating to the sufficiency of disclosure of the system according to claims 1 to 3 apply, mutatis mutandis, to the invention as specified in claims 5 to 7 and claims 9 to 11 which relate to a corresponding method and computer-readable medium, respectively.

9.1 In summary, the Board is satisfied that the person skilled in the art would be able to carry out an automated data reliability system as specified in the claims of appellant's main request on the basis of the information provided in the application and of the general knowledge to be expected of a skilled practitioner in the field of database management and repair. Hence, the present application complies with Article 83 EPC.

Article 123(2) EPC

10. In section 5. of the contested decision under the heading "OBITER DICTA", the Examining Division objected to the deletion of the feature "[said DSRS comprising] a set of policies for performing database administration tasks" which was included in claim 1 of the application as originally filed. In particular, the fact that this feature was recited in an independent claim was already an indication that it had to be regarded as an essential feature of the invention.

Furthermore, in the Examining Division's opinion, the context of the invention, namely a database-implemented file system for an operating system, implied that no database administrator was available. Normally, recovery of a database from corrupt pages involved manual efforts. In the context of the invention, it was necessary to define policies for performing database administration tasks so that these tasks could be carried out automatically. Thus, this feature was indispensable for the functioning of the system of the invention.

10.1 The appellant essentially argued that the invention lay in the specific interplay of the two levels of recovery, and not in the set of policies. Hence, this feature was not an indispensable component of the claimed system.

11. In order to assess whether the subject-matter of an amended claim, which no longer comprises a feature that was recited in the original independent claim, meets the requirements of Article 123(2) EPC, all that needs to be examined is whether the subject-matter of the amended claim has been disclosed directly and unambiguously in the application as filed considered as a whole (T 910/03 of 7 July 2005, reasons 6). In other words, an amendment is allowable under Article 123(2) EPC if it does not change the technical information contained in the application as filed.

11.1 In the original application, the feature "a set of policies for performing database administration tasks" is mentioned only in claim 1 and in paragraph [0007] of the description, whereby the latter reads as follows:

"Various embodiments of the present invention are directed [to] a data reliability system (DRS) for a DBFS wherein the DRS comprises a framework and a set of policies for performing database administration (DBA) tasks automatically and with little or no direct involvement by an end-user (and thus is essentially transparent to said end-user). For several embodiments, the DRS framework implements mechanisms for plugging error and event notifications, policies, and error/event handling algorithms into the DRS. More particularly, for these embodiments DRS is a background thread that is in charge of maintaining and repairing the DBFS in the background, and thus at the highest level the DRS guards and maintains the overall health of the DBFS" (emphasis added).

11.2 In view of the reference to unspecific policies for database administration tasks in the application as filed, it can be assumed that the expression "a set of policies" has a broad meaning covering all policies for performing general data administration tasks.

11.3 It is however evident for a skilled person that an automatic data reliability system for a DBFS requires the definition of some policies for performing database administration tasks. Mentioning in the claim an implicit feature of a database management system without giving any detail as to its implementation would not serve any meaningful purpose.

In other words, the Board sees no contradiction in the fact that a feature may be essential for the actual implementation of an invention, without being absolutely necessary for a complete definition of the invention. For instance, there would be no need to specify standard bicycle components, such as frame, wheels etc., in a claim directed to a bicycle with a new and inventive kind of hydraulic brake, although these components are certainly required for manufacturing an embodiment of the claimed bicycle.

11.4 Furthermore, apart from not adding any useful information for the skilled person, an unspecific hint to "a set of policies" may give rise to doubts as to the clarity of this feature which is not further defined in the application.

12. The Board furthermore notes that, "a set of policies for performing database administration (DBA) tasks" is recited in claim 1 as originally filed together with a subsystem for responding to data corruptions, a subsystem for a first level of recovery and a subsystem for a second level of recovery, and that the term "policies" is also mentioned in paragraph [0021] in connection with "recovery policies and detection mechanisms" which may be updated after a DBFS has been released.

12.1 Hence, the "set of policies" referred to in paragraph [0007] of the description or in claim 1 as originally filed could also be understood as relating to the "recovery policies" specified in claim 1 of the main request by feature (b)(i) of the first and second level of recovery and by features (c)(i) and (c)(ii) of the second level of recovery (see point 2.2 above).

This interpretation finds some support in paragraph [0008] which appears to substantiate the general description of the invention given in paragraph [0007] and, instead of referring to a "set of policies", specifies the steps of responding and correcting data corruptions at a page level for all page types and attempting a second level of recovery, inter alia, for index page corruptions.

According to this interpretation, a reference to "a set of policies" in claim 1 of the main request would be redundant because the claim already specifies the method's relevant "policies" for data and index recovery.

12.2 In summary, the Board considers that the omission of "a set of policies for performing database administration (DBA) tasks" from the independent system claim does not alter the technical information contained in the original application and consequently does not violate Article 123(2) EPC.

13. In the contested decision, the Examining Division furthermore objected that claim 1 then on file isolated features from the specific technical context defined by the detailed embodiment, and that the present application provided no basis for an intermediate generalisation of these features.

13.1 As specified in paragraph [0008], "[f]or various embodiments of the present invention, the DRS comprises the following features: (1) responding and correcting data corruptions at a page level for all page types; and (2) attempting a second level of recovery (rebuild or restore) for: (a) index page corruptions (clustered and non-clustered); (b) data page corruptions; and (c) page corruptions in the log file" (underlining added).

The same is reiterated in paragraph [0020].

According to paragraph [0019], "[f]or several embodiments of the present invention, the data reliability system (DRS) is a thread that maintains and repairs the database in the background, and thereby guards the general health of the database file system (DBFS)" (underlining added).

In paragraph [0021), it is specified that "[s]everal embodiments are direct [sic] to a DRS that run [sic] repairs while the DBFS database is kept online".

13.2 In summary, the Board considers that the application as originally filed discloses the general features now recited in claim 1. It is implicit that a viable embodiment may also cover other aspects of database recovery and thus include other features. However, the Board considers that the disclosure in the original application justifies a claim seeking protection for the solution to a particular aspect of the general problem of recovering a database from corrupted data pages.

13.3 The term "subsystem" used in the original claim 1 has been replaced with "means for". In the Board's opinion this is justified by the fact that it is clear from the original application that the term "subsystem" is not meant to identify physically separate units, but is associated to the different functions performed by the DRS. Furthermore, the description specifies that the system of the invention may be implemented with hardware or software or a combination of both (paragraph [0055]), or even in the form of program code transmitted over some transmission medium (paragraph [0056]). Thus, the term "subsystem" has a broad meaning in the application which is appropriately expressed by the term "means for".

14. Hence, the Board considers that claim 1 according to the main request is in compliance with Article 123(2) EPC.

Article 84 EPC

15. As to Article 84 EPC, the Board is satisfied that claim 1 defines the matter for which protection is sought in a clear and concise manner.

Independent claims 5 and 9

16. The above conclusions also apply to the independent claims 5 and 9 which relate to a method and a computer-readable medium, respectively, and whose features closely reflect the features recited in claim 1.

Further prosecution

17. Neither in the "Reasons for the Decision" nor in the "OBITER DICTA" did the Examining Division consider the question of inventive step or refer to any prior art document.

The appellant has, however, relied on document D1, which had been cited in a communication dated 30 June 2008, to explain the salient aspects of the invention.

17.1 According to the appellant, there were fundamental differences between the present invention and the teaching of document D1 which was not concerned with a database-implemented file system for an operating system. In fact, document D1 related to an unspecified relational database and, in particular, to the recovery of data pages as part of the restart procedure, for instance, after a power failure (see D1, page 69, first paragraph, and page 70, last sentence to page 71, first two lines).

Furthermore, the appellant has pointed out that document D1 indeed referred to a second recovery phase involving index files. However, as specified in D1, page 71, first full paragraph, index files were used to recover user data for which an index contained redundant data.

Hence, in the appellant's opinion, D1 was not a suitable starting point for defining the problem solved by the present invention.

17.2 The Board essentially agrees with the appellant that the present invention and document D1 address different problems and that it may be questioned whether document D1 represents the most relevant prior art.

17.3 In view of the above and, in particular, of the fact that the question of inventive step was not addressed in the contested decision, the Board considers it appropriate to make use of its power under Article 111(1) EPC and remit the case to the department of first instance for further prosecution on the basis of the main request.

18. In these circumstances there is no need to consider the appellant's auxiliary requests.