T 2061/10 () of 25.6.2015

Exposé des faits et conclusions

I. Le présent recours a été formé à l'encontre de la décision de la division d'examen rejetant la demande de brevet européen n° 06118047.7 publiée sous le numéro EP 1746837 A2 et revendiquant le droit de priorité de deux demandes de brevet français.

II. Dans la décision attaquée la division d'examen avait jugé que l'objet des revendications indépendantes 1 et 7 de la seule requête n'impliquait pas d'activité inventive par rapport au document de l'état de la technique suivant:

D1: EP 0926862 A2.

III. Avec le mémoire de recours la requérante a déposé deux jeux de revendications modifiées en requêtes principale et subsidiaire.

IV. Dans une notification selon l'article 15(1) du règlement de procédure des chambres recours (RPCR) la chambre a indiqué qu'elle était de l'avis provisoire que les revendications indépendantes 1 et 7 des requêtes principale et subsidiaire ne satisfaisaient pas aux exigences des articles 76(1) et 123(2) CBE et que leur objet n'impliquait pas d'activité inventive par rapport à D1.

V. Par courrier en date du 22 mai 2015 la requérante a déposé un nouveau jeu de revendications modifiées en requête principale et a retrogradé les requêtes déposées avec le mémoire de recours au rang de requêtes subsidiaires 1 et 2.

VI. La procédure orale s'est tenue le 25 juin 2015. Au cours de celle-ci la requérante a déposé de nouveaux jeux de revendications remplaçant les précédents.

VII. Les requêtes finales de la requérante sont l'annulation de la décision de rejet de la demande et la délivrance d'un brevet sur la base des revendications selon les requêtes principale et subsidiaire déposées respectivement à 14h00 et 17h00 pendant la procédure orale du 25 juin 2015.

VIII. La revendication 1 selon la requête principale s'énonce comme suit:

"Procédé de réception, par au moins un terminal, de données de mise à jour émises, sur un réseau de diffusion, par un central de communication vers une pluralité de terminaux, ledit central de communication étant configuré pour émettre des signaux d'annonce d'une campagne de mise à jour de terminaux sur plusieurs canaux de diffusion dudit réseau de diffusion, lesdits signaux d'annonce comportant au moins une indication temporelle pour l'émission des données de mise à jour, ledit procédé comportant une réception, par ledit terminal, d'au moins un desdits signaux d'annonce sur au moins un desdits canaux de diffusion, caractérisé en ce que :

- lesdits signaux d'annonce indiquent également un canal de diffusion spécifique parmi lesdits canaux de diffusion pour transmettre les données de mise à jour;

- lorsqu'un canal de diffusion est utilisé par un utilisateur dudit terminal et que ce canal de diffusion utilisé est différent du canal de diffusion spécifique, ledit terminal affiche, à l'instant d'émission des données de mise à jour, une proposition de changement de canal de diffusion à l'utilisateur dudit terminal de manière à télécharger des données de mise à jour,

de sorte que, en cas d'accord de l'utilisateur à la proposition de changement de canal, le canal de diffusion utilisé par l'utilisateur est changé pour devenir le canal de diffusion spécifique indiqué dans le signal d'annonce et pour recevoir les données de mise à jour;

- ledit terminal mémorise les données de mise à jour reçues sur le canal de diffusion spécifique et transmet au central un signal de bon déroulement de l'opération de mise à jour."

IX. La revendication 1 selon la requête subsidiaire diffère de la revendication 1 selon la requête principale par le texte suivant ajouté à la fin de la revendication:

";

lorsque le signal d'annonce indique la fin d'une campagne de mise à jour, ladite proposition de changement précise que, en l'absence de téléchargement des données de mise à jour, la mise à jour devra s'effectuer par une voie de retour entre le terminal et ledit central."

