T 0757/05 (Document production/UMEN) of 25.4.2008

Summary of Facts and Submissions

I. This appeal is against the decision of the opposition division to revoke European patent No. 0 832 462 under Article 100(c) EPC 1973 because the main request (claims as granted) and all auxiliary requests infringed the requirements of Article 123(2) EPC.

II. In the statement setting out the grounds of appeal the appellant (proprietor) disputed the opposition division's reasoning about the refused main request and filed a first auxiliary request with some minor amendments. The appellant requested that the decision under appeal be set aside and the case be remitted to the department of first instance for further prosecution on the basis of the main request (claims as granted), or the first auxiliary request. Respondents 01 (opponent 01 - Glaxo), 03 (opponent 03 - Merck), 04 (opponent 04 - Bayer) and 05 (opponent 05 - Ortho-McNeil) filed responses and requested that the appeal be dismissed. Respondent 02 (opponent 02 - CDC) did not make any submissions.

III. In the communication accompanying the summons to oral proceedings, requested on an auxiliary basis, the Board summarised the issues to be discussed. In a reply, the appellant filed a second auxiliary request with minor amendments. The appellant also withdrew the request for oral proceedings and stated that he would not be attending them. Respondent 04 (Bayer) did the same. Respondent 01 (Glaxo) filed a response and announced the intention to bring several accompanying persons and explained their background and the nature of their submissions.

IV. At the oral proceedings only respondents 01 (Glaxo) and 03 (Merck) attended and they requested that the appeal be dismissed. This had also been requested in writing by respondents 04 and 05. The appellant had requested in writing that the decision under appeal be set aside and the case be remitted to the department of first instance for further prosecution on the basis of the main request (claims as granted), or the first or second auxiliary request as submitted with the letters dated 11 August 2005 and 5 March 2008. At the end of the oral proceedings, the Chairman announced the decision.

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

"A method for producing a document (44) pertaining to a study of a medical product, comprising:

a) entering and storing data objects (34) pertaining to the study into a computer database (24);

b) providing at least one medical product document template (42) specifying a predetermined order and format for at least a subset of said data objects, and having standard text portions (34);

c) retrieving said subset of data objects from the database (24); and

d) reproducing, in a document compatible with a document publication system, said retrieved data objects and said standard text portions in the order and format specified within the template (42);

characterized in that:

said entering and storing step comprises the steps of:

providing a first electronic document containing said data objects and having code delimiters (<D>,<d>,<T>,<t>) identifying a type and contents of each of said data objects contained in the first electronic document; and

retrieving said data objects from the first electronic document and storing the type and contents of each of said data objects in the database."

In claim 1 of the first auxiliary request feature d) reads:

"d) reproducing, in a document compatible with a document publication system and with a word processing system, said retrieved data objects and said standard text portions in the order and format specified within the template (42);"

In claim 1 of the second auxiliary request feature d) reads:

"d) reproducing, in a document compatible with a word processing system, said retrieved data objects and said standard text portions in the order and format specified within the template (42);"

VI. The appellant argued essentially as follows:

The "type" of object referred to in claim 1 represented only the distinction between detail objects and text objects. Paragraphs [0024] to [0027] of the patent described that each study entry in the database was implemented as one or more detail files and at least one text object file, each file having the study identification code as the first part of its filename, followed by an extension identifying the type of file.

Therefore, the storage of a type of data object was expressly disclosed as the storage of a text object as one type or the separate storage of detail objects as another type.

From paragraph [0031] and Figure 2 it was clear that different types of data objects stored in the database were handled in different ways, for example by embedding of one type of data object within another, which required a distinction between those different types in the database. Claim 3 of the patent also supported this.

The update procedure described at paragraphs [0049] to [0052] disclosed scanning a document containing different types of data objects and storing them in the database. There was therefore explicit disclosure of storing the content of the data objects. However, in order to store properly such data objects in the database, the type of each data object was also stored.

