In this decision, the European Patent Office acknowledged that precomputing user habit information for a graphical user interface of a mobile device is technical. However, this difference over the prior art was found to be obvious. Here are the practical takeaways of the decision T 1718/17 (User habit list/HUAWEI) of 29.4.2019 of Technical Board of Appeal 3.5.06:
This European patent application relates to the problem of simplifying the use of complex user interfaces, e.g. in smartphones.
The invention proposes to track users’ interactions with their devices to determine their “habits” and thus to predict what they might want to do next. 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. The parameters being tracked (and taken into account to arrange the user habit list) relate to applications and their options, the frequency of calls, the time of day, and the like.
Fig. 4 of the application illustrates an example of a user habit list:
Here is how the invention is defined in claim 1 of the main request:
Claim 1 (main request)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.
Is it technical?
The Board of Appeal identified the following difference between claim 1 and the closest prior art: Instead of maintaining a single user habit list as in the prior art, claim 1 referred to at least two “user habit statistical sub-tables” which reflect the user habits for “different time span[s] of a day”.
On the one hand, the Board took the view that the multiple statistical sub-tables indeed provide a technical effect. Doing so, however, was found to be obvious:
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 noting 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.
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.
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.
Therefore, the Board decided that claim 1 does not involve an inventive step and dismissed the appeal.
You can read the whole decision here: T 1718/17 (User habit list/HUAWEI) of 29.4.2019
Bastian is a European patent attorney and a partner at BARDEHLE PAGENBERG. He specializes in software patents in Europe both from a prosecution and litigation point of view.