T 1534/14 (Contact book application/THOMSON) of 18.7.2017

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division, with reasons dispatched on 23 January 2014, to refuse European patent application No. 07 858 925.6 for lack of inventive step over the document

D4: "User's Guide for Nokia 7200", Nokia 2004.

In this decision, brief reference will also be made to

D6: US 6 658 095 A and

D7: JSR Expert Group Excerpt from "Java 2 Platform, Micro Edition - Content Handler API Specification (CHAPI)", Final Release, Java Community Press, 3 June 2005.

II. Notice of appeal was filed on 2 April 2014, the appeal fee being paid on the same day. A statement of grounds of appeal was received on 2 June 2014. With the notice of appeal, the appellant requested that the decision be set aside and that the examination proceedings be resumed. With the grounds of appeal, it filed claims 1-6 according to a main and an auxiliary request, the other application documents being the published description pages 3-9 and drawing sheets 1-6, and the description pages 1 and 2 as filed on 9 No­vem­ber 2011. The board understands the appellant's request for "resumption of the examination procedure" to mean that it is asking for a patent to be granted on the basis of one of the two requests after the due examination of their merits.

III. Sole independent claim 1 of the main request reads as follows:

"An electronic device (20), comprising:

- a native contact book application (30);

characterized by further comprising:

- at least one Java application (38) for providing one or more functions relating to information included in the native contact book application (30); and

- a content handler (36) serving as an interface between operations of the native contact book application (30) and operations of the at least one Java application (38),

- wherein the at least one Java application (38) provides additional user interface information relating to corresponding contacts included in the native contact book application (30) to the native contact book application (30) via the content handler (36), the additional user interface information including presence information and being displayed with the corresponding contacts in the native contact book application (30)."

Claim 1 of the auxiliary request differs from claim 1 of the main request only in that the presence information is specified to be "a presence icon".

IV. In an annex to a summons to oral proceedings, the board informed the appellant of its preliminary opinion that the subject-matter of claim 1 of both requests lacked inventive step over D4.

V. In response to the summons, the appellant did not submit arguments or amendments. Instead, it informed the board with letter of 5 July 2017 that it would not be attending the oral proceedings.

VI. The oral proceedings took place on 18 July 2017 as scheduled and, as announced, in the appellant's absence.

VII. At the end of the oral 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 obliged 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 also in accordance with Article 15(3) RPBA, the board treats the appellant as relying only on its written case. The appellant has chosen not to respond in substance to the board's preliminary opinion, from which the board has no reason to deviate. Thus, the reasons given below are based on the board's preliminary opinion.

The invention

2. The application relates to an electronic device (typically a mobile phone) comprising a "native contact book application" and addresses the problem of enabling Java applications to communicate with the native contact book application so as to "add information and/or actions" to it (see page 1, paragraphs 3 to 5).

2.1 It is particularly interested in enhancing the contact book application with "presence information", which may indicate whether a "contact is online or offline" (see page 2, paragraph 1, and page 7, last paragraph). The presence information may be obtained "in any conventional manner" and provided in the form of "presence icons" and "text associated with the selected contact" (see page 7, last paragraph, to page 8, first paragraph, figures 4 and 7B).

2.2 The invention proposes to use an application programming interface (API) based on "content handlers", in particular the specific interface JSR 211 (see e.g. page 4, paragraphs 2 and 4), between the native contact book application and the Java applications (see figure 2) and to have a Java application obtain the presence information (and, possibly, the presence icons) and provide it to the native contact book application.

The prior art

3. D4 is the user's guide to the Nokia 7200 mobile phone which offers a presence functionality referred to as "My presence". The presence information is indicated by icons (see pages 98 and 101) which are displayed next to the contacts (see page 97, and page 19: "presence-enhanced contacts").

4. D6 discloses a system for collecting and presenting presence information in a disparate computer and telephony network. The board takes D6 to disclose an instance of what the description (page 7, last paragraph) refers to as a "conventional manner" of obtaining presence information in a network.

5. D7 relates to the API JSR 211 which gives applications access to Java or non-Java (e.g. native) applications via what are called "content handlers" (see D7, figure 1 on page 3, and bullet points 5 and 6 on page 4). A phone book application is mentioned as a possible content handler (see D7, page 3, use case 8) and also mentioned is the idea that content handlers "can provide multiple actions that control how [...] content is displayed, modified or returned" (page 1, paragraph 1).

Inventive step, main request

