T 1538/17 (Real time database replica/ORACLE INTERNATIONAL) of 1.10.2020

Summary of Facts and Submissions

I. The applicant (appellant) appealed against the decision of the Examining Division refusing European patent application No. 06826229.4, filed as international application PCT/US2006/040792 and published as WO 2007/053314 A2. The application claims a priority date of 28 October 2005.

II. The documents cited in the contested decision included:

D5: US 6,289,357, published on 11 September 2001

D10: Jim Gray, Andreas Reuter, "Transaction Processing: Concepts and Techniques", Morgan Kaufmann Publishers, 1993, pp. 493-525, 583-628 and 630-657

III. The Examining Division decided that claim 1 of the then main request did not meet the requirements of Articles 84 and 123(2) EPC and that the subject-matter of the independent claims of the first to third auxiliary requests then on file lacked inventive step in view of document D10. The Examining Division also decided not to admit the then auxiliary requests 1B, 2B and 3B, as they were late filed and not clearly allowable. It also refused a request to continue the proceedings in writing.

IV. In its statement of grounds of appeal, the appellant requested that the contested decision be set aside and that a patent be granted on the basis of the main request or one of the three auxiliary requests submitted with the grounds of appeal. It submitted that the main request substantially corresponded to the first auxiliary request considered by the Examining Division in its decision, and that the first auxiliary request was the same as the auxiliary request 1B that had not been admitted by the Examining Division. The second and third auxiliary requests amended the first auxiliary request by citing further features.

V. In a communication under Article 15(1) RPBA 2020 accompanying the summons to oral proceedings, the Board expressed, among other things, its provisional opinion that the subject-matter of claim 1 of the main request was unclear and lacked inventive step in view of the prior art disclosed in the application itself and/or document D10. The Board also referred to page 946 of document D10 in its communication. As to the auxiliary requests, the Board indicated that its objections concerning clarity and inventive step for the main request also applied to the auxiliary requests, and that a further issue concerning insufficient disclosure arose for the auxiliary requests.

VI. By letter of 22 July 2020, the appellant submitted a main request and first to fourth auxiliary requests replacing all prior requests. The newly submitted main request and the newly submitted second to fourth auxiliary requests corresponded to the prior main request and first to third auxiliary requests, respectively, with a minor amendment to correct a formal issue in response to the Board's communication. The newly submitted first auxiliary request corresponded to the newly submitted main request with amendments made to address the issues raised by the Board in its preliminary opinion.

VII. In a subsequently filed letter, the appellant requested that the oral proceedings be held by videoconference.

VIII. Oral proceedings were held as scheduled by videoconference and the appellant was heard on relevant issues. In the oral proceedings, the appellant submitted a new procedural request that the case be remitted to the department of first instance for further prosecution if the Board did not allow the main request. At the end of the oral proceedings, the chairman announced the Board's decision.

IX. The appellant's final requests were that the decision under appeal be set aside and a patent be granted on the basis of the main request or, alternatively, of any of the first to fourth auxiliary requests, all requests as filed with the appellant's letter dated 22 July 2020. As a procedural request, the appellant requested that the case be remitted to the department of first instance for further prosecution if the main request was not granted.

X. Claim 1 of the main request reads as follows:

"A computer implemented method of processing data to update a replica of a source database, the method comprising:

identifying a capture redo byte address indicative of a physical location of a redo record in a transactional log of the source database, wherein the transactional log comprises at least one redo record with each redo record comprised by the transactional log producing a logical change number and redo byte address;

initiating, after the capture redo byte address has been identified, a capture process at the capture redo byte address to capture transactional changes to the source database;

characterised in that the method further comprises:

creating, after the capture process has been initiated, a clone of the source database containing all transactions committed to the source database prior to the logical change number of the capture redo byte address by transferring data from the source database;

transferring the clone of the source database to a target database; and

initiating an apply process at the target database to apply the transactional changes captured by the capture process for transactions that were not committed prior to the logical change number to the target database."

XI. Claim 1 of the first auxiliary request differs from claim 1 of the main request as follows:

- The step of identifying was amended to "identifying a capture redo byte address indicative of a physical location of a redo record in a transactional log of the source database, wherein the transactional log comprises at least one redo record producing a logical change number and the capture redo byte address that help to maintain ordering between changes made by multiple transactions;".

- The expression "transferring the clone" was amended to "applying the clone".

- The text at the end of the claim, "that were not committed prior to the logical change number to the target database", was amended to "and discard any transactions that were committed prior to the logical change number to the target database".

