T 1371/19 21-03-2023

1. The invention

1.1 The claimed invention relates to a method for filtering content, and in particular of recommendations sent to a user of a social network.

1.2 A user receives recommendations from their contacts in a social network. These recommendations are in the form of a contact-genre tuple (CU1,g), and relate to a content item of a specific genre (g) which has been initiated by a contact (CU1) of the user. For example, a contact of the user sends a recommendation about a detective movie. The system monitors the user's reactions to those recommendations and generates a filter based on them. For example, if a user reacts positively to a recommendation about a content item of genre (g) coming from their contact (CU1), a high "relevance-taste index" is recorded. If they react negatively, then a low relevance-taste index is recorded (see published application, page 5, lines 8 to 19 and page 16, line 7 to page 17, line 6). After a sufficient number of iterations, a filter is generated and applied, such that for example recommendations by contact (CU1) regarding a content item of genre (g) will be presented to the user only if the recorded relevance-taste index is above a predetermined threshold ("filtering criterion"; see idem., page 19, lines 8 to 19).

2. Main request, inventive step

2.1 Prior art

2.1.1 The appellant did not contest the board's selection of D2 as starting point for the assessment of inventive step.

D2 describes a computer-implemented social network where users develop direct and indirect personal relationships (contacts). The system monitors the interaction of the users within the social network and uses information filtering to measure the "affinity of a relationship" between them (paragraph [0016] and [0041]). This "affinity information" is a measure of the "level of trust" or common interests between two users (see paragraphs [0036] to [0040]). This affinity information is used to filter various information, including, but not limited to, product recommendations, ratings, polling queries, advertising, social network communications, personal ads, career opportunities, and so forth (paragraph [0017]) and also email messages (paragraph [0048]).

2.1.2 In essence, D2 describes the same operation as the claimed method: monitoring a user's behaviour within a social network, especially their behaviour in relation to other users, establishing a level of trust ("affinity information") between users based on that behaviour. The "affinity information" is then used as a filtering criterion to filter messages to the user (e.g. recommendations), much like the "relevance-taste index" of the claims of the main request.

2.2 According to the appellant, the difference of the claimed method from D2 lied in the use of the contact-genre tuple (see feature (a) of claim 1 of the main request). This tuple constituted a data structure consisting of two parts, one related to the origin of the data (CU1: the contact sending the recommendation) and the other to the content (g: the genre). D2 did not mention any details about the filtered messages.

2.2.1 Recognising such data structures consisting of these two parts was a technical feature, unknown in the prior art. The claimed method was monitoring such data structures and was also logging the user's reaction to them. Furthermore, based on the logged reactions to each data structure (tuple), a filter was generated automatically, without the user having to do anything, e.g. accept cookies. The method provided these features with the "lowest cognitive burden" for the user.

2.2.2 Having to recognise a data structure of a specific type was a technical feature. Monitoring the origin and the content of the data in combination with the user's reaction to them was thus a technical feature not known from D2.

Making reference to paragraphs [0036] and [0039] to [0041], the appellant argued that D2 was vague about how the monitoring of the user's activity was carried out. The skilled person, starting from D2, would thus have had no indication about how to proceed and arrive at the claimed method. Claim 1 of the main request involved, thus, an inventive step.

2.2.3 The appellant made also reference to decision T 1028/14 which related to spam message filtering. The deciding board, contrary to the examining division in that case, concluded that all features relating to the assessment and filtering of the messages were technical. The claimed method did not relate to spam, but carried out filtering of received messages (recommendations) in a similar way. The claimed features were thus technical and should be assessed accordingly.

2.3 The board is not convinced by the appellant's arguments.

2.3.1 The board agrees with the appellant that D2 does not explicitly disclose a differentiated affinity/trust determination where both contact (origin) of the recommendation and the content (genre) are detected/monitored. The board, however, notes that the idea for a differentiated detection of the recommendation does not solve any technical problem or involve any technical considerations. Neither the application nor the appellant provided any indications about any technical advantages gained by such differentiated detection with respect to D2. In the board's view, detecting both origin and genre of the received recommendations results from a non-technical decision taken by the administrator/designer of the method and not by the technically skilled person that is trying to solve a technical problem.

