T 1897/11 (Schema updating for synchronizing databases/BLACKBERRY) of 7.3.2017

Summary of Facts and Submissions

I. The applicant (appellant), whose name at the time was Research In Motion Limited, appealed against the decision of the Examining Division refusing European patent application No. 06121099.3.

II. In the course of the appeal proceedings, the appellant changed its name to BlackBerry Limited.

III. The Examining Division decided that the subject-matter of the claims of the main request and of the first and second auxiliary requests lacked inventive step over the prior art disclosed in the following document:

D5: Ronström, Mikael: "Design and Modelling of a Parallel Data Server for Telecom Applications", Ericsson Utveckling AB 1997.

In the written proceedings the Examining Division also cited the following prior-art documents:

D1: US2005/120123 published on 2 June 2005,

D2: US2005/071344 published on 31 March 2005,

D3: US2004/224675 published on 11 November 2004,

D4: Marco Mesiti et al.: "X-Evolution: A System for XML Schema Evolution and Document Adaptation", 10th International Conference on Extending Database Technology, Munich, Germany, 26-31 March, 2006, LNCS 3896, published on 31 March 2006.

IV. With the statement of grounds of appeal, the appellant submitted a new main request and new first and second auxiliary requests. It requested that the decision be set aside and that a patent be granted on the basis of one of the main and the first and second auxiliary requests.

V. In a communication pursuant to Rule 100(2) EPC, the Board essentially agreed with the appellant's assessment of document D5 and found that the reasons given by the Examining Division did not justify the refusal of the application.

However, as the Board was aware of a further prior-art document which might prejudice the patentability of the claimed subject-matter, the following courses of action were proposed:

(a) The Board would decide to set aside the decision under appeal and remit the case to the department of first instance for further prosecution. In its decision, the Board would merely point out the relevance of the new prior art, but draw no conclusion as to the inventive step of the claimed subject-matter.

(b) Considering, inter alia, the age of the application and the length of the procedure before the Board, the Board would conduct a full examination of the appeal in the light of the new prior art and of any submissions the appellant might wish to make. A summons to oral proceedings might then be the next step in the appeal procedure.

The Board drew the appellant's attention to the following prior art and explained its relevance:

D6: US2005/149582 published on 7 July 2005.

VI. In reply to the Board's communication, the appellant gave preference to the first course of action (a) and requested that the Board remitted the case to the Examining Division to continue examination. No submissions concerning the new document D6 were made.

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

"A method of updating and backing up a database (40, 42, 44) comprising data records, to accord with an updated database schema defining un [sic] updated structure of the data records in the database (40, 42, 44), wherein the database (40, 42, 44) is associated with mail store content, the method comprising:

obtaining (100) at a portable electronic device (22) the updated database schema associated with the database (40, 42, 44);

comparing the updated database schema (106) with a previous database schema associated with the database (40, 42, 44), to determine database schema changes;

generating an update command (108) based on said comparing (106), when the updated database schema differs from said previous database schema, said update command comprising said database schema changes;

updating the data records (110) of the database (40, 42, 44) according to the update command (108) by:

deleting a first field from each of the data records, if said database schema changes comprise a deletion of said first field of the data records;

deleting data stored in a second field in each of the data records, if said database schema changes comprise a modification of said second field of the data records; and

adding a new field in each of the data records, if said database schema changes comprise an addition of said new field of the data records; and

transmitting said update command (112) from said portable electronic device (22) to a server by way of a radio communication channel, said update command for enabling updating of a backup database (34, 36, 38) associated with the database (40, 42, 44) at the server, by performing the steps deleting a first field, deleting data and adding a new field on backup data records of the backup database (34, 36, 38) according to the update command, so that each of the backup data records of the backup database (34, 36, 38) conforms to the updated structure as defined by the updated database schema."

Claims 2 to 10 of the main request are dependent on claim 1.

Claim 11 of the main request reads as follows:

"A computer-readable medium having computer-readable code embodied therein for updating and backing up a database, comprising data records, to accord with an updated database schema, said computer-readable code for causing a computing device or system to perform the method of any one of claims l to 10."

Claim 12 of the main request reads as follows:

"A portable electronic device (22) comprising:

an input for receiving an updated database schema associated with a database (40, 42, 44);

a memory for storing data records in said database;

a processor (46) for executing computer-readable code embodied in a computer readable medium of the portable electronic device (22), said computer-readable code for causing the portable electronic device to perform the method of any one of claims 1 to 6."

