T 2518/10 (Shape-based charting/MICROSOFT) 23-11-2016

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

2. The invention

2.1 The application relates to rendering and manipulating charts, such as pie-charts, bar-charts, histograms, etc. According to the technical background described in the application, different application programs have traditionally rendered charts differently. This has the consequence that a particular chart may have a slightly different appearance in different application programs. When a chart is copied from one document of a first application to another document of a second application, it can be pasted as either a chart object or a picture. Pasting as image has the disadvantage that the user can no longer manipulate the underlying data of the chart as the chart is severed from the underlying data, whereas pasting as chart object can lead to a lower quality presentation of the chart.

The motivation of the invention is described in paragraph [0006] of the description as rendering and manipulating charts consistently across applications and providing a consistent, high-quality presentation of charts while enabling users to manipulate underlying elements of the chart.

2.2 The invention proposes that a chart is translated from a chart object in a document to a shape-based definition. The chart object defines the chart in terms of chart elements, such as bars for a bar chart, chart axis, chart legends, chart labels and so on (see paragraph [0017]), and provides references to data sources of the underlying chart data on which the chart is based. Shapes, such as lines, rectangles, circles, triangles, and so on (see paragraph [0022]), represent the visual appearance of a chart element. Although the chart is rendered as shapes, the chart object is maintained to allow for manipulation of the underlying chart data. A "common charting component" provides a common set of functions for allowing the user to manipulate the underlying data of a chart within an application program (see paragraph [0030]). As a result, when the user edits the underlying chart data, the behaviour of the chart is consistent across all application programs. The shape-based definition defines the chart in terms of shapes. The shape-based definition is used by a common graphics module to provide consistent shape rendering services and shape manipulation services for different applications (see description, paragraphs [0012] and [0013]).

3. Main request - admission

Claim 1 of the main request differs from claim 1 of the main request considered by the Examining Division only in containing two minor clarifications: the method is computer-implemented (see for example paragraph [0045] of the description) and the chart object provides references to the data sources of the underlying chart data (see for example original claim 3 and paragraph [0035] of the description). As these amendments did not introduce any complexity and were meant to overcome outstanding objections, the Board sees no reason for questioning the admissibility of the main request into the proceedings under Article 13(1) RPBA.

4. Main request - inventive step

4.1 Document D1 relates to the creation of Scalable Vector Graphics (SVG) pie charts. A content provider (in D1 a user without technical background) takes a sample XML document corresponding to the desired chart type and changes its values. The XML data is transformed by means of XSLT code into an SVG graphic, which can then be displayed (abstract, section "An Example" on pages 2 and 3, and Figure 1).

Document D1 has the goal of avoiding the cost of proprietary tools and achieves it by using SVG to represent pie charts. SVG is an XML-based vector image format for two-dimensional graphics which is usable by different applications. It is an open standard developed by the World Wide Web Consortium (W3C). Document D1 is a suitable starting point for the assessment of inventive step as it supports an application-independent chart representation.

4.2 In the Board's opinion, document D1 first discloses an XML document containing a chart object since the XML snippet shown on the top of page 3 is part of a document which is used to create a pie chart. The chart object specifies the type of chart (pie chart - see "pie.xsd" in the XML snippet) and defines the chart with chart elements (the "component" elements in the XML snippet define slices of the pie chart). The chart definition in the XML snippet contains also the underlying chart data itself since, for example, the "name" attribute of the "component" elements represents the label of each slice and the text node in the "component" elements represents a quantity.

4.3 Document D1 then explains how the chart object is translated into a shape-based chart definition (section "Transformations" on pages 4 to 8). The translation is separated into three distinct transformations, which are discussed in detail and are specific for the type of chart (pie chart). For example, the type of chart dictates how the different "component" elements of the XML snippet are transformed into slices of the resulting pie chart.

4.4 According to D1, the user provides the data in the XML snippet, which is part of the XML document, and the user can access the data in the document (section "An Example" on page 2). Thus, the chart object in D1 is maintained in the document to enable access to underlying chart data contained in the chart.

