Search This Blog

Labels

T 1204/12 - Stern but fair?

The city 'Brusque' in Brazil

In this examination appeal, the invention relates to the entering and setting of an 'availability status' in a 'Push-to-talk' application in a mobile communication device, with the independent method claims defining the associated data processing. Unfortunately for the applicant-now-appellant, the Board of Appeal quickly 'strips away' the semantic meaning of the data (e.g. 'alert status') and the data processing entities ('server', 'communication device'), to conclude that the invention merely pertains to 'storing/transmitting the data on/to different computers'. Any remaining feature+effect combinations are swept off the table as 'obvious'.

The claim of the main request:

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.

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.

This decision T 1204/12 (pdf) has European Case Law Identifier: ECLI:EP:BA:2017:T120412.20170920. The file wrapper can be found here. Photo "Brusque1.jpg" released by the author into the Public Domain and obtained from Wikimedia

Comments