T 0417/20 () of 6.12.2023

European Case Law Identifier: ECLI:EP:BA:2023:T041720.20231206
Date of decision: 06 December 2023
Case number: T 0417/20
Application number: 14830451.2
IPC class: G09B 7/00
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 429 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: INTERACTIVE TRAINING INTERFACE FOR ASSET HEALTH MANAGEMENT
Applicant name: Hitachi Energy Ltd
Opponent name: -
Board: 3.4.02
Headnote: -
Relevant legal provisions:
European Patent Convention Art 52(1)
European Patent Convention Art 56
Rules of procedure of the Boards of Appeal 2020 Art 012(2)
Rules of procedure of the Boards of Appeal 2020 Art 012(4)
Rules of procedure of the Boards of Appeal 2020 Art 012(6)
Keywords: Inventive step (main request: no)
Admission of requests filed in appeal (auxiliary requests 1 and 2: no)
Catchwords:

-

Cited decisions:
G 0001/19
T 0641/00
Citing decisions:
-

Summary of Facts and Submissions

I. The applicant (appellant) lodged an appeal against the decision of the examining division refusing European patent application No. 14830451.2.

II. Among the documents considered during the first-instance proceedings, the following documents were cited during the appeal proceedings:

D1: US 2003 028 676 A1

D2: WO 03 096 239 A2

D3: US 2003 211 451 A1

D4: US 2007 282 588 A1.

III. In the decision under appeal the examining division held that the subject-matter of the claims of the sole request then on file did not involve an inventive step (Article 56 EPC).

IV. With the statement setting out the grounds of appeal dated 3 February 2020 the applicant submitted new sets of claims according to a main request and auxiliary requests 1 and 2.

V. In a communication pursuant to Article 15(1) RPBA 2020 annexed to summons to oral proceedings the board presented a preliminary assessment of the case.

VI. With the letter dated 30 August 2023 the applicant submitted further arguments in support of its case.

VII. Oral proceedings were held on 6 December 2023.

The applicant requested that the appealed decision be set aside and that a patent be granted according to the claims of the main request or one of auxiliary requests 1 and 2, all filed with the statement of grounds of appeal on 3 February 2020.

At the end of the oral proceedings the chair announced the decision of the board.

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

"A method for providing a graphical user interactive interface (310) for asset health management, comprising:

identifying (102) one or more knowledge modules (202) each configured to be associated with asset health management;

providing a scenario generation component (204) associated with asset health management; and

evaluating the one or more knowledge modules (202) on the basis of the scenario generation component (204) to derive interactive game interface data (216), the interactive game interface data (216) comprising at least one of an asset health diagnosis module (206), a maintenance recommendations module (208), an action plan module (214), a criticality module (212), or a decision evaluation module (210);

generating (104) an asset health management scenario (308) based upon the scenario generation component (204) and on the interactive game interface data (216) and/or other information (302, 304, 306), the other information (302, 304, 306) comprising a role of user (302); and

providing (106) the asset health management scenario (308) through a graphical user interactive interface (310) to a user for interactive play, the graphical user interactive interface (310) comprising action plans selected and/or specified by the user through action plan interfaces;

updating the asset health management scenario (308) and/or the one or more knowledge modules (202) and/or the other information (302, 304, 306) by using the user action plan with the graphical user interactive interface (310) on the basis of the role of user (302)."

Claim 1 of auxiliary request 1 differs from claim 1 of the main request as follows, with deletions and additions being respectively indicated by strike-through and underlining:

"A method for providing a graphical user interactive interface (310) for asset health management, comprising:

identifying (102) [deleted: one or more] a knowledge module[deleted: s] (202) [deleted: each configured to be associated with] for real-life asset health management;

providing a scenario generation component (204) associated with asset health management; [deleted: and]

evaluating the [deleted: one of more] knowledge module[deleted: s] (202), [deleted: on] by [deleted: the basis of] the scenario generation component (204), to derive interactive game interface data (216), the interactive game interface data (216) comprising at least one of an asset health diagnosis module (206), a maintenance recommendations module (208), an action plan module (214), a criticality module (212), or a decision evaluation module (210);

generating (104) an asset health management scenario (308), [deleted: based upon] by the scenario generation component (204), [deleted: and] based on the interactive game interface data (216) and[deleted: /or] other information (302, 304, 306), the other information (302, 304, 306) comprising a role of user (302); [deleted: and]

