Changing A Mobile Device’s Notification Settings Based On A User’s Location: Non-technical

The application underlying the discussed decision concerns a computerized method for automatically changing notification settings on a mobile device based on the user’s inferred availability at a venue. The key feature at issue was the concept of determining a communication context for a venue using the user’s location and historical communication patterns, and then automatically adjusting the device’s notification settings to conform with that context. The Board of Appeal considered this feature to be non-technical, treating it as a non-technical aim that could legitimately appear in the formulation of the technical problem under the Comvik approach.

Here are the practical takeaways from the decision: T 0877/22 (Automatic changing of notification settings/MICROSOFT) of 5 December 2024, of the Technical Board of Appeal 3.5.01.

Key takeaways

The idea of changing a mobile device’s notification settings based on the user’s location in a venue and historical availability patterns is a non-technical aim, even though the final act of changing the settings is itself technical. Features that merely form part of a causal chain leading to a technical change of a device’s state are not automatically rendered technical; the Board termed this reasoning the “technical leakage fallacy” (citing T 1670/07).

The invention

The Board of Appeal summarized the invention as follows:

The invention concerns a computerized method for inferring user availability to communicate through a mobile computing device and automatically adjusting the device’s notification settings. The method analyzes sensor data, such as GPS data, to determine the present location of the mobile device. This location is then mapped to a venue, for example a library, school, or church. Historical communication records associated with that venue are analyzed to identify an availability pattern, relying on a confidence score that must satisfy a defined threshold. The confidence score may depend on factors such as the number of records forming the pattern, the variance within the pattern, and the age of the information. Based on the identified pattern, a communication context is determined for the venue at the present time, indicating which communication modes are available. If the current notification setting on the device does not conform with the determined communication context, the device automatically changes the notification setting to a contextual value. For example, when a user enters a library, the device may automatically switch to silent mode if this has been the user’s previous setting when visiting the library. The venues may also be categorized to assist in determining a communication context when little or no data is available for a specific venue.

Claim 1 of the Main Request

A computerized method for inferring user availability to communicate through a mobile computing device (102 a-n), the method comprising:

analyzing (410) sensor data captured by one or more sensors (104 a-n) of the mobile computing device (102 a-n) to determine a present location of the mobile computing device (102 a-n);

determining (420), using the present location, that a computing device (102 a-n) is located in a venue at a present time;

determining that an availability pattern of the user of the mobile computing device (102 a-n) exists in a series of historical communication records associated with the determined venue based on a confidence score satisfying a threshold, wherein the confidence score is indicative of level of certainty that a pattern is present in time stamps corresponding to instances of communications and recorded in historical communication records;

determining (430) a communication context for the venue at the present time based on the determined availability pattern of the user, wherein the communication context indicates whether different communication modes are available for communication at the venue;

determining (440) that a notification setting on the mobile computing device (102 a-n) for a specific communication mode is set to a first value that does not conform with the communication context; and

automatically, without user intervention, changing (450) the notification setting on the mobile computing device (102 a-n) for the specific communication mode from the first value to a contextual notification value that conforms with the communication context.

Is it patentable?

The Examining Division’s position

The Examining Division found that the method of inferring user availability based on location and an availability pattern for that location was an administrative matter rather than a technical one. It did not contribute to the solution of a technical problem but rather solved the non-technical problem of determining the user’s notification preferences. Furthermore, the idea of providing notifications according to the user’s preferences was considered non-technical, as it did not achieve any technical effect. Accordingly, changing the manner in which the user was notified based on the user’s preferences was a non-technical requirement. The Examining Division concluded that the technical character of claim 1 resided only in the technical implementation of this administrative method on a well-known computerised system comprising a mobile device, means for analyzing sensor data to determine a location, one or more processors, and one or more computer storage media. Such a system was considered to be well known at the priority date (citing documents D1 to D3 and D5), and the implementation of the administrative method would have been obvious for the skilled person, as it merely amounted to changing the device’s settings based on information obtained using the device’s own technical means, including location data and data relating to communication events recorded in the phone.

The Appellant’s arguments

The Appellant argued that automatically changing notification settings on a mobile communication device was technical, as it related to controlling the internal functioning of the device. All claim features defining how this was done were therefore technical features contributing to solving a technical problem. The Appellant further contended that, according to the Comvik approach (T 641/00), the technicality of a feature had to be assessed in its own right, without having regard to the state of the art. Once a feature was found to be technical by its own nature, it entered into the assessment of inventive step using the normal problem-and-solution approach. Determining technicality based on a feature’s contribution over the prior art was, in the Appellant’s view, an impermissible shortcut. The Appellant also argued that the objective technical problem should be realistic and not include pointers to the solution, warning against hindsight. In the present case, the Appellant formulated the technical problem as automatically inferring and implementing the device’s notification settings in a way that reflected socially acceptable behaviour or user preference associated with a given location or venue. The Appellant specifically argued that the following features were technical and contributed to the solution of the technical problem:

