T 0977/18 (Filtering emails on mobile devices/BLACKBERRY) of 24.6.2021

Summary of Facts and Submissions

I. This appeal is against the examining division's decision to refuse European patent application No. 11161767.6.

II. The examining division found that claim 1 of the main request was not inventive over D3 in combination with common general knowledge of the skilled person. The same conclusion was reached for auxiliary requests 1 to 4 as they essentially added obvious features relating to the automation of administrative decisions or to the presentation of information.

III. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the refused main or first to fourth auxiliary request, all re-filed with the statement setting out the grounds of appeal.

IV. In the communication accompanying the summons to oral proceedings, the Board expressed its doubts that the effect over D3, namely reducing user interactions, could be considered technical. Regarding the auxiliary requests, the Board noted that the additional features related to further user preferences or to presentation of information. The technical implementation appeared to be obvious and, hence, could not support an inventive step.

V. In a reply dated 18 May 2021, the appellant filed a fifth auxiliary request and arguments in favour of inventive step.

VI. By facsimile received on 22 June 2021, the appellant informed the Board that it would not attend the oral proceedings.

VII. At the oral proceedings, which took place in the appellant's absence on 24 June 2021 by videoconference, the Board discussed the appellant's requests. At the end of the oral proceedings the Chairman announced the Board's decision.

VIII. Claim 1 of the main request reads:

"A mobile device (400) comprising:

an auxiliary input device (404);

a display device (402); and

a processor (102), cooperating with said display device and said auxiliary input device, to perform a method of filtering data entries (630), wherein each of said data entries contains fields (631, 632) and said fields contain values, the processor (102) configured for:

displaying a list (600) of said data entries on the display device (402);

receiving at said auxiliary input device (404) input comprising an indication of one of the data entries of said list (600);

highlighting the data entry (620) in response to said indication;

after said highlighting, receiving at said auxiliary input device (404) input comprising a pause of said indication;

determining a field of the highlighted data entry (620) upon which the list (600) of said data entries should be filtered;

executing a filter for said list (600) of said data entries that match the value of said field of the highlighted data entry (620); and

displaying results (601) of the filter on the display device (402),

wherein

the step of executing a filter for said list (600) is performed upon detecting said pause, if only one option for filtering said list (600) is provided, and

said data entries (630) represent electronic messages."

IX. Claim 1 of the first auxiliary request essentially replaces the last feature of claim 1 of the main request by:

"wherein determining a field of the highlighted data entry (620) upon which the list (600) of said data entries should be filtered comprises determining if the pause is an ambiguous input, such that there are multiple fields upon which the processor is configured to filter data items, or an unambiguous input, such that only one option for filtering said list (600) is provided;

wherein when the pause of said indication is unambiguous the step of executing a filter for said list (600) is performed upon detecting said pause, and

wherein when the pause of said indication is ambiguous, displaying a menu (640) on the display device (402) in response to said pause of said indication, wherein said menu comprises at least one menu item (641, 642), wherein said menu items comprise a command to filter said list (600) based upon a value of a field of the highlighted data entry (620); and

receiving input comprising an indication to activate one of the menu items;

wherein for said executing of said filter for data entries that match the value of a field of the highlighted data entry (620), said field is determined by the menu item activated".

X. Claim 1 of the second auxiliary request adds to the end of claim 1 of the first auxiliary request:

"wherein, when unambiguous, the pause of said indication comprises a cursor being positioned over an individual field in the graphical interface displaying the data items of the message list".

XI. Claim 1 of the third auxiliary request adds to the end of claim 1 of the second auxiliary request:

"and wherein, when the pause of said indication is ambiguous, each menu item (641, 642) in the displayed menu (640) comprises a combination of the name of the data field and the value of the data field".

XII. Claim 1 of the fourth auxiliary request adds to the end of claim 1 of the third auxiliary request:

"and wherein:

the auxiliary input device (404) comprises an optical trackpad (404) or a trackball (504); and

displaying a list (600) of said data entries on the display device (402) comprises displaying said data entries only in a list format wherein a list of rows or partial rows of a database are displayed as data items, wherein the list displays the value or a partial value of one or more fields of each data item,

whereby (i) the data fields displayed include a sender field (631), a message subject field (632) and a message recipient field (633), (ii) some of the fields of the data items, including the message body, are not displayed and (iii) other fields of the data items are displayed such that only part of the data value is displayed".

XIII. Claim 1 of the fifth auxiliary request adds to the end of the penultimate feature of claim 1 of the third auxiliary request:

"and the data entries are filtered based on the individual field the cursor is positioned over".

XIV. The appellant argued essentially as follows:

The invention enabled the user to filter messages with a single combined gesture, i.e. by navigating through a message list to select a message and stop navigation for a predetermined period of time. This avoided the more cumbersome input of D3, namely a menu based selection invoked with a right-click operation. Any user would prefer the simpler user interface of the invention. Therefore, this was an objective advantage and not merely a user preference as suggested by the Board referring to T 1958/13 - Single-drag gesture/LG. For touch screens the invention provided the additional advantage of reduced cleaning requirements.

The first auxiliary request further distinguished between two types of user input. If the input was "unambiguous" no further user action was required. If it was "ambiguous" the user had to select an additional filter criterion. This distinction was caused by the user input, in particular where on the message list navigation ceased and a pause was made. In case of unambiguous input filtering was based on a selected field of the message and, thus, avoided a further user action. D3, on the other hand, always required the user to open a (drop-down) menu and did not differentiate between unambiguous and ambiguous user input.

The second auxiliary request explicitly defined the selection of a filtering field in case of unambiguous input, namely by positioning the cursor over the field. This facilitated and enhanced speed of navigation. Even if hovering were considered in D3, this would not lead to the invention as D3 did not allow a user to select a filtering field at all.

The third auxiliary request added that in case of ambiguous input, i.e. when a menu for selecting a filtering command was displayed to the user, this menu showed the name and value of the data field used as filter criterion. This improved the usability of the user interface.

The fourth auxiliary request added that the input device was an optical trackpad or trackball and further defined the content and display format of the list and messages. This facilitated navigation, in particular finding relevant messages, and, thus, improved the usability of the user interface.

The fifth auxiliary request, which was based on the third auxiliary request, clarified that the messages were filtered based on the field the cursor was positioned over. This caused the direct filtering of messages without further user input and, thus, was a technical effect independent of any user preferences.

Reasons for the Decision

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.

Order

For these reasons it is decided that:

The appeal is dismissed.