providing (106) the asset health management scenario (308) through a graphical user interactive interface (310) to a user for interactive play, the graphical user interactive interface (310) comprising action plans selected and/or specified by the user through an action plan interface[deleted: s]; and

updating the asset health management scenario (308) and[deleted: /or] the [deleted: one or more] knowledge module[deleted: s] (202) [deleted: and/or the other information (302, 304, 306)] by using the user action plan with the graphical user interactive interface (310) that provides the asset health management scenario (308) on the basis of the role of user (302), wherein the updating comprises updating a parameter, an algorithm, and/or other information implemented by a asset health management system for real-time asset health management to improve the knowledge module (202) for real-life asset health management."

Claim 1 of auxiliary request 2 differs from claim 1 of auxiliary request 1 in that the fourth sub-paragraph reading "generating (104) an asset health management scenario ..." further reads as follows:

", the generating (104) an asset health management scenario (308) comprising:

identifying an operating condition of an asset, the operating condition corresponding to at least one of configuration information, connectivity information, environmental information, or health information; and

generating (104) the asset health management scenario based upon the operating condition;".

Reasons for the Decision

1. The appeal is admissible.

2. Main request - Claim 1 - Inventive step

2.1 The claims of the main request correspond in substance to the claims of the sole request underlying the decision under appeal. In the contested decision the examining division held that the method of claim 1 of the main request did not involve an inventive step (Article 56 EPC) essentially for the following reasons:

- Claim 1 was directed to a teaching method of training an operator about the health of an asset (electrical or industrial asset) using a GUI (graphical user interactive interface).

- The method of claim 1 comprised a mixture of technical and non-technical aspects, the technical aspects consisting of the claimed features relating to the use of a GUI and the "action plans interfaces", and the remaining claimed features relating to a method not contributing to the technical character of the claimed method. In particular, the fact that the contents presented to a user related to operational or diagnosis data of an equipment of an "asset" did not contribute to the technical character of the method because no direct technical effect was achieved in a real equipment. More particularly no improvement in equipment configuration or troubleshooting was performed, and there was no direct technical link between what the user learned from the method and an actual specific technical modification of the asset. Therefore, the technical character of the claimed method resided only in the technical implementation of the teaching method.

- The closest prior art was regarded to be a notorious computer system of the type disclosed in each of documents D1 to D4 in the context of training operators; there was no technical interaction between the teaching method and the computer system which would go beyond the mere automation of the method, and the objective technical problem resided in the automation of the teaching method; and the implementation or automation of the method in a computer system as claimed was obvious for the person skilled in the art.

The applicant has disputed in several respects the reasons given by the examining division in its decision. However, in the board's view the applicant's arguments are not persuasive for the following reasons:

2.2 The board first notes that the method defined in claim 1 of the main request consists of

- an algorithm comprising all the features of claim 1 with the exception of the features relating to the use of the "graphical user interactive interface" (in the following "GUI") and of the "action plan interfaces" specified in the claim, and

- the use, as claimed, of the mentioned GUI and of the mentioned action plan interfaces.

In addition, as regards the algorithm itself, it essentially involves

- the generation of an "asset health management scenario" on the basis of a "scenario generation component" and of "interactive game interface data" and/or of "other information [...] comprising a role of user", wherein the scenario generation component is associated with "asset health management", and wherein the interactive game interface data is derived from an evaluation of previously identified "knowledge modules" associated with asset health management and comprises at least one of "an asset health diagnosis module", "a maintenance recommendations module", "an action plan module", "a criticality module", and "a decision evaluation module",

- the provision of the asset health management scenario to a user for interactive play and for allowing the user to select and/or specify "action plans", and

- updating the asset health management scenario and/or the knowledge modules and/or the information comprising the role of the user by using the user action plan on the basis of the role of the user.

Therefore, the algorithm does not go beyond a specific scheme of handling information relating to assets, presenting it to a user, allowing the user to interact with the scheme, and updating the scheme in response to the user action's, and in the board's view the algorithm is - as held by the examining division in its decision - per se devoid of technical character.

