T 1718/17 (User habit list/HUAWEI) of 29.4.2019

Summary of Facts and Submissions

I. The appeal lies against the decision of the examining division dated 24 February 2017 to refuse European patent application No. 14 814 666 for lack of inventive step, Article 56 EPC over the following document:

D1: US 2006/031465 A1.

The following document is also referred to in this decision:

D3: EP 2 178 279 A1.

II. Notice of appeal was filed on 24 April 2017, and the appeal fee was paid on the same day. A statement of grounds of appeal was received on 9 June 2017. The appellant requested that the decision be set aside and that a patent be granted on the basis of claims 1-4 according to a main request or one of auxiliary re­quests I and II.

III. In an annex to a summons to oral proceedings, the board introduced the following documents under Article 114(1) EPC:

D5: US6266060 B1,

D6: Thomas C G, "Design, implementation and evaluation of an adaptive user interface", Knowledge-Based Systems, Volume 6, Number 4, 4 December 1993, Butterworth-Heinemann, and

D7: Sun C et al., "AppRush: Using Dynamic Shortcuts to Faci­litate Application Launching on Mobile Devices", Procedia Computer Sciences 19 (2013), pages 445-452, Elsevier, available online since 24 June 2013, see https://www.sciencedirect.com/science/article/pii/S1877050913006686, and

informed the appellant of its preliminary opinion that the claimed invention lacked inventive step, Article 56 EPC.

IV. In response to the summons, by letter dated 2 Janua­ry 2019, the appellant filed amended claims 1-4, 1-4 and 1-3 according to a new main request and auxiliary requests I and II, respectively.

V. On 4 February 2019, the appellant informed the board that it would not be attending the scheduled oral proceedings and requested that the board issue a decision on the basis of the documents on file.

VI. The board cancelled the oral proceedings and issued a communication dated 6 February 2019 giving further arguments why claim 1 of the amended claim 1 also lacked inventive step.

VII. In response, on 3 April 2019, the appellant filed further material in favour of inventive step, but did not renew its request for oral proceedings.

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

"A method for processing an application of a mobile terminal, the method comprising:

. receiving a first operating command input by a user of the mobile terminal, and determining a first application corresponding to the first operating command (S20),

. receiving a second operating command input by the user, and determining content corresponding to the second operating command (S21),

. determining an occurrence time of the second operating command, determining a first user habit statistical sub-table, from at least two user habit statistical sub-tables, corresponding to a time span in which the determined occurrence time falls,

wherein each of the at least two user habit statistical sub-tables corresponds to a different time span of a day and the sum of all time spans equals a duration of a whole day, wherein at least one piece of user habit information and number of use corresponding to the user habit information are recorded in each of the user habit statistical sub-tables, and the user habit information comprises first application information and first content information,

. updating the determined first user habit statistical sub-table according to the first application corresponding to the first operating command and the content corresponding to the second operating command,

. generating, at a preset point of time, a user habit list based on one of the at least two user habit statistical sub-tables, being a second user habit statistical sub-table, which corresponds to a time span in which the present point of time falls,

. generating a display interface, wherein the display interface comprises the user habit list, the user habit list comprises at least one user habit option, and each user habit option comprises second application information and second content information (S10), wherein each user habit option is selectable by an operating command,

. receiving a third operating command input by the user, and determining a user habit option corresponding to the third operating command (S11),

. triggering a second application indicated by the second application information of the determined user habit option, which corresponds to the third operating command, to parse the second content information of the determined user habit option, which corresponds to the third operating command, so that the second application runs content corresponding to the second content information (S12),

. updating the second user habit statistical sub-table according to the second application corresponding to the third operating command and the content corresponding to the second content information."

Claim 1 of auxiliary request I reads as follows:

"A method for processing an application of a mobile terminal, the method comprising:

. generating a display interface, wherein the display interface comprises a user habit list, the user habit list comprises at least one user habit option being selectable by an operating command, and the user habit option comprises first application information and first content information (S10),

