| European Case Law Identifier: | ECLI:EP:BA:2009:T048006.20090218 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Date de la décision : | 18 Fevrier 2009 | ||||||||
| Numéro de l'affaire : | T 0480/06 | ||||||||
| Numéro de la demande : | 03292071.2 | ||||||||
| Classe de la CIB : | H04L 29/06 | ||||||||
| Langue de la procédure : | FR | ||||||||
| Distribution : | D | ||||||||
| Téléchargement et informations complémentaires : |
|
||||||||
| Titre de la demande : | Procédé d'interception de données de contrôle, notamment de qualité de service, et dispositif associé | ||||||||
| Nom du demandeur : | Alcatel Lucent | ||||||||
| Nom de l'opposant : | - | ||||||||
| Chambre : | 3.5.05 | ||||||||
| Sommaire : | - | ||||||||
| Dispositions juridiques pertinentes : |
|
||||||||
| Mot-clé : | Activité inventive (non) | ||||||||
| Exergue : |
- |
||||||||
| Décisions citées : |
|
||||||||
| Décisions dans lesquelles la présente décision est citée : |
|
||||||||
Exposé des faits et conclusions
I. Le présent recours est formé par la demanderesse de la demande du brevet européen nº 03292071.2 à l'encontre de la décision rendue le 22 septembre 2005 par la division d'examen rejetant la demande, la revendication 1 n'impliquant pas d'activité inventive au sens des exigences de l'article 56 CBE 1973 au vu du document
D1: C.-K. Tham et al, "Monitoring QoS distribution in multimedia networks", International journal of network management, Vol. 10, No. 2, Avril 2000, pages 75 à 90.
II. L'acte de recours a été déposé le 18 novembre 2005. La taxe de recours a été acquittée le même jour. Le mémoire exposant les motifs de recours a été reçu le 16 janvier 2006. La requérante a demandé l'annulation de la décision attaquée.
III. Dans une notification en annexe à une convocation à une procédure orale la Chambre a communiqué ses observations après un examen préliminaire. La Chambre a exercé ses compétences selon les articles 111(1) et 114(1) CBE 1973 et a introduit le document
D6: H. Schulzrinne et al, "RTP: A Transport Protocol for Real-Time Applications", IETF, RFC1889, 1996
dans la procédure. D6 est un document de standard auquel D1 fait référence aux pages 77, 78 et 90.
La Chambre a observé qu'elle considérait l'analyse faite par la première instance dans sa décision comme convaincant. En plus, la revendication 1 selon la requête principale et la requête auxiliaire ne semblaient pas impliquer une activité inventive au vu des documents D1 et D6.
IV. Par courrier du 16 janvier 2009 la requérante a présenté des observations concernant les objections soulevées dans la communication et a présenté une revendication 1 modifiée selon une requête subsidiaire.
V. A la procédure orale, qui a eu lieu le 18 février 2009, la requérante a présenté une nouvelle revendication 1 de la requête principale et a conclu à la réformation de la décision de rejet et à la délivrance d'un brevet sur la base de la revendication 1 soumise à la procédure orale, les revendications 2 à 32 de la demande telle que déposée et de 33 à 37 produites par lettre en date du 16 février 2005, la revendication 16 étant adaptée aux modifications marquées en italiques à la revendication 1 ou, à titre subsidiaire, sur la base de la revendication 1 produite par la lettre en date du 16 janvier 2009 adaptée aux modifications marquées en italiques à la revendication 1 soumise à la procédure orale, des revendications 2 à 32 de la demande telle que déposée et 33 à 37 produites par lettre en date du 16 février 2005, la revendication 16 étant adaptée à la revendication 1.
A la fin de l'audience la décision a été prononcée.
VI. La revendication 1 selon la requête principale s'énonce comme suit :
"Procédé d'interception de données échangées par des terminaux d'utilisateurs distants (Tij-k), via un réseau de communications, sous forme de paquets de contrôle formatés selon un premier protocole de contrôle de transfert de données en temps réel et associées à des données précédemment échangées par lesdits terminaux d'utilisateurs, caractérisé en ce qu'il comporte une étape dans laquelle, i) en cas de transfert de paquets de données entre au moins deux terminaux d'utilisateurs distants (Tij-k) sous forme de micro-flux, on intercepte au sein du réseau certains au moins desdits paquets pendant ledit transfert de manière à déterminer ceux qui sont formatés selon ledit premier protocole, puis ii) on duplique une partie au moins de chaque paquet ainsi formaté, dit "paquet de contrôle", et iii) on communique à une application de contrôle (1) implantée dans ledit réseau, des données représentatives de ladite partie dupliquée, de sorte qu'elle en déduise des informations sur ledit transfert."
La revendication 16 selon la requête principale porte sur un dispositif correspondant au procédé d'interception selon la revendication 1.
La revendication 1 selon la requête subsidiaire ajoute à la revendication 1 selon la requête principale qu'entre l'interception et la duplication, on effectue une comparaison entre une valeur seuil choisie et la valeur d'un champ d'informations du service contenu dans le paquet de contrôle intercepté, de manière à ne dupliquer que la partie au moins du paquet de contrôle dont le champ d'informations de service présente une valeur sensiblement supérieure à ladite valeur seuil.
La revendication 16 selon la requête subsidiaire porte sur un dispositif correspondant au procédé selon la revendication 1 de la même requête.
Motifs de la décision
1. Recevabilité
Le recours satisfait aux exigences des articles 106 à 108 CBE 1973, qui sont applicables selon J 10/2007, point 1 (voir Faits et conclusions, point II). Le recours est donc recevable.
2. Modifications
2.1 Recevabilité
Selon l'article 12 du règlement de procédure des chambres de recours (RPCR), la procédure de recours se fonde sur l'acte de recours, le mémoire exposant les motifs du recours déposé ainsi que sur toute notification envoyée par la Chambre et toute réponse à celle-ci produite conformément aux ordonnances de la Chambre. 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 ou sa réponse sont laissés à l'appréciation de la Chambre selon l'article 13 RPCR.
La revendication 1 selon la requête principale qui n'a été présentée qu'à l'audience a été rédigée en prenant en considération les observations de la Chambre exposées dans la notification. La revendication 1 ne diffère de la revendication 1 selon la requête principale antérieure qu'en précisant que les terminaux distants sont des terminaux d'utilisateurs, que les paquets de données sont transférés sous forme de micro-flux et que l'on intercepte au sein du réseau certains au moins desdits paquets. La Chambre considère que la différence entre la revendication 1 telle que présentée à l'audience et la revendication 1 selon la requête principale antérieure est d'une complexité modérée de sorte que la Chambre peut décider à son sujet sans que la procédure soit retardée; la requête présentée à l'audience est donc recevable.
2.2 Article 123 (2) CBE
La revendication 1 ajoute à la revendication 1 telle que présentée à l'origine que les terminaux distants sont des terminaux d'utilisateurs, que les paquets de données sont transférés sous forme de micro-flux et que l'on intercepte au sein du réseau certains au moins desdits paquets. Ces modifications sont basées sur page 1, ligne 25 à page 2, ligne 15 et page 9, ligne 1 à 6 de la description telle que présentée à l'origine.
Ces modifications satisfont donc aux exigences de l'article 123 (2) CBE.
3. Activité inventive
3.1 Requête principale
Le document D1 est considéré comme document de l'art antérieur le plus pertinent.
D1 divulgue un réseau multimédia qui comprend, entre autres, un module d'analyse d'application, des modules de détecteurs et un serveur de nom pour applications à temps réel, voir Figure 2. L'application d'analyse fait partie du programme de gestion du réseau qui analyse les informations de densité de trafic interceptées des divers détecteurs et rend les résultats d'analyse comme des paramètres relatifs à la qualité de service et la distribution de qualité de service aux utilisateurs, voir page 78, colonne droite, ligne 4 à 8. Chaque détecteur enregistre les attributs de trafic de données échangées en temps réel à détecter. Les attributs incluent, en autres, les adresses de la source et de la destination de données échangées et les paquets. L'administrateur du réseau choisit le courant de données échangées à détecter et les détecteurs correspondants, et extrait l'information, voir page 78, colonne gauche, ligne 26 à 38. Le courant des données échangées à détecter est identifié par ses adresses de source et de destination dans les diverses couches du réseau qui incluent les adresses IP, le port de transmission, par exemple un UDP-port, et le protocole de transfert en temps réel, par exemple le RTP pour lequel référence est faite au document D6, voir page 78, colonne droite, ligne 27 à 33.
D1 divulgue donc un procédé d'interception des données échangées par des terminaux d'utilisateurs distants, via un réseau de communications, sous forme de paquets formatés selon un premier protocole de transfert de données en temps réel qui comporte une étape dans laquelle on intercepte certains au moins des paquets pendant le transport de manière à déterminer ceux qui sont formatés selon le premier protocole et on communique à une application de contrôle implantée dans le réseau des données représentatives de la partie dupliquée, de sorte qu'elle en déduise des informations sur le transfert. Cet enseignement a été nommé D1B pendant la procédure d'examen.
La communication peut s'effectuer entre un seul émetteur et un seul receveur, c'est-à-dire entre au moins deux terminaux d'utilisateurs distants sous forme de micro-flux, voir figure 3.
Le procédé selon la revendication 1 diffère du procédé divulgué par D1 par le fait que l'interception concerne des paquets formatés selon le protocole contrôle de transfert de données en temps réel et par une étape de duplication d'une partie au moins de chaque paquet formaté selon le protocole de contrôle de transfert des données en temps réel.
Le problème à la base du procédé revendiqué est de pourvoir un procédé par lequel un opérateur peut plus facilement obtenir des informations concernant la qualité de communication en temps réel entre les terminaux distants dans un réseau de communications, voir paragraphe [0003] et [0004] de la demande telle que publiée.
Le document D1 porte sur l'observation de la distribution de qualité de service dans des réseaux multimédia. D1 établie dans l'introduction qu'une exigence importante pour des réseaux multimédia est de pourvoir des garanties de qualité de service. Dans ce contexte, il est important que le gérant du réseau est capable de poursuivre la qualité de service courante, de comparer la qualité de service observée avec les exigences, de détecter une dégradation possible de qualité de service et d'ajuster les ressources du réseau pour achever la qualité de service exigée. Voir page 75, colonne gauche, ligne 1 à 23. La motivation donnée dans le document D1 comprend donc le problème à la base du procédé revendiqué. L'homme du métier consulterait donc document D1.
D1 propose de procéder à base de détecteurs situés dans diverses parties du réseau pour observer la distribution de la qualité de service. Dans ce procédé des informations du trafic sont collectées par des détecteurs qui mesurent le flux dans les différentes parties du réseau. En analysant et rassemblant les informations de ces détecteurs, non seulement la qualité de service bout-à-bout mais aussi la distribution de qualité de service dans les différentes parties du réseau peuvent être déterminées. Voir page 78, colonne gauche, ligne 2 à 9. Le flux en temps réel qui correspond à une application multimédia est identifié par ses adresses de source et de destination, et le protocole de transfert de données en temps réel par exemple RTP. Dans le contexte du protocole RTP D1 fait explicitement référence au document D6. Voir page 78, colonne droite, lignes 20 à 33. Le document D6 est un document de standardisation qui spécifie le protocole RTP et représente donc les connaissances générales de l'homme du métier concernant le protocole RTP.
Selon D6 (voir Abstract) RTP est approprié pour le transport bout-à-bout des données en temps réel, par exemple des données audio, vidéo ou de simulation, par des services de réseau du type multicast ou unicast. Le transport de données est augmenté par un protocole de contrôle RTCP qui permet d'observer la livraison de données de façon à pouvoir être adapté aux exigences de grands réseaux du type multicast.
Le protocole de contrôle RTCP est basé sur la transmission périodique des paquets de contrôle à tous les participants d'une session. De cette façon tout participant peut analyser le paquet de contrôle et évaluer la qualité de la distribution de données. Cette fonction est obligatoire si le protocole RTP est utilisé dans un environnement IP-multicast et recommandé pour tous les environnements. Il est même déconseillé d'utiliser des mécanismes qui ne conviennent qu'aux réseaux du type unicast et qui ne pourraient pas être adaptés aux exigences d'une communication du type multicast. Voir D6, introduction au point 6.
Les paquets de contrôle du protocole RTCP ont un format défini. Ce format comprend des champs d'informations comprenant des informations liées à la qualité du service, par exemple le nombre de paquets perdus. Voir D6, point 6.1 et 6.3. Chaque paquet RTCP peut être traité indépendamment de l'ordre ou de la combinaison des paquets.
Il serait donc évident pour l'homme du métier, qui connait l'enseignement D1B, d'utiliser les champs d'informations de paquets du protocole de contrôle RTCP lié au protocole RTP pour observer la qualité de service dans un transfert de paquets de données en temps réel. Il comprendra en particulier que les paquets de contrôle peuvent être interceptés par chaque détecteur prévu par D1B et situé donc à l'intérieur du réseau, que les champs d'informations liés à la qualité de service peuvent être récupérés, c'est-à-dire dupliqués, et envoyés à l'application d'analyse (analysis application, network manager). Comme les détecteurs se trouvent dans des différentes parties du réseau (different network segments), il est évident que les paquets sont interceptés au sein du réseau.
L'argument de la requérante que le document D6 au point 6 déconseillerait d'utiliser RTCP dans un environnement unicast parce que D6 mentionne que dans un mécanisme de distribution du type IP multicast il est possible pour une entité telle qu'un fournisseur de service de réseau de recevoir des informations de qualité de service et d'agir comme un détecteur tiers partie pour analyser des problèmes de réseau, ne convainc pas la Chambre. La Chambre constate au contraire que D6 au point 6 indique que l'emploi du protocole de contrôle RTCP est obligatoire si le protocole RTP est utilisé dans un environnement IP-multicast et qu'il est recommandé pour tous les environnements. C'est-à-dire D6 n'exclue pas l'application du protocole contrôle RTCP dans un environnement unicast.
La requérante a argumenté que selon D6 le détecteur tiers partie se trouvait hors du réseau. Cet argument ne convainc pas la Chambre, car d'une part D6 ne dit pas que le détecteur tiers partie se trouve hors du réseau, D6 dit uniquement que le détecteur tiers partie n'est pas impliqué dans la session de communication. La Chambre est persuadée qu'un fournisseur de service de réseau fait partie du réseau et se trouve à l'intérieur du réseau.
D'autre part, même si l'on admettait que le détecteur tiers partie de D6 se trouvait hors du réseau, il n'est pas à nier que, selon l'enseignement D1B, on utilise des détecteurs dans différentes parties du réseau, c'est-à-dire à l'intérieur du réseau, pour pourvoir une distribution de qualité de service. L'homme du métier comprendrait qu'à chacun de ces détecteurs le paquet de contrôle RTCP peut être intercepté et les champs d'informations liés à la qualité de service récupérés.
La Chambre ne suit pas l'argument de la requérante que le document D1, ne se référant qu'au protocole RTP dans le contexte de l'enseignement D1B, ne donnait aucune indication au protocole contrôle RTCP, puisque le document D1 se réfère clairement au document D6 (référence 13 du document D1) et que le document D6 divulgue que le transport des données en temps réel sous le protocole RTP est augmenté par le protocole de contrôle RTCP qui permet de contrôler la qualité de service.
En outre, la requérante a argumenté que l'homme du métier déduisait de l'enseignement D1A que les messages selon le protocole RTCP ne convenaient pas à la détection de la distribution de la qualité de service à l'intérieur du réseau, car D1 à la page 77, colonne droite, lignes 22 à 25 concluait qu'en analysant les messages RTCP que pour l'émetteur et le récepteur, seul la qualité de service bout-à-bout ne pouvait être détectée. La Chambre ne suit pas cette ligne d'argumentation, car l'homme du métier comprendrait que, pour obtenir la distribution de la qualité de service à la place de la qualité de service bout-à-bout, il faut modifier l'arrangement des détecteurs utilisés et que le choix du protocole dont les messages sont évalués n'est pas pertinent dans ce contexte. De plus, il n'y a pas de raison pour l'homme du métier de ne pas profiter des avantages qui peuvent être obtenus par l'emploi du protocole RTCP, c'est-à-dire par l'accès aux champs d'informations des paquets RTCP, relatifs à la qualité de service.
L'objet de la revendication 1 n'implique donc pas d'activité inventive.
Les arguments s'appliquent de façon analogue à la revendication 16 qui porte sur un dispositif correspondant au procédé selon la revendication 1.
Requête subsidiaire
La revendication 1 selon la requête subsidiaire ajoute à la revendication 1 selon la requête principale qu'entre une interception et la duplication on effectue une comparaison entre une valeur seuil choisie et la valeur d'un champ d'informations de service contenu dans le paquet de contrôle intercepté, de manière à ne dupliquer que la partie au moins du paquet du contrôle dont le champ d'informations de service présente une valeur sensiblement supérieure à ladite valeur seuil.
Selon la description paragraphe [0029] de la demande telle que publiée, seul si la qualité du service n'est pas acceptable, l'information est remontée jusqu'à l'application du contrôle. Par rapport à la revendication 1 selon la requête principale la revendication 1 selon la requête subsidiaire présente donc une solution au problème de réduire le flux d'information de contrôle dans le réseau.
Le but du procédé est de pourvoir l'opérateur du réseau avec les informations sur la qualité de service délivrée à l'utilisateur dans un échange de données entre deux utilisateurs finaux. Cette information est récupérée des paquets de contrôle interceptés. La Chambre considère que de faire remonter l'information jusqu'à l'application de contrôle seulement si la qualité du service n'est pas acceptable est un choix évident dans la pratique professionnelle de l'homme du métier. En effet, il n'y a que les deux possibilités de faire remonter l'information récupérée de tous les paquets de contrôle et de déterminer à l'application de contrôle les paquets pour lesquels la qualité de service n'est pas acceptable ou déterminer lors de l'interception pour quels paquets de contrôle la qualité de service n'est pas acceptable et de faire remonter seul l'information pour les paquets de contrôle pour lesquels un problème se présente. Comparer la valeur d'un champ d'informations avec une valeur seuil pour déterminer si la valeur du champ d'informations correspond à une valeur exigée fait partie des connaissances de l'homme du métier.
La revendication selon la requête subsidiaire n'implique donc pas d'activité inventive.
Ces arguments s'appliquent de façon analogue au dispositif selon la revendication 16 qui correspond au procédé selon la revendication 1.
DISPOSITIF
Par ces motifs, il est statué comme suit :
Le recours est rejeté.