1. Capturing and analysing sensor data to determine the present location of the mobile device.
2. Associating the location with a venue and determining the availability pattern for that venue to establish a communication context, which was not a simple mapping but involved data processing means and databases.
3. The availability pattern itself, as it determined criteria for setting the communication context used for changing communication settings.
4. The confidence score, as it was used for reliably determining the availability pattern.
5. The last two claim features (determining and automatically changing the notification setting), as they involved controlling and setting functional data of the mobile device as opposed to storing cognitive data (referring to the Guidelines G-II, 3.6.3).

The Board’s analysis

The Board systematically addressed both the Appellant’s interpretation of the Comvik approach and the individual claim features:

On the Comvik approach and technical character

1. The Board confirmed that the assessment of whether subject-matter has technical character under Article 52(1) EPC (the “first hurdle”) must be made without regard to the state of the art (citing T 258/03 and T 931/95). However, this does not mean that once the first hurdle is passed, the question of technicality no longer arises. The technical contribution of claimed features must then be assessed when examining inventive step (the “second hurdle”).
2. Computer-implemented inventions pass the first hurdle by definition, but not every such invention necessarily provides a technical contribution supporting inventive step.
3. The Board identified the Appellant’s reasoning as an instance of the “technical leakage fallacy” (T 1670/07), in which the inherently technical nature of the implementation is inappropriately projected onto non-technical aspects of the underlying problem. The mere fact that a feature is part of a sequence ultimately resulting in a change of a device’s state does not automatically render that feature technical.
4. Regarding the “realistic problem” argument, the Board clarified that while this applies to a technical problem formulated from technical differences, it does not apply to non-technical requirements. A technically skilled person, starting from prior art, would conceive neither a realistic nor an unrealistic non-technical requirement, since the notional skilled person lacks creativity and expertise outside the relevant technical field. Formulating the problem as implementing given non-technical requirements is realistic by definition.
5. The Board also noted that formulating the problem in a way that entails direct technical consequences is not excluded under the Comvik approach (citing T 630/11).

On individual claim features

1. Controlling the notification settings (audial, visual, tactile output) is technical. However, the idea to change the notification mode based on the user’s location and previous settings for that venue is a non-technical aim (citing T 1989/12 for a similar conclusion regarding calendar-based profile switching).
2. Obtaining the user’s location from a GPS sensor is technical but was known and commonly included in mobile devices at the priority date.
3. Mapping location data to a venue or category of venues would have been a routine task, e.g., by using a database.
4. The availability pattern data is not itself technical in the sense of contributing beyond the provision of data required by the non-technical method. While “functional data” (T 1194/97) may serve a technical function, where it merely implements a non-technical requirement, it is not relevant for inventive step.
5. The confidence score is not a technical feature. It merely ensures data reliability based on straightforward considerations. A business person could readily formulate requirements such as “base the notification settings on the user’s recent activities.” Excluding unreliable or one-off data is a standard measure, since the very notion of a pattern implies repetition.
6. The final step of automatically changing the settings is technical in nature, but trivial.

On the auxiliary requests

1. The first auxiliary request added that the notification setting indicates whether a ringtone is set to mute. The Board found this was already covered by the main request reasoning and lacked inventive step for the same reasons.
2. The second auxiliary request added receiving device state information from other devices in the venue and using it to determine the communication context. The Board agreed with the Examining Division that taking into account the communication preferences of other users is non-technical and part of the problem. The implementation (e.g., via a centralized data collection source) would have been obvious.
3. The third auxiliary request combined the first and second auxiliary requests. The Board found no synergistic effect between the additional features and rejected it for the same reasons.

Conclusion

The Board dismissed the appeal and confirmed the Examining Division’s refusal. The Board concluded that claim 1 of none of the requests defined an implementation going beyond a straightforward and obvious realization of non-technical requirements on known technical means, and therefore all requests lacked inventive step under Article 56 EPC. The decision reinforces that the idea of adapting a device’s notification behaviour based on location and user patterns is a non-technical concept, regardless of whether it ultimately results in a physical change to device settings. It also provides a clear articulation of the “technical leakage fallacy,” cautioning that the technical nature of an implementation step cannot be projected back onto the preceding non-technical reasoning that motivates it.

You can read the full decision here: T 0877/22 (Automatic changing of notification settings/MICROSOFT) of 5 December 2024, of the Technical Board of Appeal 3.5.01.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.