T 2164/08 (Objects to tables/i2) of 14.4.2011

Summary of Facts and Submissions

I. European patent application number 96 913 086.3 published under the international publication number WO-A-96/34350 claims priorities from two earlier patent applications filed in 1995 for an invention related to the modelling of object-oriented database structures and their translation to relational database structures.

II. The applicant, after having made various attempts in the course of the European examination to respond to the objections of the examining division, filed three sets of amended claims as main, first, and second auxiliary requests, respectively, by letter dated 2 May 2008, claim 1 of these requests reading as follows (numbered angle brackets **(1)<>, **(2)<> etc. are added for convenience of reference):

Main request

"1. A system, comprising

means (210) for receiving a description of a user's object database (100), said user's object database having a set of classes (101) and a set of relationships (103) between pairs of said classes;

means for creating a model (230) of said user's object database in response to said description;

means for creating a relational database (250) in response to said model (230), said relational database having a set of tables, keys for said tables, and relationships between pairs of said tables implementing said classes, objects and relationships of said user's object database;

means (211, 212, 213) for receiving a set of data objects for said user's object database;

**(1)<characterised in that the system comprises>

means for translating said set of data objects for said user's object database into a set of records for said relational database, and for inserting said set of records into said relational database;

means for receiving updates to said description of a user's object database;

means for updating said model (230) in response to said updates;

means for updating said relational database in response to said means for updating said model; and

means for updating said set of records for said relational database in response to said means for updating said relational **(2)<database.>"

The changes in claim 1 of the first and second auxiliary requests are as follows:

First auxiliary request:

**(1)<...> deleted;

**(2)<database.> replaced by: "database,

characterised in that the means for creating the model (230) and the means for updating the model (230) are arranged to build and edit classes and relationships between classes."

Second auxiliary request:

**(1)<...> deleted;

**(2)<database.> replaced by: "database,

comprising means for receiving a triggering signal, wherein said means for updating said relational database operates in response to said triggering signal, characterised in that the triggering signal comprises a sufficient change in the model (230), a triggering command in a text file, or an end of file condition."