. receiving a first operating command used for selecting a user habit option and input by the user, and determining the user habit option corresponding to the first operating command (S11),

. triggering a first application indicated by the first application information of the selected user habit option, which corresponds to the first operating command to parse the first content information of the selected user habit option, which corresponds to the first operating command, so that the first application runs content corresponding to the first content information of the selected user habit option (S12),

. wherein before the generating the display interface, the method further comprises:

o receiving a second operating command input by the user, and determining a second application corresponding to the second operating command (S20),

o receiving a third operating command input by the user, and determining content corresponding to the third operating command (S21),

o updating a user habit statistical table according to the second application corresponding to the second operating command and the content corresponding to the third operating command, wherein at least one piece of user habit information and number of use corresponding to the user habit information are recorded in the user habit statistical table, the user habit information comprises the first application information and the first content information (S22),

wherein the recording the number of use comprises the step of assigning a priority to each piece of user habit information based on the number of use and a last occurrence time of the user habit information, and

o generating the user habit list according to the user habit statistical table (S23),wherein the generating the user habit list according to the user habit statistical table specifically is:

selecting a preset amount of the user habit information based on the priority descending, and generating the user habit list according to the selected amount of the user habit information."

Claim 1 of auxiliary request II differs from that of auxiliary request I in that the generating step reads as follows:

"... generating a display interface, wherein the display interface comprises a user habit list, the user habit list being selectable by an operating command, the user habit list comprises at least one user habit option [deleted: being selectable by an operating command], and the user habit option comprises first application information and first content information (S10), ..."

and from the phrase "wherein the recording the number of use comprises" to the end the claim reads as follows:

"wherein the recording the number of use comprises the step of assigning a priority to each piece of user habit information based on the number of use and a last occurrence time of the user habit information, and the assigning the priority to each piece of user habit information comprises:

if the user adds a first operation to the user habit list manually, assigning a first priority to the user habit information corresponding to the first operation,

if the user has performed a second operation within a first predetermined number of days for at least a first predetermined number of times, assigning the user habit information corresponding to the second operation a second priority,

if the user has performed a third operation within a second predetermined number of days larger than the first predetermined number of days and at least a second predetermined number of times larger than the first predetermined number of times, and at the same time less than the first predetermined number of times within the first predetermined number of days, assigning a third priority to the user habit information corresponding to the third operation,

otherwise, assigning a fourth priority to the user habit information, wherein the first priority is a highest priority and the fourth priority is a lowest priority,

o selecting a preset amount of the user habit information based on the priority descending, and generating the user habit list according to the selected user habit information."

Reasons for the Decision

The invention

1. The application relates to the problem of simplifying the use of complex user interfaces, in particular in mobile terminals such as smartphones (see e.g. page 1, line 12, to page 2, line 5; all references being to the application as originally filed).

1.1 The proposed solution is to track users' interactions with their devices in order to determine their "habits" and thus to predict what they might want to do next. Users may also add their preferences manually. A number of likely user preferences ("user habit options") are compiled from actual user operations and displayed as a "user habit list" from which the user can select. The list is ordered according to priorities that aim to express user preferences well (see, e.g., page 9, lines 10 to 18; page 12, line 17, to page 14, line 12; see also figures 3 and 4). The user habit list is continuously adapted in view of actual user interactions (see, e.g., page 12, lines 10 to 16).

1.2 The parameters being tracked (and taken into account to arrange the user habit list) relate to applications (referred to as "application information") and their arguments or options (referred to as "content information"), and, for instance, the frequency of calls, the time of day, and the category of the application (see the paragraph bridging pages 8 and 9; page 11, paragraph 3; page 16, paragraph 2, page 17, paragraph 4).

Claim construction

2. Claim 1 (of all requests) refers to each option on the list as comprising "application information" and "con­tent information". The board considers that "content information" must be construed as subsuming all kinds of parameters or arguments passed to (and parsed and "run" by) an application (see e.g. the main request, claim 1, lines 11 to 14), such as telephone numbers or web addresses (see the paragraph bridging pages 9 and 10, and figures 3 and 4: "call mom", "open http://news.bbc.co.uk", "mail to xyz@abc.com"). This also corresponds to the appellant's position (see the grounds of appeal, page 2, paragraph 3). From this perspective, the board does not share the exami­ning division's objection under Article 84 EPC against the formulation that "the application runs content" (see the decision, reason 2).

