T 0595/10 (Skinning/BLACKBERRY) of 19.3.2015

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division, the reasons for which were dispatched on 17 November 2009, to refuse European patent application No. 07 719 786.1 for lack of inventive step, Article 56 EPC, in view of the document:

D1: US 2005/0102626 A1.

II. A notice of appeal was received on 26 January 2010, the appeal fee being paid on the same day.

III. A statement of grounds of appeal was received on 15 March 2010 in which the appellant made a conditional request for oral proceedings.

IV. The board issued a summons to oral proceedings, giving in an annex its preliminary opinion that the application seemed not to comply with Article 84 EPC 1973 regarding clarity and conciseness, and Article 56 EPC 1973 regarding inventive step.

V. With a letter received on 18 February 2015 the appellant submitted claims according to a main and first and second auxiliary requests, the claims of the main request being the same as those on which the decision was based. The letter also referred to amended pages 4, 6 and 8 of the description being enclosed (see page 6, third paragraph). The online filing receipt for this letter does not mention description pages being sent to the EPO, and no such pages were received at the EPO.

VI. On 17 March 2015 a letter was received from the appellant stating that it would not be attending the oral proceedings.

VII. Oral proceedings were held on 19 March 2015 in the absence of the appellant. At the end of the oral proceedings the board announced its decision.

VIII. The appellant requests that the decision be set aside and a patent be granted on the basis of claims 1 to 16 of the main request, claims 1 to 11 of the first auxiliary request, or claims 1 to 10 of the second auxiliary request.

The remaining documents of the application on file are as follows:

Description:

Pages 1 and 4 to 45, as originally filed

Pages 2 and 3a, as received on 14 October 2008

Page 3, as received on 6 October 2009.

Drawings:

Sheets 1 to 11, as originally filed.

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

"A media engine apparatus (110) for creating a graphical interface (120) for an application (105) executed on a mobile device (100), the media engine comprising: a renderer (111) for rendering the graphical interface based on template information for the application to a display on the mobile device; a parser (114) for parsing from a template file, the template information defined using Scalar Vector Graphics (SVG) language, the template information describing how to render the graphical interface, the template information comprising: a set of data element definitions associated with a set of data elements (107) defined by the application; a set of custom event definitions associated with a set of custom events defined by the application; and layout manager control information specifying the layout requirements for controlling how a layout manager controls rendering of template information comprising: information for dynamically modifying a length of at least one data element of the set of data elements; and information for dynamically altering display information of an element defined in the template; a content interaction interface (112) for use by the application in notifying the media engine of changes to data elements of the set of data elements of the application and the occurrence of custom events of the set of custom events of the application; and the layout manager (118) for dynamically controlling the rendering of the graphical interface during execution of the application based upon: the template information including the layout manager control information; the changes to the data elements: and the occurrence of custom events notified using the content interaction interface prior to rendering."

The claims according to this request also comprise independent claim 6 to a mobile communication device, independent claim 14 to a method of generating a graphical user interface and independent claim 16 to a computer-readable medium storing instructions or statements.

X. Claim 1 of the first auxiliary request differs from claim 1 of the main request in that the first two constituents of template information parsed by the parser (114) are amended as follows:

"a description of how to display information associated with a set of data elements (107) defined by the application on the graphical interface; a description of how to display information associated with a set of custom events defined by the application on the graphical interface;".

The claims according to this request also comprise independent claims 9 and 11, which are identical to independent claims 14 and 16 of the main request, respectively, and claim 5 to a mobile communication device which refers to the media engine of any of claims 1 to 4.

XI. Claim 1 of the second auxiliary request differs from claim 1 of the first auxiliary request in that the content interaction interface (112) feature is amended as follows (additions being underlined):

"a content interaction interface (112) for use by the application in providing the data elements to the media engine and notifying the media engine of changes to data elements of the set of data elements of the application and the occurrence of custom events of the set of custom events of the application;".

The claims according to this request also comprise independent claims 8 and 10, which are identical to independent claims 14 and 16 of the main request, respectively, and claim 4 to a mobile communication device which refers to the media engine of any of claims 1 to 3.

Reasons for the Decision

1. Admissibility of the appeal

In view of the facts set out at points I to III above, the appeal is admissible, since it complies with the EPC admissibility requirements.

2. Context of the invention

2.1 The application relates to a media engine (110 in figure 1; 110a, 110b, 110c and 110d in figures 3a to 3d, respectively) for creating graphical user interfaces for applications (105 in figure 1) running on a mobile device using a library of template files (115 in figure 1) in Scalable Vector Graphics (SVG) format.

2.2 The media engine includes an Application Programming Interface (API) (112/112b in figures 3a to 3d) for interacting with the applications, a parser (114, ibid.) for parsing the template files, a template (113, ibid.) for holding the graphical interface information parsed from the template file, a layout manager (118 in figures 3b and 3d) for dynamically updating this information in response to notifications by the application and a renderer (111, ibid.) for rendering this information to the display; see paragraph [0017].

