T 2230/13 (Modifying user interface elements/CORIZON) of 3.3.2016

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dispatched on 5 June 2013, to refuse European patent applica­tion No. 06 779 109.5 because none of the pending requests con­formed with Ar­ticle 123(2) EPC. In a section entitled "Obiter dicta", the decision contains arguments as to why claim 1 of the then main request lacked clarity and, referring to objections raised in the summons to oral procee­dings before the examining division, why claim 1 of the main request lacked an inventive step. The decision refers to several documents, but does not rely on any of them for its reasons.

II. Notice of appeal was filed on 14 August 2013, the appeal fee being paid the following day. A statement of grounds of appeal was received on 14 October 2013, with which the appellant requested that the decision be set aside and that a patent be granted based on claims 1-9 accor­ding to a main or a first auxiliary request as filed with the statement of grounds of appeal, the main request corresponding to the main request as refused by the examining division.

III. In an annex to the summons to oral proceedings, the board informed the appellant of its preliminary opinion, according to which the claims of both requests lacked clarity, Article 84 EPC 1973, and inventive step, Ar­ticle 56 EPC 1973, because their subject-matter did not make a technical contribution to the art. An objection under Article 123(2) EPC was also raised.

IV. In response to the summons, the appellant maintained its previous requests, but filed new claims 1-9 according to a further, second auxiliary request.

V. Claim 1 according to the main request reads as follows.

"A method of modifying at least one of a plurality of user interface elements of a user interface, the method comprising:

receiving at one of a plurality of communicating objects (106, 107, 108), from program code running to provide said user interface, a notification of a manipulation of the user interface, the notification being provided by a call by said program code to a predetermined function, wherein each of said communicating objects represents one of said plurality of user interface elements and wherein said predetermined function is called when a function associated with a predetermined user interface manipulation is called; and

processing said notification at said one of said objects (106, 107, 108), said processing causing modification of said at least one user interface element."

Claim 1 according to the first auxiliary request is iden­tical to claim 1 of the main request, except for the preamble, which reads as follows:

"A method of modifying behaviour of a user interfaces by modifying at least one of a plurality of user interface elements of a user interface, the method comprising: ..."

Claim 1 according to the second auxiliary request is identical to claim 1 according the main request, except for the fact that the three occurrences of user inter­face elements are now specified to be "graphical" user interface elements.

All the requests contain an independent apparatus claim 9 corresponding closely to the respective method claim 1.

VI. Oral proceedings were held as scheduled on 3 March 2016. No one was present for the appellant, although this had not been indicated beforehand to the board. At the end of the proceedings, the chairman announced the board's decision.

Reasons for the Decision

Decision in the appellant's absence

1. According to Article 15(3) RPBA, the board is not ob­liged to delay any step in the proceedings, including its decision, by reason only of the absence at the oral proceedings of any party duly summoned. Therefore, and further in accordance with Article 15(3) RPBA, the board treats the appellant as relying only on its written case.

The invention

2. The application is concerned with flexibility in gene­ra­­ting and modifying user interfaces, for instance in order to provide one seamless interface for several appli­­­ca­tions (see e.g. page 1, paragraph 3 - page 2, last paragraph).

As a solution, the application discloses a "method of mo­difying a source applica­tion" (i.e. program code) at run-time (page 3, paragraph 2; page 31, para­graph 2), which is "par­ti­cularly suitable for modifying user in­ter­­fa­ces" (pa­ragraph 4). Furthermore, it dis­clo­ses "a method of affecting the behaviour of a user in­ter­face comprising a plurality of user interface ele­ments" (page 5, para­graphs 2 and 4).

2.2 This effect is achieved by manipulating the object code of a given application (see figures 8-12 and pages 16 to page 18, paragraph 1; page 31, para­graph 2 - page 33, paragraph 3)), so that whenever the applica­tion re­quires the execution of a certain piece of handler code in res­ponse to a user interface event (see figure 8, no. 50: "GetMenu"), a piece of "hooking code" is al­so exe­cu­ted (figure 8, nos. 52, 53, 61, and 73). The hoo­king code in turn calls an "agent" (see page 13, middle paragraph; page 15, last para­graph; figure 8, rightmost box), which is mostly im­ple­men­ted in the in­terpreted language Python (see figure 8, no. 43, and figure 15), and which is "responsible for providing modifications for the source application" (page 13, paragraph 3).

2.3 It is also stated in the description - and in the claims - that the invention is based on "modelling" the user inter­face in terms of "a plurality of communi­ca­ting objects" which are "pre­ferably" defined using an object-oriented language (see page 5, paragraph 4).

Article 84 EPC 1973

3. The independent claims of the main request refer to "commu­nicating objects",

a) which "receiv[e] [...] from program code [...] a notifi­ca­tion";

b) each of which "represents one user interface ele­ment"; and

c) the processing of which "caus[es] modification of user interface element[s]".

They further specify that

d) "program code running to pro­vide said user in­ter­face" notifies the communicating objects.