X. Les motifs de la decision attaquée (quant à l'activité inventive du procédé de transmission de données de mise à jour défini à la revendication 1 de la seule requête) peuvent être résumés comme suit:

Le document D1 décrit un procédé de transmission de données de mise à jour d'une pluralité de terminaux dans lequel des signaux d'annonce annonçant des données de mise à jour dans le cadre d'une campagne de mise à jour sont envoyés aux terminaux et dans lequel il est demandé à l'utilisateur la permission de mettre à jour son terminal. La réception des données de mise à jour se fait en se calant sur le canal sur lequel elles sont diffusées.

Le procédé de la revendication 1 diffère de celui de D1 en ce que si, au moment de la réception d'une mise à jour, le terminal n'est pas calé sur le bon canal, l'utilisateur se voit proposé de changer de canal pour recevoir les données de mise à jour.

Il serait évident pour l'homme du métier qu'un changement de canal intempestif représente pour l'utilisateur une gêne importante qu'il convient d'éviter. Une solution évidente à ce problème serait de demander l'accord de l'utilisateur avant d'effectuer un changement de canal pour une mise à jour. Certes, D1 enseigne de configurer le terminal à l'avance pour indiquer les plages horaires pendant lesquelles des données de mise à jour peuvent être acceptées, mais cela n'empêcherait pas l'homme du métier d'implémenter des fonctions qui simplifieraient la vie de l'utilisateur si ces fonctions viennent immédiatement à l'esprit de l'homme du métier. Cette fonction de proposer à l'utilisateur une mise à jour de son terminal est d'autant plus naturelle que l'utilisateur (et l'homme du métier) connaît de l'utilisation de son ordinateur personnel sous Windows 98 le fait d'avoir un message d'avertissement de la disponibilité d'une mise à jour.

XI. Les arguments de la requérante peuvent être résumés comme suit:

Requête principale - activité inventive

D1 divulgue un procédé de réception par plusieurs terminaux de données de mise à jour préalablement annoncées par des signaux d'annonce.

Le procédé de réception de la revendication 1 se distingue de celui de D1 par les caractéristiques suivantes:

- les signaux d'annonce sont émis sur plusieurs canaux de diffusion;

- les signaux d'annonce indiquent un canal de diffusion spécifique parmi lesdits canaux de diffusion pour transmettre les données de mise à jour; et

- lorsqu'un canal de diffusion est utilisé par un utilisateur dudit terminal et que ce canal de diffusion utilisé est différent du canal de diffusion spécifique, ledit terminal affiche, à l'instant d'émission des données de mise à jour, une proposition de changement de canal de diffusion à l'utilisateur dudit terminal de manière à télécharger des données de mise à jour, de sorte que, en cas d'accord de l'utilisateur à la proposition de changement de canal, le canal de diffusion utilisé par l'utilisateur est changé pour devenir le canal de diffusion spécifique indiqué dans le signal d'annonce et pour recevoir les données de mise à jour.

Le problème technique objectif résolu par ces caractéristiques peut se formuler de la façon suivante:

"Comment effectuer la mise à jour de terminaux en cours d'utilisation tout en limitant les perturbations associées à cette mise à jour sur le réseau de diffusion?"

En partant de D1, l'homme du métier n'arriverait pas au procédé de la revendication 1 sans faire preuve d'activité inventive pour les raisons suivantes:

- D1 enseigne de permettre à l'utilisateur de configurer le terminal pour que les données de mise à jour ne soient acceptées par le terminal que dans certaines fenêtres temporelles, afin de ne pas déranger l'utilisateur. D1 dissuade donc d'interrompre l'utilisateur pour lui demander son accord pour recevoir des données de mise à jour.

- Il n'y a aucune suggestion dans D1 de transmettre les signaux d'annonce sur plusieurs canaux.

- Il n'y a aucune suggestion dans D1 d'indiquer dans le signal d'annonce le canal sur lequel les données de mise à jour seront transmises.

- Il n'y a aucune suggestion dans D1 de demander l'accord de l'utilisateur avant de changer de canal pour recevoir les données de mise à jour.

- Il n'y a aucune suggestion dans D1 de demander cet accord à l'instant d'émission des données de mise à jour.

- L'ensemble des modifications qu'il faudrait apporter au terminal et à la signalisation des mises à jour serait considérable et irait bien au-delà d'un simple travail de routine.

Admission de la requête subsidiaire

Les revendications selon la requête subsidiaire diffèrent des revendications selon la requête principale essentiellement en ce que les caractéristiques de la revendication dépendante 5 déposée avec la lettre datée du 22 mai 2015 ont été introduites dans la revendication indépendante 1 (des modifications similaires ont également été faites dans la revendication indépendante définissant un "terminal").

Cette requête subsidiaire sert à appuyer l'activité inventive et n'a pu être déposée plus tôt à cause d'un changement de mandataire. Elle s'appuie sur des caractéristiques qui n'étaient certes pas présentes dans les revendications pendant la procédure devant le département de première instance, mais qui ont certainement fait l'objet d'une recherche d'antériorité. La chambre devrait admettre cette requête dans la procédure.

Motifs de la décision

1. Le recours est recevable.

Requête principale - activité inventive (article 56 CBE 1973)

2. État de la technique le plus proche

La requérante n'a pas contesté que D1 représente l'état de la technique le plus proche.

La requérante n'a pas non plus contesté que D1 divulgue un procédé de réception, par au moins un terminal (cf. "receiving apparatus" 100 à la figure 26), de données de mise à jour (cf. "software download" au paragraphe [0001]) émises, sur un réseau de diffusion (cf. "broadcasting", par exemple au paragraphe [0001]), par un central de communication (cf. "transmitting apparatus" 500 à la figure 1) vers une pluralité de terminaux, ledit central de communication étant configuré pour émettre des signaux d'annonce (cf. "download table", par exemple à la figure 29) d'une campagne de mise à jour de terminaux, lesdits signaux d'annonce comportant au moins une indication temporelle (cf., par exemple, figure 29) pour l'émission des données de mise à jour, ledit procédé comportant une réception, par ledit terminal, d'au moins un desdits signaux d'annonce sur au moins un desdits canaux de diffusion (cf. paragraphes [0102] et [0103]). Le procédé de D1 comprend en outre la réception et la mémorisation des données de mise à jour, ainsi que la transmission au central d'un signal de bon déroulement de l'opération de mise à jour (cf. colonne 26, lignes 23 à 26 et colonne 21, lignes 30 à 34).

3. Différences

La chambre partage l'avis de la requérante que le procédé de la revendication 1 se distingue de celui de D1 par les caractéristiques suivantes (identifiées par la chambre par les lettres (a) à (c)):

(a) les signaux d'annonce sont émis sur plusieurs canaux de diffusion;

(b) les signaux d'annonce indiquent un canal de diffusion spécifique parmi lesdits canaux de diffusion pour transmettre les données de mise à jour; et

(c) lorsqu'un canal de diffusion est utilisé par un utilisateur dudit terminal et que ce canal de diffusion utilisé est différent du canal de diffusion spécifique, ledit terminal affiche, à l'instant d'émission des données de mise à jour, une proposition de changement de canal de diffusion à l'utilisateur dudit terminal de manière à télécharger des données de mise à jour, de sorte que, en cas d'accord de l'utilisateur à la proposition de changement de canal, le canal de diffusion utilisé par l'utilisateur est changé pour devenir le canal de diffusion spécifique indiqué dans le signal d'annonce et pour recevoir les données de mise à jour.

4. Problème technique objectif

La requérante a proposé que le problème technique objectif résolu par ces caractéristiques pouvait être formulé comme suit:

"Comment effectuer la mise à jour de terminaux en cours d'utilisation tout en limitant les perturbations associées à cette mise à jour sur le réseau de diffusion?"

La chambre n'a pas d'objection à l'encontre de cette formulation.

5. Évidence

Selon les paragraphes [0102] et [0103] de D1, les données de mise à jour sont transmises sur un canal de diffusion du réseau de diffusion, de la même manière que les programmes de télévision (colonne 25, lignes 15 à 22). En général, les données de mise à jour sont transmises sur un canal dédié, mais elles peuvent aussi être transmises sur un canal transmettant des programmes de télévision (colonne 25, lignes 25 à 28). Lorsqu'un canal dédié est utilisé pour transmettre les données de mise à jour, l'utilisateur ne peut pas regarder un programme de télévision sur un autre canal car le terminal ne peut se caler que sur un seul canal à la fois (colonne 25, lignes 18 à 24).

Quant aux signaux d'annonce (cf. "download table", par exemple à la figure 29), D1 divulgue qu'ils sont transmis aux terminaux, mais ne précise pas sur quel canal - ou quels canaux - s'effectue cette transmission.

Étant donné qu'un réseau de diffusion de programmes de télévision numérique (cf. "digital" à la colonne 1, lignes 3 à 5, et la référence à "EPG" à la figure 29 indiquant qu'il s'agit de programmes de télévision numérique) comprend normalement de nombreux canaux, la chambre considère qu'il serait évident pour l'homme du métier que si les signaux d'annonce sont transmis sur un seul canal, ils ne seront reçus que par les terminaux calés sur ce canal, c'est-à-dire une petite partie de l'ensemble des terminaux. Par exemple, s'il y a 100 canaux de diffusion, la probabilité qu'un terminal soit calé sur le bon canal pour recevoir les signaux d'annonce n'est que de 1/100. Par conséquent, la chambre considère qu'il serait évident pour l'homme du métier que les signaux d'annonce doivent être transmis sur plusieurs canaux, voire sur tous les canaux. Étant donné que les signaux d'annonce sont de petite taille par rapport aux signaux de télévision, il serait clair pour l'homme du métier qu'ils peuvent facilement être insérés sous forme de paquets ("packets" au sens de MPEG) dans le "transport stream (TS)" (cf. colonne 25, ligne 19) d'un programme de télévision sans perturber la réception du programme. L'insertion de paquets dans un "transport stream" (au sens de MPEG) est bien connu de l'homme du métier et ne pose pas de difficulté technique particulière.

Pour ces raisons, l'homme du métier arriverait à la caractéristique (a) de la revendication 1 sans faire preuve d'activité inventive.

Lorsque, pour les raisons ci-dessus, les signaux d'annonce sont transmis sur plusieurs canaux, ces signaux d'annonce doivent nécessairement indiquer quand et sur quel canal les données de mise à jour seront transmises, puisque ce canal spécifique peut varier (cf. colonne 25, lignes 25 à 28).

Par conséquent, l'homme du métier arriverait également à la caractéristique (b) de la revendication 1 sans faire preuve d'activité inventive.

À la date de priorité la plus ancienne de la demande (30 décembre 1999) il était couramment connu d'afficher un message pour demander à l'utilisateur la permission d'installer une mise à jour d'un programme (voir l'exemple de Windows 98 cité à la page 4 de la décision contestée) affectant le fonctionnement du terminal/ordinateur/récepteur, par exemple en le ralentissant fortement. La chambre considère que l'affichage d'un tel message sur l'écran (cf. "display" 200 à la figure 26) du terminal de D1 serait évident, lorsque la réception de données de mise à jour pourrait gêner l'utilisateur, ce qui est le cas lorsque l'utilisateur est en train de regarder un programme de télévision que la réception des données de mise à jour va interrompre par un changement de canal.

L'homme du métier devrait alors nécessairement se poser la question de l'instant auquel ce message devrait être affiché sur l'écran du terminal. Cet instant ne peut être qu'entre le moment où le signal d'annonce est reçu et le moment où les données de mise à jour commencent à arriver. La chambre considère qu'il serait évident pour l'homme du métier que le meilleur moment pour afficher ce message est juste avant l'arrivée des données de mise à jour, car c'est le seul moment où l'on peut être sûr de ne déranger que les utilisateurs directement concernés, c'est-à-dire ceux qui sont sur le point d'être gênés par la réception des données de mise à jour. En effet, si le message est affiché plus tôt, par exemple 30 minutes plus tôt, tous les utilisateurs regardant la télévision à ce moment-là seront dérangés par le message, y compris ceux qui allaient éteindre leur terminal avant l'arrivée des données de mise à jour et ont donc été dérangés pour rien. En outre, dans cet exemple, les utilisateurs ayant allumé leur terminal moins de 30 minutes avant l'arrivée des données de mise à jour ne seront pas prévenus de l'interruption à venir, ce qui serait fâcheux.

Par conséquent, la chambre considère que l'homme du métier arriverait à la caractéristique (c) de la revendication 1 sans faire preuve d'activité inventive.

6. Les arguments de la requérante

Les arguments de la requérante (cf. point XI supra) auxquels le raisonnement ci-dessus de la chambre n'a pas encore répondu sont les suivants:

(A1) D1 enseigne de permettre à l'utilisateur de configurer le terminal pour que les données de mise à jour ne soient acceptées par le terminal que dans certaines fenêtres temporelles, afin de ne pas déranger l'utilisateur. D1 dissuade donc d'interrompre l'utilisateur pour lui demander son accord pour recevoir des données de mise à jour.

(A2) L'ensemble des modifications qu'il faudrait apporter au terminal et à la signalisation des mises à jour serait considérable et irait bien au-delà d'un simple travail de routine.

Concernant l'argument (A1):

La chambre est d'accord avec la requérante que le système de D1 comprend des mesures pour éviter que l'utilisateur soit dérangé lors de la réception de données de mise à jour. La principale de ces mesures consiste à autoriser l'utilisateur à choisir une plage horaire et à n'autoriser la réception de données de mise à jour que dans cette plage horaire (cf. figures 27 et 28 et paragraphes [0104] à [0106]). Dans le sixième mode de réalisation l'utilisateur peut en outre choisir d'autoriser exceptionnellement une mise à jour hors de cette plage horaire, si c'est la dernière occasion de recevoir cette mise à jour (cf. "enforced download" aux figures 37 et 38 et paragraphes [0116] et [0121]).

Toutefois, il est aussi prévu que le système de D1 interrompe l'utilisateur par l'affichage d'un message pour l'informer qu'un programme n'a pas pu être mis à jour (cf., par exemple, paragraphes [0070] et [0106]).

D1 n'enseigne donc pas une interdiction absolue d'interrompre l'utilisateur par l'affichage d'un message, mais plutôt que l'opportunité d'afficher un tel message dépend de l'importance et de l'urgence de celui-ci.

La chambre considère par exemple qu'il ne serait pas contraire à l'enseignement de D1 d'afficher un message pour informer l'utilisateur de la réception d'une mise à jour critique pour le fonctionnement ou la sécurité du récepteur et pour lui demander la permission de l'installer immédiatement, à un instant situé hors de la plage horaire sélectionnée par l'utilisateur. Une modification du système de D1 dans ce sens ne poserait aucune difficulté technique à l'homme du métier.

De manière plus générale, la chambre considère que demander à l'utilisateur de paramétrer à l'avance une plage horaire pour les mises à jour et demander la permission à l'utilisateur juste avant de recevoir une mise à jour sont deux faces d'une même médaille. Ces deux mesures visent à minimiser la gêne occasionnée à l'utilisateur par une mise à jour, et les avantages et inconvénients de chacune sont évidents pour l'homme du métier. Paramétrer une plage horaire a l'inconvénient de demander un effort en amont à l'utilisateur (peut-être pour rien si les mises à jour arrivent de toute façon toujours quand l'utilisateur n'utilise pas son terminal, par exemple la nuit) et peut retarder, voire rendre impossible, certaines mises à jour, mais présente l'avantage de diminuer les interruptions intempestives quand l'utilisateur est en train de regarder un programme de télévision. Les avantages et inconvénients de l'affichage d'un message pour demander l'accord de l'utilisateur juste avant une mise à jour sont à l'opposé de ceux du paramétrage d'une plage horaire: pas d'effort en amont, mais une gêne occasionnée par l'affichage d'un message quand l'utilisateur regarde un programme. La chambre considère donc qu'il serait évident d'utiliser l'une et l'autre de ces deux mesures dans des proportions variables en fonction des circonstances. Par exemple, il serait évident de permettre à l'utilisateur de paramétrer des plages horaires qui seraient généralement respectées, mais d'afficher quand même un message demandant l'autorisation de recevoir une mise à jour si la mise à jour est suffisamment urgente ou si l'utilisateur n'a pas (encore) fait l'effort de paramétrer une plage horaire.

Concernant l'argument (A2):

La requérante a affirmé durant la procédure orale que les modifications qu'il faudrait apporter au terminal et à la signalisation des mises à jour seraient considérables et iraient bien au-delà d'un simple travail de routine.

La chambre est de l'avis que ces modifications seraient relativement simples et tout à fait à la portée de l'homme du métier. En effet, émettre sur plusieurs canaux des signaux d'annonce comportant le numéro du canal sur lequel les données de mise à jour seront transmises et afficher un message à un instant donné ne présentent aucune difficulté technique particulière.

7. Conclusion

Pour les raisons présentées ci-dessus, la chambre conclut que l'objet de la revendication 1 de la requête principale n'implique pas d'activité inventive (article 56 CBE 1973) par rapport à D1.

Par conséquent, la requête principale n'est pas admissible.

Recevabilité de la requête subsidiaire

8. Selon l'article 13(1) RPCR, l'admission et l'examen de toute modification présentée par une partie après que celle-ci a déposé son mémoire exposant les motifs du recours sont laissés à l'appréciation de la chambre. La chambre exerce son pouvoir d'appréciation en tenant compte, entre autres, de la complexité du nouvel objet, de l'état de la procédure et du principe de l'économie de la procédure.

9. La revendication 1 selon la requête subsidiaire comprend les caractéristiques des revendications 1 et 5 de la requête principale.

10. La chambre a fait les observations suivantes sur les caractéristiques que cette requête subsidiaire a introduites dans la revendication 1 (cf. point IX supra):

- Ces caractéristiques ne figuraient ni dans les revendications considérées dans la décision faisant l'objet du recours, ni dans les revendications déposées avec le mémoire de recours.

- Ces caractéristiques proviennent de la description de la demande et ont été introduites dans un jeu de revendications pour la première fois avec la requête principale déposée avec la lettre datée du 22 mai 2015 (cf. la revendication dépendante 5 de cette requête), c'est-à-dire environ un mois avant la date de la procédure orale.

- Ces caractéristiques font mention pour la première fois d'une "voie de retour" qui n'a fait l'objet d'aucune discussion dans le cadre de l'activité inventive et n'est pas directement liée aux autres caractéristiques de la revendication.

- Ces caractéristiques ont été introduites dans la revendication 1 à un stade très tardif de la procédure (à 17h00 lors de la procédure orale du 25 juin 2015, la procédure orale ayant commencé vers 9h00).

11. La requérante a fait valoir que ces modifications de la revendication 1 servaient à appuyer l'activité inventive et n'avaient pas pu être déposées plus tôt parce qu'il y avait eu un changement de mandataire entre le dépôt du mémoire de recours et la lettre datée du 22 mai 2015 déposée en réponse à la citation à la procédure orale.

12. La chambre n'a pas été convaincue par ces arguments. Les modifications de la revendication 1 de la requête subsidiaire, qui selon la requérante visaient à appuyer l'activité inventive, auraient pu être déposées pendant la procédure devant la division d'examen ou, au moins, avec le mémoire de recours. Ni la notification de la chambre selon l'article 15(1) RPCR (jointe à la citation à la procédure orale), ni les débats pendant la procédure orale, n'ont créé une situation radicalement nouvelle pouvant justifier le dépôt de ces modifications puisque à ces deux occasions la chambre a essentiellement adoptée la même ligne sur l'activité inventive que celle utilisée dans les motifs de la décision attaquée.

En outre, la chambre n'a pas été en mesure d'établir si ces caractéristiques, qui n'étaient présentes dans aucune des revendications lors de la procédure devant le département de première instance, avaient fait l'objet d'une recherche d'antériorité par le département de première instance. Du fait de cette incertitude, l'admission de ces revendications à ce stade tardif de la procédure aurait obligé la chambre, soit à examiner un objet n'ayant peut-être pas été recherché, soit à renvoyer l'affaire à la première instance en pure perte si l'objet avait été recherché. La chambre aurait donc été contrainte de procéder dans une voie qui aurait nuit considérablement à la qualité et/ou à l'économie de la procédure. Ces considérations ont mis en lumière le fait que de telles modifications auraient dû être déposées pendant la procédure devant le département de première instance.

Quant à l'argument reposant sur un changement de mandataire, selon la jurisprudence constante des chambres de recours, le changement de mandataire ne constitue pas un motif acceptable pour la présentation tardive de moyens, à moins que ce changement ne relève de la force majeure, ce qui n'était visiblement pas le cas dans la présente affaire (cf. La Jurisprudence des Chambres de recours de l'Office européen des brevets, 7ème édition, Septembre 2013, point IV.C.1.4.6.e et IV.E.4.6.2).

13. Pour ces raisons, la chambre a considéré que, compte tenu de l'état de la procédure et du principe de l'économie de la procédure, la requête subsidiaire ne devait pas être admise dans la procédure (article 13(1) RPCR).

Conclusion

14. Puisque la requête principale n'est pas admissible et que la requête subsidiaire n'a pas été admise dans la procédure, le recours doit être rejeté.

Dispositif

Par ces motifs, il est statué comme suit

Le recours est rejeté.