As a result of the transformation, the pie chart of Figure 1 is created (page 2, section "Rationale", paragraph 4, page 3, section "An Example", Figure 1, and page 8, section "The Result").

4.5 In summary, document D1 discloses a computer-implemented method for rendering a chart comprising steps of determining, translating, maintaining and rendering as recited in claim 1, except that the chart object does not provide references to data sources of the underlying chart data.

4.6 The appellant argued during the oral proceedings that there was a further difference between the subject-matter of claim 1 and the method of claim 1: the XML snippet on the top of page 3 did not correspond to the chart in Figure 1 of D1. This was for example evident from the fact that the last 3 components of the XML snippet were missing in the pie chart. When the user wanted to change the "other" component, it was unclear how to change the chart. Due to the differences between the XML snippet and the chart there was no two-way relationship between the chart and the chart object, and in fact, the underlying chart data were not updated, when the user modified the chart as indicated in section "The Result" on page 8 of D1. Consequently, the shape-based chart definition according to D1 would not define the same chart as defined by the chart object.

4.7 The Board notes that the method of claim 1 does not specify a two-way relationship between the chart and the chart object: there is only a translation from the chart object to a shape-based chart definition, but not the other way around. Moreover the XML snippet of D1 defines the chart of Figure 1, because the resulting chart is completely determined by the XML snippet and the transformation process. Hence, in the Board's opinion, the XML snippet can be regarded as a chart object that defines the chart of Figure 1 (which is rendered based on the shape-based chart definition). It is true that the transformation process in D1 is complex and comprises a sequence of three different transformations. However, multiple transformations are not excluded by the wording of claim 1.

As to the appellant's objection that the shape-based chart definition would not define the same chart as the chart object, it is acknowledged that the transformation of D1 is not a one-to-one transformation of chart components into sections of the pie chart. However, this is also not ruled out by the wording of claim 1.

4.8 The appellant argued also that D1 would not hint at a document that was compatible with many applications.

However, the Board notes that D1 uses standardised formats (XML, SVG) which are compatible with many applications.

4.9 In the Board's opinion, the subject-matter of claim 1 hence differs from the disclosure in document D1 in that

- the chart object provides references to data sources of the underlying chart data, and

- the shape-based chart definition is saved with the document.

4.10 The appellant argued that the problem addressed by the present invention would be to simplify the task to define a chart. However, this problem is not formulated based on the effect actually achieved by the claimed subject-matter, but it implies that the data is required to reside in data sources, because without this non-technical constraint it would be simpler to include the data directly in the chart definition, as it is already done in D1. Hence, starting from document D1, the problem suggested by the appellant cannot be the one actually solved by the claimed method.

4.11 Compared to document D1, the provision of references to data sources of the underlying data has the effect that the user can define a chart by referring to the underlying chart data in data sources without a need to copy this data into the chart object. The user can also edit the underlying chart data in the data sources without a need to access the chart object.

Saving the shape-based chart definition together with the document has the advantage that this definition is immediately available for the rendering of the chart without a need to repeat the translation of the chart object (see also the description of the application, paragraph [0032]).

The advantages of the saving step are independent of the chosen storage location for the underlying chart data (in the chart object or in a data source): the advantages from the saved shape-based chart definition are obtainable simply by reading this definition into the memory. It is not necessary to read again the chart object and/or the underlying chart data. The Board does not see any functional interdependence between the two differences over D1 and thus considers that it is legitimate to apply the problem and solution approach to each of the differences separately starting with different (partial) problems to be solved (see Case Law of the Boards of Appeal of the EPO, 8th edition 2016, I.D.9.2.2).

4.12 Hence, starting from D1, the first technical problem to be solved is how to support a user in creating and editing a chart when the data is stored in existing data sources.