The prior art

3. Document D1 relates to the problem of handling complex user interfaces and refers to the common practice of enabling users to define shortcuts ("hot" or "soft" keys) to frequently used applications (see paragraphs 3 to 4). Improving on that idea, a system is disclosed that tracks user interface events, learns user behaviour patterns such as "how, when and where applications are launched", "how long the applications are used" or how long "the pauses between [two] usages" of the same applications are (see paragraphs 29 and 31, and the abstract), and arranges "soft" or "hot" keys accordingly and without user intervention (see paragraphs 33 and 34, and again the abstract).

4. Document D3, filed by the same applicant as that in the present case, refers to complex smartphone interfaces and the prior art approach of allowing users to define shortcuts for preferred applications (see paragraph 4). A proposed improvement would enable users to specify their habits in more detail (see, e.g., paragraphs 19 and 20). Document D3 also discloses that the system "record[s] the phone contact information of the contacts which are frequently contacted by the user" and produces a user interface displaying a user's most frequently used contacts (see figure 2, no. 1053, and figure 4).

5. Document D5 discloses an adaptive arrangement of options on a menu based on various heuristic criteria, most notably including recency and frequency, but also "time of day" (see, e.g., the abstract; column 2, lines 41 to 47; column 9, lines 31 to 35, columns 11 to 12, section "menu arrangement", and column 16, line 39 et seq. in relation to figure 12).

6. Document D6 discloses an early adaptive user interface dubbed "Flexcel", for the program Excel, which mentions, inter alia, that a user profile contains how often a user calls the same function (i.e. "application") with the same values (i.e. "content"; see page 235, left column, paragraph 4, and page 236, right column, paragraph 1).

7. The board also notes that it has been a standard technique in the field of adaptive user interfaces to base the prediction of possible user interactions on recency, frequency and duration (RFD) of earlier actions. Document D7, which discloses an adaptive user interface for a smartphone, mentions this specifically (see the abstract).

8. Moreover, document D7 discloses an "App Launch Predictor", which analyses the times of day during which a user starts specific applications (see, in particular, figure 4b, and page 448, last paragraph) and determines a "ranking" depending on, inter alia, the hour of day (HOD) (see section 4.5 on page 450). The display interface is adapted accordingly (loc. cit.). Document D7 does not disclose how often the ranking formula from section 4.5 is evaluated, but the board considers that figures 4(a) and 4(b) and the corresponding explanation suggest that this might be done only a few times per day, e.g. at the start of the morning, the afternoon, the evening and the night.

Inventive step

Main request

9. The examining division has based its assessment of inventive step on document D1, which the board accepts is a suitable choice.

9.1 In the board's understanding, some of the user actions recorded in document D1 correspond to applications, while others corres­pond to menu options of individual applications. For example, in the context of a "Date Book" appli­ca­tion the option to create a "New Event" is referred to (see figure 9 and paragraph 34). This seems to correspond exactly to the example of the "message" application and the option "new message" disclosed in the application (see page 11, paragraph 3). However, the board tends to agree with the appellant that the patterns recorded by document D1 do not disclose any "content" information that is "parsed" and "run" by an application (see the grounds of appeal, page 3, paragraph 1).

9.2 Therefore, the board prefers to start its analysis of inventive step from document D3.

10. Document D3 discloses the idea of displaying, for the user to choose from (i.e. "selectable by an operating command"), a list of preferred "content" in the context of a telephony application (see figure 4).

10.1 Although the application is not mentioned in the individual "user habit options" on this list, it is still implicitly included in each of them.