2.3 The procedure for creating the graphical user interface is explained in paragraphs [0048] to [0050] with reference to figure 5a. When an application starts on the mobile device, it notifies the media engine of its ID (501 in figure 5a). The media engine uses this ID to locate a template file in the template library (505, ibid.). Some example template files used by the media engine are provided in paragraphs [0043] and [0046]. The template file is then passed to the parser which stores the parsed template information (515 and 520 in figure 5a) in the template. The media engine waits to receive API calls from the application (109 in figures 2, 3a to 3d) concerning data element updates or custom event notifications (525 in figure 5a). When such an API call is received, the layout manager updates the template (530, ibid.) and, if the graphical user interface should be updated (535, ibid.), passes the template to the renderer (540, ibid.).

3. Admittance of the requests

The claims according to the present main request are a refiling of the claims upon which the appealed decision was based. The first and second auxiliary requests were submitted in reply to the board's summons to oral proceedings and hence, according to Article 13(1) RPBA (Rules of Procedure of the Boards of Appeal; see OJ EPO 2007, 536), the board has a discretion whether or not to admit them into the proceedings. Given that the amendments to the claims are not complex and intended to address the board's objections under Article 84 EPC 1973 raised in the annex to summons, both requests were admitted into the procedure.

4. Clarity and construction of the claims, Article 84 EPC 1973

4.1 In the annex to the summons to oral proceedings the board raised objections under Article 84 EPC 1973, regarding the clarity of the claims, inter alia against the terms "data element definitions" and "custom event definitions" used in the main request.

4.2 The appellant indicated in its letter of 18 February 2015 (page 2, first full paragraph) that the "... 'data element definitions' and 'custom event definitions' included in the template file can only refer to the information defining how to display the custom events or data elements on the graphical user interface". The appellant further indicated that the amendments to claim 1 of the first auxiliary request were made to address this particular objection by the board (pages 6 and 7, §5.1) and that the only further amendment to claim 1 of the second auxiliary request was made to clarify that data elements were received from the application (page 8, §5.2).

4.3 In the light of the appellant's explanations, the board finds that claim 1 of the main request is sufficiently clear for the purposes of assessing inventive step. As the amendments to claim 1 of the first and second auxiliary requests merely clarify the features of claim 1 which had been objected to as unclear in the context of the main request (see also appellant's letter of 18 February 2015, page 8, §6 and page 9, §6), and as these amendments do not alter the board's understanding of the subject-matter of the claimed invention, the board considers that the same assessment of inventive step is applicable to claim 1 according to all three requests on file.

5. Document D1

5.1 D1 discloses a method for creating custom skins for software applications. A skin (300 in figure 3; paragraph [0064]) typically consists of a master file called a "skin definition file" (302 in figure 3) accompanied by a plurality of art and script files (304 and 306 in figure 3). The skin definition file is written in a hierarchical tag-based language, typically XML (Extensible Markup Language), wherein tag pairs define elements of the user interface and their behaviour (paragraph [0067]). The example embodiments in D1 are given in the context of Microsoft Windows Media Player; see paragraph [0036]. Examples of skin definition files are given in figures 10 and 18 to 22. Figure 14 illustrates two views of an exemplary skin.

5.2 The behaviour of the elements in a skin definition file including the responses to user input events, as well as internal events notified by the application, are defined using scripts; see paragraphs [0126] to [0133]. Scripts can either be provided by script files (paragraphs [0122] to [0128]) or inline (paragraphs [0182] to [0183]; figures 18 and 19).

5.3 The process for creating skins and the computer architecture for performing the process are illustrated in figures 12 and 11, respectively. The system includes an XML parser (1104 in figure 11), a layout manager (1106, ibid.) comprising a rendering engine (1114, ibid.) and a script engine (1108, ibid.). The XML parser parses the skin definition file into an intermediate representation in the form of a hierarchical data structure describing the skin and its attributes (step 1204 in figure 12; paragraph [0140]). The layout manager uses the intermediate representation to create rendering elements (paragraph [0141]). If any scripts are specified in the skin definition, then the layout manager instantiates the script engine and provides it with handles to the various rendering elements and the code that it needs to impart the scripted functionality to the elements (paragraphs [0142] and [0147]). Consequently, in the rendering phase, the rendering engine renders or draws the skin (paragraph [0152]). In response to a predefined event at runtime, the rendering engine redraws at least a portion of the skin that corresponds to the effected rendering elements; see figure 13, paragraphs [0155] and [0156].

6. Inventive step, Article 56 EPC 1973

6.1 It is common ground between the examining division in its decision and the appellant, and the board agrees, that D1 forms the closest prior art.

6.2 In the decision under appeal the examining division identified four differences between the subject-matter of claim 1 and the disclosure of D1; see point 1.2 of the reasons. The differences were not considered to involve an inventive step, Article 56 EPC 1973. As explained below, the board agrees that three of these four differences exist and also finds that there are no further differences.

6.2.1 The first difference identified in the appealed decision is that the media engine apparatus according to claim 1 is for an application executed on a "mobile device", as opposed to that of D1 which is for a "hand-held device". The board considers the terms "hand-held device" and "mobile device" to be synonymous in this case and does not see any difference in this regard between the subject-matter of claim 1 and the disclosure of D1.

