T 1204/12 (Alert status/QUALCOMM) of 20.9.2017

Summary of Facts and Submissions

I. The appeal is directed against the decision of the examining division, dated 8 December 2011, to refuse application No. 07865814.3 for lack of inventive step.

II. A notice of appeal was received on 31 January 2012. The appeal fee was paid on the same day. A statement of grounds of appeal was received on 4 April 2012. A sole claim set labelled "main request" was filed. Oral proceedings were conditionally requested.

III. In its summons to oral proceedings, the board gave reasons for its preliminary opinion that claim 1 lacked an inventive step.

IV. In a letter dated 18 August 2017, the appellant filed two new requests replacing the previous one.

V. Oral proceedings were held on 20 September 2017 in the absence of the representative (at no notice). At their conclusion, the board announced its decision.

VI. The appellant requests that the decision be set aside and that a patent be granted based on the main or auxiliary request, both filed on 18 August 2017.

The other application documents are the same as in the appealed decision.

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

"1. A method of establishing a user communications availability in an application (206) operative on a mobile communications device (200), the method comprising:

determining an alert status associated with the mobile communications device (200);

responsive to the determination of the alert status being in a first state, presenting to a user a first plurality of options, each of the first plurality of options corresponding to establishing the user communication availability in the application with a status applicable to said application (206);

responsive to the determination of the alert being in a second state, presenting to the user a second plurality of options having at least one option different from the first plurality of options, each of the second plurality of options corresponding to a user communication availability with a different status applicable to said application (206);

receiving a selection from the user of an option from said first or second plurality of options;

responsive to said selection of the option from said first or second plurality of options, auto­matically establishing and setting, at the mobile communications device, the status of the user communication availability in said application (206) in accordance with the status corresponding to the selected option; and

sending the status of the user communication availability in said application to a server (114), wherein the sending causes the server (114) to transmit an availability status representative of the status of the user communication availability in said application to at least one other mobile communications device associated with said application."

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

"1. A method of establishing a user communications availability in an application (206) operative on a mobile communications device (200), the method comprising:

determining an alert status associated with the mobile communications device (200);

responsive to the determination of the alert being in a first state, presenting to a user a first plurality of options, each of the first plurality of options corresponding to establishing the user communication availability in the application with a status applicable to said application (206);

responsive to the determination of the alert being in a second state, presenting to the user a second plurality of options having at least one option different from the first plurality of options, each of the second plurality of options corresponding to a user communication availability with a different status applicable to said application (206);

receiving a selection from the user of an option from said first or second plurality of options;

receiving, from a server storing a status of the user communication availability applicable to said application, an availability status indicating the stored status;

determining whether the status corresponding to the selected option is different from the received availability status; and

responsive to a determination that the status corresponding to the selected option is different from the received availability status:

automatically establishing and setting, at the mobile communications device, the status of the user communication availability in said application (206) in accordance with the status corresponding to the selected option; and

sending the status of the user communication availability in said application to a server (114), wherein the sending causes the server (114) to transmit an availability status representative of the sent status of the user communication availability in said application to at least one other mobile communications device associated with said application."

Reasons for the Decision

1. Summary of the invention

The application relates to entering and setting a user communication availability status for a push-to-talk application (PTT app 206, see figure 5) in a mobile communication device 200 (e.g. a PDA, a smart phone or a PC; see original description, [20]). Push-to-talk is a server-based voice communication system for a group of users over a packet-switched network such as GPRS (see for example https://de.wikipedia.org/wiki/Push-to-Talk_ over_Cellular).

The PTT app 206 in the mobile communication device 200 is the client-side software for this service. Its login availability module 232 ([48], last sentence) prompts the user for his/her communication availability status ([62]-[64]). The possible status values are "available", "do not disturb" and "silent/non-audible" (see original claims 7-9, [63] and figure 6, S45 and S26; in the original claims, the user communication availability status is called the "application state").

The claims relate to the second embodiment ([60]-[69]; figures 5 and 6). The user initially sets a ringer or alert status either to "audible/ring" or "non-audible/silent" ([19] and [61]). Depending on this ringer/alert status, only two of the three options are presented for selecting the user communication availability status. If the ringer/alert status is "ring", then "silent" is not presented as a selectable option for the user communication availability status ([63]; figure 6: S24). If the ringer/alert status is "silent", then "available" (corresponding to "ring") is not presented ([63]; figure 6: S26).

If the status has changed, it is set in the availability manager 230 ([48], last sentence) of the PTT app 206 in the mobile communication device 200, transmitted to a PTT exchange server 114 and set therein ([66]; figure 5: 232, 234; figure 6: S32, S34, S36).

According to the state, PTT server 114 routes an incoming call for the user of the mobile communication device 200 directly to it (if the status is "available"; [45]), it asks whether the client user would like to accept the call ("silent"; [45]) or automatically rejects the call ("do not disturb"; [46]). However, neither the PTT server nor its routing behaviour are claimed.

2. Inventiveness of claim 1 of the main request

2.1 The appealed decision (section 4) selected as the closest prior art an example of a PTT application residing in a cellular telephone, as acknowledged in the description ([10] and [11]).

2.2 However in the board's opinion, the invention as claimed does not relate to PTT communication as such but merely to an input-/output-process. It is unnecessary to take into account the semantics of the data entered by the user (i.e. of the user communi­cation availability status or alert status), since there is no step of a PTT communication being triggered by the data in any of the claimed method steps following the entry of the data. The claim mainly relates to inputting this data, in particular by presenting to the user a selection of possible options depending on a previously entered setting (the alert or ringer status of the mobile communication device; see [19] and [61]).

2.3 However, inputting this data does not produce any other technical effect than storing/transmitting the data on/to different computers.

2.4 In the grounds of appeal (page 3, paragraphs 8 and 9), it is argued that presenting only valid options for selecting the user communication availability status depending on the previously entered alert status reduces the number of gestures required to alter the user communication availability status.

2.5 However, such a reduction of input gestures only occurs when the user tries to input an invalid value. He or she would then have to repeat the selection (possibly after a warning message).

2.6 The board considers it to be obvious for a skilled person to design the method so that only valid options are presented, in order to avoid an invalid selection by the user. Presenting only valid options is a usual practice for the skilled person in programming.

2.7 Therefore, claim 1 of the main request is not inventive (Article 56 EPC).

3. Inventiveness of claim 1 of the auxiliary request

3.1 Claim 1 of the auxiliary request differs from that of the main request in that the mobile communication device tests whether the newly entered status is the same as the old status, which has previously been received from the server storing the status. The new status is only stored and transmitted if it is different from the old status.

3.2 In the letter dated 18 August 2017 (last page), the appellant argues that this reduces network traffic and processing at the other mobile communication device.

3.3 However, the board considers it obvious to the skilled person not to update (i.e. transmit and store) data which has not changed.

3.4 Therefore, claim 1 of the auxiliary request is also not inventive (Article 56 EPC).

Order

For these reasons it is decided that:

The appeal is dismissed.