Document D1 points already to the business need to consider underlying chart data that resides in data sources such as data repositories or spreadsheets (see D1, section "An Example", second paragraph). The Board considers that the use of references in the chart object is a straightforward solution as the use of references to point to data in data sources is common general knowledge. For example, it was well known at the priority date from the Microsoft Excel software for the creation of charts. In particular, document D3 (page 609, section "Creating a New Chart", first paragraph) states that: "The snappiest way to create a chart is to select some data - or a single cell within a data block - and press F11. Excel blasts your data, no questions asked, into whatever chart style is the current default, placing the result on a new chart sheet". Furthermore, on page 611, section "Step 2: Specifying the Data to Plot", the data range in Figure 24-2 shows the reference to the data source of the underlying chart data by referring to the positions of the cells in the Excel sheet that were marked when the chart was created. Hence, there can be no doubt that the skilled person as a matter of routine activity could and would consider implementing the claimed solution in the context of charts when trying to solve the problem posed.

4.13 The appellant argued that the content provider in D1 would not edit the XML snippet, but the SVG code.

It is correct that in D1 the content provider can modify the SVG code (see D1, section "The Result" on page 8). However, this does not mean that it would not be necessary or useful to be able to edit the underlying chart data. The content provider can modify the SVG code to adapt the displayed chart according to his wishes. As far as specific details of the graphic display are concerned, this is a reasonable approach. However, when the underlying data need to be changed, it is more intuitive for the user to update the XML snippet. In particular, D1 emphasizes (see abstract, second paragraph) that the content providers are not expected to master SVG.

4.14 Hence, the claimed solution to the first problem lacks an inventive step.

4.15 The second technical problem to be solved in view of document D1 is how to improve the speed of rendering the chart, when the document is opened again later (see description paragraph [0032]).

In the Board's view, a skilled person exercising routine activity could and would consider at least the well-known design option to "trade space for time" when addressing the problem posed: Instead of performing the translation from the chart object each time the document is opened, the shape-based chart definition is stored and retrieved from the document when it is opened. In other words, the skilled person would use more data storage space in order to save processing time in the future. Such a trade-off between space and time is commonplace in computing. It is a routine development which poses in the present case no particular technical difficulty for a programmer as it only requires saving the shape-based chart definition with the document so that it can be read later when the document is opened again.

4.16 The appellant argued that there was no hint in D1 to arrive at the claimed solution. There was no reason why the skilled person would save the SVG graphic of D1 (corresponding to the shape-based chart definition) in the document containing the XML snippet (corresponding to the chart object). The skilled person would rather store the SVG graphic on a central location or a cache, where it could be accessed when needed. Storing the same content in two different formats in a single document was not obvious.

The Board is not convinced by these arguments. When a document containing a chart definition is opened it is desirable to show the user not only a text-based definition of the chart, but also the graphic object. This is due to the fact that the graphic display of the chart is easier to understand than a corresponding textual definition in the chart object. Since the graphic object can be rendered faster based on the SVG graphic, it is obvious to store the SVG graphic together with the XML snippet in order to meet the user requirement to render the chart faster when the document is reopened.

4.17 Consequently, the solution of the second problem is obvious and the method of claim 1 lacks an inventive step, Articles 52(1) and 56 EPC.

5. First auxiliary request - admission

Claim 1 of the first auxiliary request differs from claim 1 of the first auxiliary request considered by the Examining Division in containing the two minor clarifications that are also present in the main request, and in clarifying the last steps in that the user changes the underlying chart data. This feature is supported by paragraph [0029] of the description ("the user edits the underlying chart data and thereby changes the chart object"). As these clarifications resulted from the discussion held during the oral proceedings and raised no new issues, the Board decided to admit the first auxiliary request into the proceedings under Article 13(1) RPBA.

6. First auxiliary request - inventive step

6.1 Claim 1 of the first auxiliary request differs from claim 1 of the main request in that it replaces the last step of claim 1 ("saving the shape-based chart definition with the document") as follows:

"changing, by a user, the underlying chart data and

