T 2998/19 19-12-2023

1. The claimed invention

The invention relates to a method and a system providing analytics data for an application.

A user device (e.g. a mobile phone) generates metrics regarding the use of an application on the device. These metrics are compared to a usage model for the application that indicates an expected set of states of the application and transition between those states during execution of the application. If the difference between the metrics and the usage model determined from the comparison exceeds a predetermined threshold, then analytics data based on the generated metrics are transmitted to an external device (analytics service) (see Figures 1 and 4 of the application).

2. Main request

2.1 It was common ground that the starting point for the skilled person was a generally known method for providing analytics data for an application, in the same technical context as the claimed method. In the conventional method, analytics data based on the generated metrics related to the use of the application were always transmitted to an external device. The examining division did not cite any specific prior art document and the appellant did not contest that such a method was part of the state of the art. The board sees no reason to disagree.

2.2 It was also common ground that the claimed method differed from the state of the art in that it compared the generated metrics to a usage model for the application, determined a difference between the metrics and the usage model and, when the difference exceeded a predetermined threshold, analytics data based on the generated metrics were transmitted to an external device.

2.3 The appellant argued that the method of claim 1 solved a technical problem in that it reduced the network usage/bandwidth requirements and the power consumption of the user device.

2.3.1 Making reference to paragraphs [0003], [0033] and [0045] of the application, the appellant pointed out that by transmitting the analytics data to the external device only when the difference between the metrics and the usage model exceeded a predetermined threshold, the amount of data transmitted to the external device was reduced. This reduced the network usage/bandwidth requirements of the user device and thereby its power consumption, extending the battery life-time.

2.3.2 In addition, the appellant argued that the analytics data should be considered as "functional data" in the sense of decision T 1194/97 (see also Case Law of the Boards of Appeal, 10th Edition, July 2022, I.D. 9.2.10c)). The analytics data indicated whether the application code achieved its desired technical effect. The claimed method should thus be seen as a method for determining whether the application code produced its desired technical effect. There was a need to know what the (application) code was actually doing and whether any "unexpected state" occurred. This was achieved by the generation and transmission of functional control data (the analytics data).

2.3.3 Regarding the threshold, according to the applicant the value of 5% mentioned in the description was an illustrative example of an acceptable threshold value. The actual value of the threshold was not important. There would always be savings in bandwidth and power consumption, since the use of any threshold meant that not all the analytics data would be transmitted.

2.3.4 According to the appellant, therefore, the features distinguishing the claimed method from the prior art were technical. The claimed method solved the technical problem of reducing network usage/bandwidth requirements and the power consumption of the user device. Since no relevant suggestion was present in the prior art, these features were also inventive.

2.4 The appellant's arguments do not persuade the board.

2.4.1 Regarding the analytics data, the board disagrees that they should be seen as functional data. The "unexpected states" of the monitored application mentioned by the appellant do not relate to any fault conditions or errors in the application code. The metrics relate to the usage of the application, and, more specifically, to transitions from one state to another. The "unexpected states" relate to usage or transitions that differ from the usage model, which is generated based on usage statistics (see e.g. Figure 5 and paragraphs [0050] to [0054]). In other words, an "unexpected state" occurs when a user of the application uses the application in a way that is different from the way the majority of the users use it or the developer might have expected.

This information may be of interest to the developer of the application, who may wish to modify the application in order to facilitate such a specific usage. The developer may also chose to ignore it. This indicates that the analytics data do not affect the way the application operates but merely convey information about how the application is used in a particular case. Hence, the analytics data cannot be seen as functional data producing a technical effect.

It should also be noted that the way an application functions is a design decision by the developer. What is "normal" or "unexpected" usage or transition between states of the application depends thus on the developer's design decisions. It cannot therefore be accepted that an "unexpected state" is an error or a fault which affects the application's function.

2.4.2 Regarding the predetermined threshold, the applicant stated that the value of 5% (see paragraph [0038]) was an illustrative example. Indeed there is no information in the claims or in the application as a whole about how the value of the threshold is (to be) determined.