Claim 13 of the main request is dependent on claim 12.

Claim 14 of the main request reads as follows:

"A method carried out at a server (30) for updating a backup database (34, 36, 38) comprising backup data records stored on the server, to accord with an updated database schema of a database (40, 42, 44) operated by a portable electronic device (22), wherein the database (40, 42, 44) operated by the portable electronic device (22) is associated with mail store content, the method comprising:

receiving an update command (114) from the portable electronic device (22) by way of a radio communication channel, said update command for enabling updating a database schema for the backup database (34, 36, 38);

wherein the update command comprises database schema changes of the updated database schema with respect to a previous database schema of the database (40, 42, 44) operated by the portable electronic device (22);

wherein the previous and updated database schema define a structure of the data records in the database (40, 42, 44) operated by the portable electronic device (22); and

updating (118) the backup data records according to the update command so that each of the backup data records of the backup database (34, 36, 38) conforms to the updated structure as defined by the updated database schema, by:

deleting a first field from each of the backup data records, if said database schema changes comprise a deletion of said first field of the data records,

deleting data stored in a second field in each of the backup data records, if said database schema changes comprise a modification of said second field of the data records; and

adding a new field in each of the backup data records, if said database schema changes comprise an addition of said new field of the data records."

Claim 15 of the main request reads as follows:

"A server (30) for updating a backup database comprising backup data records, to accord with an updated database schema of a database (40, 42, 44) operated by a portable electronic device (22), wherein the database (40, 42, 44) operated by the portable electronic device (22) is associated with mail store content, the server comprising:

means for receiving an update command (114) from the portable electronic device by way of a radio communication channel, said update command for enabling updating a database schema for the backup database (34, 36, 38), the backup database stored at the server;

wherein the update command comprises database schema changes of the updated database schema with respect to a previous database schema of the database (40, 42, 44) operated by the portable electronic device (22);

wherein the previous and updated database schema define a structure of the data records in the database (40, 42, 44) operated by the portable electronic device (22); and

means for updating (118) the backup data records according to the update command so that each of the backup data records of the backup database (34, 36, 38) conforms to the updated structure as defined by the updated database schema, by:

deleting a first field from each of the backup data records if said database schema changes comprise a deletion of said first field of the data records,

deleting data stored in a second field in each of the backup data records, if said database schema changes comprise a modification of said second field of the data records; and

adding a new field in each of the backup data records, if said database schema changes comprise an addition of said new field of the data records."

The wording of the claims of the auxiliary requests is not relevant to the present decision.

VIII. The appellant's arguments relevant to the Board's decision are discussed in detail below.

Reasons for the Decision

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

The invention

2. The application relates to database schema updates for synchronised databases, for example a database and its synchronised backup database. A database schema defines the tables (types of records) and, for each type of record, includes information relating to each field.

2.1 According to the technical background described in paragraph [0005] of the description, data records of a database that do not conform to the new database structure defined by a new database schema are invalidated and permanently deleted. Hence, any change in a database schema, including a simple modification of a single field in the schema, results in the invalidation of the entire backup database.

The invention attempts to avoid this inefficient handling of schema updates, in particular where database backup occurs over the air (by radio communication), as performing a backup of all records of a database can be time-consuming and costly to a user.

2.3 The invention solves this problem by comparing at a portable device a new version of a database schema to its prior version, by generating an update command, based on the comparison, to update the database at the portable device to conform to the new schema, by updating the database at the portable device using the generated update command, and transmitting the update command over the air from the portable device to a server storing a backup database of the database at the portable device to enable the server to update the backup database in the same manner using the transferred update command. Different schema updates (add/modify/delete field) are specified in more detail.

Main request

3. Amendments - Article 123(2) EPC

3.1 With the statement of grounds of appeal the appellant submitted that claim 1 of the main request had been amended compared to claim 1 of the main request considered in the contested decision to specify that:

(a) the updated database schema defined an updated structure of the data records in the database;

(b) the database was associated with mail store content;

(c) the update command was generated prior to updating of the data records in the database;

(d) the data records of the database were updated according to the update command;

(e) data stored in a second field in each of the data records was deleted if said database schema changes comprised a modification of said second field of the data records;

(f) the update command was transmitted from said portable electronic device to a server by way of a radio communication channel;

(g) the backup database was updated by performing the steps "deleting a first field", "deleting data" and "adding a new field" on backup data records of the backup database according to the update command;

