Commissioner’s Decision #1341
Décision du Commissaire #1341
TOPIC: J00, J70, O00
SUJET : J00, J70, O00
Application No. : 2,222,229
Demande no : 2,222,229
RÉSUMÉ DE LA DÉCISION DU COMMISSAIRE
D.C . 1341 Demande 2,222,229
Évidence, objet brevetable
L’examinateur a rejeté la demande pour cause d’évidence et au motif qu’elle vise un objet non brevetable.
Le Commissaire aux brevets a refusé la demande.
BUREAU CANADIEN DES BREVETS
DÉCISION DU COMMISSAIRE AUX BREVETS
La demande de brevet n̊ 2,222,229 a été rejetée par l’examinateur conformément au paragraphe 30(3) des Règles sur les brevets. La Commission d’appel des brevets et le commissaire aux brevets se sont penchés sur la décision de l’examinateur de rejeter la demande. Voici les conclusions de la Commission et la décision du commissaire :
Agent du demandeur
MARKS & CLERK
Suite 1800
280 Slater Street
OTTAWA (Ontario)
K1P 1C2
INTRODUCTION
La présente décision porte sur la révision, par le commissaire aux brevets, de la décision finale de l’examinateur concernant la demande de brevet n° 2,222,229 intitulée « SYST ME ÉLECTRONIQUE RÉPARTI D’EXÉCUTION DE TRANSACTIONS COMMERCIALES ET MÉTHODE UTILISÉE PAR CE SYST ME ». Le demandeur actuel est RPX Corporation, et l’inventeur est James McKanna Gregory. La demande a été déposée et une requ te d’examen a été reçue le 25 novembre 1997. La demande revendique la priorité sur une demande américaine déposée le 15 janvier 1997.
Suivant quatre rapports d’examinateur, l’examinateur saisi a rendu une décision finale, le 20 novembre 2006, qui rejetait la demande, pour cause qui était fondée d’évidence et d’objet non brevetable. Le demandeur a présenté des arguments en réponse la décision finale, le 22 mai 2007.
Apr s la décision finale, le 6 novembre 2008, la Cour supr me du Canada a rendu sa décision dans l’affaire Sanofi-Synthelabo Canada Inc. c. Apotex Inc. 2008 SCC 61 [Sanofi] qui préconisait de suivre une démarche quatre volets pour évaluer le caract re évident d’une revendication.
Également apr s la décision finale, le 5 mars 2009, la commissaire a énoncé une approche suivre pour évaluer un objet brevetable en vertu de l’article 2 de la Loi sur les brevets, compte tenu de la décision dans l’affaire Demande 2,246,933 d’Amazon.com Inc. (2009) D.C. 1290 [D.C. 1290].
Dans une lettre datée du 29 mai 2009, le demandeur s’est vu offrir la possibilité d’argumenter, par écrit et/ou lors d’une audience, le caract re évident la lumi re de l’arr t Sanofi et d’apr s l’article 2, selon l’approche énoncée dans D.C. 1290. La lettre était accompagnée d’un résumé des motifs présentés par l’examinateur qui clarifiait les détails du rejet de la demande fondé sur la non-conformité aux articles 28.3 et 2 de la Loi sur les brevets. En réponse la lettre, le demandeur a présenté des observations écrites, le 28 ao t 2009.
Dans une lettre datée du 19 janvier 2010, le demandeur déclinait l’offre de comparaître une audience et demandait qu’une décision sans audience soit rendue, fondée sur les observations écrites.
Le 20 avril 2010, la demande a été attribuée d’AT&T Intellectual Property II, L.P. au demandeur actuel, RPX Corporation.
Le 24 novembre 2011, la Cour d’appel fédérale dans l’arr t Canada (Procureur général) c. Amazon.com Inc., 2011 CAF 328 [Amazon CAF], a prononcé un jugement concernant l’objet brevetable qui était en désaccord avec l’approche présentée dans C.D. 1290.
Dans une lettre datée du 31 ao t 2012, la Commission a offert au demandeur la possibilité de dire si, selon lui, l’objet des revendications de la présente demande est brevetable ou non la lumi re du projet de procédure administrative qui a été élaboré et a fait l’objet de consultations apr s l’arr t Amazon, CAF. Dans cette lettre, la Commission indiquait aussi une nouvelle référence qu’elle estimait pertinente pour déterminer les connaissances générales courantes d’une personne versée dans l’art. La Commission faisait également des observations concernant la clarté du mémoire descriptif. Le demandeur s’est vu offrir la possibilité de répondre toutes les questions soulevées par la Commission, par écrit et/ou lors d’une audience. Dans une lettre datée du 14 novembre 2012, le demandeur a refusé de présenter d’autres observations.
CONTEXTE
La présente demande expose un syst me et une méthode de commerce électronique qui séparent les informations détaillées consignées par les marchands de la fonctionnalité transactionnelle, au moyen de serveurs distincts. Un serveur de transactions est relié, au moyen d’un réseau, un ou plusieurs serveurs marchands. Le serveur de transactions fournit aux clients des résumés des informations sur les marchands inscrits et les produits qu'ils proposent. Les clients qui souhaitent obtenir des informations plus détaillées sur un produit précis, offert par un marchand spécifique, peuvent accéder directement au serveur marchand correspondant, partir du serveur de transactions. Lorsque le client choisit un article acheter sur le site du marchand, une demande d’achat est transmise du serveur marchand au serveur de transactions qui traite la transaction d’achat de l’article sélectionné.
Le demandeur soutient que, traditionnellement, les marchands avaient le choix entre deux possibilités, savoir, utiliser leur propre serveur commercial ou acheter des services de commerce électronique aupr s d’un fournisseur de ces services. La premi re option entraînait, pour les marchands, l’obligation de gérer des serveurs complexes et co teux qui fournissaient la fois une fonctionnalité transactionnelle et de contenu. Dans la deuxi me option, en s’en remettant au fournisseur, le marchand ne maîtrisait plus la mani re dont se traitent les affaires et dont les informations sont présentées; quant au fournisseur, il était tenu d’offrir un service de commerce électronique qui répond aux diverses exigences de chaque marchand (pages 1 3 de la présente demande).
Afin de permettre aux marchands et aux fournisseurs de surmonter le probl me que représente la gestion d’un serveur commercial complexe qui [TRADUCTION] « fournit dans une large mesure toute la fonctionnalité indispensable pour effectuer la vente et l’achat sur un réseau » (page 2, lignes 4 6 de la présente demande), la présente demande offre une solution qui comprend la répartition de la fonctionnalité de commerce électronique entre plusieurs serveurs. Le demandeur propose qu’en séparant, entre serveurs distincts, la fonctionnalité transactionnelle et les informations consignées par les marchands, les marchands et les fournisseurs puissent se consacrer offrir des services dans leurs domaines de compétence respectifs, et éviter ainsi la gestion de serveurs de commerce électronique complexes.
Une représentation de l’invention proposée est illustrée la figure 2 de la présente demande. Les serveurs de contenu (22), sous le contrôle des marchands, fournissent des informations détaillées sur les marchands et les produits qu’ils offrent. Le serveur de transactions (23) (ou serveur commercial) est sous le contrôle d’un fournisseur de services et il fournit une fonctionnalité transactionnelle ainsi que l’acc s aux résumés des informations consignées par les marchands (24) relatifs aux produits offerts au moyen du syst me électronique d’exécution de transactions commerciales. Grâce un outil de recherche de contenu, le serveur de transactions permet au client (25) d’effectuer une recherche dans les résumés des informations consignées par les marchands afin de trouver un marchand et le produit qu’il désire acheter. Dans le résumé des informations consignées par le marchand que lit le client figure un lien (adresse URL ou réseau - page 17, lignes 2 9 de la présente demande) au site Web du marchand que le client peut visiter pour obtenir des renseignements plus détaillés sur un produit spécifique offert par ce marchand. Lorsque le client a choisi le produit qu’il va acheter sur le site du marchand auquel il a accédé, une demande d’achat est transmise du serveur marchand au serveur de transactions (la description sugg re que cette opération s'effectue en cliquant sur un bouton « Make Purchases » [Faire des achats]- page 18, lignes 3 6 de la présente demande). Le serveur de transactions exécute la transaction en extrayant les informations nécessaires de sa propre base de données commerciales et en interagissant avec les syst mes de paiement externes comme les banques. Le serveur de transactions peut produire des rapports pour le client et le marchand partir d’un historique des données liées aux transactions.
REVENDICATIONS
Le dernier ensemble de revendications, daté du 25 novembre 2004, compte 15 revendications. Trois revendications indépendantes portent sur un procédé, un serveur de transactions et un syst me de commerce électronique.
La revendication 1 se lit comme suit :
[TRADUCTION]
1. Un procédé d’exécution de transactions commerciales électroniques dans un serveur de transactions contenant les résumés des informations consignées par les marchands, connecté sur un réseau à un serveur marchand, ledit procédé comprenant les étapes consistant à :
rechercher des informations commerciales générales dans les résumés des informations consignées par les marchands, en fonction de la demande de renseignements reçue;
afficher les résultats de la recherche;
renvoyer aux informations détaillées consignées par les marchands, stockées dans le serveur marchand;
recevoir la demande d’achat transmise par le serveur marchand pour le produit choisi, et
traiter la demande d’achat pour créer une transaction d’achat.
Les revendications dépendantes 2 9 précisent les restrictions relatives au traitement des demandes d’achat, au stockage dans une base de données et l’extraction des dossiers de transaction et des informations sur les paiements, et la création de rapports de transactions.
La revendication 10 se lit comme suit :
[TRADUCTION]
10. Un serveur de transactions dans un système électronique d’exécution de transactions commerciales, ledit serveur de transactions est relié, par un réseau, à un serveur marchand contenant des informations détaillées sur les produits, le serveur de transactions comprenant :
un outil de recherche de contenu pour permettre au client d’explorer les résumés des informations consignées par les marchands sur tous les produits disponibles par le biais du système de commerce électronique;
un processeur de transactions pour accepter et traiter les demandes de transaction émises par les clients et transmises par le serveur marchand, et
une base de données où sont stockées les résumés des informations consignées par au moins un marchand inscrit, le résumé des informations consignées par un marchand incluant une référence aux informations détaillées stockées sur le serveur marchand, la référence étant fournie en fonction du résultat d’une recherche.
Les revendications dépendantes 11 et 12 précisent les restrictions relatives au processeur de transactions et une interface marchand utilisée pour modifier les résumés des informations consignées par les marchands.
La revendication 13 se lit comme suit :
[TRADUCTION]
13. Un système de commerce électronique pour l’exécution de transactions électroniques sur un réseau, entre un client et au moins un marchand inscrit, ledit système de commerce électronique comprenant :
un serveur de transactions pour le traitement des transactions électronique comprenant :
un processeur de transactions pour accepter et exécuter les demandes de transaction émises par les clients;
une base de données où sont stockées les résumés des informations consignées par au moins un marchand inscrit;
un outil de recherche de contenu pour permettre au client d’explorer les résumés des informations consignées par les marchands sur tous les produits disponibles par le biais du système de commerce électronique, et
au moins un serveur marchand relié au serveur de transactions sur le réseau, ledit serveur marchand ayant une base de données pour le stockage des informations détaillées sur les produits et les marchands;
où le serveur marchand transmet au processeur de transactions les demandes de transaction émises par les clients.
Les revendications dépendantes 14 et 15 précisent les restrictions relatives au processeur de transactions et une interface marchand utilisée pour modifier les résumés des informations consignées par les marchands.
QUESTIONS EN LITIGE
La Commission doit trancher les questions suivantes :
1 Les revendications 1 à 15 sont-elles évidentes sur le fondement de l’article 28.3 de la Loi sur les brevets?
2 Les revendications 1 à 15 visent-elles un objet non brevetable au sens de l’article 2 de la Loi sur les brevets?
RÉFÉRENCES
Documents cités dans la décision finale
Les références suivantes sont citées dans la décision finale :
D1 : Site Internet www.amazon.com, 1996
D2 : Publication de CNET « PSINet joins commercial trend », 9 octobre 1996 (référence tirée de http://news.cnet.com/2100-1017-236324.html)
D3 : Demande internationale PCT n̊ 95/16971 (Gifford), publiée le 22 juin 1995
D4 : Brevet américain n̊ 5 557 518 (Rosen), publié le 17 septembre 1996
Document présenté par la Commission
Dans une lettre datée du 31 ao t 2012, la Commission présentait le document ci-dessous qu’elle estimait pertinent pour déterminer les connaissances générales courantes d’une personne versée dans l’art.
D5 : Arthur M. Keller, « Smart Catalogs and Virtual Catalogs » dans International Conference on Frontiers of Electronic Commerce, octobre 1995; une version antérieure est parue dans USENIX Workshop on Electronic Commerce, juillet 1995.
La référence D5 peut tre obtenue sur : http://infolab.stanford.edu/pub/keller/keller-papers.html
APERÇU DES RÉFÉRENCES
Concernant la référence D1, la Commission remarque qu’il n’est pas possible actuellement d’utiliser ou de vérifier la fonctionnalité du site Web tel qu’il existait en 1996. Par conséquent, dans notre analyse des antériorités, D1 ne sera pas évaluée en tant que référence citée.
Avant d’examiner les questions portant sur l’objet et l’évidence, il convient de se pencher sur chacune des références D2 D5.
Enseignements de la référence D2
La référence D2 décrit PSINet, un fournisseur de services Internet offrant aux entreprises un service de commerce électronique qui leur permet de vendre leurs produits sur Internet en utilisant un hébergeur Web appelé PSIWeb. PSIWeb ajoute des services en arri re-plan puisqu’il a déj le matériel nécessaire pour l’exécution des transactions de commerce électronique. L’article mentionne ce qui suit :
[TRADUCTION]
La fonctionnalité eCommerce de PSIWeb crée intègre et gère des vitrines virtuelles pour les marchands qui souhaitent faire du commerce sur Internet sans investir massivement dans le matériel et les communications. Les marchands ont le contrôle du contenu et de l’administration de leur vitrine.
Le service intègre le système de paiement sécurisé de CyberCash pour le traitement des transactions par carte de crédit et la technologie de magasin virtuel SoftCart de Mercantec.
Le système de paiement CyberCash inclut un « porte-monnaie » électronique pour les clients, une « caisse enregistreuse » électronique pour les marchands et un service de passerelle relié aux réseaux bancaires existants pour exécuter les transactions.
SoftCart permet aux développeurs de créer un environnement de magasinage complet, consultable en ligne et permettant de payer les achats au moyen de méthodes de paiement sûres comme CyberCash. SoftCart tient un registre des achats, crée les factures, calcule les frais d’expédition et les taxes de vente et transmet les commandes terminées directement aux systèmes comptables.
Enseignements de la référence D3
La référence D3 présente un syst me d’achat de produits (marchandises ou informations) au moyen d’un réseau informatique.
Un objectif principal énoncé dans la référence D3 est de [TRADUCTION] « fournir un syst me de vente sur réseau informatique, interactif pour l’utilisateur, dans lequel l’utilisateur peut utiliser librement le marchand de son choix et payer au moyen des instruments financiers existants (page 2, lignes 16 19 de D3). La référence D3 mentionne que [TRADUCTION] « actuellement, il n’existe pas de mécanisme de paiement indépendant du marchand pour les réseaux informatiques qui permette l’utilisateur d’utiliser des instruments financiers conventionnels comme les cartes de crédit, les cartes de débit et exige des avoirs en compte » (page 1, lignes 26 30 de D3). La référence D3 affirme que dans les syst mes antérieurs, l’utilisateur devait [TRADUCTION] « créer d’abord un compte avec chaque marchand pour pouvoir utiliser le marchand » (page 2, lignes 8 et 9 de D3).
Dans le syst me de vente sur réseau informatique décrit dans la référence D3, un utilisateur (client), partir d’un ordinateur acheteur, envoie un ordinateur vendeur une requ te d’utilisateur concernant une annonce. L’ordinateur vendeur extrait l’annonce et l’envoie l’ordinateur acheteur o elle s’affiche. Si l’utilisateur désire acheter le produit décrit par l’annonce, une demande d’achat est alors transmise de l’ordinateur acheteur l’ordinateur vendeur qui envoie ensuite un ordre de paiement un ordinateur de paiement pour obtenir l’autorisation (figure 6 de D3). Dans un autre mod le, l’ordinateur acheteur envoie l’ordre de paiement l’ordinateur vendeur pour qu’il le transf re l’ordinateur de paiement. Dans un autre mod le encore, l’ordre de paiement est transmis directement de l’ordinateur acheteur l’ordinateur de paiement (figure 12 de la référence D3). L’ordinateur de paiement interagit avec les syst mes financiers en temps réel pour obtenir l'autorisation (figures 13 et 14 de la référence D3). Si l’autorisation est émise, le marchand prépare la livraison du produit.
Enseignements de la référence D4
La référence D4 présente un syst me de commerce électronique ouvert qui permet aux clients d’acheter des produits ou des services électroniques aupr s de marchands, sur demande et de façon s re et anonyme.
Le syst me comprend un agent de confiance du marchand (ACM) capable d’établir une session sécurisée par cryptographie avec un agent de confiance du client (ACC). Le syst me comprend également un premier module de paiement qui est capable de communiquer en toute sécurité avec l'ACC, et un deuxi me module de paiement qui est capable de communiquer en toute sécurité avec l’ACM et d’établir une session sécurisée par cryptographie avec le premier module de paiement. La marchandise électronique est transférée de l’ACM l’ACC, mais elle est retenue provisoirement et ne peut tre utilisée tant que le paiement n’est pas effectué. Pour effectuer le paiement, l’ACC fournit la premi re information de paiement au premier module de paiement, l’ACM fournit la deuxi me information de paiement au deuxi me module de paiement, et un montant d’argent électronique correspondant la premi re et la deuxi me information de paiement est transféré du premier module de paiement au deuxi me module de paiement. La marchandise électronique n’est plus retenue provisoirement et devient accessible d s que le premier module de paiement informe l’ACC que l’argent a été transféré avec succ s et que le deuxi me module de paiement informe l’ACM que l’argent a été reçu avec succ s.
Enseignements de la référence D5
La référence D5 présente des catalogues électroniques, en particulier des catalogues virtuels qui récup rent de façon dynamique des informations provenant de plusieurs catalogues intelligents et présentent les données sur les produits de mani re homog ne. La partie 4, intitulée Virtual Catalogs [Catalogues virtuels], présente un scénario dans lequel un détaillant ou un distributeur qui vend les produits de plusieurs fabricants souhaite que les clients aient acc s aux caractéristiques détaillées des produits. Plutôt que de reproduire toutes les informations sur les produits de chaque fabricant dans son propre catalogue et d’en assumer le stockage et le co t considérables, la référence D5 sugg re que [TRADUCTION] « l’approche classique utilisant le WWW consiste, pour le détaillant, fournir un hyperlien au catalogue de chaque fabricant afin que le client puisse obtenir les caractéristiques détaillées des produits ». La référence D5 poursuit en énumérant les probl mes reliés la méthode des hyperliens :
[TRADUCTION]
Il existe plusieurs problèmes reliés à la méthode des hyperliens. Premièrement, le client risque de « se perdre » dans l’espace Web du fabricant et de ne plus savoir comment revenir au site du détaillant. Deuxièmement, le fabricant ne connaît pas le contexte des interactions du client avec le détaillant. Troisièmement, le client peut arriver sur une page « Comment commander » fournie par le fabricant, et passer une commande auprès de quelqu’un qui n’est pas le détaillant initial. Quatrièmement, si le client revient au détaillant initial à l’aide du bouton « Retour », il ne conserve aucune information obtenue sur le site du fabricant, comme la configuration du produit désiré. Cinquièmement, si le client revient au détaillant par la page « Comment commander » du fabricant, le détaillant ne connaît pas le contexte initial de l’interaction avec le client (p. ex. les autres produits sélectionnés pour une commande dans cette même session).
La référence D5 propose de régler ces probl mes en utilisant des catalogues virtuels qui permettent aux détaillants de récupérer de façon dynamique les informations provenant des catalogues des fabricants la suite d’une requ te de client.
ÉVIDENCE
Principes juridiques - Évidence
Comme il a été mentionné au paragraphe [3], apr s la décision finale, la Cour supr me du Canada a rendu sa décision dans l’arr t Sanofi, dans lequel la Cour préconisait la démarche suivre pour évaluer le caract re évident :
(1) (a) Déterminer qui est cette personne fictive « versée dans son art » :
(b) Déterminer quelles sont les connaissances générales courantes pertinentes de cette personne;
(2) Définir le concept inventif de la revendication en cause, au besoin par voie d’interprétation;
(3) Recenser les différences, s’il en est, entre ce qui ferait partie de « l’état de la technique » et le concept inventif qui sous-tend la revendication ou son interprétation;
(4) Abstraction faite de toute connaissance de l’invention revendiquée, ces différences constituent-elles des étapes évidentes pour la personne versée dans l’art ou dénotent-elles quelque inventivité?
Comme il a été mentionné au paragraphe [5], notre lettre datée du 29 mai 2009 offrait au demandeur la possibilité de présenter des observations la lumi re de l’arr t Sanofi.
Références citées
L’examinateur a cité la référence D2 la lumi re des connaissances générales courantes relatives la technique du commerce électronique présentées dans les références D3 ou D4.
Dans notre lettre datée du 31 ao t 2012, le demandeur a été informé de l’évidence supplémentaire des connaissances générales courantes (voir D5).
Analyse – Les revendications 1 à 15 sont-elles évidentes?
(1)(a) Déterminer qui est cette personne fictive « versée dans son art »
Dans le résumé des motifs, l’examinateur définit la ou les personnes versées dans l’art comme étant [TRADUCTION] « compétentes dans les domaines du commerce électronique, du marketing et des ventes ainsi qu’en programmation informatique ». En réponse, le demandeur observe que la personne versée dans l’art [TRADUCTION] « connaîtrait la programmation informatique pour les applications Web » et que « la personne compétente en marketing et en ventes ne serait pas forcément compétente en commerce électronique et en programmation informatique, et inversement ».
La Commission mentionne que le technicien fictif versé dans l’art peut prendre la forme d’une équipe de scientifiques, de chercheurs et de techniciens dont les connaissances combinées se rapportent l’invention en cause (Lundbeck Canada Inc. c. Ministre de la Santé, 2009 CF 146). En conséquence, la Commission est d’accord avec la description de l’examinateur en ce qui concerne une personne versée dans l’art.
(1)(b) Déterminer quelles sont les connaissances générales courantes pertinentes de cette personne
Concernant les connaissances générales courantes, l’examinateur indique que [TRADUCTION] « la personne versée dans l’art comprend ce qu’est le commerce électronique, y compris les concepts de demandes d’achat entre les entités pour l’exécution d’une transaction électronique. La personne versée dans l’art connaît bien aussi les techniques de programmation informatique, y compris la conception modulaire permettant de séparer des fonctionnalités différentes ». En réponse, le demandeur n’est pas d’accord, mais il précise que [TRADUCTION] « la mesure dans laquelle la personne versée dans l’art connaît la conception modulaire pour séparer des fonctionnalités différentes dépend du degré d’utilisation de cette conception modulaire en commerce électronique et applications Web la date de la revendication de cette demande ».
La Commission consid re qu’un programmateur informatique versé dans son art connaît un grand nombre de techniques de programmation, et leurs domaines d'application possibles, comme l’usage courant de la conception modulaire pour la division de la fonctionnalité. Nous répétons que la personne versée dans l’art est une équipe qui connaît la programmation informatique et le commerce électronique. Par conséquent, la Commission est d’accord avec la description de l’examinateur en ce qui concerne les connaissances générales courantes de la personne versée dans l’art.
La présente demande montre qu’avec les méthodes courantes de commerce électronique, les marchands peuvent acheter des services aupr s de fournisseurs qui poss dent des compétences en exploitation du matériel et des logiciels de commerce électronique et qu’ils sont également tenus d’acquérir, de publier et de maintenir le contenu des marchands (pages 1 3 de la présente demande). En conséquence, la Commission note que la capacité d’un serveur de transactions de maintenir et de présenter des informations consultables consignées par les marchands, en plus de sa capacité traditionnelle de traiter une demande d’achat pour créer une transaction d’achat (comme le font les serveurs de commerce électronique), est considérée comme faisant également partie des connaissances générales courantes.
Compte tenu de la référence D5, la Commission ajoute que la personne versée dans l’art connaît aussi ce qui était décrit en 1995 comme « l’approche classique » consistant fournir un hyperlien au catalogue de chaque fabricant afin que le client puisse avoir acc s aux caractéristiques détaillées des produits lorsqu’il consulte le site du détaillant. Le demandeur a choisi de ne pas présenter d’observations en réponse notre lettre datée du 31 ao t 2012 qui indiquait D5 comme une référence de connaissances générales courantes et invitait le demandeur prendre en considération la partie 4 du document qui traite précisément de la méthode des hyperliens. Nous estimons que cette absence de commentaires signifie que le demandeur accepte notre évaluation de la référence D5 comme étant pertinente pour établir les connaissances générales courantes du métier avant la date de la revendication.
(2) Définir le concept inventif de la revendication en cause, au besoin par voie d’interprétation
Le résumé des motifs décrit un seul concept inventif commun toutes les revendications de la mani re suivante :
[TRADUCTION]
Le concept inventif concerne la séparation de la fonctionnalité transactionnelle des informations consignées par les marchands en renvoyant (à partir d’un serveur de transactions) à des informations détaillées consignées par les marchands et stockées dans le serveur marchand, et la réception des demandes d’achat transmises par le serveur marchand sur le serveur de transactions.
En réponse, le demandeur ne décrit pas un concept inventif, mais plutôt des commentaires sur les avantages proposés de l’invention et ses caractéristiques. Ayant examiné la réponse du demandeur, la Commission consid re que ces avantages sont implicites ou représentés dans la description du concept inventif fournie par l’examinateur. Ainsi, l’évaluation de l’ingéniosité selon l’étape 4 tient compte de ces avantages.
En déterminant si le concept inventif décrit par l’examinateur est pertinent, la Commission vérifie d’abord s’il refl te adéquatement le probl me pratique que l’invention vise résoudre, et sa solution. Cela est conforme la pratique administrative sur le caract re évident, datée du 2 novembre 2009, qui note que le paragraphe 80(1) des R gles sur les brevets précise que « la description doit contenir [...] une description de l’invention en des termes permettant la compréhension du probl me technique [...], et de sa solution ».
Bien que la réponse du demandeur ne fournisse pas d’explication du concept inventif, elle indique un passage précis dans la description de la présente demande qui est utile pour définir le concept inventif. Le passage décrit ce que le demandeur consid re comme étant la faille ou le probl me des antériorités et que la présente demande promet de surmonter ou de résoudre :
[TRADUCTION]
Ainsi, selon les méthodes actuelles utilisées en commerce électronique, le marchand, dont l’expertise réside dans la production et la gestion de contenu, a le choix entre exploiter et maintenir un serveur commercial coûteux ou laisser le contrôle de son marketing à un fournisseur. Le fournisseur, dont l’expertise réside dans l’acquisition et la maintenance de matériel et de logiciels de commerce électronique, doit porter le fardeau de l’acquisition, de la publication et de la maintenance du contenu du marchand. (Page 3, lignes 18 à 26 de la présente demande)
Le demandeur sugg re que [TRADUCTION] « la meilleure façon de faire du commerce électronique est de laisser au marchand l’essentiel de la tâche d’acquisition et de maintenance du contenu, et de laisser au fournisseur de services l’essentiel de la tâche de fournir la fonctionnalité transactionnelle pour le commerce électronique » (page 3, ligne 29 - page 4, ligne 2 de la présente demande). Le demandeur y parvient en fournissant [TRADUCTION] « un syst me de commerce électronique pour l’exécution de transactions électroniques sur un réseau o la fonctionnalité transactionnelle est assurée par un serveur commercial contenant une base de données commerciales, tandis que le contenu détaillé consigné par les marchands est fourni dans des serveurs distincts réservés au contenu consigné par les marchands » (page 4, lignes 4 9 de la présente demande).
Selon les considérations du demandeur sur les failles existant dans les antériorités, savoir l’obligation pour le marchand et pour le fournisseur d’offrir une fonctionnalité hors de leurs domaines de compétence, le probl me pratique visé par les revendications est en relation avec la façon de surmonter les complexités liées l’utilisation d’un seul serveur qui assure toute la fonctionnalité de commerce électronique. La solution revendiquée comprend la répartition de la fonctionnalité de commerce électronique entre plusieurs serveurs en renvoyant, partir d’un serveur de transactions, un serveur marchand offrant des informations détaillées consignées par les marchands, et en transmettant la demande d’achat du serveur marchand au serveur de transactions afin qu’elle soit traitée. La Commission consid re donc que la description de l’examinateur en ce qui concerne le concept inventif est exacte et peut tre reformulée ainsi :
[TRADUCTION]
Une méthode pour faire du commerce électronique consistant à : (i) renvoyer, à partir d’un serveur de transactions, aux informations détaillées consignées par le marchand sur le serveur marchand; et (ii) recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée.
La Commission a examiné les revendications 1 15, lesquelles, en plus de décrire le concept inventif, précisent les restrictions relatives au traitement des demandes d’achat, la création des rapports et la modification des résumés d’informations. Nous estimons que toutes les revendications portent sur le m me concept inventif puisque ces restrictions supplémentaires ne changent rien au concept inventif. Notre conclusion rejoint les observations du demandeur qui ne font pas valoir d’autres caractéristiques distinctives ou originales. En conséquence, nous adoptons le concept inventif tel qu’il est décrit au paragraphe [50] ci-dessus, pour évaluer le caract re évident de toutes les revendications.
(3) Recenser les différences, s’il en est, entre ce qui ferait partie de « l’état de la technique » et le concept inventif qui sous-tend la revendication ou son interprétation
La référence D2 refl te l’état de la technique. Les références D3, D4 et D5 refl tent les connaissances générales courantes. Pour la clarté de l’analyse, les références D3 et D4 sont évaluées selon l'étape 3, et la référence D5 est évaluée selon l’étape 4.
Ayant examiné les documents cités, la Commission a recensé des différences entre l’état de la technique et le concept inventif. Pour les raisons énoncées ci-apr s, nous estimons que les références D2 D4 n’enseignent pas la façon de : (i) renvoyer, partir d’un serveur de transactions, aux informations détaillées consignées par le marchand sur le serveur marchand; et (ii) recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée.
(i) Renvoyer, à partir d’un serveur de transactions, aux informations détaillées consignées par les marchands et stockées sur un serveur marchand
La décision finale admet que la référence D2 « ne montre pas que le serveur de transactions fournit un lien des informations plus détaillées sur le site Web du marchand ».
La référence D2 indique que « la fonctionnalité eCommerce de PSIWeb crée, int gre et g re des vitrines virtuelles pour les marchands qui souhaitent faire du commerce sur Internet [...] Les marchands ont le contrôle du contenu et de l’administration de leur vitrine ». La fonctionnalité eCommerce de PSIWeb permet au marchand d’avoir le contrôle de sa vitrine, mais il n’est pas dit clairement que le contenu du serveur marchand est en effet accessible par l’entremise d’un serveur de transactions. En tentant de confirmer ce point, la Commission a découvert un article concernant PSINet qui cite une source (Eric Paulak, analyste de recherche chez Gartner Group, Inc.) faisant observer que l’offre de PSSINet [TRADUCTION] « est bonne pour les achats en ligne par catalogue. Mais si vous avez besoin d’explorer la base de données d’un marchand, vous ne pouvez le faire » (Wexler, Joanie. « PSINet takes E-commerce plunge. » Network World 13.41 (1996) : 8.). Pour la Commission, cela signifie que la fonctionnalité eCommerce de PSIWeb ne permet pas l’utilisateur d’accéder au serveur marchand et son contenu. Par conséquent, la référence D2 ne décrit pas un serveur de transactions qui renvoie des informations détaillées consignées par le marchand sur un serveur marchand.
(ii) Recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée
La référence D2 ne décrit pas un serveur de transactions capable de recevoir les demandes d’achat transmises par un ou plusieurs serveurs marchands puisque, comme le démontrent les paragraphes [54-55] ci-dessus, elle ne montre pas un serveur de transactions qui renvoie un ou plusieurs serveurs marchands. De plus, la décision finale reconnaît que la référence D2 n’indique pas « recevoir une demande d’achat et traiter la demande d’achat pour créer une transaction d’achat ».
L’examinateur s’appuie sur les références D3 et D4 pour démontrer que la transmission des demandes d’achats fait partie des connaissances générales courantes. La décision finale FA énonce que m me si la référence D2 n’indique pas précisément « recevoir une demande d’achat et traiter la demande d’achat pour créer une transaction d'achat », il s’agit néanmoins d’étapes couramment pratiquées en commerce électronique comme le montrent les références D3 ou D4.
Les syst mes décrits dans D3 et D4 ne fonctionnent pas comme le syst me faisant l’objet de la présente demande. Selon le syst me de la présente demande, l’utilisateur acc de directement au serveur de transactions, se connecte au serveur marchand par l’entremise du serveur de transactions pour obtenir des informations détaillées sur un produit souhaité, puis revient au serveur de transactions avec une demande d’achat qui est traitée aussitôt que le choix du produit est effectué.
Dans le syst me décrit dans la référence D3, l’utilisateur n’acc de pas l’ordinateur vendeur par l’entremise d’un serveur de transactions, mais par un ordinateur acheteur, et il extrait l’information consignée par le marchand directement de l’ordinateur vendeur. Sur la base des informations extraites, soit l’utilisateur envoie une demande d’achat pour le produit souhaité l’ordinateur vendeur qui crée alors un ordre de paiement et l’envoie un ordinateur de paiement, soit l’utilisateur compose l’ordre de paiement effectif sur l’ordinateur acheteur et l’envoie l’ordinateur vendeur qui le transmet l’ordinateur de paiement. L’ordre de paiement composé peut aussi tre envoyé directement de l’ordinateur acheteur l’ordinateur de paiement. L’ordinateur de paiement a pour objet d’effectuer l’autorisation des ordres de paiement.
Dans le syst me décrit dans la référence D4, un élément nommé « Buyer Transaction Application (BTA) » [application de transaction d’acheteur] relie l’utilisateur au serveur marchand afin de parcourir les marchandises du vendeur et d’effectuer une sélection. Lorsque l’utilisateur choisit un produit acheter, la BTA envoie l’identité du produit désiré au serveur marchand, et un message l’agent de confiance du client, accompagné des instructions pour acheter le produit identifié. Du côté du marchand, un message est envoyé du serveur marchand l’agent de confiance du marchand, accompagné des instructions pour vendre le produit identifié. Les agents de confiance communiquent ensemble et avec leurs modules de paiement respectifs pour effectuer le transfert de la marchandise et du paiement.
Puisque le but de la présente demande est d’exposer un syst me qui sépare la fonctionnalité transactionnelle des informations détaillées au moyen de serveurs distincts, pour évaluer comment la division de la fonctionnalité est réalisée dans la technique citée, il convient de déterminer quelle unité transmet la demande d’achat, quelle unité reçoit et traite la demande d’achat et comment le flux de contrôle s’effectue entre elles. Bien que les références D3 et D4 démontrent que la transmission des demandes d’achat électroniques est déj connue, la Commission est d’accord avec le demandeur sur le fait que ni D2, D3 ou D4 ne rév le la transmission d’une demande d’achat d’un ordinateur vendeur au m me serveur de transactions qui a renvoyé ou relié le client l’ordinateur vendeur.
(4) Abstraction faite de toute connaissance de l’invention revendiquée, ces différences constituent-elles des étapes évidentes pour la personne versée dans l’art ou dénotent-elles quelque inventivité?
Comme il est mentionné l’étape 3, les références D2 D4 n’enseignent pas la façon de : (i) renvoyer, partir d’un serveur de transactions, aux informations détaillées consignées par le marchand sur le serveur marchand; et (ii) recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée. La question est donc de savoir si ces étapes dénotent ou non quelque inventivité.
(i) Renvoyer, à partir d’un serveur de transactions, aux informations détaillées consignées par les marchands et stockées sur un serveur marchand
La référence D5, qui représente les connaissances générales courantes avant la date de la réclamation, énonce précisément que « l’approche classique utilisant le WWW consiste, pour le détaillant, fournir un hyperlien au catalogue de chaque fabricant afin que le client puisse obtenir les caractéristiques détaillées des produits ».La référence D5 reconnaît qu’un serveur de transactions qui renvoie des informations détaillées consignées par le marchand sur un serveur marchand fait partie des connaissances générales courantes.
(ii) Recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée
La réponse du demandeur au résumé des motifs indique qu’il importe que [TRADUCTION] « la transaction proprement dite soit effectuée par le serveur de transactions qui a initialement renvoyé le client au marchand ». Sinon, [TRADUCTION] « les transactions générées par le serveur de transactions pourraient tre renvoyées n’importe o par le serveur marchand pour tre traitées, annulant tout bénéfice pour l’opérateur du serveur de transactions » (page 3 des observations du demandeur, 28 ao t 2009). De m me, la référence D5 reconnaît qu’une fois que le client a visité le catalogue du fabricant, il faut le ramener au m me détaillant (serveur de transactions) qui a initialement mis le client en relation avec le fabricant (serveur marchand), sans doute pour que le détaillant réalise la vente, et bénéficie ainsi du fait d'avoir engagé le client et effectué le renvoi. La référence D5 sugg re qu’il est difficile d'y parvenir en raison des probl mes inhérents la méthode des hyperliens, nommément : 1) le client risque de se perdre dans le site du fabricant et de ne plus savoir comment revenir au site du détaillant; 2) le détaillant ne connaît pas le contexte initial des interactions du client avec le détaillant; 3) le client peut finir par commander aupr s d’un autre détaillant s’il arrive sur une page « Comment commander » affichée dans le site du fabricant ; 4) si ele client utilise le bouton « Retour » pour revenir au site du détaillant, aucune information obtenue sur le site du fabricant, comme la configuration du produit désiré, ne sera transmise au détaillant; 5) si le client revient au détaillant par la page « Comment commander » du fabricant, le détaillant ne connaît pas le contexte initial de l’interaction avec le client comme les autres produits sélectionnés pour la commande dans cette m me session.
Pour surmonter ces défis, la référence D5 propose une solution qui évite compl tement d’utiliser la méthode des hyperliens en fournissant un catalogue virtuel exploité par un distributeur qui acc de aux informations de façon dynamique, partir des catalogues des fabricants, éliminant ainsi tout contact direct entre le client et le fabricant. Bien que la solution proposée par la référence D5 soit tr s différente de celle offerte par la présente demande, en précisant les probl mes reliés la méthode des hyperliens, la référence D5 décrit également, en tant que connaissances générales courantes, l’étape de (ii) recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée.
Il est particuli rement important de signaler le cinqui me probl me énuméré au paragraphe [64] ci-dessus, qui reconnaît la possibilité qu’un client revienne au détaillant par la page « Comment commander » du fabricant, utilisant la méthode des hyperliens. On présume que lorsque le client atteint la page de commande du fabricant, il a déj choisi un produit et il est pr t effectuer un achat. Par conséquent, ramener le client au site du détaillant, ce stade, pour passer une commande, plutôt que de commander aupr s du fabricant ou d’utiliser le bouton « Retour », suppose qu’une demande d’achat est transmise du fabricant au détaillant, accompagnée des informations nécessaires pour tre traitée.
Certes, la référence D5 n’explique pas en détail comment ramener le client dans le site du détaillant depuis la page de commande du fabricant. Elle reconnaît seulement qu’il est nécessaire et possible de le faire. Toutefois, on peut dire la m me chose de la présente demande qui promet de transmettre une demande d’achat, du serveur marchand au serveur de transactions, afin qu’elle soit traitée, mais ne rév le pas la mani re de réaliser cela, ni comment un serveur marchand conventionnel peut offrir une telle fonctionnalité. En effet, l’information suivante, tirée la description de la présente demande et des observations faites par le demandeur, crée de la confusion ce propos :
[TRADUCTION]
Un autre avantage de la présente invention est que tout serveur ayant du contenu peut s’inscrire auprès du serveur commercial sans devoir être conçu spécialement pour tirer avantage du service. En plus d’adhérer au service, il faut seulement que le marchand consigne les résumés du contenu sur le serveur commercial. (Pages 12 et 13 de la présente demande)
Chaque écran de ce modèle de serveur de contenu peut aussi avoir un bouton « Faire des achats ». L’acheteur clique sur ce bouton quand il est prêt à effectuer une transaction électronique par laquelle les produits choisis sont achetés. Lorsque l’acheteur a choisi les produits et qu’il clique sur le bouton « Faire des achats », l’information sur la commande des produits choisis est transmise au serveur commercial. (Pages 17 et 18 de la présente demande)
Dans le système avec serveurs revendiqué, cette même entité physique du système électronique d’exécution de transactions commerciales est répartie entre deux entités physiques (le serveur de transactions et le serveur marchand) avec un réseau qui relie les deux serveurs. Cette répartition exige une révision des modes de recherche des produits, de traitement des transactions, d’interactions des acheteurs et d’exécution des flux de contrôle. Il est nécessaire de réviser le processus de communication et le flux de contrôle en raison de la répartition. Chacun des deux serveurs qui résultent de cette séparation doit être conçu et configuré d’une façon entièrement nouvelle afin de mettre en œuvre et d’établir le processus de communication, le flux de contrôle et l’organisation du matériel en réseau, conformément à l’invention revendiquée. (Page 4 des observations du demandeur, 28 août 2009)
Le système avec serveurs revendiqué intègre également un processeur de transaction dans le serveur de transactions pour exécuter une transaction en acceptant des demandes de transaction émises par l’acheteur et transmises par le serveur marchand. Cet élément assure que la transaction proprement dite est exécutée par le serveur de transactions, qui a initialement envoyé le client au marchand. Sans cet élément, les transactions générées par le serveur de transactions pourraient être renvoyées n’importe où par le serveur marchand pour être traitées, annulant tout bénéfice pour l’opérateur du serveur de transactions. (Page 3 des observations du demandeur, 28 août 2009)
Selon le deuxi me passage indiqué au paragraphe [67] ci-dessus, un bouton « Faire des achats » sur le serveur marchand transmet l’information sur la commande au serveur de transactions. On suppose que des modifications de la conception du serveur marchand sont nécessaires pour intégrer la fonctionnalité d’un tel bouton. Le premier passage indique cependant que tout serveur marchand peut s’inscrire sans subir au préalable de modifications de conception spécifiques. Si aucune adaptation n’est nécessaire, il n’apparaît pas clairement comment le serveur marchand conventionnel peut communiquer avec le serveur de transactions et tirer avantage de la présente invention, que ce soit au moyen d’un bouton ou par tout autre moyen. De plus, cette déclaration semble contredire le troisi me passage qui sugg re que le serveur marchand et le serveur de transactions doivent tre conçus et configurés d’une façon enti rement nouvelle pour tirer avantage de la présente invention. Si cela est vrai, on ne sait pas bien o cette configuration « enti rement nouvelle » et ces changements de conception sont divulgués ou revendiqués. De plus, il serait inapproprié pour la Commission de compléter la divulgation dans la présente demande avec des détails techniques décrits dans les observations du demandeur qui ne découlent pas raisonnablement du mémoire descriptif. Le quatri me passage semble suggérer qu’un processeur de transaction intégré au serveur de transactions est chargé d’assurer que le serveur marchand renvoie la demande d’achat au m me serveur de transactions. Cela aussi n’est ni revendiqué ni divulgué dans la présente demande. La divulgation indique simplement que le serveur de transactions accepte la commande d’achat provenant du serveur marchand, mais elle ne fournit pas d’autres détails sur la façon dont il s’assure que la commande est renvoyée du serveur d’achat au m me serveur de transactions (page 18, lignes 3 25 et page 20, ligne 44 - page 21, ligne 14 de la présente demande).
Par conséquent, la lumi re de ce qui est divulgué, il semble que la solution proposée par la présente demande n’est rien d’autre qu’une promesse de répondre aux besoins déj identifiés par la référence D5, ou qu’une déclaration d’un résultat désiré (c’est- -dire les probl mes décrits dans la référence D5 reformulés comme étant résolus dans la présente demande, sans explication l’appui). Autrement dit, la référence D5 reconnaît que la méthode des hyperliens oblige renvoyer le client sur le site du détaillant pour traiter la transaction. Elle sugg re m me que cela peut tre effectué au moyen de la page « Comment commander » du fabricant, plutôt que d’utiliser simplement le bouton « Retour », pour que l’activité qui s’est déroulée dans le site du fabricant soit communiquée au détaillant. La référence D5 reconnaît qu’il existe des difficultés pour y parvenir; cependant, la présente demande ne précise pas comment sont surmontés les probl mes inhérents la méthode des hyperliens, identifiés dans D5. Par conséquent, la contribution de la présente demande l’état existant de la technique n’est pas apparente. Il est possible que l’inventeur ait estimé qu’une fois l’idée de séparer la fonctionnalité de commerce électronique entre des serveurs distincts communiquée l’équipe compétente, les détails de la mise en uvre n’exigeraient aucun effort d’invention, auquel cas, la Commission consid re que cela signifie que le concept inventif ne dénote pas une certaine ingéniosité, puisque la référence D5 présente déj la répartition de la fonctionnalité de commerce électronique entre des serveurs distincts.
Dans son explication de « l’approche classique » de la méthode des hyperliens, la référence D5 présente tous les éléments du concept inventif de la présente demande. Il ne semble pas y avoir d’ingéniosité dans le fait de (i) renvoyer, partir d’un serveur de transactions, aux informations détaillées consignées par le marchand sur le serveur marchand; et de (ii) recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée. Compte tenu de la référence D5, la Commission consid re que tous les éléments du concept inventif font partie des connaissances générales courantes du métier. Par conséquent, la Commission conclut que les revendications 1 15 ont un caract re évident.
OBJET BREVETABLE
Principes juridiques – Objet brevetable
Les inventions qui sont utiles, nouvelles et non évidentes ne sont pas toutes admissibles la protection qu’accorde le brevet. Certains types d’objets sont exclus de la brevetabilité.
L’article 2 de la Loi sur les brevets définit le sens du mot invention.
« invention » Toute réalisation, tout procédé, toute machine, fabrication ou composition de matières, ainsi que tout perfectionnement de l’un d’eux, présentant le caractère de la nouveauté ou de l’utilité.
Afin d’en arriver une décision en ce qui concerne l’article 2 en question, la Commission tient compte du plus récent jugement, concernant ce qui constitue un objet brevetable, rendu dans le domaine des inventions mises en uvre par ordinateur, Canada (Procureur général) c. Amazon.com Inc, 2011 CAF 328.
Dans sa décision, la Cour d’appel fédérale a indiqué, aux paragraphes 62 et 63 :
[62] Schlumberger illustre une tentative infructueuse de breveter un procédé visant à recueillir, enregistrer et analyser des données sismiques à l’aide d’un ordinateur programmé selon une formule mathématique. Cette utilisation de l’ordinateur était une application pratique et l’information résultante était utile. La demande de brevet a toutefois été refusée faute d’objet brevetable parce que la Cour a conclu que le seul aspect nouveau de l’invention revendiquée était la formule mathématique qui, n’étant que « de simples principes scientifiques ou conceptions théoriques », ne peut pas faire l’objet d’un brevet en raison de l’interdiction prévue au paragraphe 27(8).
[63] On peut soutenir que les revendications du brevet qui font l’objet de la présente instance pourraient être rejetées pour les mêmes raisons, selon la réponse donnée à la question de savoir si une interprétation téléologique des revendications mène à la conclusion que l’on ne peut établir une distinction entre Schlumberger et la présente espèce, parce que le seul aspect inventif de l’invention revendiquée est l’algorithme – une formule mathématique qui est programmée dans l’ordinateur de manière à ce qu’il accomplisse les opérations nécessaires pour effectuer un achat en ligne en un seul clic. D’un autre côté, on peut également soutenir qu’une interprétation téléologique des revendications peut conduire à la conclusion qu’on peut établir une distinction entre Schlumberger et la présente affaire du fait qu’un nouveau procédé pour effectuer en un seul clic un achat en ligne ne constitue pas l’invention entière, mais seulement un élément essentiel parmi d’autres dans une nouvelle combinaison. À mon avis, le commissaire devrait en l’espèce procéder de nouveau à l’interprétation téléologique des revendications, en gardant à l’esprit la possibilité qu’une nouvelle pratique commerciale constitue un élément essentiel d'une revendication de brevet valide.
Analyses – Les revendications 1 à 15 visent-elles un objet non brevetable?
La Commission, dans sa lettre datée du 31 ao t 2012, invitait le demandeur présenter des observations sur l’incidence de l’arr t Amazon, CAF. Le demandeur n’a produit aucune observation.
la lumi re de l’orientation fournie dans les arr ts Amazon CAF (paragraphes 62, 63, 74) et Free World Trust c. Électro Santé Inc., 2000 CSC 66 (voir paragraphe 15), il convient de distinguer et de séparer dans l’interprétation les « superpositions complexes de définitions de différents éléments (ou « composants » ou « caractéristiques » ou « parties intégrantes ») dont la complexité, l’interchangeabilité et l'ingéniosité sont variables. »
Pour ce qui est du caract re évident, nous avons tenu compte du probl me pratique visé par la présente demande et conclu que la solution comprend la séparation de la fonctionnalité de commerce électronique entre plusieurs serveurs. La revendication 1 présente [TRADUCTION] « un serveur de transactions contenant les résumés des informations consignées par les marchands, connecté sur un réseau un serveur marchand » (les autres revendications indépendantes utilisent un langage similaire). Selon la demande, la solution proposée comprenant deux serveurs constitue une alternative au syst me classique de commerce électronique qui repose sur un seul serveur complexe procurant la fois la fonctionnalité de contenu et de transactions. Cela concorde avec le concept inventif consistant (i) renvoyer, partir d’un serveur de transactions, aux informations détaillées consignées par le marchand sur le serveur marchand; et (ii) recevoir, sur le serveur de transactions, une demande d’achat transmise par le serveur marchand afin qu’elle soit traitée. Ainsi, le recours un ordinateur (en l’esp ce, deux ordinateurs ou serveurs en communication sur un réseau) est important pour la façon dont l’invention fonctionne.
la lumi re de l’orientation fournie par les tribunaux, la Commission conclut que, tout le moins, le fait d’avoir des serveurs en communication sur un réseau est essentiel pour l’invention. Ces caractéristiques constituent « un élément essentiel parmi d’autres dans une nouvelle combinaison » (voir Amazon CAF, au paragraphe 63).
La restriction relative au réseau étant un élément essentiel, l’objet revendiqué n’étant pas une chose abstraite, et l’objet n’étant pas autrement exclu de la brevetabilité, la Commission conclut que les revendications 1 15 sont conformes l’article 2 de la Loi sur les brevets.
CONCLUSIONS ET RECOMMANDATION
La Commission conclut que :
1 Les revendications 1 à 15 sont évidentes et non conformes au paragraphe 28.3 de la Loi sur les brevets.
2 Les revendications 1 à 15 sont conformes à l’article 2 de la Loi sur les brevets.
La Commission recommande que le rejet de la demande soit confirmé pour non-conformité avec le paragraphe 28.3 de la Loi sur les brevets parce que les revendications 1 15 sont évidentes. Nous recommandons que la demande soit refusée conformément l’article 40 de la Loi sur les brevets.
En conséquence, la Commission recommande le refus d’accorder un brevet dans le cadre de la présente demande.
C. Nasrallah P. Sabharwal A. Strong
Membre Membre Membre
DÉCISION
Je souscris aux conclusions de la Commission d’appel des brevets voulant que les revendications sont évidentes et non conformes au paragraphe 28.3 de la Loi sur les brevets, et sa recommandation que la demande soit refusée conformément l’article 40 de la Loi sur les brevets.
En conséquence, je refuse d’accorder un brevet dans le cadre de la présente demande. Conformément l’article 41 de la Loi sur les brevets, le demandeur dispose d’un délai de six mois pour interjeter appel de ma décision devant la Cour fédérale du Canada.
Sylvain Laporte
Commissaire aux brevets
Fait à Gatineau (Québec),
le 28e jour de mars 2013