T 0546/18 (Help information by means of query string/BROTHER) 26-07-2022

1. The invention

The application relates to the display of data, e.g. help data or settings on a management screen of a terminal device connected to a device such as a printer (description par. [0003] and [0004]).

The application aims to solve the problem that if, on each management screen, data is provided for the help pages on all different terminal devices, a large amount of data is required.

To solve this problem, claim 1 foresees that the terminal device is controlled to acquire the help information corresponding (specifically) to a target item displayed on the management screen by acquiring identification information (ID) of the target item, adding the ID to a string variable, adding the string variable as a query to a URL of a server, the server being configured to store help information, and acquiring the help information corresponding to the target item by using the URL having the query, and to display a help screen indicating the help information.

As a consequence, unnecessary additional data does not need to be stored which would otherwise make data management overly complicated and require the storage of unnecessary data (see point 3.2.10 in the grounds of appeal).

2. Novelty (Article 54 EPC) - main request

2.1 D1 discloses (cf. also the decision under appeal, point 2.1 of the reasons, until the middle of page 5)

a device (embedded system, column 2, lines 23-35)

configured to connect to a terminal device (client system, column 2, lines 23-35), the device comprising:

a supply unit, which is configured to supply management screen data to the terminal device (column 2, lines 28-35 and column 5, line 44 to column 6, line 11),

the management screen data represents a management screen to be displayed on the terminal device and to include a plurality of display items, which are related to the device (column 5, line 63 to column 6, line 11 and column 2, lines 35-47),

at least one of the plurality of display items being a target item for which help information is displayable on the terminal device in response to a help command received by the terminal device, the help information being respectively set to correspond to the target item (column 6, lines 3-11, the data page received is a dialog box requesting settings for timer or clocks, which are the plurality of target items. Clicking on the help button (this corresponds to the help command) further information is retrieved for the timers or clocks being displayed)

wherein, in response to the help command received by the terminal device, the management screen data includes instructions to control the terminal device to:

acquire the help information corresponding to the target item displayed on the management screen (column 6, line 13 to column 7, line 9).

2.2 D1 also discloses a server (column 6, line 32 to column 7, line 9), which is configured to store help information (column 2, lines 33-35) corresponding to the target item (column 4, lines 60-64, column 5, lines 12-24 and lines 25-31) as well as the display a help screen indicating the help information (column 7, lines 41-45).

2.3 The appellant argued (point 3.2.5 in the grounds of appeal) that D1 does not disclose adding identification information of the target item to a URL, and more specifically that D1 does not disclose the steps of acquiring identification information of the target item, adding this information to a string variable, adding the string variable to a URL as a query and acquiring help information using this URL having the query.

2.4 In its response of 17 August 2017 to the summons to oral proceedings before the first instance, the appellant provided a full reasoning why it considered that D1 does not disclose said steps (see pages 2 and 3 of the response).

2.5 As regards the applicant's argument that in D1 the URL does not contain identification information for the target items, the appealed decision (point 2.5) merely draws the applicant's attention "to column 6, lines 25 to 40 of document D1 and for what stated there the Applicant's arguments are considered to be not convincing". The decision does not refute the applicant's argument (in the middle of page 2 of its response to the summons) that, "even if it is assumed that the claimed target item does correspond[] to a dialog box requesting settings for timer or clocks, the claimed identification information of the target item is not set for the dialog box, and therefore, the "Server Location", "Release Identifier", "IIHTML Topic" do not correspond [to] the identification information of the target item".

The appealed decision also does not address the applicant's reasoning that D1 does not disclose the steps of adding the string variable to a URL as a query and acquiring help information using this URL having the query. The decision merely states that said feature is disclosed in D1 by making a broad reference to column 6, line 32 to column 7, line 9 in that document. The decision does not address the applicant's point (ibid., middle of page 3) that D1 does not disclose providing a URL with a query based on the target items on the page, i.e. corresponding to the target item displayed on the management screen, which means that in D1 (in contrast to claim 1), different help pages for different management screens may be required.

2.6 The board accepts the appellant's arguments and therefore holds that the subject-matter of claim 1 of the main request is new (Article 54 EPC).

2.7 The following features are not disclosed by D1:

acquiring identification information of the target item;

adding this information to a string variable;

adding the string variable to a URL as a query; and

acquiring help information using this URL having the query.

3. Inventive step (Article 56 EPC) - main request

3.1 The board holds that D1 is a suitable starting point for the assessment of inventive step.

3.2 According to the grounds of appeal (point 3.2.10), the advantage of the above distinguishing features is that unnecessary additional data does not need to be stored, which would otherwise make data management overly complicated and require the storage of unnecessary data.

In particular, the appellant submits (ibid., 3.2.13) that the system of D1 requires the provision of a help page corresponding to each embedded form.

3.3 According to the appellant's response of 8 April 2022 (middle of page 3), the indicated difference results in fact in a reduction in the processing load whilst also improving robustness and versatility.

3.4 According to the board's judgment, the subject-matter of claim 1 and the disclosure of D1 differ essentially in the following way:

3.4.1 In D1, a specific file on the server is associated with each possible help button (see column 2, lines 33-35). This means that, if the client system sends an HTTP request to obtain the corresponding help page (see figure 3 and corresponding text in the description), D1 allows the use of a fixed URL. The possibility of using a dynamic URL is not disclosed in D1. Instead, only the use of fixed URL's is shown; see for instance figure 8 and corresponding text in the description. In D1, the URL is most likely known to the system, and it is most likely pre-computed.