automatically translating the chart object again into an updated shape-based chart definition."

6.2 Document D1 discloses that the user changes the underlying chart data: the user receives a sample XML document and has to change its values (see D1, page 2, section "An Example", second paragraph). For example, the user needs to change the "name" attribute of the "component" elements of the XML snippet on page 3 of D1 to enter the labels of each desired slice.

6.3 Hence, claim 1 of the first auxiliary request adds the difference over D1 that the chart object is automatically translated into an updated shape-based chart definition after the user has changed the underlying chart data.

6.4 This added difference has the effect that the shape-based chart definition is kept consistent with the underlying chart data. Hence, an updated chart can be rendered to reflect updates of the underlying data. This is useful to support a user (content provider) in defining pie charts that respond dynamically to updated underlying chart data by correspondingly updating the display of the chart.

There is no functional interdependence between this added difference and the difference already identified for claim 1 of the main request (the chart object provides references to data sources of the underlying chart data), which is also present in claim 1 of the first auxiliary request.

6.5 Hence, the additional partial problem to be solved is how to improve the chart generation method of D1 to support charts that respond dynamically to updates of the underlying data.

6.6 Dynamically responding charts were at the priority date per se well known. For example, D4 demonstrates that Microsoft Excel 2003 supported automatic updating of the chart graphic when the underlying chart data was changed (see D4, for example page 11, last paragraph: "In this way, as the data in the XML list change, so does the display in the chart."; page 9, section "Dynamic Chart Sources", first paragraph; page 1, summary).

The skilled person wishing to implement charts that respond dynamically to updates of their underlying data would choose the same solution. Rendering of the updated chart in D1 necessitates that the SVG code is updated beforehand. Hence, a translation is a necessary step of a solution. Performing the translation automatically is an obvious measure for a programmer wishing to achieve a short response time for the user.

6.7 The appellant argued that D1 was silent on the changes to the chart object. If a user of D1 wished to change the chart object, the user could modify the SVG code directly. This was disclosed in D1, section "The Result" on page 8. In D1 there was no motivation for the user to change the data in the XML snippet as there was no one-to-one correspondence between the data in the XML snippet and the chart.

The Board has a different view. The user/content provider in D1 is not expected to be familiar with SVG and hence will normally modify the XML snippet when changes to the chart need to be made based on modified underlying chart data.

6.8 The added difference over the main request can therefore not support an inventive step of claim 1 of the first auxiliary request, Articles 52(1) and 56 EPC.

7. Second auxiliary request - admission

Claim 1 of the second auxiliary request differs from claim 1 of the auxiliary request 2a submitted with the statement of grounds of appeal as follows: It contains the two minor clarifications that are also present in the main request. It adds the step of rendering already present in the main request (and present in original claim 2). Finally, it adds the steps of determining a type of the chart (see Figure 3, reference sign 302) and retrieving data from a data source referenced by the chart object (see original claim 3) to the step of translating (see Figures 2 and 3). As these clarifications and amendments raise no new issues and can be regarded as a legitimate reaction to the Board's communication, the Board finds it appropriate to admit the second auxiliary request into the proceedings under Article 13(1) RPBA.

8. Second auxiliary request - inventive step

8.1 Claim 1 of the second auxiliary request adds the following features compared to claim 1 of the main request:

- the underlying chart data includes data values, labels, and data formats;

- data from a data source referenced by the chart object are retrieved;

- the translating is performed automatically when the document is opened; and

- the chart is edited through a common charting component, the common charting component being used by one or more application programs.

The step of saving the shape-based chart definition with the document has been removed.

8.2 In the Board's opinion, document D1 discloses that the underlying chart data includes data values, labels, and data formats (see for example the XML snippet on page 3 of D1, the "component" elements) and that the chart is edited through a common charting component, the common charting component being used by one or more application programs. In fact, the XML document of D1 must be edited through some kind of editor, which is usable for at least this application, in order to change the values - see section "An Example"). The appellant has not contested the Board's interpretation of D1 in this respect.