An example of how the data was stored was given at page 5, lines 27 to 28, namely that the database was organised by "using the study identification code as the first part of each filename within a study entry, followed by an extension identifying the type of file". The skilled reader would have known that this could be implemented using file extensions like .D01, .D02, .D03 for storing detail objects and file extensions like .T01, .T02, etc. for storing the text object files.

Under these circumstances, the most reasonable interpretation of the feature objected to was linked to a top level classification "text object" or "detail object" even if further information on a lower granularity, as defined by the opposition division, was additionally found.

Even if the "type" of a data object were taken to be a "unique object identifier", the skilled person would have realised that these "types" were also stored in the database, since some form of unique identifier must be used and stored for each object.

The feature objected to was covered by the principles set out in G 1/93 because it did not provide a technical contribution to the claimed subject-matter and merely limited the protection of the claim.

VII. The respondents, in particular respondent 01, argued essentially as follows:

The opposition division was correct in finding various levels of "granularity" in the meaning of the term "type", so that "storing the type" could not be derived directly and unambiguously from the subject-matter of the application as filed.

There was an asymmetric handling of the "type" of an object and its contents. The contents could be changed during the update procedure, but there was no disclosure of changing the "type". Changing the "type" was also not compatible with the rest of the disclosure, which was that the structure of the study database was defined "up front". There was no disclosure that the structure could be changed afterwards. Hence, "type" of a data object should rather be considered to relate to the various categories of details, such as listed in Table 1 of the patent, or to the various categories of text objects, such as listed in Table 2 of the patent. There was, however, no original disclosure that the type should be stored at this level of granularity.

Since the amendments involved addition of subject-matter (i.e. unsupported "storing the type"), the appellant was in the "inescapable trap" and could neither keep them in, nor delete them from the claims.

Reasons for the Decision

1. The patent concerns the problem of simplifying the drafting of different types of documents necessary at different phases in a study of a medical product (paragraph [0010]).

2. This is achieved by providing templates for each of the required documents 80 (Figure 7) containing the text of the document 82 and codes (e.g. 84 - DETAIL 1, or 88 - TEXT 1) designating the information required from the study for the different parts of the document. This information is contained in a clinical study database 24 (Figure 2) in the form of "detail files" 32, relating to small objects such as the name of the drug, and "text object files" 34, relating to larger objects such as the objective of the study (see paragraphs [0024] to [0026]). The system automatically generates a document 80a by inserting the data from the database in the relevant parts of the template (paragraph [0040]). When it inserts the data, it also marks it with a delimiter code pair (e.g. 84a - <D1>...<d>, or 88a - <D2>...<d>).

3. The data can be entered directly into the study database (paragraphs [0027] to [0030]), or from previously generated documents via an essentially inverse (paragraph [0052]) update procedure. In the update procedure, the delimiter codes in an already completed electronic document are used to locate the relevant data which is then stored in the database (paragraphs [0048] and [0049]). The update procedure is the subject of the characterising part of claim 1.

4. The update procedure was defined quite well in originally filed claim 8, which specified in feature d) "storing in said database said data objects retrieved from said previous document". Unfortunately, the amendment introduced into the granted patent additionally specified, "storing the type ... of each of said data objects", which the opposition division considered to be an extension of subject-matter. The present decision is based on an assessment of this objection in the light of the parties' arguments and not on any possible objections to patentability.

5. There is much discussion of the interpretation of the term "type" of the data objects in the parties' submissions. Three possibilities have been discussed.

6. Firstly, the proprietor, now appellant, argues that the "type" simply represents the distinction between detail objects and text objects. In support of this, the appellant cites paragraphs [0024] to [0026] of the patent, in particular that each study entry in the database is implemented as one or more detail files and at least one text object file, having the study identification code as the first part of its filename, followed by an extension identifying the type of file. Thus, when the object is stored in the database, the "type" must also be stored by virtue of this filename.