III. In a decision posted on 11 July 2008, the examining division refused the application for lack of clarity in claim 1 of all requests. Under the heading "Obiter dicta", additional objections were raised against claim 1 of the main request for lack of novelty and against claim 1 of the auxiliary requests for added subject matter. The objection concerning novelty was based on the publication M. Kisworo et al., "Implementation of an Object-Oriented Front-End to a Relational Database System", Proceedings of the 1990 IEEE Region 10 Conference on Computer and Communication Systems (IEEE TENCON'90), vol. 1, pages 811-815 (cited as document D6).

IV. The appellant (applicant) lodged an appeal against the refusal of its application on 8 September 2008, paying the appeal fee on the same day. By letter dated and received by the EPO on 10 November 2008, the appellant submitted a statement setting out the grounds of appeal, including three sets of amended claims for replacement of the claims then on file.

V. In a communication summarising the results of the preliminary examination of the appeal, the Board raised objections of lack of clarity and added subject matter to the newly filed claims; regarding the previous version of claims filed on 2 May 2008, the Board took up and sustained the objections raised by the examining division obiter dictum in the decision under appeal.

VI. By letter dated 14 December 2010, the appellant re-presented the claims filed on 2 May 2008, dropping the claims in the version filed with the statement of grounds of appeal. Following summons to oral proceedings scheduled for 14 April 2011, the appellant's representative informed the Board by letter dated 25 March 2011 that he would not be attending the oral proceedings, but nevertheless presented further arguments in support of his case.

VII. At the oral proceedings on 14 April 2011, no-one appeared on behalf of the appellant.

VIII. According to the submissions in writing, the appellant requested that the decision under appeal be set aside and a patent be granted on the basis of the claims filed on 2 May 2008 as main request and as first and second auxiliary requests.

IX. The appellant's arguments submitted in writing may be summarised as follows:

The invention was novel over prior art document D6. This document disclosed a front-end add-on to a database system for a relational database which had already existed from the outset. In contrast thereto, the present invention started from an object database. The aim of the invention was the creation of a relational database based on such an existing object database. Neither document D6 nor any other prior art provided guidance how to translate the objects and relationships of the object database model into corresponding relational structures.

In particular, a relational database with the feature of having tables and "keys for said tables" was not anticipated by document D6. Even if keys were a normal feature of relations systems, which was not conceded, the present application was patentably distinguishable from the prior art. The examining division erred in equating the "keys" defined in claim 1 with the "pointers" cited in document D6. These were well-known but very different concepts. The term "key" as used in the context of database technology sharply contrasted with the term "pointer". A "key" was a field or a group of characters within a record that uniquely identified the record and which thus could be used to sort or identify data. A pointer pointed to another address or value and would be used to define a relationship between keys or to provide a link between tables. These were important distinctions which had to be considered in judging the novelty of the present invention.

Referring to the objections of added subject matter, the appellant submitted that it was clear to the skilled person from the disclosure of the specification as a whole that the process of building and editing the user's database model included arranging the means for creating the model and the means for updating the model to build and to edit classes and relationships between classes. The added feature could be clearly derived from page 12, lines 4 to 10 (citations of the application as filed refer to the international publication of the application).

A similar argument applied in relation to the second auxiliary request. The additional limitation concerning the means for receiving a triggering signal had a clear basis in page 12, lines 18 to 24 (sic; the Board assumes that lines 26 to 32 are intended). This passage referred explicitly to "a sufficient change in the user database model" as a possible triggering signal.

Reasons for the Decision

1. The appeal, although admissible, is not allowable since the main request does not comply with the requirement of novelty (Article 52(1) EPC and Article 54(1) and (2) EPC 1973) whereas the first and second auxiliary requests do not comply with the requirement of Article 123(2) EPC that amendments should not extend the subject matter of the application beyond the content of the application as filed.

Main request

2. The subject matter of claim 1 of the main request is not new since it is already disclosed in document D6.

2.1 In fact, this document relates to an IBM DB2 relational database system in combination with OOSQL, an object-oriented SQL front-end application implemented on top of the DB2 relational database (see the abstract, the introduction at page 811, left-hand column, penultimate paragraph, and section 3.4 (at page 814). This combined prior art system (in the following referred to as the "DB2 system") corresponds to and fully anticipates the system defined by claim 1 of the main request.

2.2 The DB2 system starts from a conceptual representation of the real world in terms of objects and inter-object relationships in a Semantic Entity-Relationship Model (SERM) used as data model (section 1 at page 811). The concrete realisation shown in figures 1 and 2 at page 815 as an example is a structured collection of user-relevant data about the real-world and can thus be termed a user's object database in the sense of present claim 1. An important support for such a construction of claim 1 is provided by figure 2 of the present application, which shows the user's object database 100 as a "conceptual" data model very similar to the SERM schema shown in document D6, figure 1 at page 815.

2.3 The objects of the SERM schema disclosed in document D6 include classes (OBJECT , PERSON etc.), relationships between pairs of objects (ISA, DEPENDENT etc), and individuals within the database (John Doe etc.) as illustrated in figures 1 and 2 at page 815.

2.4 Moreover, as explained in sections 2.3 and 2.4 at page 812 and section 3.1 at page 812 f., the OOSQL syntax includes OOSQL commands (CREATE ...) for defining, creating, and updating objects of the data model. A first layer of the OOSQL front-end responsible for the interactive dialog receives the commands for defining and creating objects. The first layer of the OOSQL application, therefore, constitutes a means in the sense of present claim 1 for receiving a description of the user's (conceptual) object database (SERM schema).

2.5 OOSQL creates and stores the objects of the data model and creates a model of the user's object database by providing an object catalogue (see last paragraphs of section 3.1 at page 813, right-hand column and section 3.3 at page 814, right-hand column). OOSQL is thus a means in the sense of present claim 1 for creating a model of the user's object database in response to the description of the user's object database.

2.6 In response to OOSQL commands, a second and a third OOSQL layer (see section 3.4) create tables and catalogues, the constitutive elements of a relational database (DB2 tables, internal tables etc, data dictionary, object catalogue etc, see sections 3.3 and 3.4 at page 814).

The tables created also contain an object identifier (OBJ$ID), which is a unique identifier of the object, and the name of the object (OBJ$NAME), which is unique for the objects within the same object type (see for example the second paragraph of section 2.4 at page 812, right-hand column and section 3.3 at page 814). Both identifiers are accessible by the user; the name of the object may also be externally used to identify an object for the user (loc. cit.). It follows that these identifiers are "keys" within the ordinary scope of meaning given to the term in the field of database technology.

The distinction drawn by the appellant between pointers and keys is not convincing: The two terms are not mutually exclusive; the object identifier OBJ$ID could be used as pointer for identifying an object within a link but it could as well be used as sorting parameter and thus as key for the table OBJ$OBJ forming part of the OBJECT catalogue (see section 3.3 at page 814).

2.7 The first OOSQL layer is a means in the sense of claim 1 for receiving a set of data objects for the user's (conceptual) object database, which the DB2 system then stores as objects and translates into records of the relational database (SQL relational database system, see section 1. at page 811 and section 3.4 at page 814).

2.8 Furthermore, the DB2 system also provides, in the sense of claim 1, a means for receiving updates to the description of the user's object database (the first layer, see above), a means for updating the model in response thereto (the second layer in executing the UPDATE method, see the third paragraph of section 2.4 at page 812, the last paragraph of section 3.2 at page 814, and the first paragraph of section 3.4 at page 814), and a means for updating the relational database and the records of the relational database (the third layer, see the last paragraph of section 3.2 at page 814).

2.9 It follows that all features of the system of claim 1 are anticipated and that consequently the novelty of the system is destroyed by document D6.

First auxiliary request

3. The additional feature of claim 1 of the first auxiliary request that the "means for creating the model" and the "means for updating the model" are arranged to build and edit classes and relationships between classes is not derivable from the application as filed, and in particular not from the text portion at page 12 cited by the appellant. Nowhere in the corresponding section, starting at page 11, line 21 to the end of page 12, is there any link between an arrangement of the means for creating and updating and the process of building and editing the user database model.

At page 11, line 22 ff. the application actually assigns the role of building and editing the user database model to user interface 210, without it being clear from the application what the actual relationship is between the means for creating and updating as defined in claim 1 and interface 210.

The text portion cited by the appellant does thus not support the original disclosure of the feature in question.

Second auxiliary request

4. The additional feature of claim 1 of the second auxiliary request defines a triggering signal comprising a sufficient change in the model (230), a triggering command in a text file, or an end of file condition. The means for updating the relational database operates in response to the triggering signal.

However, as the examining division has pointed out, the text portion at page 12, last paragraph, cited by the appellant to prove due disclosure of this feature, describes a "triggering event" for translation of the user database model (rather than for updating it). The functions of the triggering signal as claimed and the triggering event as described are apparently not identical or technically equivalent and the relation between the definitions remains unclear. Therefore, the passage cited cannot provide support for the original disclosure of the feature in question, nor can any other part of the application as filed.

5. In summary, none of the requests before the Board include claims which could form the basis for the grant of a patent.

Order

For these reasons it is decided that:

The appeal is dismissed.