XII. Claim 1 of the second auxiliary request differs from claim 1 of the main request in that the text "to a target database" was amended to "to a target database, wherein the target database is heterogeneous to the clone", and in that the text ", such that the target database and the source database are two separate databases synchronized at the operational level" was added at the end of claim 1.

XIII. Claim 1 according to the third auxiliary request differs from claim 1 of the second auxiliary request in that the following text was added at the end of the claim:

"wherein the capture redo byte address is the address of the first redo record generated by the oldest active transaction in the source database".

XIV. Claim 1 according to the fourth auxiliary request differs from claim 1 according to the third auxiliary request in that the following text was added at the end of the claim:

"and

wherein the method further comprises running a query on the source database that lists all active transactions so as to identify the logical change number that represents a low watermark for the change made by the oldest active transaction; and

the capture redo byte address is determined in dependence on said run query so as to identify a logical change number."

XV. The appellant's arguments, where relevant to the decision, are discussed in detail below.

Reasons for the Decision

Admissibility of the appeal

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

The invention

2. The application relates to a technique for replicating a database system (paragraph [0002] of the published application).

2.1 According to the background section, a known approach to building high availability systems was to construct a replica of a source database system to a target database system. Replication of a system database was commonly achieved by making an initial copy of the data (an instantiation) and subsequently applying the database's transaction (redo/undo) logs to propagate the ongoing changes from the source to the target database (paragraph [0004]). However, known techniques designed to construct the initial copy of the source database commonly required the source database or application to be shut down during data extraction, or to implement some form of "locking" or "quiescing" on the database. Hence, these techniques affected the availability of data (paragraph [0005]).

2.2 According to the application (paragraph [0021]), a database management system logs "before images" and "after images" of changes made by a database transaction in a redo log. Once a redo log file is filled, it is archived for recovery purposes and the database starts writing a new redo log file. Each redo log file has a unique log sequence number (LSN) associated with it.

One transaction can generate multiple redo records and each redo record "produces" a unique logical change number (LCN) and redo byte address (RBA) that help to maintain ordering between changes made by multiple transactions (paragraph [0022]). The RBA indicates the physical location in the redo log file where the redo record was written.

2.3 The application proposes a database replication process that identifies a capture redo byte address, initiates a capture process at the capture redo byte address, creates a clone of the source database to a logical change number, and initiates an apply process at a target database (paragraphs [0006] and [0027] to [0031]; Figure 4).

2.4 The capture process and the apply process relate to log-based replication (LBR). The replication is accomplished through a two-step process (paragraph [0023]). First, a capture process termed "log-based extraction (LBE) capture" reads the source database's transactional logs and captures the transactional changes present. The capture process maintains a queue of all transactions in the database. Once a transaction commits, the changes are transmitted to the replica database. Second, an apply process termed "LBE apply" applies the changes at the target database that were captured by the LBE capture process (paragraph [0023]).

2.5 The instantiation (i.e. the replication of transactions committed prior to the start LCN - see paragraph [0023]) is accomplished by techniques including online

backups, for example by taking a hot backup (paragraph [0024]).

2.6 A clone database is a copy of the source database containing all committed transactions up to the recovery LCN, but not containing any transactions made on the source database subsequent to or at the recovery LCN (paragraph [0025]). Thus, the clone database is a copy of a database as of a prior point in time. The clone database is homogeneous to the source database. Accordingly, if a clone database is desired across a heterogeneous system, a new database must be created. Data from the clone database is transferred to a new heterogeneous target database, the cross-clone database.

Admission of the requests

3. The sets of claims according to the main request and the first to fourth auxiliary requests were a response to objections raised for the first time in the preliminary opinion of the Board. The amendments made in the main request and the second to fourth auxiliary requests only correct a minor deficiency in the prior pending requests noted by the Board in its communication. The first auxiliary request was amended to address several of the Board's other clarity objections.

As this was the appellant's first opportunity to address these objections, the Board considers that there are exceptional circumstances (see decisions T 32/16 of 14 January 2020, point 1.3 of the Reasons; T 2329/15 of 8 September 2020, point 4.4 of the Reasons; and T 1255/18 of 16 June 2020, point 6.1 of the Reasons) which justify the admission of the newly filed requests into the appeal proceedings (Article 13(2) RPBA 2020).

Main request

4. Claim 1 of the main request relates to a "computer implemented method of processing data to update a replica of a source database" which comprises the following steps, as itemised by the Board:

A identifying a capture redo byte address indicative of a physical location of a redo record in a transactional log of the source database, wherein the transactional log comprises at least one redo record with each redo record comprised by the transactional log producing a logical change number and redo byte address;

B initiating, after the capture redo byte address has been identified, a capture process at the capture redo byte address to capture transactional changes to the source database;