10.2 In a smartphone it would be a straightforward modification to provide a similar list of preferred websites in the context of a browser application. The immediate adaptation of document D3 would yield two separate interfaces: one for the telephony and one for the browser. However, it would be an obvious simplifica­tion to join these interfaces into one; as an immediate consequence, the user habit options would have to mention the "application" explicitly: in this case, telephony or web browsing.

10.3 Claim 1 of the main request further differs from document D3 in that, instead of maintaining a single user habit list, at least two "user habit statistical sub-tables" are maintained which reflect the user habits for "different time span[s] of a day" (the "sum of all time spans equal[ling] a whole day") and are separately updated in view of user activity in the respective periods of time. Moreover, the "display interface" is always generated from the sub-table corresponding to the "prese[n]t point in time".

11. Document D3 discloses that the mobile terminal may display a different user interface according to circumstances depending on the current time. In particular, paragraph 29 discloses that the display will show different sets of frequently used telephone numbers during wor­king hours and in spare time: during working hours the numbers will probably relate to business partners, and during spare time to friends (see also paragraphs 4, 19 and 20).

11.1 According to document D3, the display interface thus creates and displays a different interface for different "time spans of a day", which, together, cover the entire day. In order to generate these displays, the system of D3 must keep track of which telephone numbers are most frequently called during the different time spans of the day (see figure 2, no. 1053).

11.2 It is mentioned in passing that documents D5 and D7 also disclose that different "user habit lists" are displayed depending on the time of day (see the references in the above-mentioned brief summary of documents D5 and D7).

11.3 Arguably, document D3 does not explicitly disclose the maintenance of "sub-tables" but only that the relevant "user habit list" and "display interface" are generated as needed from the relevant statistical data (see the "scene-setting module" 105 in figure 2, and again in paragraph 29). The same applies to documents D5 and D7.

11.4 In the application to hand, the "sub-tables" are disclosed in embodiments 4 and 6 (see the original description, page 17, line 9, to page 19, line 7, and page 20, line 9, to page 22, line 16). Apart from no­ting that different sub-tables can model time-dependent user habits (see page 17, lines 16 to 29) - which is known from documents D3, D5 and D7 - the description does not disclose any specific technical effect of using the claimed subtables for the implementation of that model.

11.5 The board can only speculate that maintaining the pertinent information as "sub-tables" rather than (re-)generating the tabular information as needed has the advantage that the display interface can be generated more quickly when actually needed, but the disadvantage that the sub-tables must be precomputed and kept in memory. From this perspective, precomputing sub-tables would have been obvious to the skilled person to achieve the effect known from document D3 as a matter of the well-known trade-off of "precomputing", namely between time and space requirements on the one hand and system responsiveness on the other.

11.6 In its letter of 3. April 2019, the appellant criticizes this argument as being a mere statement made with­out substantial proof, and requests that the established "could/would approach" be applied, which would mean "asking not whether the skilled person could have carried out the invention, but whether he would have done so in the hope of solving the underlying technical problem or in the expectation of some im­prove­ment or advantage" (see page 2, paragraphs 1 to 3). The appellant argues that for lack of an explicit prompt in (or starting from) document D3, the introduction of sub-tables could not be obvious, and any statement to the contrary would have to be based on an inadmissible ex post facto view (see the paragraph bridging pages 2 and 3).

11.7 The board takes the view that, in the art of computing, "precomputation" is a well known method of speeding up program execution. The basic idea is to avoid the time-consuming computation of certain data when it may be needed urgently, by computing it - or part of it - earlier. This speeds-up access to the data when needed and may, thereby, increase system responsiveness. This advantage comes at a cost, in that the precomputed data has to be stored until needed and thus increases the program's memory consumption.