2.2.1 The applicant has submitted that asset health management, i.e. tasks relating to monitoring and/or maintaining the health of assets such as those of an electrical power system or an industrial system, was genuinely a technical task. In particular, the assets were, as specified in the description of the application, some kind of equipment or component of a physical infrastructure, and in particular technical pieces of equipment, and managing their health, i.e. ensuring they worked and functioned properly, was intrinsically a technical matter. In addition, the steps of the claimed method such as the generation of the asset health management scenario and updating it constituted features that a technical expert would have provided, rather than features that would have been specified by a non-technical expert. In particular, technical knowledge and insight was intrinsically required to allow the provision of meaningful and realistic health management scenarios and to subsequently assess and update the scenarios, knowledge modules and/or further information by using the selected user action plans.

However, in the board's view the algorithm does not involve technical considerations and does not require technical means for its implementation. More particularly, in the board's view "asset health management", i.e. tasks relating to monitoring and/or maintaining "the health of an asset", does - contrary to the applicant's submissions - not constitute a technical task in itself. The description of the application refers to industrial assets, and in particular to assets of an electric utility or mining or water company (paragraphs [0002] and [0004]), but - contrary to the applicant's submissions and also to the examining division's assumption in the decision under appeal - the concept of "asset health management" is not restricted by the wording of claim 1 to "real-life assets" and, in any case, encompasses assets of a non-technical nature (financial assets, intellectual property rights assets, etc.). In addition, even assuming that the expression "asset health management" is to be interpreted - as submitted by the applicant - as being restricted to the management of tangible "real-life assets" of a technical nature such as electrical or industrial assets, this management consists of the task of handling cognitive information relating to monitoring and/or maintaining the health of the assets and it does not necessarily involve technical considerations, among other reasons because it encompasses carrying it out exclusively, among other possibilities, as a purely administrative or managerial task (see, for instance, the components 104 and 204 in the respective flow diagrams of Fig. 1 and 2 of the application and the corresponding description, in which the asset health management is generated on the basis of "knowledge modules"). More particularly, the board cannot see in what respect the fact that the mentioned algorithm can be used for the purpose of mitigating the risk of losing the knowledge of asset experts (see, for instance, paragraph [0002] of the application) and/or of leveraging the knowledge from users to improve the knowledge module for asset health management (paragraphs [0019] and [0024]) and/or of allowing the user to play the asset health management scenario as an interactive game for learning and/or training purposes (paragraphs [0005] and [0022]) could confer technical character to the algorithm.

2.2.2 The board also notes that, in view of the comments mentioned above and of the broad formulation of claim 1, the claim encompasses embodiments in which the whole of the features of the mentioned algorithm could, by its very nature - and contrary to the applicant's submissions -, have been provided by a non-technical expert working in administrative and/or managerial and/or training fields, without it requiring any technical consideration or the assistance of an expert in a technical field.

2.3 The claimed method involves the use of a GUI and of the corresponding user's interactive interface(s) to be used as "action plans interfaces", and the claimed GUI presupposes - as held by the examining division - a computer system with which a user interacts by means of the interactive interfaces of the GUI. For this reason, the claimed method constitutes an invention having technical character and pertains to a field of technology (Article 52(1) EPC).

However, claim 1 only specifies that the claimed method is "for providing" a GUI "for asset health management" and - contrary to the applicant's submissions - the claim requires the use of the GUI together with its interactive interfaces only for carrying out the penultimate step of the method, i.e. for the step of "providing (106) the asset health management scenario (308) through a graphical user interactive interface (310) to a user for interactive play ...". The last step of claim 1, i.e. the updating step, contains the expression "with the graphical user interactive interface", but the formulation of the step in the last paragraph of claim 1 ("updating the asset health management scenario (308) and/or the one or more knowledge modules (202) and/or the other information (302, 304, 306) by using the user action plan with the graphical user interactive interface (310) on the basis of the role of user") does not exclude that the mentioned expression refers to the action plan selected and/or specified by the user "with the graphical user interactive interface" in the previous step. This interpretation is not only consistent with the formulation of the last paragraph of claim 1, but also consistent with the description (see paragraph [0019], lines 14 to 19: "User interaction data with the interactive game interface [...] may be used as feedback in order to update ..."), and the applicant's submissions that claim 1 requires carrying out the claimed updating step itself with the GUI is not supported by the actual formulation of the claim. More particularly, claim 1 does not exclude that the updating step is carried out, for instance, by a person observing directly on the GUI which user action plans are selected and/or specified by the user with the interface(s) of the GUI.