Hence, following established case law and practice, the detection of both origin and content of the received recommendation (contact-genre tuple) would be part of the non-technical constraints given to the skilled person for implementation.

2.3.2 Neither the claims nor the application provide any details about the implementation of this differential detection. Feature (a) of claim 1 of the main request is a mere repetition of the non-technical constraint: "detecting (110) that a recommendation of a contact-genre tuple (CU1,g) has been filed in a user account of a user A of the social network". There is no detailed information about how this detection is (to be) carried out.

2.3.3 Moreover, there is nothing special about a data structure comprising a part containing data and a part indicating the origin of those data. In the board's view, this corresponds to any common message transmitted within a network (e.g. e-mail), as every message normally indicates the sender (origin) and has a content (data). The board is of the opinion that detecting such data structures is a standard feature, which the skilled person would implement using only common general knowledge. In addition, D2 describes specifically the monitoring of user's reactions to recommendations received from other users. It is considered implicit that such recommendations consist of a part indicating who sent them (origin) and a part containing the actual recommendation (genre).

2.3.4 Regarding decision T 1028/14, the board notes that the claim on which this decision was based (see point III. of the Facts and Submissions) defined several technical details about how the received messages were logged (feature (ii)) and how they were assessed using reputation metrics using databases at a reputation engine (feature (iii)). The deciding board considered that these features were technical and should be taken into account in the assessment of inventive step, something the examining division had not done, since it had regarded those features as non-technical.

In the case at hand the board also considers all the features of claim 1 to be technical, as far as they are implemented within a computer system. It is their implementation that the board considers obvious for the skilled person. The board is thus satisfied that there is no contradiction with the ratio decidendi in T 1028/14.

2.3.5 Summarising, the board considers that the features distinguishing claim 1 of the main request from D2 represent an implementation of a non-technical constraint. The skilled person, a computer programmer in this case, would carry it out in an obvious manner using only common general knowledge.

2.3.6 The board's conclusion is therefore that the subject-matter of claim 1 of the main request does not involve an inventive step within the meaning of Articles 52(1) and 56 EPC.

3. First auxiliary request

3.1 Claim 1 of the first auxiliary request defines a filter apparatus arranged for being coupled to a recommender system for a user of a social network comprising features corresponding to the features of the method of claim 1 of the main request.

3.2 The appellant argued that claim 1 of the first auxiliary request defined explicitly a device and therefore all the claimed features were features of a device carrying out a specific implementation of the claimed invention. All the claimed features were thus technical and defined technical implementations of the corresponding operations.

3.3 The board agrees that the features of claim 1 are technical. However, it notes that they are only defined by their functions: a "detector" configured to detect, a "monitoring unit" configured to monitor, a "data logger" configured to log data, etc. There are no details about any technical components, structures, or operations of these features other than the function they are configured to carry out.

3.4 In the board's view, therefore, the arguments against the method of claim 1 of the main request are also valid for the device of claim 1 of the first auxiliary request. The appellant did not provide any further arguments for the first auxiliary request, either.

3.5 The board's conclusion is hence that the subject-matter of claim 1 of the first auxiliary request does not involve an inventive step for the same reasons as for claim 1 of the main request (Articles 52(1) and 56 EPC).

4. Second auxiliary request

4.1 Claim 1 of the second auxiliary request defines a device with all the features of claim 1 of the first auxiliary request and the additional feature of a buffer where all the blocked recommendations are kept (buffered). When the filtering criterion is adjusted (changed), blocked recommendations which fulfil the adjusted criterion are released to the user account.