C creating, after the capture process has been initiated, a clone of the source database containing all transactions committed to the source database prior to the logical change number of the capture redo byte address by transferring data from the source database;

D transferring the clone of the source database to a target database;

E initiating an apply process at the target database to apply the transactional changes captured by the capture process for transactions that were not committed prior to the logical change number to the target database.

5. Clarity and support

5.1 Features A, C and E of claim 1 refer to a logical change number (LCN). The expression LCN does not have an established technical meaning. The claim does not specify how this number is defined or what the technical function of this number is.

In the oral proceedings, the appellant argued that an LCN was a sequential numbering of the changes made to the database. Asked by the Board how this related to the changes made concurrently by multiple transactions, the appellant replied that it applied to changes within a given transaction in the sense of a sequential numbering of changes within a transaction. When the Board asked how LCNs corresponding to a sequential numbering of changes within a transaction could help to maintain ordering between changes made by multiple transactions, which were executed concurrently in the database, the appellant replied that changes to the database were sequentially numbered independent of the transaction making a change. Hence, in the oral proceedings, the appellant's submissions concerning the technical meaning of the LCNs were not consistent.

The description, paragraph [0022], explains the following:

"One transaction can generate multiple redo records and each redo record produces a unique logical change number (LCN) and redo byte address (RBA) that help to maintain ordering between changes made by multiple transactions. The RBA indicates the physical location in the redo log file where the redo record was written. Additionally, the transactional log contains a commit logical change number (cLCN) for the redo record that committed the transaction. To illustrate, FIG. 3b presents an example of the content of an LSN. The LSN starts at RBA 0 306 and ends at RBA 1048575 308. FIG. 3b also displays a transaction that generated a redo record at an LCN of 1100 310 that eventually commits with another redo record with a cLCN of 1158 312."

The Board understands this passage as meaning that the LSN identifies the log file (the transactional log consists of several log files - see paragraph [0021] and Figure 3a) and the RBA identifies a specific byte address within a log file. Figure 3b shows an exemplary transaction that generated a redo record at an LCN of 1100 that eventually commits with another redo record with a cLCN of 1158. Thus, a transaction that successfully changes the database generates multiple redo records having different LCNs and one cLCN. It is not understandable, however, how the LCNs and the RBA "help to maintain ordering between changes made by multiple transactions" as stated in paragraph [0022]. Moreover, according to the same paragraph, "each redo record produces a unique logical change number (LCN) and redo byte address (RBA)." This sentence does not fully clarify whether the word "unique" refers only to LCN or to the combination of LCN and RBA. However, according to the example provided in Figures 3a and 3b, the LCNs are unique whereas the RBA is unique only in combination with the LSN (the RBA identifies the byte position in a log file identified by the LSN).

Figures 4 and 5 and paragraph [0027] disclose that the LCNs correspond to some "logical time" (which seems not to be further explained in the application). According to Figure 5, several redo records have the same logical time "L", which means that they have the same LCN if an LCN corresponds to a unique point in logical time. This is in contradiction with the example in Figure 3b and the corresponding description in paragraph [0022] according to which the LCNs are unique for each redo record.

In view of the above, the Board is not satisfied that the term LCN has a clear meaning for the skilled person, and the appellant's inconsistent explanations with respect to the meaning of LCN rather confirm the Board's view. Moreover, the description and the figures of the application do not disclose the concept of LCNs in a consistent and understandable manner. Consequently, the skilled person is not able to understand the technical meaning of an LCN even when claim 1 is read in the light of the application as a whole.

Consequently, claim 1 of the main request is unclear (Article 84 EPC).

5.2 In the oral proceedings, the Board raised a further objection under Article 84 EPC. It noted that claim 1 of the main request refers in steps A, C and E to an LCN. Claim 1 as originally filed specified the following steps:

- identifying a capture redo byte address;

- initiating a capture process at the capture redo byte address;

- creating a clone of a source database to a logical change number; and

- initiating an apply process at a target database.

The Board pointed out that the method in original claim 1 identified a capture redo byte address for initiating the capturing process and then created a clone of a source database "to a logical change number", i.e. corresponding to the source database as it was at a particular point in time as defined by an LCN. This LCN was apparently different from the LCN associated with the capture redo byte address.

In the oral proceedings, the Board observed that its interpretation of original claim 1 was consistent with the embodiment disclosed in the description as originally filed on pages 7 and 8. According to page 7, paragraph [0027], "the first processing operation is to identify the LCN that represents a low watermark for the change made by the oldest active transaction 400. The LCN, L, is guaranteed to be at a lower logical time than the first change made by the oldest transaction and may be identified using a query on the source database that lists all active transactions". The Board understands this passage as defining a first LCN, L, as a low watermark for the change made by the oldest active transaction.