7. Secondly, the opponents, now respondents, and the opposition division consider that the disclosures of "each text object type" at page 7, lines 43/44 and "type of detail" at page 15, line 54 imply a lower level of "granularity". This is the distinction between the different categories of text and detail objects defined in Tables 1 and 2 of the patent, e.g. the name of the drug, or the objective of the study discussed in paragraph 2 above. It is argued that when the content of an object is stored, the individual category is not stored with it. Because of the different possibilities for defining "type", it is not directly and unambiguously derivable that the type of the object is stored.

8. Thirdly, the parties discuss a third "type" of even lower granularity, namely each specific object, e.g. a particular drug name. In the Board's view, this does not play a role in the present decision.

9. The Board first turns to the wording of the claim, which is where the term "type" is to be interpreted. The beginning of the characterising portion of the claim defines that code delimiters (<D>,<d>,<T>,<t>) identify a type and contents of each object in the document. The description of the study update procedure in paragraphs [0048] to [0052] and Figure 7 gives further information about the code delimiters and explains how they are used. In particular, paragraph [0050] states that the update procedure:

"...will locate the detail delimiter <D1> indicating the start of the detail text 84a and identifying the type of detail so delimited. Then, the text 84a between the delimiters <D1> and <d> will be retrieved and placed into the detail file of the selected study at the location where the specified detail resides." (Board's emphasis).

The same procedure applies to the detail delimiter <D2> and also for the text delimiter <T1>.

10. The appellant interprets the distinction made between the detail and text "type" as implying that the "type" is stored. However, the Board comes to a different conclusion about the interpretation of these passages. In particular, the Board considers that the separate specification of "the type of detail" and "the specified detail" for the detail delimiters <D1> and <D2> distinguishes between different detail delimiters and is not compatible with the appellant's idea that the "type" is only detail or text. Rather it implies the finer granularity alleged by the opposition division and the respondents, namely the type of detail or text object possible in the various different documents, as listed for example in Tables 1 and 2.

11. Concerning the question of what is actually stored, the Board considers that the passages only disclose that the contents of the objects are stored, but not the type. Moreover, the Board agrees with the respondents that the fact that the contents are stored at the "location where the specified detail resides" implies that the study database has already been set up prior to the update procedure with fixed locations for the various possible details or texts in each study, so that the "type" does not need to be stored. The pre-determined and fixed structure of the database is further supported by the discussion of the manner of manual data entry of the detail and text objects in paragraphs [0028] to [0030]. Although manual data entry could in principle be more flexible than the automatic update procedure, the allowable entries are nevertheless only mentioned as being associated with a clinical study protocol. Figures 5 and 6 show examples of forms used to enter the data. In these forms, the fields or "types" of data that can be entered are fixed by the protocol and it is only possible to store or change the contents of a field. The Board finds no disclosure of the capability of the user, and therefore by analogy the update procedure, to change the structure of the protocol itself, in particular to change or add any "types".

12. The Board has considered whether there is an implicit disclosure of storing the "type" under any interpretation of the term by virtue of the fact that in a database the content of the object is always associated with its type so that storing the content automatically implies "storing" its type. However, the Board considers that in the context of the type and contents of each object identified in the method of claim 1, one would not use the wording "storing the type and contents of each of said data objects in the database" to cover this operation, but rather a wording along the lines of "storing the associated contents in the database". The chosen wording, however, covers the step of explicitly storing the type, which as explained above, is not considered to be disclosed in the original application.

13. Thus, the Board concludes that the term "type" has at least the second level of "granularity" alleged by the opposition division and respondents, and that it is not directly and unambiguously derivable from the original disclosure that this is stored. This feature therefore extends beyond the content of the application as originally filed.

14. Since the appellant has not attempted to delete the offending feature, there is no need to consider the appellant's argument based on G 1/93, nor the respondents' comments about the "inescapable trap".

15. Accordingly, since claim 1 of all requests contains the extension of subject-matter, the differences in the requests relating only to the feature of the compatibility of the reproduced document, none of them are allowable (Article 123(2) EPC).

ORDER

For these reasons it is decided that:

The appeal is dismissed.