11.8 The appellant did not challenge the board's assumption that precomputation or its implied trade-off was known in the art. Contrary to the appellant's suggestion, however, the board is of the opinion that the skilled person would not need an explicit prompt to consider the application of a generally known pattern of program optimisation. In the context of document D3 (or documents D5 and D7), the skilled person would realise, without exercising an inventive step, that the time-dependent "user-habit lists" had to be recomputed again and again, and so be aware (or even experience) that recomputation might delay the display of the user interface if done just in time. It would be to avoid this delay that the skilled person would not hesitate to use precomputation to achieve its well-known "improvement or advantage" (see again the appellant's letter, page 2, last sentence). Since this analysis relies on what the skilled person would - as opposed to merely could - do, in the board's view it is not based on an inadmissible ex post facto view.

11.9 In summary, the appellant's considerations could not sway the board's conclusion that claim 1 of the main request lacks inventive step over document D3, alone or in view of documents D5 and D7, Article 56 EPC.

Auxiliary request I

12. Claim 1 of auxiliary request I contains the additional feature that a priority is assigned to each "piece of user habit information", "based on the number of use and a last occurrence time of the user habit information" and used to generate the user habit list. Effectively, this feature says that the user habit list is generated with a view to frequency and recency of the user actions. Since the claim does not specify how priorities are determined, the feature that pieces of user habit information are assigned priorities according to various criteria merely means that they are ordered (or "ranked", as document D7 puts it).

12.1 The board notes that frequency and recency of a user action are well-known parameters in adaptive user interfaces (see, in particular, document D1, paragraphs 29 and 31; document D6, page 236, right column, paragraph 2; documents D5 and D7, abstracts).

12.2 Hence, the board concludes that it would be obvious to take into account re­cency in the system of document D3 to improve the adaptation of the interface in question. To assign priorities "based on" frequency and recency is an obvious way of ordering the "pieces of user habit information" in order to be able to decide which pieces to display and in which order.

12.3 Accordingly, claim 1 of auxiliary request I lacks inventive step over D3 in view of common knowledge in the art, Article 56 EPC.

Auxiliary request II

13. Claim 1 of auxiliary request II specifies, in addition to claim 1 of auxiliary request I, that priorities are assigned manually by the user or in view of frequency and recency of use. It is prior art that users may define their shortcuts manually (see, e.g. documents D1 and D3, paragraph 4). Apart from that, the available prior art does not disclose the particularly claimed prioritisation rules.

13.1 However, the board is not convinced that these rules can be said to solve any particular technical problem. It is in the nature of an adaptive user interface that the skilled person would want to improve the quality of adaptation. In other words, the skilled person would try to arrange the "user habit options" on the list so that users will, as often as possible, find their preferences high up on the list.

13.2 Since no specific application or content is claimed, it cannot be assessed from the claims whether the claimed prioritisation rules achieve the desired effect of improved adaptation or not. Also, the description lacks such detail, so it is impossible to say that adaptation is improved in general.

13.3 In its letter of 2 January 2019 (page 8, last paragraph), the appellant argues that, by introducing specific prioritisation rules, "it is possible to provide a sim­plified use of a complex user interface": "simpli­fied" in the sense that users will, on average, be able to make their choices more quickly. The board disagrees. Obviously, the claimed prioritisation rules cause a different user habit list to be displayed. Whether this simplifies the use of the user interface will depend, in the board's understanding, on whether the prioritisa­tion rules reflect the user preferences properly. The appellant considers that in this regard "of course it doesn't matter which kind of application is used" (loc. cit.). For priorities in general, that may be true but, as argued above, the board finds the use of priorities alone to be obvious over document D3. As regards the specifically claimed prioritisation rules, the board disagrees with the appellant. For instance, claim 1 specifies that manually assigned priorities always take priority over priorities determined in view of frequency and recency. This decision may or may not properly describe the actual user preferences. An individual user might give, say, calling their mother a high priority even though, in fact, they call other people more often. The "simpler" user interface should, therefore, list the telephone numbers of other people above that of the user's mother, but the claimed prioritisation rules would not achieve this.

13.4 Since a technical effect of the specifically claimed prioritisation rules cannot be established, the board concludes that they cannot contribute to inventive step. In view of this, it need not be decided whether the claimed prioritisation criteria themselves are obvious choices.

13.5 The board concludes that claim 1 of auxiliary request 2 also lacks inventive step over document D3 and common knowledge, Article 56 EPC.

Order

For these reasons it is decided that:

The appeal is dismissed.