6.2.2 The second difference identified in the appealed decision is the use of the SVG markup language for the definition of the template. The examining division argued that SVG and its specification for mobile phones were well known at the priority date of the present application. The board agrees with the examining division regarding the existence of this difference and the obviousness of using SVG for skinning applications. Moreover, considering that the skins in D1 are defined using a hierarchical tag-based language, in particular XML, the board finds no teaching in D1 which would have led the skilled person away from using SVG, which is an XML-based language specifically conceived for describing graphics.

6.2.3 The third difference identified in the appealed decision is that, while in D1 the handlers for custom events are stored in a JScript file separate from the XML file containing the data element objects, according to the claimed invention they are stored in one single file. In the annex to the summons to oral proceedings the board agreed with the examining division's position that the number of files constituting a computer program product was a straightforward design decision for the skilled person, but also pointed out that this feature seemed to be disclosed in D1 which, in addition to the use of separate script files for event handlers, also discloses the use of inline scripts.

The appellant submitted in its letter of 18 February 2015 (page 5) that the inline scripts disclosed in D1 were used in combination with external script files and claimed several technical advantages of integrating all kinds of control information within one single template file, such as reducing the amount of code and the number of files required and thus the need for storage and reducing the amount of time required to update the GUI. The appellant further argued that the media engine of the invention, unlike the system of D1, did not require an object model builder or intermediate rendering elements.

The board does not accept that the question of whether or not the media engine of the invention requires an object model builder or intermediate rendering elements is related to the question of whether or not the third difference feature is obvious. Turning to the number of files constituting the software product, the board is of the view that the trade-offs involved in organising software in a single file or a plurality of files, in particular of using inline or external scripts, would have been apparent to the person skilled in programming.

6.2.4 The fourth difference identified in the appealed decision is that the layout manager control information includes information for modifying the length of at least one data element. The examining division referred in the decision inter alia to GUI elements such as text and buttons in D1 and argued that it was implicit that the length of these elements could be dynamically modified. The appellant argued in its letter of 18 February 2015 (page 3, §5.2) that the claim does not refer to the length of any GUI element, but of data elements passed by the application to the media engine, referring, in particular, to paragraph [0034] of the description. The cited paragraph discloses inter alia an example in which strings exceeding a certain length are truncated, and an ellipsis ("...") is appended to their end. The board notes that the skin depicted in D1, figure 14, in particular the playlist on the right-hand side of the second media player, contains one song with the truncated title "Everybody gets the ..." and considers that the claimed feature would have been a usual design modification of the renderer known from D1 to perform a truncation to produce the result depicted in figure 14.

6.3 In the statement of grounds of appeal the appellant challenged the distinguishing features of claim 1 as identified by the examining division and argued that the template information in D1 did not include "custom event definitions" and "layout manager control information specifying the layout requirements for controlling how a layout manager controls rendering of template information" as set out in claim 1. The appellant also argued that there was no dynamic modifying of element display information in D1 during execution of the application.

6.3.1 Concerning "custom event definitions", the appellant alleged a "lack of explanation of the reasoning behind the examining division's rejection". It argued that the division relied on figures 9 and 10 in alleging that D1 disclosed custom events. It was not clear to the appellant how the BUTTONGROUP, PAYELEMENT and STOPELEMENT elements depicted in figure 10 could teach custom events.

However the decision under appeal cites at points 1.1.6 and 1.1.7 paragraphs [0127] to [0135] of D1, in particular paragraphs [0128] to [0129], relating to external event handling, and provides its interpretation under 1.1.7 that the external events in D1 are analogous to custom events. Thus the board considers the explanation given in the appealed decision to be sufficient.

6.3.2 The appellant argued, in relation to paragraphs [0127] to [0135] of D1, that, although these paragraphs described handling events, they did not suggest "custom events" as recited by the claims.

The examining division interpreted "custom events" at point 1.1.7 of the appealed decision as external user input events analogous to external events of D1 in paragraph [0129]. The board finds that this interpretation is not the only possible one of the term "custom event" in the context of the present application. According to the description, paragraph [0018], a "custom event is some event of significance that occurs in the application's business logic." This definition seems to the board to correspond to the internal events described in paragraphs [0134] and [0135] in D1. In any event the board regards both types of events as being disclosed by D1.

6.3.3 Concerning "layout manager control information", the examining division referred in the appealed decision, in particular, to paragraph [0141] of D1 as disclosing that the XML parser read the skin definition file and created an intermediate representation to be used for the layout manager, which meant that information for controlling the layout manager was in the skin definition file. The board agrees with the finding in the appealed decision that the existence of a layout manager in D1 and the fact that it reads the intermediate representation generated by the XML parser from the skin definition file to build an object model and to render it, together mean that the skin also has information for controlling the layout manager.

6.4 The board concludes that the subject-matter of claim 1 of the main and first and second auxiliary requests does not involve an inventive step, contrary to Article 56 EPC 1973.

Order

For these reasons it is decided that:

The appeal is dismissed.