INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
La figure 3 illustre plus en détail la face avant du boîtier de la figure 2. On y retrouve l'écran d'affichage ECR matérialisant dans l'exemple décrit une grille de LOTO (marque déposée). Le clavier CL comporte un certain nombre de touches TT éventuellement pourvues d'une zone IS pour une inscription spécifique. Certaines de ces touches peuvent être utilisées pour déplacer un curseur sur l'écran d'affichage, tandis qu'une autre touche peut être utilisée pour valider la position du curseur et donc le nombre choisi. Enfin, l'organe d'activation OG est ici matérialisé par un bouton-poussoir sur lequel est représenté un combiné téléphonique.
En résultat, lorsque l'Application 2 produit les "informations d'événements particulières" (c'est-à-dire, lorsque l'opérateur au niveau du poste de travail 26 sélectionne quelque chose en plaçant la souris 18 dans une fenêtre 12b et en appuyant sur un bouton de la souris), du fait que l'Application 2 sait que l'Application 1 est intéressée par la réception des informations d'événements particulières, l'Application 2 envoie ces informations d'événements particulières "directement" à l'Application 1 (via la ligne 40). c est-à-dire que les informations d'événements particulières ne sont pas envoyées à partir de l'Application 2 26cl vers le serveur 26c2 (via la ligne 38) ni à partir du serveur 26c2 vers l'Application 1 24cl (via la ligne 36). Du fait que le serveur 26c2 n'est pas impliqué dans le transfert des informations d'événements particulières à partir de l'Application 2 vers l'Application 1, un temps de traitement appréciable est économisé. En résultat, la "Structure Distribuée pour Communications Inter-tâches entre Applications sur Poste de Travail" de la présente invention est "extensible".
C'est-à-dire que pour un programme d'application client particulier s'exécutant dans un poste de travail tel que représenté par l'une des fenetres 12b affichées sur la figure 1, un développeur d'applications peut définir (1) le type d'événements que l'application client particulière va recevoir à partir d'une autre application client s'exécutant concurremment, et (2) le type de données associées aux événements qui seront reçues à partir des autres applications client à chaque fois que ces événements seront transmis à partir des autres applications client.
Sur la figure 7, un organigramme de l'enregistrement et de la distribution d'objets d'intérêt est illustré. Cet organigramme décrit certains des concepts décrits ci-dessus en référence à la figure 6. Sur la figure 7, lorsque l'Application Client 1 24cl souhaite enregistrer un intérêt dans un événement (c'est-à-dire, lorsque l'Application 1 souhaite enregistrer un intérêt dans un événement du fait qu'elle souhaite recevoir des informations en provenance d'une ou de plusieurs autres applications client lorsque les autres applications client pratiquent ou exécutent l'événement), un certain nombre d'étapes de traitement sont pratiquées par l'Application 1 24cl, le serveur 26c2 et l'Application 2 26cl 1. Sur la figure 7, dans le bloc 24cl(a), l'Application Client 1 24cl ("Application 1") inclut deux parties : (1) une première application client ("application client 1"), et (2) un client pour une Communication Inter-tâche (ITC) ("client ITC") . Lorsque l'Application 1 exécute la première application client et si la première application client requiert des informations concernant un événement que l'on appellera par la suite "événement X", la première application client enregistre un intérêt dans l'événement X avec le client ITC en envoyant un "objet d'intérêt" au client ITC. L'objet d'intérêt contient un "jeton d'événements".
2. Sur la figure 7, dans le bloc 24cl(b), le client ITC mémorise certains jetons d'événements. Lorsque le client ITC reçoit l'objet d'intérêt à partir de la première application client, le client ITC vérifie le jeton d'événements présent dans l'objet d'intérêt en localisant une coïncidence entre le jeton d'événements contenu dans l'objet d'intérêt et un jeton d'événements catalogué dans une base de données. Lorsqu'une coïncidence entre jetons d'événements est localisée, le client ITC va "enregistrer un rappel d'application" ; c'est-à-dire que le client ITC va envoyer un signal de confirmation en retour à la première application client.
3. Sur la figure 7, dans le bloc 24cl(c), le client ITC envoie alors un signal d"'objet d'intérêt" au serveur ITC 26c2.
4. Sur la figure 7, dans le bloc 26c2(a), le serveur ITC reçoit le signal d"'objet d'intérêt" en provenance du client ITC et, en réponse à celui-ci, le serveur ITC enregistre (c'est-à-dire, le serveur ITC mémorise à l'intérieur de celui-ci) des données ou des informations relatives à l'intérêt manifesté dans l'événement X que la "première application client" de "l'Application 1" a précédemment produit. On rappelle que la première application client de l'Application 1 a préalablement indiqué (en envoyant le signal d"'objet d'intérêt" au serveur ITC) qu'elle souhaite recevoir certaines informations à partir des autres applications client qui sont produites lorsque "l'événement X" est exécuté ou pratiqué par les autres applications client.
5. Sur la figure 7, dans le bloc 26c2(b), lorsque le serveur ITC enregistre les informations relatives à l'intérêt manifesté par la première application client dans la réception des informations d'événements X à partir d'autres applications client conformément au bloc 26c2 (a) , le serveur ITC diffuse vers toutes ces autres applications client un tel intérêt manifesté par la première application client. En résultat, toutes les autres applications client (c'est-à-dire, tous les autres programmes d'application client exécutés dans tous les postes de travail du réseau de postes de travail) savent que la première application client de l'Application 1 24cl est intéressée par la réception de certaines informations spécifiques à partir des autres applications client, les informations spécifiques étant produites à partir des. autres applications client uniquement lorsque "l'événement X" est exécuté ou pratiqué par les autres applications client.
6. Sur la figure 7, dans les blocs 24cl(a), 24cl(b), ..., et 24cl(N), toutes les autres applications client ("application client 2" 26cl(a), "application client 3" 26cl(b), . .., et "application client N" 26cl(N)) enregistrent (c'est-à-dire mémorisent) l'intérêt manifesté par la première application client pour la réception d'informations relatives à "l'événement X" à chaque fois que l'une quelconque ou que la totalité des application client 2, application client 3, ..., et application client N pratiquent ou exécutent "l'événement X".
Sur les figures 8a et 8b, un autre organigramme de l'enregistrement et de la distribution d'objets d'intérêt (qui décrit des concepts similaires aux concepts décrits ci-dessus en relation avec les organigrammes des figures 6 et 7) est illustré. Dans l'organigramme des figures 8a et 8b, "l'application client 1" 24cl ("Application 1") est représentée comme étant en communication avec le serveur 26c2 et "l'application client 2" 26cl ("Application 2"), comme illustré précédemment sur les figures 6 et 7. Cependant, de plus, sur les figures 8a et 8b, deux autres applications client sont illustrées : "application client 3" 42 ("Application 3") et "application client 4" 44 ("Application 4"). En fonctionnement, en se reportant aux figures 8a et 8b, on suppose aux fins de la description que l'Application 1, l'Appli cation 2, l'Application 3 et l'Application 4 représentent des programmes d'application client qui s'exécutent dans quatre (4) postes de travail différents similaires au poste de travail de la figure 1. On suppose en outre que chacune des quatre applications (Application 1 à Application 4) produit un affichage à fenêtres au niveau de son poste de travail respectif similaire à l'affichage à fenêtres 12b représenté sur la figure 1. On suppose en outre que l'Application 1 de la figure 8a est représentée par le "logiciel client 1" 24cl sur la figure 3, que l'Application 2 de la figure 8a est représentée par le "logiciel client 2" 26cl sur la figure 3, et que le serveur 26c2 de la figure 8a est représenté par le "logiciel serveur" 26c2 sur la figure 3. Sur les figures 8a et 8b, l'Application 1 24cl enregistre un intérêt dans un événement ITC appelé "événement X" (les mécanismes réels situés derrière l'enregistrement de cet objet d'intérêt seront mieux compris en référence à la figure 14). Un objet d'intérêt est envoyé à partir de l'Application 1 24cl vers le serveur 26c2 via la ligne 46 sur la figure 8a.
Lorsque l'objet d'intérêt est reçu par le serveur 26c2, le serveur 26c2 enregistre, au sein de celui-ci, l'intérêt manifesté par l'Application 1 24cl dans l'événement X. Le serveur 26c2 redistribue alors l'objet d'intérêt à : "l'Application 2" 26cl via la ligne 48, "l'Application 3" 42 via la ligne 50, et "l'Application 4" 44 via la ligne 52. Lorsque le serveur 26c2 redistribue l'objet d'intérêt de l'Application 1 aux autres applications client, Applications 2, 3 et 4, les autres applications client (Applications 2, 3 et 4) enregistrent dans celles-ci l'intérêt manifesté par l'Application 1 à l'égard de l'événement X.
Sur les figures 9a et 9b, une représentation schématique de haut niveau de la propagation d'événements utilisant une communication entre homologues est illus trée. On rappelle d'après les figures 8a et 8b que l'Application 1 24cl a transmis un signal "objet d'intérêt" au serveur 26c2 et que le serveur 26c2 a redistribué ce signal "objet d'intérêt" à l'Application 2 26cl. Le signal "objet d'intérêt" (qui identifie l'Application 1 comme étant sa source) a été enregistré dans l'Application 2 comme provenant de l'Application 1 et exprime un intérêt de l'Application 1 dans certaines informations spécifiques susceptibles d'être produites par l'Application 2 lorsqu'un "événement X" est pratiqué ou exécuté par l'Application 2. En résultat, sur les figures 9a et 9b, du fait que le signal "objet d'intérêt" préalablement envoyé à l'Application 2 par le serveur 26c2 identifie l'Application 1 comme étant le demandeur de telles informations spécifiques concernant "l'événement X", lorsque l'Application 2 26cl pratique ou exécute "l'événement X", les certaines informations spécifiques mentionnées cidessus concernant l'exécution ou la pratique de "l'événement X" sont envoyées directement à partir de "l'Application 2" 26cl vers "l'Application 1" 24cl (c'est-à-dire que les certaines informations spécifiques mentionnées ci-dessus ne sont pas transmises de l'Application 2 au serveur 26c2 ni du serveur 26c2 à l'Application 1 ; le serveur 26c2 est évité).
La transmission des certaines informations spécifiques mentionnées ci-dessus (concernant la pratique par l'Application 2 de l'événement X) directement à partir de l'Application 2 vers l'Application 1, sans passage à travers le serveur ni enregistrement, est une amélioration par rapport à la description de Good et autres de la technique antérieure, référencée dans l'arrière-plan technologique de la présente description. On rappelle que, dans la description de Good et autres, toutes les données à communiquer entre programmes d'application informatiques s'exécutant simultanément doivent être acheminées par l'intermédiaire d'un programme serveur ou d'un programme régulateur intermédiaire.
Sur les figures 10a et 10b, un schéma de haut niveau représentant la diffusion multiple d'informations d'événements à partir de l'Application 2 vers de multiples autres applications client intéressées est illustré.
En se reportant brièvement aux figures 8a et 8b, on rappelle qu'un objet d'intérêt a été envoyé à partir de l'Application 1 24cl vers le serveur 26c2, via la ligne 46 sur la figure 8a. On rappelle en outre que, lorsque l'objet d'intérêt a été reçu par le serveur 26c2, le serveur 26c2 a enregistré, à l'intérieur de celui-ci, l'intérêt manifesté par l'Application 1 24cl dans l'événement X. Le serveur 26c2 a alors redistribué l'objet d'intérêt à "l'Application 2" 26cl via la ligne 48, "l'Application 3" 42 via la ligne 50, et "l'Application 4" 44 via la ligne 52. Cependant, maintenant que l'objet d'intérêt, dans "l'événement X", a été redistribué par le serveur 26c2 aux Applications 2, 3 et 4, si l'une quelconque ou la totalité des Applications 2, 3 et/ou 4 pratiquent ou exécutent "l'événement X", l'Application responsable (2, 3 et/ou 4) transmet des informations concernant "l'événement X" directement en retour au demandeur, qui est l'Application 1 24cl, sans ré-enregistrement avec le serveur 26c2 ni passage à travers celui-ci (le serveur 26c2 reste inactif) Par conséquent, sur les figures 10a et 10b, on suppose que le demandeur de l'événement X est à la fois "l'Application 1" 24cl et "l'Application 4" 44 (l'Application 1 et l'Application 4 ont toutes deux précédemment envoyé un objet d'intérêt dans "l'événement X" au serveur 26c2, et le serveur 26c2 a redistribué cet objet d'intérêt dans l'événement X à l'Application 2). Par conséquent, l'Application 2 sait que les Applications 1 et 4 sont intéressées par la réception d'informations concernant la pratique de "l'événement X". En résultat, lorsque "l'Application 2" 26cl pratique ou exécute "l'événement X", des informations concernant l'exécution de "l'événement X" sont envoyées directement à partir de l'Application 2 à la fois vers "l'Application 1" 24cl et vers "l'Application 4" 44 (les informations relatives à l'exécution de l'événement X ne sont pas ré-enregistrées par le serveur 26c2 ni ne sont acheminées par celui-ci et, en résultat, le serveur 26c2 est évité).
Sur les figures ila et îlb, un schéma de haut niveau représentant la "révocation d'intérêts" est illustré. On suppose que l'Application Client 1 24cl (Application 1) a préalablement enregistré un intérêt dans l'événement X avec le serveur 26c2 (en envoyant un objet d'intérêt au serveur), et, ensuite, que le serveur 26c2 a redistribué cet objet d'intérêt dans l'événement X à l'Application Client 2 26cl (Application 2), à l'Application Client 3 42 (Application 3), et à l'Application Client 4 44 (Application 4). Ensuite, on suppose que l'Application 1 souhaite révoquer son intérêt dans "l'événement X". Pour révoquer son intérêt dans "l'événement X", l'Application 1 envoie un "objet de révocation" au serveur 26c2 (via la ligne 46 sur la figure 11), "l'objet de révocation" représentant l'indication par l'Application 1 aux autres applications client qu'elle ne souhaite plus recevoir aucune information concernant la pratique ou l'exécution, par d'autres applications, de "l'événement X". En réponse à la réception de l'objet de révocation, le serveur 26c2 supprime l'enregistrement, à l'intérieur de celui-ci, de l'intérêt manifesté par l'Application 1 dans la réception d'informations relatives à l'exécution, par d'autres applications client, de "l'événement X" lorsque l'événement X est pratiqué par d'autres applications. Ensuite, le serveur 26c2 redistribue l'objet de révocation, provenant de 1'Appli cation 1, à toutes les autres applications client c'est-à-dire que, sur la figure lla, le serveur 26c2 redistribue l'objet de révocation à l'Application 2 (via la ligne 48), à l'Application 3 (via la ligne 50) et à l'Application 4 (via la ligne 52). Lorsque les autres applications client (Applications 2, 3 et 4) reçoivent "l'objet de révocation", les autres applications client (Applications 2, 3 et 4) suppriment l'enregistrement de l'intérêt manifesté par l'Application 1 dans "l'événement X". En résultat, aucune information concernant la pratique ou l'exécution, par les autres Applications Client 2, 3 ou 4, de l'événement X, n'est envoyée vers l'Application 1.
Sur les figures 12a et 12b, un schéma de haut niveau de la révocation implicite d'un intérêt pour un client déconnecté est illustré. On suppose que l'Application 1 24cl meurt ou se termine, tandis qu'elle possède des intérêts actifs en suspens. On rappelle que l'Application 1 possède des intérêts actifs en suspens du fait que l'Application 1 a précédemment transmis un objet d'intérêt dans "l'événement X" (et, peut-être, dans d'autres événements) au serveur 26c2 et que le serveur 26c2 a précédemment redistribué cet objet d'intérêt dans l'évé- nement X, et dans d'autres événements, aux autres applications client, "Application 2" 26cl, "Application 3" 42 et "Application 4" 44. Sur les figures 12a et 12b, si l'Application 1 meurt ou se termine, le serveur 26c2 avertit la fin de l'Application 1. Lorsque le serveur 26c2 avertit la fin de l'Application 1 24cl (le programme de l'Application 1 cesse de s'exécuter), le serveur 26c2 supprime l'enregistrement, au sein de celui-ci, de tous les intérêts en suspens que l'Application 1 a précédemment envoyés au serveur 26c2 (via la ligne 46). Ensuite, le serveur 26c2 distribue un "objet de révocation" correspondant à tous les intérêts en suspens de l'Applîca- tion 1 dans tous les événements à toutes les autres applications client, c'est-à-dire à "l'Application 2" 26cl, "l'Application 3" 42 et "l'Application 4" 44 sur la figure 12. Lorsque les autres applications. . .client (Applications 2, 3 et 4) reçoivent l'objet de révocation en provenance du serveur 2Gc2 associé à tous les intérêts en suspens de l'Application 1 dans tous les événements, les autres applications client (Applications 2, 3 et 4 sur la figure 12) suppriment l'enregistrement de tous les intérêts manifestés dans tous les événements que "1 'Application Client 1" 24cl a précédemment transmis aux Applications 2, 3 et 4 via le serveur 26c2.
Les colonnes 22 d'assemblage sont engagées dans des perçages correspondants ménagés dans le bloc 19 support d'enclume(s), de façon à être fixées rigidement à ce bloc 19, au moins lorsque celui-ci est en position fixée et montée sur l'embase 20 de la semelle 1. Pour ce faire, l'extrémité inférieure de chaque colonne 22 est engagée dans un perçage du bloc 19 et fixée par une vis 23 à tête dont l'extrémité est vissée dans un taraudage de la colonne 22, cette vis 23 étant engagée par l'extrémité inférieure du perçage du bloc 19 support d'enclume(s).
Le bloc 16 support de matrice(s) comprend un perçage traversant vertical pour le guidage du bloc de support de matrice par rapport à chaque colonne 22. Ce perçage est ménagé dans une équerre 24 s'étendant horizontalement vers l'arrière. L'extrémité supérieure de chaque colonne 22 est dotée d'une tête 25 limitant le mouvement relatif de translation dans le sens de l'écartement vers le haut du bloc 16 support de matrice(s), par rapport au bloc 19 support d'enclume(s), à une valeur supérieure ou égale à celle de leur écartement maximum definie entre le porte-outil 2 et la semelle 1, lorsque ces deux blocs 16, 19 y sont fixés. Ainsi, lorsque la cassette de sertissage 21 portant les outils de sertissage est démontée du dispositif (figures 1, 7 et 8), les deux colonnes 22 maintiennent ensemble les deux blocs 16, 19 en empêchant leur démontage relatif. Au contraire, lorsque la cassette de sertissage est montée et fixée dans le dispositif, le bloc 16 étant fixé dans le porte-outil 2 et le bloc 19 étant fixé sur la semelle 1, les mouvements de translation et le guidage relatif du bloc 16 support de matrice(s) par rapport au bloc 19 support d'enclume(s) est essentiellement assuré par le guidage du porte-outil 23 par rapport à la semelle 1, c'est-à-dire par les étriers 12, ainsi que par les mouvements du coulisseau de presse. En conséquence, on comprend que l'assemblage relatif des blocs 16, 19 et des colonnes 22 présente un certain jeu aussi bien dans le sens de la translation que dans les directions transversales et n'a pas à être réalisé de façon précise.
Ces jeux doivent être en tout cas suffisants pour éviter que les colonnes 22 ne gênent le guidage en translation verticale du porte-outil 2 et des matrices 8 par rapport à la semelle 1 et aux enclumes 6.
Le bloc 19 support d'enclume(s) est simplement assemblé et fixé de façon amovible à l'embase 20 de la semelle 1 par un assemblage de type à queue d'aronde, d'axe parallèle à l'axe de sertissage 9. Par exemple, le bloc 19 support d'enclume comprend une queue d'aronde mâle 26 et l'embase 20 comporte une queue d'aronde femelle 27.
Cet assemblage 26, 27 à queue d'aronde permet de placer chaque enclume 6 et chaque matrice 8 dans le plan vertical contenant l'axe de sertissage 9 et l'axe vertical de translation 28 du porte-outil 2 par rapport à la semelle 1.
Une vis transversale de blocage axial de 1 assemblage à queue d'aronde peut être prévue. La position en translation de l'ensemble de la cassette 21 de sertissage selon l'axe 9 de sertissage est déterminée par les faces arrières 29 du bloc 16 support de matrice(s) et 30 du bloc 19 support d'enclume(s) qui viennent en butée et en appui contre des faces verticales du porte-outil 2, respectivement d'un support 31 des étriers 12 solidaire de la semelle 1.
Egalement, le bloc 16 support de matrice(s) présente une face supérieure horizontale 52 venant en butée et en appui contre une face horizontale du logement 17 du porte-outil 2. Le bloc 19 support d'enclume(s) repose sur la semelle 1.
La vis 18 de fixation amovible du bloc 16 de support de matrice s'étend parallèlement à l'axe de sertissage 9 et permet de bloquer l'ensemble de la cassette 21 de sertissage en position montée par rapport au dispositif.
Le bloc 16 support de matrice(s) comporte en outre des moyens 32, 33 de réglage continu de la position d'au moins une matrice 8 de sertissage et donc d'une première empreinte de sertissage, selon la direction verticale de translation du porte-outil 2. Ces moyens 32, 33 comportent une cale 32 à portée inclinée venant au contact de l'extrémité supérieure de la matrice 8, et une vis 33 à tête moletée dont le filetage est engagé dans un taraudage traversant de la cale 32 pour en déterminer la position transversale par rapport à la matrice 8. Ainsi, en tournant la vis 33, on modifie la position de la cale 32 par rapport à la matrice 8, ce qui a pour effet de déplacer verticalement en translation cette matrice 8 par rapport au bloc 16 support de matrice. En outre, la matrice 8 comprend au moins une lumière verticale oblongue 34 traversée par des vis de fixation 35 des matrices 8 par rapport au bloc 16 support de matrice(s). Cette lumière verticale 34 est adaptée pour permettre le réglage vertical en translation de la matrice 8 par rapport au bloc 16 support de matrice(s).
Chaque cassette d'outils 21 peut comprendre une ou plusieurs matrices 8, par exemple une première matrice de sertissage de la cosse autour de l'âme conductrice du fil, et une deuxième matrice adjacente pour le sertissage de la cosse autour de l'extrémité de la gaine isolante du fil. De même, chaque bloc 19 support d'enclume peut porter une ou plusieurs enclumes 6, à savoir par exemple une enclume pour le sertissage de la cosse autour de l'âme dénudée du fil électrique et une deuxième enclume pour le sertissage de la cosse autour de l'extrémité de la gaine du fil.
En outre, deux variantes de réalisation sont possibles. Dans la variante représentée, la cassette 21 comprend également un dispositif 36 permettant de découper la bande de cosses, après son déplacement transversal, en vue de la séparation de chaque cosse placée selon l'axe de sertissage. Dans une autre variante, ce dispositif coupe bande peut être monté solidaire des moyens 3 d'alimentation et donc porté par l'ensemble du dispositif et par la semelle 1 (et non par la cassette 21).
Les matrices 8 sont assemblées sur le bloc 16 par une ou plusieurs vis 35 de serrage. En variante, les matrices 8 et les empreintes 7 peuvent être formées par le bloc 16 lui-même en une seule pièce conformée à cet effet.
Les enclumes 6 peuvent être assemblées sur le bloc 19. Dans le mode de réalisation représenté, les enclumes 6 et les empreintes 5 sont formées par le bloc 19 lui-même en une seule pièce conformée à cet effet.