4.2 The appellant argued that this feature was different from the "recycle bin" of known operating systems and the "whitelisting" of email addresses in spam filters (see point 2.6 of the reasons of the decision under appeal and point 6.3 of the board's communication under Article 15(1) RPBA 2020 dated 14 November 2022). The claimed feature defined an automatic operation without any user intervention. Once the filtering criterion was modified (adjusted), the blocked recommendations which fulfilled the adjusted criterion were automatically sent to the user. In a "recycle bin" the user had to select manually which of the discarded items to reinstate. A change in a spam filter applied only for future messages and not for those already blocked by the spam filter.

4.2.1 The board notes at first that the application does not describe that the filtering criterion is applied automatically. There are two vague statements, that the filtering criterion is "adjusted dynamically" (see page 8, line 7) and that it "can change over time" (see page 19, line 22). These statements leave open the possibility that the filtering criterion is applied manually by the user. The appellant acknowledged this during the oral proceedings, too.

So, the release of the messages is not done completely automatically, as the appellant argued, but only after the user has modified manually the filtering criterion.

4.2.2 Secondly, the board is of the opinion that this feature does not solve any technical problem but is an additional non-technical feature decided by the administrator/designer of the system. Keeping the blocked recommendations in a buffer (and not deleting them) and releasing them after the filtering criterion is modified is an administrative decision, which involves no technical considerations. It is rather a feature which is considered "nice to have" for non-technical purposes without producing any technical effect.

4.2.3 As with the previous requests, the definition of this added feature in claim 1 of the second auxiliary request does not go beyond repeating this non-technical idea. There are no details about how this is (supposed to be) carried out. The non-technical constraint is thus merely repeated in the context of the claimed device and its implementation is left to the skilled person. In the absence of any technical details about this implementation, the board concludes that carrying it our would be a routine step of the skilled person using common general knowledge.

4.2.4 The subject-matter of claim 1 of the second auxiliary request, therefore, does not involve an inventive step (Articles 52(1) and 56 EPC).

5. Third auxiliary request

5.1 The device of claim 1 of the third auxiliary request has the same features as the device of claim 1 of the first auxiliary request and the following additional features relating to:

- grouping blocked recommendations relating to a common content item (genre), calculating an accumulated relevance-taste index, and releasing them to the user, as a single combined recommendation, if the accumulated relevance-taste index fulfils the filtering criterion; and

- introducing a second metric, the "like-degree" for the common interest item (y) for each of the identified senders (B) of recommendations to the user (A) indicating the respective sender's interest in the common content item (y) and using this "like-degree" to calculate a "normalized accumulated relevance-taste index". If this index fulfils the filtering criterion, a recommendation for the common content item (y) is filed in the user's account.

5.2 As with the added features in the previous requests, the board considers that these features, too, relate to administrative decisions about non-technical aspects of the system. These features neither solve any technical problems nor involve any technical considerations. They rather represent non-technical constraints that would be given to the skilled person for implementation. Their definition in the claim does not go beyond the description of these non-technical constraints as no technical details are provided about their implementation. The skilled person tasked with their implementation would, thus, carry them out in an obvious manner using only common general knowledge.

5.3 In relation to the second added feature relating to the "like-degree", the appellant argued that the normalized relevance-taste index constituted a "better" filtering criterion which provided "better" results. It reiterated that this criterion was automatically determined by the system without user intervention. This constituted a technical implementation which was not obvious for the skilled person.

5.4 The board does not find this argument convincing. It is not evident what is meant by a "better" filtering criterion. What seems to result from the claimed definition is that it may be more likely that the recommendations sent to the user are positively accepted. This is not a technical effect. In any case, as explained before, the board's view is that any advantage obtained by the new filtering criterion is a result of an administrative decision not involving any technical considerations. As to the automatic setting of the filter by the system, this is also done in D2, where the system monitors the interactions between the users and determines the corresponding level of trust ("affinity information") automatically.

5.5 The board's conclusion is thus that the subject-matter of claim 1 of the third auxiliary request does not involve an inventive step (Articles 52(1) and 56 EPC).

6. Fourth auxiliary request

6.1 The device of claim 1 of the fourth auxiliary request comprises all the features of the device of the first auxiliary request and the combination of the added features of the devices of the respective claim 1 of the second and third auxiliary requests.

Following from the board's conclusions regarding the previous auxiliary requests, the conclusion is that the subject-matter of claim 1 of the fourth auxiliary request does not involve an inventive step, either (Articles 52(1) and 56 EPC).

The appellant did not present any additional argument regarding this auxiliary request.

7. Remittal

7.1 The appellant requested remittal of the case to the examining division for further prosecution. It did not, however, put forward any reasons for such a remittal.

7.2 The board does not see any such reasons, either.

Moreover, the board has examined all requests as to their substance and concluded that there is no allowable request on file. Consequently, there is also no request on the basis of which the application could be further prosecuted under Article 111(1), second sentence, EPC. As a result, the request for remittal is rendered moot.

8. Since there is no allowable request on file, the appeal must fail.