3.4.2 In claim 1, on the other hand, where a query string is used, the URL is dynamic; it is generated "on the fly".

3.5 The board holds that the use of a dynamic instead of a static URL constitutes an obvious choice providing no unexpected technical effect.

3.6 According to the appellant (see point 3.2.10 in the grounds of appeal), the advantage of using a query string is that unnecessary additional data does not need to be stored, which would otherwise make data management overly complicated and require the storage of unnecessary data.

In particular, the appellant submits (ibid., 3.2.13) that the system of D1 requires the provision of a help page corresponding to each embedded form.

However, the acquisition of help information using a query in itself does not avoid the need to store help pages corresponding to each possible situation. The skilled person should take additional steps to ensure that this advantage is indeed reached. Otherwise, as a rule, the quantity of help information to be stored will most likely be equivalent to that in the system of D1.

It is primarily such additional measures taken by the skilled person which achieve said effect. The effect does not depend on whether query strings or fixed URL's are used. In the latter case, for example, storage space would be saved by the help pages themselves containing content that is dynamic.

3.7 In its response of 8 April 2022 (middle of page 3), the appellant submits that the distinguishing features result in a reduction in the processing load whilst also improving robustness and versatility.

The board holds that the distinguishing features by themselves do not cause a reduction in the processing load. To achieve this, just like for a reduction in the required storage space (see above), additional measures would need to be taken. The board further notes that terms such as "robustness" and "versatility" are fuzzy and give no indication of a concrete technical effect.

3.8 In summary, the features distinguishing the subject-matter of claim 1 from the disclosure of D1 can only be seen as a mere choice among well-known alternatives of forming a URL address.

The appellant objected (response of 8 April 2022, paragraph spanning pages 2 and 3) to the board's stating, without citing a document, that the use of a query string instead of a set URL is well-known. The board therefore introduced D5 and D6 to demonstrate this fact.

D5 discloses that query strings can be used instead of set URLs to increase flexibility (see section entitled "Flexibility vs. security").

D6 gives an example (first paragraph under the section entitled "Query strings") where a query string ("CustomerID=1234") is passed to a page for processing by appending it to the URL of that page. The implication to the skilled person is that there is no need to have a dedicated page for each value of CustomerID.

3.9 The board therefore concludes that the subject-matter of claim 1 of the main request is not inventive (Article 56 EPC).

4. Inventive step (Article 56 EPC) - auxiliary request 1

4.1 The subject-matter of claim 1 of auxiliary request 1 is the same as that of the main request. It is therefore not inventive (Article 56 EPC) for the same reasons as indicated above.

5. Inventive step (Article 56 EPC) - auxiliary request 2

The features added in claim 1 of auxiliary request 2 allegedly (see appellant's response of 8 April 2022, middle of page 3) provide a (further) reduction of the processing load and a (further) improvement of robustness and versatility.

Similarly as written above, the board can see in such features no indication of a concrete technical advantage. Those features should rather be seen as a straightforward manner of implementing a non-technical requirement, i.e. the requirement to deal with an unspecified "error state", which is not further defined and is in particular not tied to any concrete technical "error" situation.

The subject-matter of claim 1 of auxiliary request 2 is therefore also not inventive (Article 56 EPC), for similar reasons as given above.

6. Inventive step (Article 56 EPC) - auxiliary request 3

6.1 For auxiliary request 3, the appellant in its response of 8 April 2022 (middle of page 4) referred mutatis mutandis to the arguments it gave for auxiliary request 2, which as indicated above do not convince the board.

6.2 During the oral proceedings, the appellant explained that the amendment in auxiliary request 2 was introduced in view of the argument provided in the board's summons of 14 January 2022, point 5.4, penultimate paragraph, that if there is only one target item, the quantity of help information to be stored in the arrangement of claim 1 would likely be equivalent to that in the system of D1.

However, the board's reasoning given in point 3.6 above does not depend on the number of target items.

6.3 Further, the board fails to see indications of a synergistic effect between the features added in auxiliary request 3 with the other features of claim 1.

6.4 The subject-matter of claim 1 of auxiliary request 3 is therefore also not considered inventive (Article 56 EPC).

7. Inventive step (Article 56 EPC) - auxiliary request 4

Claim 1 of auxiliary request 4 is based on that of auxiliary request 3, with additional details on how the error state is determined. Given that these additional details are non-technical, they do not remedy the inventive step objection raised against auxiliary request 3.

The subject-matter of claim 1 of auxiliary request 4 is therefore also not considered inventive (Article 56 EPC).

8. Auxiliary requests 5 and 6

8.1 The board holds that the fact that auxiliary requests 5 and 6 can be dealt with in substance in a straightforward manner constitutes an exceptional circumstance under Article 13(2) RPBA 2020. The board therefore admits these requests into the procedure.

8.2 Claim 1 of auxiliary requests 5 and 6 includes standard features which the server would be expected to have. These additional features do not remedy the inventive step objection raised against the higher ranking auxiliary requests.

The subject-matter of claim 1 of auxiliary requests 5 and 6 is therefore also not considered inventive (Article 56 EPC).