3.1 In the board's understanding, a) implies that the "communicating objects" are themselves some form of program code, which, however, need not be written in an object-orien­ted pro­gramming language, as this choice of language is disclosed as mere­­ly preferable. In its letter of 3 February 2016 (page 2, penultimate para­graph), the appellant confirmed this inter­­pretation. On that un­der­standing, however, the board considers that neither the term "communicating objects" as a whole, nor its components "communicating" or "objects", are suffi­cient to im­ply any specific limitation on the program code re­ferred to.

3.2 As regards b), the board agrees with the decision under appeal (see reasons 5.2) that this sentence is vague and ambiguous, Ar­ticle 84 EPC 1973. On a broad reading, the skilled person might deduce that each communi­cating ob­ject "represents" one user interface element in that there is one such object per user interface element, no­ting however that this would have no further implication as to what the communicating objects are intended to "do" when executed. In the board's view, the claim wor­ding also covers the inter­pretation that the communi­cating ob­jects "implement" the user inter­face elements in terms of their appea­­rance and beha­viour. Al­ter­native­ly, the communi­ca­ting objects might be understood to implement only the be­ha­viour of a user interface ele­ment, the appearance of which is defined elsewhere. Or, they might be unders­tood to imp­le­ment part but not all of what consti­tutes a user in­ter­face element in terms of appearance and/or beha­vi­our.

3.3 As regards c), it is noted that the claims do not de­fine the term "modifi­ca­tion of user interface ele­ment[s]" explicitly. Its meaning can also not be de­rived indi­rect­ly from the behaviour of the communica­ting objects because, as just argued, the claims also fail to de­fine what exe­cution of the "communicating object" is meant to achieve, other than by reference to said "modifica­tion". Therefore, it is unclear how the "pro­cessing of [a] no­tification at [the] objects" is meant to "cause" said modification, Article 84 EPC 1973.

3.4 Phrase d) implies that the "pro­gram code" is distinct from the "communicating objects", but it is left open in what way: Specifically, the claims leave open the exact diffe­rence between the pro­gram code "providing" the user in­terface and the commu­nica­ting objects "re­pre­senting" it.

4.

4.1 The appellant argues that "the term 're­pre­sents'" is "distinct from 'implements' and 'provides'", "takes its ordinary meaning and would be clear to the skilled per­son in the art, especially in light of the detailed de­scription." The appellant also states that "the commu­nicating ob­jects neither implement appearance or beha­vi-our, but merely re­pre­sent, and cause modifi­ca­tion of" user in­terface ele­ments (see letter of 3 Fe­bru­ary 2016, page 2, paragraph 2). However, the appellant fails to define what it considers to be the "ordinary meaning" of the terms "represent" in the present con­text, except by illustrating it with the equally un­clear term "model" (see the letter, page 1, last para­graph, to page 1, paragraph 1), to explain how speci­fically it con­siders this mea­ning to be different from that of the terms "imple­ment" and "provide" and why the skilled person would understand it not to cover the implemen­tation of "appea­rance or behaviour". The appellant suggests that the "program code running to provide [the] user inter­face" referred to the user in­terface of an existing applica­tion which the communi­ca­ting objects were meant to modify "at runtime" (the letter, loc. cit.) so that it would not have to be de­veloped "from scratch" (page 2, paragraph 4). While it is accepted that method claim 1 refers to the behaviour of an "existing" user inter­face at runtime, the claim language implies that the "communi­cating objects" are "existing" and "running" in just the same sense. This explanation is thus insuffi­cient to explain the re­la­tion and diffe­rence between the claimed program code and the communicating objects.

4.2 In summary, the board considers that the independent claims of the main request are unclear as regards­ the roles of the program code and the communi­ca­ting objects in implementing the user interface (ele­ments) and in bringing about any "modification" of them, Article 84 EPC 1973.

5. In the first auxiliary request, the independent requests are limited by the amended preamble to modifications of the "behaviour" of the user interface. The board takes this to exclude the interpretation discussed above with re­spect to a), i.e. that the communicating objects might affect the appearance of the user interface elements.

5.1 The board observes that this may be regarded as being in conflict with the description, which focuses on the adaptation of the "look and feel", i.e. the appearance of user interfaces rather than their behaviour.

5.2 This observation aside, however, the board notes that the limitation to user interface behaviour is insuffi­cient to explain the difference between the "program code running to provide [the] user interface" and the "communicating objects represent[ing] the [...] user interface elements", or how both piece of program code interact to "cause[e] modification of [the] user interface element[s]".

5.3 Therefore, the independent claims of the first auxiliary request also lack clarity, Article 84 EPC 1973.

6. In the second auxiliary request, the independent re­quests are limited to refer to graphical user interface elements.

6.1 The board considers that this limitation shifts the focus of the claims to the modification of the appea­rance of the user interface elements rather than their behaviour, in this respect being complementary to the claims of the first auxiliary request.

6.2 However, also this limitation to user interface appea­rance is insuffi­cient to explain the difference between the "program code running to provide [the] user inter­face" and the "communicating objects represent­[ing] the [...] user interface elements", or how both pieces of program code interact to "cause[e] modification of [the] user interface element[s]".

6.3 Therefore, the independent claims of the second auxil­iary request also lack clarity, Article 84 EPC 1973.

Order

For these reasons it is decided that:

The appeal is dismissed.