T 0977/18 (Filtering emails on mobile devices/BLACKBERRY) 24-06-2021

1. Background

1.1 The invention simplifies the filtering of electronic messages, for example e-mails, which are displayed as a message list on a mobile phone (see paragraphs [0004] and [0005] of the original application).

1.2 Looking at Figure 4 of the application, the user can scroll through a message list 600 and select a specific message 620 (paragraph [0055]). If the user then stops moving the input device over the messages ("pause of ... indication" in claim 1), the messages are automatically filtered based on the value of a specific field (for example the "From" field 631) of the selected message (paragraph [0056]). Thus all the messages with the given value ("John Henry") of the specific field ("From") are displayed (Figure 6). If more than one filtering field is possible, the user is given the choice of which one to use - see Figure 5 and paragraph [0057].

2. Main request

2.1 It is common ground that D3 is an appropriate starting point for assessing inventive step.

The appellant argued that claim 1 essentially differed from D3 by the manner of user input for filtering messages. Without lifting a finger from the input device, for example a trackball, the user could scroll through a message list, move the cursor to a specific field and by ceasing movement and keeping the finger for a predefined duration on the input device trigger the filtering action.

The Board notes that this is not the only conceivable claim interpretation. For example, another possible interpretation is that the user directly clicks on the message to select it and then pauses navigation for a predefined duration. In this case the only difference over D3, see paragraphs [0036], [0037] and Figure 5B, is that pausing instead of selecting an option from the drop-down menu triggers the filtering action.

For the analysis of inventive step the Board follows the appellant's interpretation, in particular as described in paragraphs [0050] and [0051] of the description. Should this interpretation not be found inventive, a fortiori neither would be one closer to D3.

2.2 In the Board's view the key issue in this case is whether the user input for filtering messages provides an objectively credible technical effect. If it does not, this cannot form a valid basis for a technical contribution over the prior art.

2.3 When developing graphical user interfaces the steps preceding the programming phase normally include a conceptual phase in which the user interaction, i.e. the "look and feel" and the "behavior", is defined. This includes the input-functionality mapping, for example that a click on a data object opens a menu with predefined actions. When defining this mapping, besides user preferences also technical considerations, for example in the field of ergonomics, might need to be taken into account. Such considerations are, however, not apparent in the present case.

2.4 The Board agrees that some users scrolling through a message list and pausing navigation on a selected message might indeed feel this to be convenient or efficient. Others, however, might prefer an explicit click and selection operation both to feel in control and to avoid mistakes, for example when inadvertently scrolling through the message list.

This trade-off between perceived efficiency and error-tolerance depends on subjective user preferences and, thus, is to be included in the requirements developed during the conceptual phase.

2.5 Once the requirement to select messages by scrolling has been specified, it is inevitable to add some delay (a pause in navigation) before triggering the filtering action in order to meet the requirement. Otherwise the messages would always be filtered based on the first message selected during scrolling. In addition, the delay also reflects the user's normal expectation, namely to be able to review and possibly correct a selection before making it.

Again, the duration of the delay is not based on technical considerations. If it is too short it might prevent the user's wish to only highlight a message or reconsider his selection. On the other hand, if the duration is too long it might be felt to be a nuisance.

2.6 In addition, it is self-evident that user input is not required if a user is not provided with corresponding options in the first place. If a default filtering criterion, for example a (value of a) sender field, is preconfigured - see paragraph [0056] of the description - clearly there is no need to display a menu or use any other input means for its selection.

The user might perceive this as efficient, however, this comes at the expense of less flexibility and is a direct and inevitable consequence of the desired level of automation or configuration.

2.7 Any effects resulting from an obvious implementation of non-technical requirements as mentioned above would be inevitable bonus effects and, thus, could not contribute to the recognition of an inventive step. Nevertheless, the Board also cannot identify any device-specific or performance-oriented improvements resulting from the specific input sequence. On the contrary, it appears that the invention, in addition to handling common input events such as scrolling or clicking events, requires a timer and, thus, additional computing resources - see paragraph [0051] of the description.

2.8 In view of the above the Board concludes that, in line with T 1958/13 (supra, see reasons 2.2.5), the effect mentioned by the appellant, namely a simple operation due to reduced user input, depends on subjective user preferences and cannot be regarded as objectively credible technical effect.

In the Board's view these user preferences are drafted as user requirements in the conceptual phase and, in a later stage, implemented by the skilled person, namely a computer programmer.

2.9 Consequently, the question of inventive step is answered by looking at the implementation of these requirements.

D3 discloses a mobile device with an auxiliary input device for interacting with graphical control elements (paragraph [0020], Figure 1), for example for selecting and highlighting messages. Events generated by the input device are used to trigger filtering of messages in a message list (see paragraphs [0037] and [0038], Figures 5A and 5B).

The Board judges that the skilled person would have no difficulties adapting this prior art to implement the given user requirement without inventive effort. All he needs to do is to program the application in D3 to provide the required input operations. At the general level of the claim, this is a routine task and, thus, cannot support an inventive step.

2.10 The Board doubts that, for a touch-sensitive device, the invention reduces cleaning requirements. In this case the user has to select the desired message by moving and holding his finger on the touch screen. A click-based selection, on the other hand, requires only touching the screen in a limited area and, thus, keeps the screen cleaner.

Irrespective of the above, the alleged effect is an inevitable consequence of the user requirement as set out previously and, thus, cannot support the presence of an inventive step.

2.11 In summary, the Board judges that claim 1 lacks an inventive step starting from D3 in view of the common knowledge in the art (Article 56 EPC).

3. First auxiliary request

3.1 This request essentially adds that the determination of a filtering criterion includes a step of determining whether the pause is an "ambiguous" or "unambiguous" input. In the first case a menu with the filter criteria is shown - see the options "Filter by Sender" and "Filter by Subject" in Figure 5.

3.2 The Board considers that the decision to filter messages using a predefined field or a field selected by the user via a menu must be pre-configured. Paragraphs [0056] to [0058] of the description describe various ways to determine a filter criterion, however, it is always the processor which is "configured" to make a specific choice.

Not only does the description not mention that the choice depends on the user input, but this would also not make any sense. The user has always to perform the same input sequence, namely scrolling through a message list to select a message and stopping navigation. The Board cannot see how this same input sequence could instruct the processor to either display or not display a menu with filtering options.

3.3 In view of the above, the Board considers that the pre-configuration is a direct expression of the user's wish to either actively select a filtering criterion or immediately filter on a predefined, default field, for example the one most relevant to him.

D3 offers similar choices which are pre-configured in the application (see paragraphs [0038] - "The manner in which these messages are identified may be predefined within the application" and [0039] - "... the application may permit the user to specify one or more characteristics associated with messages ...").

Also, menus for displaying selectable options form an integral part of many graphical user interfaces and, thus, cannot support an inventive step - see also Figure 5B of D3.

For these reasons the Board concludes that claim 1 lacks an inventive step.

4. Second auxiliary request

4.1 This request further adds that in case of unambiguous input a cursor is positioned over a message field.

The Board notes that the wording "the pause of said indication comprises a cursor being positioned ..." has no clear technical meaning. Furthermore, claim 1 does not define the relationship between the field hovered over by the cursor and the field used as a filter criterion.

The Board interprets the additional feature in light of paragraph [0056] of the description and as clarified in the fifth auxiliary request, namely that by positioning a cursor over a specific field of a message this field is used as a filter criterion.

4.2 The description does not, however, provide any details how this selection is done. A possibility might be that the user first scrolls vertically through the message list and then horizontally to select the desired field.

Again, the Board assumes that the option to filter based either on a predefined field or on the one hovered over by the cursor is pre-configured.

4.3 The Board considers that the claim, in addition to what has been said for the main request, differs from D1 by the further user input action, namely positioning the cursor over a message field to select it as a filtering criterion.

In D3, after right-clicking a message, a drop-down menu with user selectable options is opened (see paragraph [0036] and Figure 5B). D3 also teaches that the user can specify a characteristic such as a message field as a filter criterion (see paragraphs [0038] and [0039]). It does not, however, mention how this is implemented.

The skilled person when implementing any selection operation would certainly explore different options available in the state of the art. In the Board's view implementing either a scrolling and hovering operation as in claim 1 or a right-click and menu based selection as in D3, is entirely motivated by the users' preferences.

Similar to what has been said for the main request some users might perceive scrolling and hovering as faster and easier and, thus, prefer it over clicking. Others, however, might find it annoying.

Hovering indeed saves the user a click, but this comes at the expense of a more erratic or unexpected behavior. For example, by moving the cursor accidentally over the navigation area users might inadvertently filter the (wrong) messages.

As said before, these preferences are gathered during the conceptual phase preceding the actual programming activity. The Board does not see any technical hurdles which the skilled person needs to overcome in an inventive manner to implement the desired user operation. Standard programming techniques available before the priority date of the present application suffice.

Thus, the Board concludes that claim 1 of the second auxiliary request lacks an inventive step.

5. Third and fourth auxiliary requests

5.1 The third auxiliary request adds that, if a menu is shown to the user, it displays the name and value of the data field, for example filter by "Sender=John Henry".

The fourth auxiliary request adds that the auxiliary input device is an optical trackpad or a trackball, and furthermore, which data and in which format it is displayed to the user, i.e. the data fields and values in each message and the format of the message list.

5.2 The appellant essentially argues that the added features improve the usability of the user interface.

5.3 The Board is not convinced. It finds that the information displayed and the display format depend on what users find appealing or helpful when scrolling through and selecting messages.

The content and layout of the message list might have a mental effect on the user resulting in a different user operation which is eventually executed by the processor. However, any potential technical effect of this is a typical case of a broken chain in the sense of T 1670/07 - Shopping with mobile device/NOKIA, reason 11. In other words a direct technical effect between the user interface and the device is missing and it cannot be replaced by evidence of a potential overall technical effect.

The inventive user interface, at best, lowers the user's cognitive burden. This is, however, in itself not sufficient to demonstrate a technical effect (see e.g. T 1741/08 - GUI layout/SAP, Catchword) and, hence, of no relevance for assessing inventive step.

Programming the message list as claimed is a routine task for a computer programmer (see also Figure 5A of D3 which shows a similar list).

D3 - see paragraph [0020] - discloses a mobile device with an auxiliary input device such as a trackball. Hence, there is no difference in this regard.

Accordingly, the Board judges that claim 1 of the third and fourth auxiliary request lacks an inventive step.

6. Fifth auxiliary request

6.1 The Board raised an objection under Article 84 EPC for the first time in the communication under Article 15(1) RPBA 2020. In response to this communication, the appellant filed a fifth auxiliary request aimed at overcoming this objection. The Board considers this to be an exceptional circumstance within the meaning of Article 13(2) RPBA 2020 and, thus, admits the fifth auxiliary request into the appeal proceedings.

6.2 The added feature vis-à-vis claim 1 of the third auxiliary request clarifies that in the case of unambiguous input, messages are filtered based on the field the cursor is positioned over.

6.3 This feature has first been introduced, although in an unclear manner, in auxiliary request 2 and is also present in auxiliary requests 3 and 4. When analysing auxiliary request 2 the Board concluded that it did not contribute to inventive step - see point 4.3 above.

Therefore, the conclusions reached for the third auxiliary request apply mutatis mutandis to the fifth auxiliary request which, thus, also lacks an inventive step.