8.3 Hence, the method of claim 1 differs from the method disclosed in D1 in the following features:

- underlying chart data is retrieved from a data source referenced by the chart object;

- the translation is performed automatically when the document is opened.

8.4 The Board has already established for claim 1 of the main request that the use of references to data sources of the underlying chart data is obvious. As the underlying chart data is needed for the translation, it is necessary to retrieve this data from the data sources in order to accomplish the translation. Hence, adding the actual data retrieval cannot support an inventive step.

8.5 The appellant argued that it was not known from D1 that the translation is done automatically when the document is opened. This automatic translation solved the problem to speed up the rendering process.

The Board accepts this definition of the problem, but finds that there is no functional interdependence between the automatic translation and the retrieval of the underlying data from referenced data sources.

8.6 The appellant argued that performing the automatic translation when the document of D1 was opened would not make sense. D1 did not even disclose that or how the document was stored. It was not clear how this worked in detail in D1.

In the view of the Board, this feature allows users of D1 to see immediately the chart resulting from the chart object specified in XML when the document is opened. It helps users understand the chart definition via XML by comparing the XML snippet and the resulting chart.

Performing the translation automatically when the document is opened can also be regarded as an obvious alternative to saving the shape-based chart definition with the document (as specified in claim 1 of the main request).

Furthermore, it is an obvious implementation option to perform the translation automatically when the document is opened as the opening of the document offers the first opportunity to prepare for the rendering of the chart by providing the translation. In case of charts, it is evident that the users will be more at ease with a graphically displayed chart than XML code. Hence, the selection of the opening of the document as trigger for an automatic translation is obvious in order to speed-up the rendering process.

8.7 Consequently, claim 1 of the second auxiliary request is obvious over D1 in combination with the skilled person's general knowledge, Articles 52(1) and 56 EPC.

9. Third auxiliary request - admission

The third auxiliary request, filed by the appellant in reply to the summons to oral proceedings, clarifies that the method of claims 1 to 8 of the auxiliary request 2b submitted with the statement of grounds of appeal is computer-implemented. In addition, independent claims 9 and 17 were amended to correspond in computer-readable medium and system terms to the computer-implemented method of claim 1. Claims 21-24 were cancelled, but a new dependent claim 21 was introduced.

With the statement of grounds of appeal the appellant submitted the following with respect to auxiliary request 2b:

"The auxiliary request 2b is similar to auxiliary request 2a and is based on the allowed claims of the corresponding US case."

Auxiliary request 2b was not further mentioned in the statement of grounds. With its reply to the summons, the appellant submitted a marked-up version of the third auxiliary request showing the amendments compared to auxiliary request 2b and indicating passages of the original application as basis for independent claims 1, 9, and 17 and new dependent claim 21. Moreover, the appellant submitted that the independent claims of the third auxiliary request differed from the independent claims of the second auxiliary request filed with the same letter in that the translating step of claim 1 of the third auxiliary request translated a plurality of chart elements into a plurality of corresponding shapes based on the type of chart and the data values associated with each of the plurality of chart elements. In addition, a shape-based chart definition based on the plurality of corresponding shapes was generated.

9.1 The Board notes that the corresponding US patent US 7584415 B2 was published on 1 September 2009. It would thus have been possible to submit auxiliary request 2b already during the examination proceedings (the oral proceedings before the Examining Division took place 21 June 2010).

9.2 The third auxiliary request was filed only in reply to the summons for oral proceedings. Hence, the Board has to exercise its discretion according to Article 13(1) RPBA in view of inter alia the complexity of the new subject matter, the current state of the proceedings and the need for procedural economy.

9.3 The appellant has not submitted specific arguments for the allowability of this auxiliary request during the written phase of the appeal proceedings. In the letter of reply to the summons for oral proceedings, the appellant submitted that the new independent claims defined novel and inventive subject-matter and that more detailed arguments would be provided during the oral proceedings.