Paragraph [0028] discloses that "the next processing operation is to create a clone database of the source database 404. This can be achieved using the online backup techniques discussed above." According to the same paragraph, the "last processing operation shown in FIG. 4 is to start the LBE Apply process at the target database 408. The LBE Apply process is supplied with a user[-]defined clone LCN that represents the recovery LCN for the clone database. The LBE Apply process subsequently discards any transactions that were committed prior to the clone LCN and applies the changes captured by [the] LBE Capture process." The Board understands the cited passage as introducing a second LCN, the user-defined clone LCN, which is equal to the "recovery LCN for the clone database" and different from the LCN L.

In the oral proceedings, the appellant argued that according to its invention and claim 1 of the main request, there was only one LCN and not two as argued by the Board. In response, the Board referred the appellant to paragraph [0029] on page 8 of the description as filed, which discloses the following: "If the transaction committed before L, it will also be committed in the target database because the clone or cross-clone database was recovered to a clone LCN higher than L." The Board considers that this passage confirms its reading that the clone LCN and the LCN L are indeed different.

However, the appellant, even after having been provided with more time to consider this issue during an interruption of the oral proceedings, maintained its position that according to claim 1 of the main request, there was only one LCN.

The Board concludes that claim 1 of the main request is not supported by the description as filed (Article 84 EPC).

5.3 In view of the above, claim 1 of the main request does not meet the requirements of Article 84 EPC.

Auxiliary requests

6. Clarity and support

6.1 The first auxiliary request amends the identifying step of claim 1 to specify that "the transactional log comprises at least one redo record producing a logical change number and the capture redo byte address that help to maintain ordering between changes made by multiple transactions". As the Board has already construed claim 1 according to the main request in the light of the description as meaning that the LCN aims to help to maintain ordering between changes made by multiple transactions, the first auxiliary request does not further clarify the technical meaning of an LCN. Consequently, the Board's objection above that claim 1 of the main request is unclear applies also to the first auxiliary request.

Furthermore, none of the amendments made in the first auxiliary request specifies that the LCN used by the apply process is different from the LCN identified in step A. Hence, claim 1 according to the first auxiliary request, for the same reasons as claim 1 of the main request, lacks support by the description.

Consequently, claim 1 of the first auxiliary request does not meet the requirements of Article 84 EPC.

6.2 The second to fourth auxiliary requests add that the target database is heterogeneous to the clone and that the target database and the source database are two separate databases synchronised at the operational level. However, these amendments do not concern the definition of an LCN or the use of different LCNs in the identifying step and the apply process.

The third and fourth auxiliary requests further define the capture redo byte address as the address of the first redo record generated by the oldest active transaction in the source database. The fourth auxiliary request specifies how that address is obtained. The Board does not see how these amendments

could overcome the objections made to the main request under Article 84 EPC.

The Board concludes that claim 1 of each of the second to fourth auxiliary requests does not meet the requirements of Article 84 EPC.

The appellant's request for remittal to the department of first instance

7. The appellant argued that it was appropriate to remit the case for further prosecution to the Examining Division, as the Board had raised a fresh clarity objection in the oral proceedings and there were different opinions on how to read the claim when assessing inventive step. According to the appellant, this could only properly be dealt with before the Examining Division.

However, the Board is competent to determine the issues to be assessed in appeal proceedings and notes that there is no reason why issues of clarity and claim interpretation cannot be dealt with in such appeal proceedings. In the present case, the new clarity objection was directly related to the Board's and the appellant's diverging views on the interpretation of claim 1. This divergence would have had to be resolved before the Examining Division's decision refusing the then first auxiliary request (which essentially corresponds to the present main request) for lack of inventive step could be reviewed. The Board therefore considers it appropriate to deal with the clarity objection in these appeal proceedings.

Moreover, in view of the other clarity objections raised by the Board in its communication, the appellant could not have been surprised by the interpretation of the claims and the detailed functioning of the invention being important points of discussion at the oral proceedings. Furthermore, the appellant was given time to consider the new objection when the divergence in understanding of the claimed invention between it and the Board became apparent. It did not however request a further interruption of the oral proceedings for this consideration.

The Board therefore considers that there is no special reason for a remittal under Article 11 RPBA 2020, and thus that the request for remittal cannot be allowed.

Conclusion

8. As none of the appellant's requests can form the basis for the grant of a patent, and as the appellant's request for remittal to the department of first instance cannot be allowed, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.