2.4 The closest prior art is represented by a general programmable computer system comprising a GUI having interactive interfaces of the type generally known before the priority date of the application, see for instance any of documents D1 (Fig. 86 and paragraphs [0021] and [0029]), D2 (Fig. 1 and paragraphs [0035] and [0036]), D3, (Fig. 1 and paragraph [0012]) and D4 (paragraph [0009]).

The claimed method differs from the mentioned programable computer system in that the system is specifically programmed to implement the penultimate step of the algorithm defined in the claimed method (see penultimate paragraph of claim 1), i.e. to receive, as an input, the asset health management scenario together with possible action plans, to provide them through the GUI to the user "for interactive play" as claimed, and to allow the user to select and/or specify action plans in the interactive interfaces of the GUI. As already noted in point 2.3 above, claim 1 does not require that all the remaining steps of the method - including the last updating step - are implemented by the computer associated to the GUI; in particular, none of the features of claim 1 exclude that these steps are implemented by some other (in particular, non-technical) means external to the computer.

2.5 An algorithm as that mentioned in point 2.2 above defines non-technical constraints to be considered in the assessment of inventive step only if they contribute to the technical character of the claimed method, for example if they interact with the technical features of the claimed invention so as to bring about a technical effect (see the so-called Comvik approach of decision T 641/00 and its support in, for instance, decision G 1/19, points 110 and 121 of the reasons).

2.5.1 The applicant has essentially submitted that

- the claimed method, in particular when used as a training or learning method for enhancing the capabilities to perform the technical task of asset health management, related to a technique of providing a GUI for collecting or gathering information from experts and updating the asset health management scenario, knowledge modules associated with an industrial asset and/or other information, thereby assisting a user in asset health management via the GUI (description of the application, in particular paragraphs [0005] and [0024]);

- the claimed method involved steps such as collecting data and leveraging user knowledge, and in particular the generation and provision of an asset health management scenario to a user via a GUI comprising actions plans selected and/or specified by the user, and therefore the method steps interacted with the claimed GUI and the respective interactive interfaces so as to result in the advantageous technical effect of improving performance in asset health management via the GUI and to address the technical problem of providing or improving a GUI for asset health management that is adaptive to user input so as to improve the user's capability of performing asset health management tasks; and

- even assuming that, as held by the examining division in its decision, the consequences of the choices of the user were that the training material was updated based on the responses given by the user and that therefore there was no direct technical link or causality with the specific operation parameters of the asset, the process would still improve the GUI for asset health management because the knowledge modules being updated were modules used for real-life asset health management.

2.5.2 The board notes, however, that the claimed method only requires from the technical point of view the use of a GUI for the purpose of providing the asset health management scenario to the user as required by the algorithm and allowing the user to select and/or specify action plans as also required by the algorithm, and the board sees no interaction between, on the one hand, the algorithm and, on the other hand, the GUI and its interactive interfaces other than the fact that the GUI is provided for carrying out the mentioned non-technical purpose. Therefore, the mere fact that the algorithm is carried out using a GUI as claimed may improve the non-technical task of carrying out the algorithm, but it does not result in any effect of a technical nature, let alone in a technical effect of the GUI itself. In particular, the board cannot follow the applicant's references to "improving an interface for asset health management". The use of a GUI may help in carrying out the non-technical task of carrying out the algorithm, but a GUI, and in particular as disclosed in documents D1 to D4, includes interactive interfaces with which a user may interact, and the GUI itself cannot be said to be improved from the technical point of view by the mere use of the GUI as claimed. In addition, a GUI generally interacts, as submitted by the applicant, with data structures to provide visual information to the user, and in the present case the mere implementation of the penultimate step of the algorithm by using a GUI does not go beyond the use of the GUI as such.

Therefore, in line with the view expressed by the examining division in the decision under appeal, the algorithm does not interact with the GUI so as to contribute to the technical character - in particular, so as to result in an effect of a technical nature - beyond the mere implementation of the algorithm, and in particular of its penultimate step, in a computer system having a GUI.

2.6 Since the implementation of the algorithm as defined in claim 1 constitutes an aim to be achieved in a non-technical field (cf. points 2.2 and 2.5.2 above), this aim may legitimately appear in the formulation of the problem as part of the framework of the objective technical problem to be solved, in particular as a non-technical constraint to be met by the (technical) skilled person (see decision T 641/00, headnote 2).