Independent claim 1 of the third auxiliary request is based on auxiliary request 2b filed with the statement of grounds of appeal. However, the statement of grounds of appeal does not substantiate why its new wording would meet the requirements of Article 123(2) EPC. Moreover, no arguments why this request would overcome the objection to lack of inventive step as set out in the decision of the Examining Division were submitted. Consequently, the appellant had not presented arguments (apart from the reference to the decision of the USPTO to allow the claim) in favour of an inventive step of the method of claim 1 of the third auxiliary request before the oral proceedings. Rather the appellant had first pointed out in the statement of grounds of appeal that the auxiliary request 2b was similar to auxiliary request 2a, and then set out in the reply to the summons that these requests were different.

9.4 Claim 1 of the third auxiliary request adds at least the following features compared to claim 1 of the second auxiliary request:

- a step of receiving a chart object;

- a translation engine of a common charting module that can be used by multiple application programs and includes a common charting component;

- a step of generating a shape-based chart definition based on the plurality of corresponding shapes (obtained from the translation) that is performed automatically when the document is opened.

In addition, claim 1 of the third auxiliary request removes at least the following features compared to claim 1 of the second auxiliary request:

- the document includes the chart object;

- the chart object provides references to more than one data source;

- the chart object includes labels and data formats;

- the shape-based chart definition defines the chart with shapes;

- the translating comprises the steps of determining a type of the chart and retrieving data from a data source;

- the step of rendering the chart;

- the common charting component is used by one or more application programs.

9.5 These differences between the second and third auxiliary requests are substantial and introduce complex new subject-matter at a very late stage of the proceedings. It is not immediately apparent to the Board which objections were intended to be overcome by the various amendments to claim 1 of the third auxiliary request listed above and how these amendments would overcome such objections.

9.6 The appellant argued during the oral proceedings that references had been provided with respect to Article 123(2) EPC, that the number of claims had been reduced and the wording of the claims had been harmonised with respect to Article 84 EPC, and that the second and third auxiliary requests were similar, but had a different focus with respect to Article 56 EPC. Moreover, the appellant argued that the statement of grounds of appeal (see there, section 3.2) provided detailed arguments in favour of an inventive step for the auxiliary requests 2a and 2b. Consequently, the third auxiliary request (which clarified auxiliary request 2b) should be admitted.

However, the statement of grounds of appeal does not specifically address the wording of the auxiliary request 2b or the differences between the auxiliary requests 2a and 2b. For example, the appellant submitted in the statement of grounds of appeal, after introducing auxiliary requests 2a and 2b, that it "has been clarified that data is retrieved from a data source referenced by the chart object, that the translating step is performed automatically when the document is opened and that the chart is edited through a common charting component wherein the common charting component is used by one or more application programs". The first two of these clarifications are already present in the auxiliary request 2a. The last one concerning the common charting component is not present in the auxiliary request 2b. Hence, the Board cannot see how these arguments could have substantiated auxiliary request 2b as a further auxiliary request in addition to auxiliary request 2a.

9.7 Furthermore, as pointed out at the oral proceedings, the Board doubts that there is a basis

- for the step of receiving a chart object (in combination with the further features of claim 1),

- for a common charting module that can be used by multiple application programs (which seems to imply that the translation engine can be used by multiple application programs), and

- for the step of generating (separate from the step of translating).

The Board has also prima facie doubts about the clarity of the wording of claim 1 of the third auxiliary request. For example, it is not clear which technical features of a program module are implied by the feature "that can be used by multiple application programs".

9.8 In summary, the Board considers that the third auxiliary request is not primarily directed to overcoming outstanding objections raised by the Examining Division or the Board, but rather represents a substantial change of the appellant's case at a very late stage in the appeal proceedings, which raises new complex issues.

Consequently, the Board exercises its discretion under Article 13(1) RPBA not to admit the third auxiliary request into the proceedings.

10. Conclusion

Since none of the requests can form the basis for the grant of a patent, the appeal is to be dismissed.