6. It is common ground that D4 discloses the Nokia 7200 to have a native contact book application and a "My presence" application adding functionality to that native contact book application by displaying presence information "with" the contacts.

6.1 D4 does not disclose how the My presence application is implemented. That is, D4 discloses neither that My presence is a Java application nor that it is a native application. It also does not disclose how closely the contact book and the My presence application are integrated and, hence, how difficult it might be to "remove" the latter from the former (see the grounds of appeal, page 3, last paragraph).

6.2 Claim 1 therefore differs from D4 in that

(a) the My presence function is provided as a Java application and that

(b) a "content handler" is provided as an interface between the My presence application and the native code book application.

These are essentially the differences identified in the contested decision (see reasons 1.1, page 4, paragraphs 3 and 4).

6.3 The board also agrees with the examining division and the appellant that these differences serve to implement the My presence feature in a flexible and portable manner (see the contested decision, page 4, paragraph 5, and the grounds of appeal, page 3, the last 4 lines above section "Obviousness"). In the summons to oral proceedings, the board expressed its doubts as to whether this was a technical problem. However, the question can be left open because the board considers that the invention lacks inventive step either way.

7. The board disagrees with the appellant as to what the skilled person starting from D4 and setting out to solve that problem would have had to do to arrive at the subject-matter of claim 1.

7.1 For the sake of argument, the board follows the appellant's plausible, if unproven, assertion that both the contact book and the My presence function were provided by closely integrated native applications in the Nokia 7200.

7.2 Even under this assumption, the skilled person would not have had to modify the device as disclosed in D4 and, in doing so, untangle the two applications, implement one in Java and keep one native, in order to arrive at the invention (see the grounds of appeal, page 3, last paragraph, to page 4, paragraph 2).

7.3 Rather, in the board's view, the skilled person would simply have had to re-implement the functions known from D4, for instance on a next-generation mobile phone. The idea of implementing the functionality of D4 "from scratch" rather than by modifying an existing implementation is, in the board's view, a realistic and thus obvious one.

7.4 In this situation, the skilled person would, in the board's view, find it obvious to consider the option of implementing the contact book as a native application and the My presence function as a Java application. Furthermore, the skilled person would make that decision by balancing the known advantages and disadvantages of native and Java applications. In the case at hand, the skilled person would inter alia consider the fact that the contact book is a basic ("built-in or standard"; see the description, page 1, pargraph 3) and local function of the mobile phone, whereas the presence function is more expendable than the code book application and also more complex because it requires interaction with external computers. In view of this, the board considers that the skilled person would give preference to an application of My presence in Java which might be easier to develop, easier to adapt and easier to port than a native application.

7.5 An interface between both applications is obviously needed, for instance because the presence information should only be displayed for the user's contacts (see D4, page 100). In this respect, the JSR 211 (known e.g. from D7) would be an obvious choice because it was developed for just this type of purpose.

7.6 The appellant's assertion that modifying D4 towards the invention would require the implementation of a "counter handler" (see grounds of appeal, page 4, paragraphs 1, 3 and 5) is immaterial for claim 1, which does not mention a counter or functionality implying the need for one. Moreover, the board takes the view that implementing a counter handler, if required, would be straightforward for the skilled person.

7.7 The board thus concludes that claim 1 of the main request specifies an obvious implementation of the functionality known from Nokia 7200 and thus lacks inventive step over D4, D7 and common knowledge in the art, Article 56 EPC 1973.

Inventive step, auxiliary request

8. That the presence information is indicated by icons displayed on the interface of the contact book application is known from D4.

8.1 Amended claim 1 of the auxiliary request thus differs from D4 by the additional feature that

(c) the presence icons are part of the "additional user interface information" provided by the My presence application in Java.

8.2 The board notes that in the given scenario the icons have to be provided either by the contact book or the My presence application. The board considers both to be obvious. However, since the presence icons are logically related to the My presence function, the board regards it as preferable to implement the presence icons by the My presence application, for instance as an obvious matter of modularity. Moreover, if the icons (and possibly associated text) are individually defined by the user (as seems to be intended, although not claimed: see figure 4, nos. 50 and 54), they will have to be obtained over the network just like the presence information. For the reasons given above with respect to the presence information (see point 7.4), the board considers it obvious to have the Java application obtain the icons from a user's contacts.

8.3 In summary, also claim 1 of the auxiliary request lacks inventive step over D4 and common knowledge in the art, Article 56 EPC 1973.

Order

For these reasons it is decided that:

The appeal is dismissed.