(h) the backup data records were updated such that each of the backup data records of the backup database conformed to the updated structure as defined by the updated database structure.

The corresponding independent claims 14 and 15 had been amended accordingly.

With respect to the basis for these amendments, the appellant referred for amendment (a) to paragraph [0023] of the description, for amendment (b) to paragraph [0009] of the description, for amendment (c) to Figure 4 and the related description, for amendment (d) to paragraph [0025] of the description, for amendment (e) to former claim 2, for amendment (f) to paragraph [0015] of the description, for amendment (g) to claim 7 and paragraph [0026] of the description, and for amendment (h) to paragraph [0009] in combination with paragraph [0005] of the description.

The Board notes that paragraph [0025] of the description is a suitable basis for amendment (e) and that original claims 5, 6, 10 and 11 are a relevant basis for amendment (g). The Board accepts that these amendments do not introduce deficiencies under Article 123(2) EPC.

4. Inventive step - Article 56 EPC

4.1 According to the contested decision, all features of the then pending claim 1, apart from the use of a portable electronic device, are disclosed in document D5.

4.2 In the statement of grounds of appeal, the appellant argued that D5 did not disclose the following features F1 to F6 of claim 1 of the main request (features F2 and F4 and parts of features F1, F3 and F5 were already present in claim 1 of the main request underlying the contested decision):

- D5 did not disclose a portable device and a transmission of the updated command from the electronic portable device to the backup server by way of a radio communication channel (hereinafter: feature F1).

- D5 did not disclose the step of "comparing the updated database schema with a previous database schema associated with the database, to determine database schema changes on the portable electronic device" (hereinafter: feature F2).

- D5 did not disclose the step of "generating an update command based on said comparing, when the updated database schema differs from said previous database schema, said update command comprising said database schema changes" (hereinafter: feature F3).

D5 did not disclose the step of transmitting a specific update command from the portable electronic device to the corresponding backup server (hereinafter: feature F4).

- D5 did not disclose the step of "deleting data stored in a second field in each of the data records, if said database schema changes comprise modification of said second field of the data records" (hereinafter: feature F5).

- D5 did not disclose a database which was associated with mail store content (hereinafter: feature F6).

With respect to feature F2, the appellant submitted that according to the Examining Division "a comparison, in a general sense," was disclosed in D5. In particular, the Examining Division pointed to phase 3 of Fig. 10-2, where a set of test transactions is run on the new schema in order to decide whether the new schema is OK or not. However, D5 did not determine explicit database schema changes based on comparing the updated database schema with a previous database schema associated with the database. Moreover, the claimed "comparing step" was performed before database schema changes were implemented in the database, whereas the test transactions were run after the implementation of the schema changes. In fact, D5 did not store any previous database schema, because all schema changes were implemented immediately by broadcasting log messages.

The appellant argued that the passages cited by the Examining Division with respect to feature F3 (D5, page 186, lines 5 to 12 and section 10.5.2) related to providing logs for schema changes to the plurality of backup systems. The Examining Division seemed to have interpreted D5 as meaning that a sequence of update commands could be generated. This was different from the "single update command comprising a plurality of schema changes" as claimed. Furthermore, the serialised logs used in D5 for propagating schema changes contained the changes to each data record and could not be equated to an update command comprising changes to the structure of the data records (the database schema). In particular, the size of the logged data was proportional to the number of records in the database. This was fundamentally different from transmitting a single update command comprising database schema changes. Hence, the generating step was not disclosed by D5.

With respect to feature F4, the appellant argued that the log messages used in D5 were unspecific, whereas the update command was "specific to the corresponding backup database" and that the broadcasting of log messages was different from the transmission of the update command.

Feature F5 was not disclosed in section 10.4.2 of D5 cited by the Examining Division. This passage related to the change of attributes, but did not disclose the deletion of data subject to the database change indicating a modification of the corresponding field.

Moreover, D5 concerned a database management system for heavy telecom maintenance and operations applications such as home location registers. Hence, the technical context of D5 was fundamentally different from the context of the claimed subject-matter, which was associated with mail store content (feature F6).

In view of these distinguishing features, the appellant proposed to formulate the objective technical problem as "how to synchronise database schemas of an email database at a portable electronic device and a backup server over a bandwidth-limited and intermittent wireless link" (features F1 and F6).