Claim 1 differs from the known general programmable computer system comprising a GUI having interactive interfaces in the steps of the algorithm mentioned above. Since, as already concluded above, the algorithm is not technical (cf. point 2.2) and it does not interact with the GUI so as to contribute to the technical character, and in particular so as to result in an effect of a technical nature (cf. point 2.5.2), the objective technical problem solved by the claimed method can be formulated in terms of the technical implementation of the steps of the algorithm, and in particular of the penultimate step, in the known computer system having a GUI.

The (technical) skilled person having general knowledge of computer programming and confronted with the objective technical problem, and in particular with the underlying requirement of the algorithm relating to providing the asset health management scenario to the user for interactive play and allowing the user to select and/or specify action plans, would have considered programming the known computer system having a GUI so as to implement at least the penultimate of the steps of the mentioned algorithm in a straightforward manner and - as held by the examining division - without technical difficulties that would have required the exercise of inventive skills. In particular, the use of a GUI for viewing and selecting and/or specifying items was generally known in the art, and the skilled person would readily have considered the GUI of the known computer system as being suitable for providing the asset health management scenario to the user and to enable the user to select and/or specify through the interactive interfaces of the GUI action plans as required by the algorithm.

2.7 For these reasons, and in particular in the absence of any technical contribution beyond the straightforward implementation of the mentioned algorithm in a computer system having a GUI, the board concludes that the method defined in claim 1 is, as held by the examining division in the decision under appeal, a mixture of non-technical and technical features devoid of an inventive step within the meaning of Article 56 EPC.

3. Auxiliary requests 1 and 2

3.1 Auxiliary requests 1 and 2 were filed for the first time with the statement of grounds of appeal in 2020.

The claims of these two auxiliary requests have no counterpart in the claims of the requests considered during the first-instance proceedings and they differ in substance from the claims of the request underlying the decision under appeal (see for claim 1 point VIII above, together with point 2.1 above, first sentence, cf. Article 12(2) RPBA 2020).

The appellant has not demonstrated otherwise but affirmed that the requests are amendments of the appeal case (cf. Article 12(4), first sentence, RPBA 2020).

Thus, the admission of auxiliary requests 1 and 2 is at the Board's discretion under all relevant parts of Article 12(4) to (6) RPBA 2020, upon consideration of the requirements of Article 12(2) RPBA 2020.

3.2 In this respect, the Board reminds of the following. Article 12(2) RPBA 2020 lays down that, in view of the primary object of the appeal proceedings to review the decision under appeal in a judicial manner, a party's appeal case shall be directed to the requests on which the decision under appeal was based. According to Article 12(4), first and second sentences, RPBA 2020, any part of a party's appeal case which does not meet the requirements in Article 12(2) RPBA 2020 is to be regarded as an amendment, unless the party demonstrates that this part was admissibly raised and maintained in the proceedings leading to the appealed decision, and such amendments may be admitted only at the discretion of the Board. Under Article 12(6), second sentence, RPBA 2020, the Board shall not admit requests which should have been submitted in the proceedings leading to the decision under appeal, unless the circumstances of the appeal case justify their admittance.

3.2.1 In the present case, there were, in the board's view, reasons to submit the claims of auxiliary requests 1 and 2 during the first-instance proceedings in reaction to the objections raised by the examining division. In particular, the substantive amendments made to claim 1 of auxiliary requests 1 and 2 involving the assets consisting of "real-life" assets and the last of the feature included at the end of claim 1, as well as the second "identifying" and the second "generating" steps included in claim 1 of auxiliary request 2 (see point VII above), could, and in fact should, already have been made during the first-instance proceedings in reaction to the objections raised by the examining division.

The applicant has essentially submitted in support of the admission of auxiliary requests 1 and 2 into the appeal proceedings that the amendments to the claims were in reaction to an argument that was explicitly presented by the examining division in the contested decision, but which was not explicit in the preceding communications or in the course of the first-instance proceedings, so that the applicant was not in a position to react to the corresponding reasoning during the first-instance proceedings.