Moreover, according to paragraph [0033] of the application, setting and using a threshold to limit the amount of the transmitted analytics data is merely a user preference. The user may chose to have the analytics data transmitted every time (see the last sentences of the paragraph). The board sees this also as an indication that the setting of a threshold and the comparison to a usage model are not necessarily related to any technical problems but rather depend on user preferences, in other words on design decisions which do not involve any technical considerations.

2.4.3 In the board's view therefore both the comparison to a model and the predetermined threshold relate to the decision of what should be included in the analytics data transmitted to the external device, i.e. to the definition of the analytics data in the context of the present application. This decision is taken by the designer of the system without considering any technical problems or involving any technical considerations.

2.4.4 The board takes thus the view that the claimed method is dictated by the administrative (business) definition of the analytics data, i.e. the decision what to include in the analytics data transmitted from the user device to the external device.

The steps of the claimed method are seen as implementations of non-technical constraints that would be given to the skilled person for implementation. In the absence of any related details in the claims or the application as a whole, these implementations are considered to be obvious for the skilled person using common general knowledge.

2.4.5 The board agrees with the appellant that reducing network usage/bandwidth requirements and power consumption of a device are technical problems.

The network usage in the present context relates to the transmission of a certain amount of analytics data from the user device to the analytics (external) device (see Figure 1). Compared to a client device transmitting the analytics data every time, the network usage of the claimed application is reduced by reducing the amount of analytics data transmitted to the external device (see also paragraph [0033] of the application).

2.4.6 In the present case, however, this reduction is achieved by modifying the underlying administrative (business) scheme relating to the definition of what data should be comprised in the transmitted analytics data and not by any technical means.

According to established case law and practice, the technical problem identified is thus not deemed to have been solved by technical means, but merely circumvented (see e.g. T 258/03, Dutch Auction/Hitachi, OJ 2004, 575; Headnote II and Reasons 5.5 to 5.7).

2.5 The board's conclusion is therefore that the subject-matter of claim 1 of the main request does not involve an inventive step.

3. Auxiliary requests

3.1 Both the first and second auxiliary requests were filed after the notification of the summons to the oral proceedings and the board's preliminary opinion. Their admittance is thus governed by Article 13(2) RPBA.

3.2 The appellant explained that the auxiliary requests were rather clarifying the main request than introducing new features. Claim 1 of the first auxiliary request made clear the distinction between transmitting and not transmitting of the analytics data based on the comparison to the usage model and that this was done for each of a plurality of monitored applications. Claim 1 of the second auxiliary request included a definition of the threshold, specifying that it was calculated based on probabilities.

The appellant also explained that its main substantive arguments were the same as for the main request.

3.3 Since the board was not confronted with any new arguments and was not persuaded by the appellant's arguments regarding the main request, it decided to leave the question of admittance of the auxiliary requests open and to decide on their substance.

3.4 Claim 1 of the first auxiliary request defines in addition to claim 1 of the main request that there are several applications monitored for which metrics are generated and that for each one of them the metrics are compared to a corresponding usage model. It also adds that if the difference between the metrics and the usage model does not exceed the threshold, no analytics data will be transmitted to the external device.

The board considers the monitoring of the usage of several applications on the user device instead of one to be a straightforward measure, which would be obvious to the skilled person. The appellant did not argue the contrary, either. The non-transmission of analytics data when the difference between the metrics and the usage model does not exceed the threshold is considered implicit in claim 1 of the main request, which defines that when the difference from the usage model exceeds the predetermined threshold, analytics data are transmitted. As explained for claim 1 of the main request, the board fails to see how this feature could lead to the recognition of an inventive step.

3.5 Regarding the definition of the threshold in claim 1 of the second auxiliary request, the board's view is that it is still a design decision of how to define the threshold. It does not provide any particular technical effect or involve any technical considerations. The appellant did not argue the contrary, either.

3.6 The board's conclusion is, hence, that the subject-matter of claim 1 of the first and the second auxiliary requests does not involve an inventive step for the same reasons as for claim 1 of the main request.

4. Since none of the requests on file is allowable, the appeal must fail.