This objective technical problem was solved by generating an update command comprising the plurality of database schema changes (feature F3). The list of changes was determined by comparing the updated database schema with a previous database schema (feature F2). Furthermore, the problem was solved by associating database transactions with the plurality of database schema changes which could be implemented at the main database (at the portable electronic device) and at the backup database (at the backup server) independently of any additional transaction logs (feature F5). As a result, it was possible to synchronise the database schemas of the databases at the portable electronic device and at the backup server by transmitting only the list of database schema changes without the need to transmit any transaction logs regarding the individual data records (feature F4).

This solution was not obvious, as D5 related to the continuous synchronisation of heavy telecom data servers via continuous wireline links providing high bandwidth using a logging system which generated a log for each modification to a particular data record of the primary database. Claim 1 was directed to bandwidth-efficient synchronisation of an email database on a portable device with a backup server over a wireless link. Due to this different technical context, it was questionable whether a skilled person would consider D5 when faced with the objective technical problem as formulated by the appellant.

D5 exchanged logs for synchronisation which allowed for continuous synchronisation as required for high-availability applications. However, this involved a high amount of data and required high bandwidth on the link between the primary and the backup databases. Such a synchronisation method was in contrast to the objective technical problem. Moreover, D5 did not provide any hints to the skilled person towards replacing the logs containing changes to each data record by a single update command comprising a plurality of database schema changes. Hence, the subject-matter of the amended independent claims was new and involved an inventive step.

4.3 In the Board's opinion, at least some of the appellant's arguments are convincing.

4.4 Document D5 is a 245-page research publication proposing a new design for future telecom database systems, which are defined as data storage nodes used for the operation of the telecom network or used in applications that are part of the telecom network (D5, page 2, section 1). Such databases have inter alia the following significant features: scalability, security, very high availability, and very high reliability (D5, pages 5 and 6, section 1.4).

In order to support these features, D5 discloses a parallel data server having a local and a global replication structure (D5, pages 107 to 110). The local replication structure (D5, page 107, section 5.1.1) replicates fragments of database tables using a primary node and a hot stand-by node. This hot stand-by node is called backup node in D5. In addition, there are stand-by nodes which participate in all transactions but only log the transactions. The global replication structure (D5, page 110, section 5.1.2) uses "backup replicas on system level". Starting on page 148, section 8 of D5 presents protocols to implement replication between a primary system and a backup system. D5 discusses in section 10 on page 171 how schema change operations can be performed without any major interference with user operations (so-called online schema changes, where the database remains accessible for other users).

In section 10.1.2 on page 172, D5 defines simple and complex schema changes. Simple schema changes are those which can be executed as one transaction and involve only changes to schema information. Examples are adding and dropping tables, attributes, foreign keys and indexes (D5, page 175, section 10.3). Complex schema changes are long-running transactions (D5, section 10.1.2), which always involve changes to a number of tuples (D5, section 10.1.4, second paragraph on page 173; tuples correspond to data records). Examples of complex schema changes are changes of attributes, splitting a table, and merging a table (D5, section 10.4 on page 177).

D5 explains in section 10.2.3 on page 174 and Figure 10-1 on the same page that a simple schema change is performed similar to a two-phase commit, which is a well-known protocol for transaction processing. D5 clearly describes how these simple schema changes are implemented in a kind of distributed transaction at the same time and at all nodes (all local nodes comprising primary node, backup nodes and stand-by nodes - see D5, section 8.2 on page 149, page 150, Figure 8-2 and page 153, Figure 8-5).

For complex schema changes D5 describes an implementation with five phases in section 10.4 starting on page 176. The third phase uses test transactions if some schema changes are incompatible (D5, page 171, section 10.1.1).

D5 describes the propagation of schema changes to the backup system (global replication) in section 10.5 starting on page 186. Section 10.5.2 describes how the schema information is modelled as a single fragment for which a log channel is then set up in order to send transactions to the backup system (global replication).

4.5 The appealed decision refers to section 10.2.3 and Figure 10-2 of D5 to show that D5 discloses comparing the updated schema with a modified schema. It states that the test transactions "provide[d] a means to compare the efficacy of the new schema against the old schema". Hence, D5 disclosed "a comparison, in a general sense".

However, what is claimed is not a comparison of the efficacy of the new schema against the old schema by means of test transactions, but a comparison of the new schema against the old schema with the stated specific purpose of determining database schema changes, which are then used to determine which updates have to be carried out in order to implement the transition from the previous database schema to the updated database schema. Hence, D5 does not disclose the claimed comparison of database schemas and cannot disclose the further steps which are based on this comparison.