The board notes that the mentioned argument of the examining division - as summarised by the applicant - essentially objected to the lack of a technical link between, on the one hand, the claimed method steps or the data used therein and, on the other hand, the way in which data could influence the operation of the asset (see reasons of the decision under appeal, point 2.3, third paragraph, last sentence, and point 3.3, second paragraph). However, this argument was already presented - although, as submitted by the applicant, not in such an explicit manner - in points 2.3, 2.10 and 3.1 to 3.4 of the annex to the summons to the first-instance oral proceedings and also during the oral proceedings (minutes, penultimate paragraph). In addition, the mentioned argument was - contrary to the applicant's submissions - also specified in an explicit manner in the communication dated 14 August 2019 issued by the examining division in reply to the amendments filed by the applicant in preparation for the oral proceedings, and in particular by the examining division's counter-argument in point 2.5 of the mentioned communication reading: "The examining division is of the opinion that the consequences of the choices of the user is that the training material is updated based on the responses/interaction given by the user. There is no direct technical link with the operation parameters of the asset."

The applicant has submitted that the mentioned passage in point 2.5 of the examining division's communication was ambiguous and only related to the question of a link between the "choices of the user" and the "operation parameters of the asset", but not to a link between the entire algorithm and the asset operation, so that this argument was different from the argument presented by the examining division for the first time in the appealed decision and there was no reason or incentive at that time to file the claims of auxiliary requests 1 and 2.

However, in point 3.3 of the reasons of the decision the examining division expressed the view that "the consequences of the choices of the user is that the training material is updated based on the responses/interaction given by the user. There is no direct technical link/mapping or causality with the specific operation parameters of the asset disclosed in the application.". The board sees no difference in substance between this argument and the argument already expressed by the examining division in point 2.5 of the mentioned communication and quoted above, in any case no substantive difference that would justify seeing the argument expressed in the decision as a new argument and that would support the applicant's contention that auxiliary requests 1 and 2 were submitted at the earliest possible stage with the statement of grounds of appeal.

3.2.2 The applicant has also submitted that the examining division presented the mentioned argument only with the communication dated 14 August 2019, i.e. shortly before the oral proceedings held on 5 September 2019, whilst they could have done it earlier, for instance with the communication annexed to the summons to oral proceedings.

The board notes, however, that the argument was presented by the examining division in reaction to the amended claims submitted by the applicant in reaction to the communication annexed to the summons and in preparation for the oral proceedings. In addition, the applicant could have submitted the claims of auxiliary requests 1 and 2 in reply to the communication dated 14 August 2019, either before or during the first-instance oral proceedings.

3.2.3 For these reasons the board is of the opinion that the claims of auxiliary requests 1 and 2 could, and in fact should have been submitted during the first-instance proceedings in reaction to the objections and arguments presented by the examining division in writing and during the oral proceedings, and in particular in reaction to the mentioned argument explicitly presented in the communication dated 14 August 2019.

3.3 The board also sees no specific circumstance in the present case that would justify the admission of auxiliary requests 1 and 2 into the appeal proceedings under Article 12(6), second sentence, RPBA 2020. In particular, by filing the claims of auxiliary requests 1 and 2 for the first time with the statement of grounds of appeal the applicant has presented the board with subject-matter on which no decision was taken by the department of first instance, so that the admission of these requests into the proceedings would compel the board either to give a first ruling on several issues (in particular, under Articles 123(2), 84 and 56 EPC) - a task incompatible with its primary reviewing role under Article 12(2) RPBA 2020 -, or to remit the case to the department of first instance, which in the present case would be contrary to procedural economy (cf. Article 12(4), fourth sentence, RPBA 2020).

3.4 During the oral proceedings before the board the applicant argued that filing auxiliary requests 1 and 2 during the first-instance proceedings implied a risk of them not being admitted by the examining division and, therefore, of them not being admitted by the board under Article 12(6), first sentence, RPBA 2020 in a subsequent appeal.

This argument does not affect, let alone alter the board's assessment.

The legal bases for the board's negative view on the admission of the auxiliary requests as set out above - Article 12(2), (4) and (6), second sentence, RPBA 2020 - have their own criteria. These criteria are distinct from those of Article 12(6), first sentence, RPBA 2020, and the appellant's argument has no bearing on their respective application.

In particular, since the provisions in the first and second sentences of Article 12(6) RPBA 2020 and in Article 12(2) RPBA 2020 in effect all emphasise the importance of the examination carried out in the first instance proceedings, circumventing the applicability of one of these provisions by escaping that examination cannot restrict the applicability of the others.

3.5 In view of all these considerations, and in the absence of reasons that would justify doing otherwise, the board decided not to admit auxiliary requests 1 and 2 into the appeal proceedings (Article 12(2), (4) and (6) RPBA 2020).

4. The board concludes that, in the absence of an admissible and allowable request, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation