T 2091/10 (Virtual documents/US LYNX) of 24.10.2014

Summary of Facts and Submissions

I. This appeal is against the Examining Division's decision to refuse European patent application 04777955.8. The application was refused for lack of inventive step in the light of document D1 (WO 99/66425).

II. With the statement setting out its grounds of appeal, the appellant filed a new main and a new auxiliary request. The appellant requested oral proceedings, if neither the main nor the auxiliary request was allowed.

III. The Board arranged oral proceedings and set out its provisional view of the case in a communication sent with the summons.

IV. In response, the appellant submitted further arguments.

V. At oral proceedings held on 24 October 2014, the appellant requested that the decision under appeal be set aside, and that a patent be granted in the form according to the main request or else of the auxiliary request, both of which were filed with the statement setting out the grounds of appeal.

VI. Claim 1 according to the main request reads as follows:

An automated document publishing system comprising:

a document type store containing data defining a plurality of document types, each document type identifying a document structure definition for use in the construction of a plurality of instances of virtual document editions, each document structure definition comprising a complete hierarchy of element definitions capable of defining a plurality of instances of virtual document editions having different hierarchy instances of element definitions which are incomplete compared with the universal hierarchy;

a business data store containing business data;

a content library store containing a library of content components, each component being capable of use in a plurality of documents;

an element store containing a plurality of elements for use in the construction of a document edition, each said element being defined by a said element definition and having a pointer to a said component, and said element definitions defining rules and attributes;

a document manager for using a selected said document type, said business data, said elements and said rules and attributes to form a document structure for a document edition to identify a plurality of said elements forming a hierarchy instance, each said element having a pointer to a said component and/or at least one other said element, said elements including rules related to said business data and attributes, and child elements in the hierarchy instance capable of inheriting rules and attributes from parent elements in the hierarchy instance;

a document structure store storing at least one said document structure for at least one respective instance of a virtual document edition to be published; and

an output system for forming at least one structured serial document for publishing using the at least one stored document structure.

VII. Claim 1 according to the auxiliary request appends the following:

...;

wherein said document manager is adapted to autopopulate said document structure by selecting and evaluating candidate elements against said business data, or by using a said document structure of a previous edition and re-evaluating the elements and pointed to components against said business data.

VIII. The appellant's arguments can be summarized as follows.

The invention produced virtual documents, where a virtual document was one which contained pointers to content, rather than the content itself, which was stored elsewhere. Thus, more than one document could make use of the same content, each by pointing to it. If some content had to be modified, it would not be necessary to find all the documents containing it. Rather, each such document would just find itself pointing to the modified version. According to D1, on the other hand, only static documents were produced. If a modification were needed, it might be made in only one of the static documents; or it would be necessary to reflect the changes in each of them.

The invention relied on a particular way data was stored in a computer, namely, in a hierarchy that represented the structure of the document. While D1 did disclose that data might be shown hierarchically, it did not indicate any particular manner of storage in a computer. In particular, if Figure 4 of D1 did show a hierarchy, that was no more than a convenient representation the draftsperson had chosen, rather than an indication that the data should be stored in that way. Indeed, it could not be such an indication, because "Warehouse Fire" could not reasonably be understood as a unifying hierarchical element for the insertions 12a, 12a' and 12b. Another way of expressing this was that the hierarchy shown in Figure 4 of D1 existed only in the mind of an editor, say, rather than in the way the data was stored in the computer.

The term "universal hierarchy", used in the claims, should be understood as synonymous with "complete hierarchy".

The terms "complete hierarchy" and "incomplete hierarchy" should be understood as a pair. The former should be understood as possibly comprising more elements than the latter, the latter as possibly comprising fewer than the former. The user of the invention would be presented with a collection of elements, and would keep those needed for a particular document; thus proceeding from a "complete" hierarchy to an "incomplete" one. "Complete" should not be understood as implying that some other elements could not, later, be added. The user of the system disclosed by D1 was not presented with a complete hierarchy, but only with a collection of possible content. The content would then have to be fitted, somehow, into a document without the system providing any guidance in terms of hierarchical elements.

The term "serial document", used in the claims, meant the final output, in which the content to which a virtual document merely points, is actually contained within the document.

Reasons for the Decision

Introduction

1. The invention concerns the automated generation of documents. The context is that several people may cooperate in preparing, composing, and publishing a set of documents that may share some structural elements and content.

2. A document may have to comply with some set of rules. A particular logo might be required on the front page, for reasons of corporate identity, or some particular material might be required by law.

3. It is often the case that some particular content is used several times in the same or different documents. Examples would include a header that appears at the top of each page, the name of a newspaper that appears on the front page of each edition, and a table of financial data used in different prospectuses. One of the aims of the invention is to make such re-use simple.

4. The invention does not represent documents as simply a string of alpha-numeric characters (e.g. as a "flat ascii" file). Rather, a document is represented as a hierarchy of elements which comprise pointers to their contents. Thus, if some content is contained in, say, ten different documents, each of the documents has one or more element that points to it. If the content is modified, the documents do not need to be changed; it is enough that what they point to is now different.

5. The hierarchical structure means that child elements can inherit properties from their parents. Thus, if a document has the property "language = Swedish", all the elements of that document can inherit the same language.

The main request

6. The Board finds that D1 discloses the following features defined in claim 1.

6.1 A document type store.

The Board cannot follow the appellant's assertion that D1 does not disclose data defining a plurality of document types. In particular, the argument that the references to a "logical data structure" do not indicate a plurality of document types does not seem relevant. Figure 4 of D1 shows three documents (D1 calls them "insertions"), all connected to a story on a "warehouse fire". If it could be disputed that the articles for page 3 and for page 8 are really different types of documents, that is because the present application does not clearly explain how one type of document differs from another. However that may be, the Board is satisfied that the page 3 version and the web version (D1, Figure 4, blocks 12a and 12b) can be viewed as different types of document.

6.2 Complete and incomplete hierarchies.

The appellant accepted that the terms "complete" and "incomplete" do not appear in the application as filed, but considered that they were nevertheless intelligible to the skilled reader. The appellant, in particular, explained that complete and incomplete hierarchies should be understood as forming a pair: the user is presented with an initial hierarchical structure, but could choose to discard those elements which were not needed for the present document, thus leaving a hierarchy with fewer elements. Thus, "complete" and "incomplete" mean nothing more than that the latter is a proper sub-hierarchy of the former. The appellant also explained that the term "complete" should not be interpreted as meaning that no further elements could be added, because it was entirely possible that the user, after producing the sub-hierarchy and providing it with content, might want to add some element that had not been in the original hierarchy. The appellant also submitted that the term "universal hierarchy" should be treated as synonymous with "complete hierarchy".

In the light of the appellant's explanations, the Board is satisfied that what D1 calls "components" and "insertions", which can be "partially or fully defined a priori" (D1, page 16, lines 5 - 8), such as predefined "content and insertions for a given page in a given publication" (D1, page 22, lines 8 - 10) or "logos, page number identifiers, templates, etc." (D1, page 22, lines 17 - 18), can be considered as providing a "complete hierarchy". Since some components and insertions can be edited (D1, page 26, lines 7 - 12), it is inherent that a sub-hierarchy can and will be generated.

The appellant's argument that any hierarchy in D1 is merely a convenient representation, rather than, as in the invention, an integral part of how data are stored, is not convincing. It seems to draw a distinction between storing data which happens to be hierarchical (which D1 does) and storing data as a hierarchy (which the appellant asserts the invention does). The Board does not see any clear distinction between storing "a ... hierarchy of element definitions" (claim 1) and what is shown in Figure 4 of D1, which is a collection of element definitions, arranged hierarchically, and stored.

The Board is, therefore, satisfied that D1 discloses both complete and incomplete hierarchies.

6.3 The ability to produce different virtual document editions.

The appellant explained that a "virtual document" should be understood as one with pointers to content, rather than copies of content.

The system of D1 seeks to avoid that "the same content must be duplicated for each publishable instance" (D1, page 3, lines 21 - 23). One way the system of D1 does that is by providing what it calls "linked" content (D1, page 30, line 24 - page 31, line 18). It is significant that "linked content is not multiple copies of the same data, but rather, a single copy of data that is logically linked to different insertions". The Board cannot see any distinction between that and a virtual document as the appellant described it.

6.4 A business data store.

The appellant does not contest that D1 discloses this. Examples given in the application are that "many documents ... have mandated content" and "most business and government documents follow a consistent template..." (published application, page 10, lines 25 - 32). The inclusion of a particular logo would be an example, and D1 explicitly discloses that (D1, page 22, lines 17 - 18).

6.5 A content library store.

The appellant has not disputed that D1 discloses this. The collection of predefined content and insertions (D1, page 22, lines 21 - 23) is one example.

6.6 An element store.

The content in the system of D1 is stored (D1, Figure 4, "components" 14a, b, c, d, for example), and components may comprise pointers to actual content. D1, page 27, lines 9 - 10 explains that "the user can indicate in the insertion that the content exists as an archive", but, as the content is not destined to be placed randomly in the insertion, but rather in a particular component, it is clear that when the user indicates "in the insertion", the computer must store a link from the corresponding component. D1 (page 31, lines 6 - 11) explains that, when components of different insertions have the same content and changes to one component are reflected in the others (D1 uses the term "linked"), there are not multiple copies (one for each insertion) but a single copy that is logically linked to the insertions. Again, the link must be associated with a particular component.

One of the possibilities the system of D1 provides is that a user may define "details related to preexisting content, shape, size and other dimensional characteristics" (D1, page 22, lines 11 - 13). In the Board's view, pre-defined content, shape, size etc amount to "rules and attributes".

The Board, therefore, is satisfied that D1 discloses an element store as claimed.

6.7 A document manager.

Most of the definition of this feature in claim 1 is a repetition of what has already been defined, and amounts to saying that the previously-defined features are actually used to do what they were put there to do. Since the corresponding features in the system of D1 also do what they were put there to do, there is, with one exception, no further issue as to novelty.

The one exception is that according to the claim, "child elements [are] capable of inheriting rules and attributes from parent elements." The Board is satisfied that D1 discloses inheritance: "An insertion ... operates as an instruction set for a given subset of components" and "... for example, an insertion defines the particular form (e.g. format) that the components ... will take ..." (D1, page 16, lines 6 - 10). This is a straightforward instance of lower elements in the hierarchy, e.g. components 14a, b, c, and d of Figure 4, inheriting "rules and attributes" from a higher element, e.g. insertion 12a of Figure 4. In the light of this, the Board rejects the appellant's assertion that inheritance in D1 can only be identified by applying knowledge of the present invention. D1 is explicit on this point.

The Board, therefore, is satisfied that D1 discloses a document manager as defined in claim 1.

6.8 A document structure store.

This feature says no more than that some virtual document is stored. Since it has already been established that the system of D1 produces a virtual document, its storage is inevitable.

6.9 An output system.

This feature produces as "serial document". That is, a document which actually contains its content (as opposed to simply pointing to content). It is, of course, the purpose of the system of D1, to produce some actual document, be it page 3 or page 8 of a newspaper, or a web edition. A physical page of a newspaper comprises its content. It does not simply inform readers where to look for the contents of paragraph 1. Thus, D1 produces a "serial document" and the Board concludes that D1 discloses an output system as claimed.

7. The Board, therefore, finds that D1 discloses all the features defined in claim 1. What is more, since D1 sets out a single system, the individual features are disclosed in combination. The Board's conclusion, therefore, is that the main request cannot be allowed for lack of novelty (Article 54 EPC).

The auxiliary request

8. Claim 1 adds "autopopulation" and the re-evaluation of elements "against ... business data".

9. By "autopopulation", the Board understands that some content is automatically included. In the system of D1, it is possible "to predefine content and insertions for a given page in a given publication zone/edition/medium." The Board sees that as "autopopulation".

10. The re-evaluation amounts to checking whether the contents of a document still comply with business requirements. D1 discloses that "...insertions are created based on publication configuration and scheduling information ... " and "... it will be impossible to schedule an editorial story for publication in an invalid publication ..." (D1, page 7, lines 20 - 24). The data defining these limitations are stored in the "a priori database". This database is used, for example, to enforce restrictions (D1, page 25, lines 6 - 8). It is, of course, the case that the restrictions are applied for each publication at the relevant time. In particular, when content is re-used (D1, page 27, lines 3 - 10), the restrictions will be considered.

11. The Board concludes that the subject matter of claim 1 is not novel and that the auxiliary request cannot be allowed.

Order

For these reasons it is decided that:

The appeal is dismissed.