Moreover, according to D5 such test transactions are only used in case of hard complex schema changes. However, adding and dropping attributes according to D5 are implemented as soft schema changes, because D5 relies on a particular implementation to avoid modifying the actual data records in this case (D5, page 176, section 10.3.2). Hence, there is another reason why the corresponding claim features cannot be disclosed in D5.

Moreover, the Board agrees that D5 provides no motivation to replace log-based synchronisation with the claimed use of a generated update command based on comparing schema versions. As stated above, D5 concerns a shared high-availability database system used for high-performance transaction processing with replicated backup servers. In this technical context logging is necessary for transaction processing. Hence, using the log avoids additional workload for the database server due to replication, as the log records can be read independently and shipped via a high-bandwidth link to a replicated server where the log records can be used for replication. This is fundamentally different from an email database on a portable device, which will typically not be shared between users, might have only limited support for transaction processing, has no high-bandwidth connection to the server, and does not have the same constraints for high availability and performance as a mission-critical database for telecom network infrastructure. Consequently, the Board shares the appellant's opinion that D5 is not a suitable starting point for assessing inventive step for the amended independent claims.

4.6 Hence, the Board reaches the conclusion that it would not have been obvious to a skilled person starting from the teaching of document D5 to arrive at the subject-matter of the independent claims (Article 56 EPC).

4.7 During the examination proceedings further prior art was cited. The relevance of these documents is now reviewed.

4.8 D1 relates to MPEG-21 Digital Item Adaptation, which requires negotiation between different MPEG-21 peers.

4.9 D2 relates to a method for creating an XML schema and specifically to an improved method for creating an XML schema to support validation of data for entry into a database.

4.10 D3 relates to communication systems, and in particular to collaborative data and intelligent synchronisation for mobile devices. It uses a data schema to select a subset of database data for synchronisation between a server database and a database on a mobile device, but is not concerned with database schema updates or the propagation of such updates to a backup database.

4.11 D4 was cited as evidence of general knowledge about XML schema evolution, but is not concerned with database schema changes.

4.12 Consequently, the cited prior-art documents D1 to D4 are not relevant to the technical problem of applying database schema updates efficiently to synchronised or replicated databases, in particular over a wireless connection.

5. Newly introduced prior art

5.1 The Board considers that a more appropriate assessment of the inventive step of the present invention can be made in the light of document D6.

D6 relates generally to the synchronisation of copies of a database. In particular, it provides a lightweight database synchronisation and migration framework for pushing schemas and migration scripts to database developers or production systems as a natural part of a development or product upgrade cycle (see D6, paragraph [0002]). It addresses the problem of synchronising different database schemas while avoiding the problem of losing all data in the database (see D6, paragraph [0005]). The initial copies of the database contain duplicates of one or more tables, and one of the copies might be a master copy (D6, paragraph [0025]).

D6 explains that changes are made to a schema of a first copy of a database and that a migration script reflecting those changes is sent to other copies of the database to propagate those changes (D6, paragraphs [0016] and [0028]). The "newly changed schema of the local database" is accessed in order to compare the schema stored in the history folder to the newly changed schema of the local database and in order to generate a database migration script based on the determined changes (D6, claim 6 and paragraph [0028]). Examples of changes to the database are "addition or subtraction of fields in existing tables" (D6, paragraph [0033]).

Finally, according to D6, the migration script is transmitted, for example via electronic mail, to other databases for execution (D6, claims 1, 8 and 11, paragraphs [0038] to [0042]). The changes may be delivered to the server, which maintains the master version (D6, paragraph [0029]).

Conclusion

6. In summary, the Board considers that the subject-matter of the independent claims involves an inventive step with respect to document D5 and that, for this reason, the Examining Division's decision cannot be upheld. However, before a patent can be granted, the claimed subject-matter has to be examined in the light of document D6 introduced by the Board into the proceedings. Should the Examining Division identify patentable subject-matter, the more formal requirements of the claims would also need to be examined.

7. Considering that new and more relevant prior art was introduced at a late stage in the appeal proceedings, and in order not to deprive the appellant of the possibility of having the issue of inventive step considered by two instances, the Board finds it appropriate to make use of its powers under Article 111(1) EPC and to remit the case to the department of first instance for further prosecution as requested by the appellant.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the department of first instance for further prosecution.