INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
des étapes 70-76 remplaçant l'étape 66 dans la procédure selon la figure 6 ou 7 Les paramètres eplus et eminus pour l'adaptation de débit sont définis comme précédemment (eplus = a.Ei et eminus = aI4Ni) ), et on définit en outre des paramètres de même nature pour le poinçonnage supplémentaire dans chaque TrCH i et chaque trame ni appartenant au TTI de ce TrCH . epluscm[ni] = a' Nfr, eminus[ni] ~ -a Ncm[ni] avec a' = 2 (par exemple), et des compteurs supplémentaires ecm[ni] sont initialisés à Nfr, à l'étape 60. A l'étape 70, l'index col de la trame du TTI dans laquelle se trouvera le symbole gi,n(colonne de l'entrelaceur 26i après permutation) est calculé en utilisant la fonction BR définie précédemment Si cette trame n'est pas en mode comprimé ( aNm [col] = 0 au test 71), le symbole g,n reçoit la valeur (0, ci@m) à l'étape 72, puis l'index n est incrémenté d'une unité à l'étape finale 73. Si la trame est en mode comprimé (ANcm[col] 0 lors du test 75, le module 24 passe à l'étape 72 précitée pour affecter la valeur (0, ci l m) au symbole g; , n qui sera conservé dans la trame en mode comprimé.
Une autre façon de procéder au niveau de la station de base (ci-après méthode 2) consiste, pour chaque TrCH i et chaque TTI de ce TrCH comportant au moins une trame en mode comprimé, à appliquer sur la séquence de bits ci l'algorithme d'adaptation de débit selon la figure 6 ou 7, en tenant compte, dans le nombre #Ni de bits à poinçonner ou répéter, à la fois de l'adaptation de débit statique (#NiTTI) et de l'éventuel mode comprimé ( ON m ), et à ajouter les ANPm bits marqués p dans les premières positions
des colonnes correspondant à des trames en mode comprimé. Ceci permet d'optimiser la distance entre les bits d'information poinçonnés ou répétés.
Quatre cas se présentent : 1 ) NTTI < 0 , de sorte que AN, = dNTTI + ONcm < 0 . Le taux de poinçonnage est simplement augmenté.
2) AN7 > 0 et 1 ANcm i > 4Ni , de sorte que AN,
3) AN7 > 0 et Ans 1 0 On n'a pas besoin de poinçonner des bits d'information uniques Il suffit de moins répéter que ce que demande l'adaptation de débit statique. Donc on répète AN bits et on insère -AN bits marqués p 4) AN# > 0 et INml = AN# , de sorte que AN = 0 On n'a besoin ni de poinçonner ni de répéter des bits d'information Il suffit d'insérer -Nm bits marqués p .
La figure 9 illustre une réalisation selon cette méthode 2, en montrant des étapes 80-83 remplaçant l'étape 66 dans la procédure selon la figure 6 ou 7. Les paramètres eplus et eminus pour l'adaptation de débit sont définis par : eplus = a Ei eminus ;;: a.1N;n-1 + NFml et on utilise Fi compteurs supplémentaires cbi[n,] dénombrant les bits p insérés au début des colonnes de l'entrelaceur (0 :Ç ni < Fj). Ces compteurs cbi[n,] sont initialisés à 0 à l'étape 60. A l'étape 80, l'index col de la trame du TTI dans laquelle se trouvera le symbole gi,n(colonne de l'entrelaceur 26i après permutation) est calculé en utilisant la fonction BR Si cbi[col] < Ncm[col] (test 81), l'étape 82 est exécutée pour insérer un bit p à la position n de la séquence de sortie gi et incrémenter d'une unité le compteur cbi[col] et l'index n, après quoi le module 24i revient à l'étape 80 pour la
position suivante. Quand cbi[col] = ANcm[col] au test 81 (c'est-à-dire que la trame n'est pas en mode comprimé car #Ncm[col] = 0, ou que tous le bits p requis ont été introduits dans la trame en mode comprimé), l'étape finale 83 est exécutée pour écrire le bit ci,m (avec le préfixe 0) dans le symbole gi,net pour incrémenter l'index n d'une unité Dans le cas où le module de codage de canal 23, utilise un turbocode de rendement 1/3, la procédure de poinçonnage est appliquée par le module d'adaptation de débit 24, uniquement sur les bits de parité. Ceci est illustré par la figure 10 La procédure est similaire à celle de la figure 6, des références numériques identiques étant employées pour désigner des étapes homologues.
Plutôt que d'avoir un thread par objet, les activités de tous les objets peuvent être traitées dans un seul thread : celui du Séquenceur. Le rôle de ce Séquenceur sera donc de régir le passage d'un sous état d'activité à un autre par l'émission de l'événement next, pour tous les objets.
La mise sous forme canonique correspondante est illustrée sur la figure 146.
Comme précédemment, l'objet entre dans l'état Sentry et y effectue toute les actions On Entry prévues dans l'état S. Puis, l'objet entre automatiquement dans l'état Swait.
A. Création de la macrostructure Pour que le code source puisse être restructuré et stocké en évitant les redondances, l'utilisateur spécifie quels éléments sont des contenus et à quel contenant chaque contenu appartient. Ceci permet de constituer ce qu'on appelle ici la macrostructure.
Les contenants sont spécifiés au moyen d'attributs. Utiliser des attributs plutôt que des balises ( tags en terminologie anglo-saxonne) offre l'avantage de ne pas modifier la structure et ainsi, notamment, de ne pas remettre en cause l'application de feuilles de style XSL. La restructuration est ainsi non intrusive . On va maintenant présenter l'application d'une méthode de spécification de contenus et contenants (en se servant de l'exemple déjà présenté plus haut) au moyen d'attributs :
exemple d'informations de toutes sortes exemple informations texte exemple informations texte On notera que : - Hubert est dans un container (CONTAINERNUMBER= "1") différent de celui d' Antoine , Edouard et Raymond (CONTAINERNUMBER= "2").
- les attributs myfriend et myenemies sont des références aux n#uds de l'arbre, car ils ont été spécifiés comme tels (type idref ) par le schéma associé au code source en langage XML.
Remarques : 1- La macrostructure permet de dissocier les éléments, de la structure dans laquelle ils résident. Ainsi, les éléments sont stockés de manière unique sur le serveur quel que soit le nombre de fois où ils ont été reproduits.
2- Par défaut, sans aucune intervention manuelle, la macrostructure pourrait être automatiquement calquée sur la structure du document. La granularité du partage (granularité des éléments qui peuvent être répliqués) serait alors celle des éléments du document. Mais le système serait alors lourd à manipuler pour l'utilisateur, la macrostructure serait volumineuse et les performances s'en ressentiraient.
L'approche que nous présentons consiste à permettre de spécifier la macrostructure explicitement dans les documents, c'est-à-dire de choisir la granularité des contenus qui peuvent être partagés. Ainsi, lors de la spécification d'un contenu, celui-ci est, par la même occasion, localisé dans un contenant qui peut regrouper plusieurs contenus. Comme les contenus auraient pu être calqués sur la structure des éléments du document, les contenants auraient pu être calqués sur la structure des contenus (tous les contenus enfants d'un même parent auraient alors été mis dans un contenant). On a préféré ici spécifier explicitement quels contenus sont situés dans quels contenants.
B. Code décomposé A partir des indications figurant dans le nouveau code source, est construite la structure décomposée, constituée d'une part par l'arbre de structure et d'autre part la suite de contenus.
Dans notre exemple, l'arbre de structure est la suivante : (Container où se trouve Hubert)
(Container où se trouvent Antoine, Edouard et Raymond)
La suite de contenu est la suivante : exemple d'informations de toutes sortes
exemple informations texte exemple informations texte Comme on peut le voir, toutes les données d'arbre de départ sont séparées dans la suite de contenus. L'arbre de structure représente l'imbrication des contenants entre eux.
L'imbrication entre Root et Henri ne figure pas dans l'arbre de structure car Root et Henry sont dans le même contenu. Par contre, l'imbrication entre
Anatole et Hubert , Edouard , Antoine et Raymond est reflétée dans l'arbre de structure, car Hubert , Edouard , Antoine et Raymond sont regroupés dans deux contenants différents sous Anatole .
De plus, on constate que les contenants peuvent être disposés de façon bien précise dans les contenus. On parlera de positionnement. Les contenus dans lesquels se trouvent des contenants portent une balise indiquant où les contenants se trouvent (au moyen d'un numéro POSITION~CONTAINER N). Les positions dans les contenus sont utilisés dans l'arbre de structure. Chaque contenant est en effet imbriqué sous une balise POSITION CONTAINER ayant un numéro. Ce numéro correspond à l'indication N figurant dans les contenus. Ceci est illustré sur la figure 72.
Lorsque certaines balises possèdent des références à d'autres balises, cela est matérialisé dans l'arbre de structure et dans la suite de contenus au moyen de la balise POSITION~ELTREFS. La même approche que pour le positionnement des contenants est utilisé. La position de références à des éléments est matérialisée dans un contenu à l'aide d'un numéro POSITION~ELTREFS N, que l'on retrouve dans l'arbre de structure, dans le champ CONTENTREF correspondant. Cette indirection permet de retrouver, dans la structure arborescente de contenants, le contenu où se trouve l'élément référencé. Ceci est illustré à la figure 73.
(c'est-à-dire des sous-objets), ce qui permet de les inclure dans le cas général du traitement des objets. (Les attributs se distinguent des objets en général, par le fait qu'ils n'ont pas de liens avec d'autres objets ; ceci ne contredit pas la généralisation ici faite). Pour mémoire, la figure 140 illustre l'équivalence entre une classe Classe dotée d'un attribut Attributel (de classe Classe2) , et le lien entre les deux classes Classe et Classe2 .
va décrire maintenant, par référence aux figures 12A à 12G, les principales architectures pouvant être mises en ceuvre dans le cadre de l'invention.
figure 12 A illustre une architecture de système selon laquelle la partie est stockée en local sur le terminal 1. Celui-ci connecté à un serveur eloigné 4, via le réseau Internet RI. Les données de applet" à charger dans la à puce 2a, référencées Da, sont stockées sur ce serveur 4. Une requête "HTTP" permet de les transférer vers la carte à puce 2a, via le terminal 1 (et lecteur de carte à puce non représenté), par mise en #uvre du protocole de communication Internet "TCPIIP".
Dans l'architecture de système représentée sur la figure 12B, la partie de programme de chargement OL et les données Da sont stockées localement dans le terminal 1. La connexion du terminal 1 au réseau Internet RI est optionnelle. Pour le moins, elle n'est pas requise pour le chargement d'une "applet" selon les étapes du procédé de l'invention. Cette connexion a été représentée en traits pointillés. Le terminal peut donc être autonome.
Dans l'architecture de système représentée sur la figure 12C, la partie de programme de chargement OL et les données Da sont stockées dans un serveur distant 4. Les communications entre le serveur 4 et la carte à puce 2a, via le réseau Internet Ri, le terminal 1 et le lecteur de carte à puce (non représenté) s'effectue par des requêtes "HTTP", et mise en ceuvre protocole "TC PII P".
L'architecture de système représentée sur la figure 12D similaire à celle de la figure 12C. La seule différence est que la partie de programme de chargement OL est stockée dans un premier serveur distant, référencé 4a, et les données Da, sont stockées dans un second serveur distant, référencé 4b.
Dans l'architecture de la figure 12E, la partie du programme de chargement, référencée ici OU, est constituée par un composant navigateur 1 lui-même. II s'agit avantageusement d'une "applet" intégrée dans ce navigateur. Le type d'entrée à utiliser dans ce cas est "file" (fichier).
De façon avantageuse également, les données Da, de "applet" à charger sur la carte à puce 2a, peuvent être stockées sur un support d'enregistrement de données externe 9, par exemple une disquette comme illustré par la figure 12E. Naturellement d'autres supports sont utilisables CedéROM, bande magnétique, etc.
Si on utilise la méthode "POST" précitée, il suffit de spécifier la lettre de l'unité dé stockage, par exemple "A" pour la disquette 9, un éventuel chemin (répertoire, sous-répertoires) et le nom du fichier à charger. Pour fixer les idées, le chemin complet pourrait être typiquement A:IAPPLET. BIN (8) Du fait de la fonction serveur/client "WEB" offerte la carte à 2a, selon une des caractéristiques du procédé de l'invention, navigateur est à même, contrairement à l'art connu, de communiquer directement avec cette dernière, comme il l'a été montré en regard des figures à 4. Les communications s'effectuent par l'ouverture de sessions entre agents appariés. L'architecture de système illustrée par la figure 12F est une variante de l'architecture de la figure 12E. Selon cette variante, la partie de programme de chargement OL est stockée dans la carte à puce 2a elle-même, sous forme d'une "applet" en langage "JAVA". Par une requête "HTTP", cette "applet" peut être chargée dynamiquement sur le terminal 1, en OL". Ce chargement s'effectue à l'aide de requêtes posées par le navigateur 10, lors d'étapes préliminaires. Une fois la partie OL chargée, les étapes ultérieures sont communes au cas précédent. Les données Da peuvent également être stockées sur un support externe, par exemple une disquette 8.
L'architecture de système de la figure 12G est une variante de celle de la figure La seule différence est que la partie de programme de chargement est stockée sur un serveur éloigné 4, sous forme d'une "applet" en langage "JAVA". Comme précédemment, par une requête "HTTP", cette "applet" peut etre chargée dynamiquement sur le terminal 1, en OL". Ce chargement s'effectue à l'aide de requêtes posées par le navigateur 10, lors d'étapes préliminaires. Les autres étapes sont communes au cas précédent.
II est clair que d'autres variantes d'architecture peuvent être mises en oeuvre sans sortir du cadre de l'invention. II est notamment possible de charger les données dans le terminal 1 à partir de diverses sources : par exemple à partir d'un autre système informatique, connecté au terminal 1 par un réseau local ou tous autres moyens télématiques.
A lecture de ce qui précède, on constate aisément que l'invention atteint bien buts qu'elle s'est fixés.
La mise en oeuvre du chargement d'une "applet" dans une carte à puce par l'interface "CGI" d'un serveur "WEB" logé dans cette carte à puce présente notamment avantages suivants L'utilisation de formulaires en langage "HTML" standardise chargement rend les parties de programmes de chargement OL et IL a priori compatibles. effet, comme il a été montré, c'est la partie IL située dans carte à puce décrit, dans les champs du ou des formulaire(s) renvoyé(s), paramétrage chargement auquel il s'attend.
ailleurs, ce mécanisme de communication entre les parties programme chargement OL et IL permet de gérer simplement des séquences d'échanges dynamiques lors du chargement.
L'utilisation des protocoles Internet "HTTP" et "TCPIIP" pour échanges entre les parties de programme de chargement OL et IL permet de séparer physiquement. Seul un routage de paquets "IF est nécessaire sur terminal. chargement peut alors se faire dans un lecteur carte à puce banalisé, puisque l'on conserve le protocole de communication ISO 7816. terminal peut etre un simple micro-ordinateur standard connecté à Internet.
Selon un aspect avantageux également du procédé de l'invention, applications stockées dans la carte à puce restent standards, et donc n'ont à être réécrites. La carte à puce et le terminal eux-mêmes ne nécessitent peu de modifications pour pouvoir accommoder le procédé de l'invention : ces dernières se résument à l'implantation, dans ces deux unités, d'une couche logicielle de protocole de communication qui a été appelée spécifique, couche logicielle incluant des agents intelligents.
Alternativement, la partie de programme de chargement OL peut être chargée dynamiquement sur le terminal, au travers la carte, à partir de celle-ci ou d'un serveur "HTTP" éloigné.
et présenter les liens ajoutés obtenus à partir de ces répertoires (répertoires candidats) par exemple à travers le premier répertoire de la première liste de la figure 5 5 a, qui est proposé à l'utilisateur par défaut.
La figure 64 illustre la présentation graphique d'un lien ajouté inverse sur une page (sous forme d'affichette). Une page p1 a un lien ajouté sur une page p2 qui est déjà très encombrée d'une multitude de liens ajoutés présentés graphiquement sous forme de vignettes (dans une liste verticale). Sur la page p2, le lien ajouté inverse pointant sur p1 n'est pas présentée comme une vignette de plus, mais sous forme d'une affichette directement sur le contenu de la page. La représentation graphique du lien ajouté inverse peut aussi être automatiquement inséré dans une région qui normalement aurait dû contenir de la publicité. L'administrateur espère par là attirer l'attention de l'internaute.
En effet, non seulement, un lien ajouté inverse incite directement l'utilisateur à accéder à la page vers laquelle il pointe (en l'occurrence la page p1 de la figure 64), mais en outre, les liens ajoutés de la page (p2) à laquelle le lien ajouté inverse est associé peuvent être publiés (voir la section Publication de liens ajoutés ) et être ainsi propagés d'un utilisateur à l'autre.
La prévision d'audience peut être effectuée avantageusement en appliquant le coefficient de probabilité d'acceptation qui tient compte du comportement des utilisateurs (tel que décrit plus haut dans la section Détection de Répertoires Proches ).
Section 9 - Publication de Répertoires Un perfectionnement du système consiste à permettre à l'utilisateur de publier (ou mettre à la disposition d'un groupe restreint) au moins un sous-ensemble des répertoires de sa toile personnelle.
De la même manière que dans l'approche décrite plus haut dans la section Publication de liens Ajoutés , les liens vers des pages contenus dans un répertoire publié pourront être visualisés : - directement au moyen d'un navigateur standard (par exemple suite à la réception d'un e-mail) ; - ou au moyen du système.
On observera que l'on pourrait mettre également en archive les éléments supprimés dont le compteur de dérivation est nul pour permettre leur restauration... Dans ce cas, la vidange se ferait de la même manière qu'avec la corbeille d'un explorateur de fichiers. Les éléments ne pourront cependant être vidangés tant que leur compteur de dérivation est non nul. e) Action 4 : de sous-éléments implicites Les éléments dérivés possèdent implicitement les sous-éléments de l'élément original.
Le répertoire consulté par l'utilisateur au moyen du système devient son répertoire courant. Il peut s'agir d'un de ses propres répertoires ou d'un répertoire publié par un autre utilisateur. L'utilisateur peut manuellement insérer de nouveaux liens dans ce répertoire.
L'utilisateur qui visualise le contenu d'un répertoire au moyen du système, peut également enrichir ce contenu en se faisant suggérer des liens à partir d'autres répertoires qui lui sont proposés dans les listes Spécialistes , Voisins d'intérêt , et Copains (comme pour le cas des liens Ajoutés). Ces trois listes sont rappelées ci-dessous : 1. Les répertoires Spécialistes sont ceux proposés par l'administrateur du site, et celui-ci peut proposer à l'utilisateur un nombre de répertoires Spécialistes (candidats) plus grand que le nombre de répertoires qui seront présentés dans cette première liste. Le système sélectionne : - d'abord les répertoires spécifiés comme devant être présentés par défaut (s'il en existe), - ensuite, au fur et à mesure de l'acceptation de liens par l'utilisateur (l'acceptation est décrite plus loin dans cette section) dans le répertoire courant, le système sélectionne les répertoires dont les liens sont les plus voisins possibles des liens couramment déjà acceptés (ou gelés) par l'utilisateur.
Pour ce faire, le système choisit essentiellement les répertoires contenant le plus de liens en commun avec l'ensemble de liens acceptés (ou gelés) par l'utilisateur au moment courant.
Un répertoire Spécialiste peut contenir un nombre de liens supérieur au nombre de liens qui seront suggérés à l'utilisateur. Le système sélectionne alors de préférence les liens associés par le plus grand nombre de liens ajoutés (dans le répertoire Spécialiste candidat) avec des liens qui (dans le répertoire courant) sont déjà acceptés. Bien évidemment, ne seront suggérés à l'utilisateur que les liens qui ne figurent pas déjà dans le répertoire courant.
2. Les répertoires de Voisins d'intérêt sont déterminés automatiquement par le système. Ce sont : - soit des répertoires proches et de même catégorie, qui sont déterminés en amenant le système à sélectionner, parmi les répertoires de même catégorie, ceux qui contiennent le plus de liens en commun avec les liens acceptés (ou gelés) par l'utilisateur.
- soit des répertoires contenant le plus de liens en commun avec des liens acceptés (ou gelés) dans le répertoire courant, quelles que soient leurs catégories ; cette approche peut se révéler performante si la sélection de ces répertoires peut se faire en accès direct à partir des liens contenus dans le répertoire courant (voir le type de requête schématisé sur la figure 65) ; outre, cette approche permet d'associer des catégories aux répertoires automatiquement, car les catégories associées à chaque répertoire déterminé automatiquement sont proposées à l'utilisateur, lorsque ce dernier sélectionne ledit répertoire.
Le grand avantage de ce procédé est qu'il permet aux utilisateurs d'associer aux répertoires des catégories appartenant à un vocabulaire commun (le système incite à parler un langage commun ).
3. Les répertoires Copains sont les répertoires choisis par l'utilisateur (Voir la section Publication de liens Ajoutés ).
Le principe de Publication et Suggestion étant le même que pour la Publication de liens Ajoutés (voir la section Publication de liens Ajoutés ), nous ne précisons pas ici tous les détails, mais quelques particularités des liens (associés aux répertoires) par opposition aux liens ajoutés (associés aux pages).
Dans l'ensemble de liens (vers des pages) qui sont contenus dans le répertoire que l'utilisateur est en train de visualiser, l'utilisateur reçoit des liens supplémentaires à partir des répertoires sélectionnés dans les trois listes sus-décrites (Spécialistes, Voisins, Copains).
Comme pour les liens Ajoutés, le système peut avantageusement comporter des moyens pour sélectionner des liens sur la base de critères ( Offreur , Demandeur , etc), données par l'utilisateur ou associés au répertoire visualisé.
Les liens qui sont ainsi suggérés à l'utilisateur doivent être distingués de ceux qu'il avait lui-même ajoutés : il peut en effet en refuser certains. Dans ce but, les liens peuvent se trouver dans un parmi plusieurs modes différents: Suggéré , Accepté , Refusé (et Gelé , ce dernier mode étant décrit dans la section Liens en mode Gelé ).
Les liens reçus par un premier utilisateur, à partir des liens publiés par un deuxième utilisateur (ou à partir d'un des répertoires du premier utilisateur), sont chez le premier utilisateur au départ en mode Suggéré .
L'Utilisateur A peut ainsi automatiquement filtrer (dans ses requêtes) les suggestions faites par des Utilisateurs dont le degré de confiance est inférieur à un certain seuil.
L'intérêt de cette fonction réside surtout dans le fait que l'évaluation (ou notation) se fait dans le cadre l'utilisation courante de l'outil, de manière transparente.
En effet, l'Utilisateur A a confiance dans les suggestions faites par l'utilisateur B. Donc si l'Utilisateur B estime que les suggestions de l'Utilisateur C ne correspondent pas à ses attentes, alors l'Utilisateur A peut être confiant qu'il aurait la même opinion négative.
Par exemple, pour que l'Utilisateur A puisse se fier au jugement de l'Utilisateur B au sujet de l'Utilisateur C, le degré de confiance qu'accorde l'Utilisateur A à l'Utilisateur B doit être supérieur à un certain seuil depuis un certain temps (critère de stabilité).
La présente invention a également pour objet des homopolymères ou copolymères comportant des motifs d'au moins un monomère de formule (I) tel que défini ci-dessus.