Selected decisions 

1. A request for apportionment of costs is not inadmissible for the sole reason that it had been filed after the closure of the appeal proceedings. Decision T 1556/14 is not followed. (Reasons 1.1 to 1.17)

2. A request for apportionment of costs after termination of the appeal proceedings can still open ancillary proceedings for deciding issues arising out of the original appeal proceedings, without re-opening the substantive appeal proceedings. (Reasons 1.6 to 1.7)

3. A reasonable time limit for filing a request for apportionment of costs where the appeal proceedings are terminated by a withdrawal of an appeal should correspond to the usual time limits applicable to proceedings before the EPO, namely the standard two months of Rule 132(1) EPC. Questions should be asked only if the request is submitted after a reasonable period of time. (Reasons 1.20 to 1.21)

4. Beyond the general obligation to inform the other parties as soon as possible, the parties have no formal obligation to take even more active steps merely to avoid the costs already foreseen by the other parties. At most, parties must seek to avoid additional costs. The recognition of such a formal obligation would place an unrealistic burden on parties to the proceedings before the EPO. (Reasons 2.6)

1. Inventive step - credibility of the alleged technical

effect and burden of proof (reasons, points 2.5.6 and

2.5.7).

2. The amendment referred to in Article 12(4) RPBA is not

synonymous with the "amendment to a party's appeal case"

within the meaning of Article 13(2) RPBA (reasons, point

3.5).

3. An amendment by way of deletion of an (alternative in an)

independent claim is an amendment of the appeal case within

the meaning of Art 13(2) RPBA (reasons, point 3.6).

The general idea of protecting a transaction, here a registration, with a password is non-technical and also well known. The idea of using a predefined set of one-time passwords for user authentication also lacks technicality. Even when considered technical, it could not support an inventive step, as it corresponds to the well-known transaction authentication number (TAN) authentication procedure commonly used in online transactions. Using a server to store and verify the TAN numbers and distributing these on cards is a straightforward implementation of this known procedure.

(See point 8 of the reasons)