T 0452/14 (Integrating charts in documents / MICROSOFT) 13-02-2020

1. Background

The invention concerns a method for managing and editing a chart presented in a host application. Users may request updates to the displayed chart by means of user actions for example keystrokes or mouse clicks (originally filed application, page 10, lines 8 to 11). The update processing varies depending on the nature of the requested updates.

If the requested update merely aims at changing the chart position, the host application repositions the chart itself (page 10, lines 16 to 18). If, however, the update aims at modifying the values of the data in the chart, the spreadsheet application is launched and the update is performed using the spreadsheet application (page 10, lines 26 to 30). The spreadsheet application can be run as a "visible" or "non-visible instance". The visible instance is run, if it is established based on the user action that the user needs to interact with the spreadsheet data set; the non-visible one if the user has no such need (paragraph bridging pages 10 to 11).

The application does not give any examples of user actions that the non-visible spreadsheet instance should handle, or what processing it performs when it runs.

The user action notification is passed from the host application to the running spreadsheet application instance which can then modify the spreadsheet data set underlying the chart (page 11, last two paragraphs). If the change to the spreadsheet data set necessitates an update to the chart visualising it, the chart update is requested (page 12, paragraphs 1 to 4).

The invention is further concerned with a file structure enabling persistence of a host application document including an embedded chart and an associated spreadsheet data set. The host application document is stored as a file containing a pointer to the spreadsheet document containing the spreadsheet data set on which the chart is based. The spreadsheet document is either embedded in the host application file or stored in an external file (page 9, lines 20 to 29).

2. First auxiliary request, claim 1

The Board finds it convenient to discuss the more specific first auxiliary request before the main request.

2.1.1 Inventive step - Article 56 EPC

The closest prior art D5 discloses a system enabling a spreadsheet object to be incorporated into a word processing application document. The spreadsheet object comprises tabular data and a chart (column 8, lines 50 to 56; Figure 3). The user can select the spreadsheet object in the word processor window and edit the object directly in this window using the functionality of a spreadsheet application launched for this purpose by the word processor (column 8, lines 19 to 24 and lines 31 to 39). In addition to editing the spreadsheet object using the spreadsheet application, the user can cut or copy the embedded spreadsheet object (column 8, lines 29 to 40 and Figure 8). Activating menu items triggering the cut, copy and edit options corresponds to receiving a user action associated with the chart and determining whether a spreadsheet is needed to perform the action in the first two features of claim 1. Column 8, lines 22 to 28 discloses that if the edit action is selected, it is sent from the word processor to the launched spreadsheet application using a generated link. This corresponds to the generating and sending steps of the claim.

The appellant argued during the oral proceedings that D5 employed the object linking and embedding (OLE) API and had to be read in this context. More particularly, within the OLE-based framework, an object comprised only programming code and it was not correct to map the objects and spreadsheet instances of D5 to the claimed entities.

The Board does not find this argument persuasive. It is correct that D5 discloses that in the preferred embodiment the word processor and the spreadsheet application communicate using interface methods defined by the OLE API (column 8, line 50 to column 9, line 10 and column 9, lines 39 to 44). However, the passages of D5 cited above are not part of this preferred embodiment. They rather provide general teaching on a functional level and are not limited to using the OLE API. Beyond that, the Board cannot see why using the OLE API for implementing communication between the host application (container application in terms of D5) and the spreadsheet application should invalidate the above straightforward reading of D5. In fact, the application also discloses at page 7, line 15 to page 9, lines 4 that the spreadsheet application and other software components communicate through a set of COM interfaces.

2.1.2 The main difference between the subject-matter of claim 1 and D5 is that:

A) If it is determined that a spreadsheet is needed, it is determined, whether a visible instance of the spreadsheet application is required to handle the user action and a visible instance of the spreadsheet application is initiated if this determination is positive, otherwise a non-visible instance of the spreadsheet application is initiated.

In addition to this main difference, the subject-matter of claim 1 further differs from D5 in that:

B) The chart is edited according to the feature set provided by the spreadsheet application.

C) It is determined whether chart data changes and whether an update to the chart is required based on the changes, and if so, an update of the chart data is requested from the spreadsheet application.

2.1.3 Concerning the main distinguishing feature A, the appellant agreed that the application did not explicitly discuss operations performed in the invisible mode. However, he argued that the skilled person would infer from description page 10, lines 28 to 31 that actions performed in the invisible mode were "uni-directional" actions which did not require the user to change the chart data or to interact therewith. It would be clear to the skilled person that straightforward examples of such actions were changing color themes of the chart or the chart's font size. The skilled person would also infer from the description that these uni-directional actions were triggered by predefined keyword shortcuts. Furthermore, performing the actions in the invisible mode contributed to saving computer and memory resources, as less information was displayed. Hence, in the appellant's opinion the objective technical problem was "how to save computer and memory resources"

The appellant argued further that recognising that certain actions could be performed in an invisible mode in order to save computer resources was not obvious over D5, as D5 did not provide any hint in this direction. In the absence of such a hint, the skilled person starting at D5 would perform all chart-related spreadsheet actions in the visible mode shown in Figure 4.

2.1.4 The Board considers that the problem of saving resources is in this case too general and speculative. The amount of consumed resources depends, in both visible and invisible mode, on the actions' nature and the manner in which they are processed rather than merely on the decision to perform actions visibly or invisibly for the user.

The fact that neither the claim nor the description discuss actions performed invisibly to the users in positive terms poses a difficulty in formulating the objective technical problem. As long as it is not clear what these actions are and what processing ensues, their effect cannot be determined. However, the identification of an effect produced by novel features is essential in the problem and solution approach, because such an effect provides basis for the formulation of the objective technical problem.

Furthermore, the problem cannot be based on the negatively formulated effect of enabling actions whose handling does not require the user to interact with the chart data. The reason is that such a problem comprises a pointer to the offered solution. And it is even less appropriate to include in the problem that certain spreadsheet actions should be performed invisibly for the user.

In the Board's view, one credible problem follows from the appellant's inferred feature that the actions that result in invisible processes must be triggered by predefined keyword shortcuts. Providing such shortcuts that then enable triggering spreadsheet actions increases user friendliness. Thus the Board bases the objective technical problem on this effect along the lines of "how to increase user friendliness of the system of D5". The skilled person confronted with this problem and referring to his common general knowledge would consider enhancing the host application by exposing required actions, also chart-related actions, by means of predefined shortcuts. The Board judges that using keyword shortcuts invoking applications in order to perform preprogrammed actions was commonplace in the field of human-computer interaction and formed part of the common general knowledge at the priority date. The shortcuts were employed to expedite operations by reducing input sequences to a keystroke; hence the term "shortcut".

The skilled person would immediately recognise that shortcuts would be most useful for actions that do not require any user input. For such actions, it is also not necessary to notify the user that the spreadsheet application instance is running, as the user is only interested in the result. Since user-friendliness implies avoiding presenting the user with unnecessary information, refraining from providing visual indication of the performed spreadsheet operations results naturally from the objective technical problem.

The appellant argued that the claimed solution went against the OLE framework of D5 and therefore would not have been considered by the skilled person. However, the Board cannot see why using the OLE facilities should hinder the skilled person from adapting the general teaching of D5 in the above manner (cf. remarks concerning the OLE in point 2.1.1 above)

The Board therefore judges that feature A is obvious.

2.1.5 Distinguishing features B and C do not add anything of inventive merit. They are motivated by the business requirement that the chart should visualise data displayed next to it and reflect changes to this data. Using the COMVIK approach, this business requirement is provided to the technically skilled person as part of the framework of the objective technical problem. The Board considers that it would be obvious for the skilled person, facing the problem of implementing this business requirement, to determine each time after the user edits the spreadsheet data set whether changes introduced by the user to the data set necessitate a chart update. If so, the chart would have to be updated accordingly. Hence, features B and C are obvious.

2.1.6 Accordingly, the subject-matter of claim 1 lacks inventive step.

2.2 Main request, claim 1

Since claim 1 of the first auxiliary request contains all features of claim 1 of the main request, the above objection under Article 56 EPC applies also to claim 1 of the main request.

Hence, claim 1 of the main request also lacks an inventive step

3. Third auxiliary request, claim 1.

The Board finds it convenient to discuss the more specific third auxiliary request before the second auxiliary request.

3.1 New features

Claim 1 of the third auxiliary requests adds to claim 1 of the first auxiliary request that:

D) The spreadsheet application determines both the values and format to be used for the chart.

E) A presentation application (and not the host application) displays the chart.

F) A presentation file includes a chart file directing the presentation application to a spreadsheet file that includes chart data for the chart, the chart data including the values to be used for the chart.

G) The spreadsheet file is stored either as a spreadsheet file embedded within the presentation file or as a spreadsheet file external to the presentation file.

3.2 Inventive step - Article 56 EPC

3.2.1 D5 discloses implicitly that the spreadsheet application which created the displayed chart determines, upon the chart creation, the value and format for the chart. Thus, D5 discloses feature D.

Concerning feature E, the appellant argued during the oral proceedings that the description disclosed at page 5, lines 12 and 17 that the presentation application was not a word processor application but rather the PowerPoint application. Therefore, the claim should be read in the light of this disclosure. Thus, claim 1 differs from D5 by the provision of the "presentation application" instead of the word processor. However, the Board considers that the general expression "presentation application" encompasses any application presenting data to the user including a word processor application. Thus, feature E is disclosed in D5.

Hence, the subject-matter of claim 1 differs from D5 by features A-C, discussed above, and added features F-G.

3.2.2 Features A-C and F-G do not interact synergistically.

As set out above, features A-C are obvious.

Concerning features F-G, the Board judges that they are also obvious. D5 discloses that the embedded spreadsheet object of D5 is stored as an embedded or linked object (column 7, lines 65 to 67). Since, D5 does not provide any disclosure regarding used storage structures, the skilled person starting from D5 inevitably faces the objective technical problem of how to implement a storage structure enabling embedding a spreadsheet object within the word processor document or linking the object to the document. The Board judges that it would be obvious to the skilled person to store the word processor document as a file comprising a pointer to either an external spreadsheet file or to an embedded spreadsheet object. Such a pointer corresponds to the chart file interpreted in the light of the description at page 9, lines 20 to 21 saying that "the chart file...is more similar to a pointer and directs the presentation application to another file...that includes the chart data".

Furthermore, basing the chart on data included in the embedded spreadsheet object or external spreadsheet file, such that the embedded object or the file provides data for the chart, is an obvious implementation of the business requirement that the chart should visualise data displayed next to it. See comments concerning obviousness of features B and C in point 2.1.5 above.

The appellant argued that the claimed solution could not be implemented in the OLE-based framework of D5. OLE objects of D5 were something different than files and D5 taught away from the claimed solution. The Board does not find this argument persuasive for reasons similar to those given for the first auxiliary request in points 2.1.3 and 2.1.4 above. Here again, the Board cannot see why using the OLE in the preferred embodiment should hinder the skilled person starting from D5 from implementing the file structure discussed above.

Hence, the Board judges that features F and G are obvious and claim 1 of the third auxiliary request lacks inventive step.

4. Second auxiliary request, claim 1

Although the second auxiliary request relates to the host application instead of the presentation application, this does not add anything to the scope of the third auxiliary request, because the broad expression "host application" encompasses a presentation application. Apart from this difference, claim 1 of the third auxiliary request contains all features of claim 1 of the second auxiliary request.

Hence, the objection under Article 56 EPC raised for the third auxiliary request also applies to claim 1 of the second auxiliary request.

Hence, claim 1 of the second auxiliary request lacks inventive step.