INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Un exemple peut être utilisé pour maximiser la disponibilité en puissance lors de la décharge. Par exemple, on cherche à disposer d’une puissance utile le plus longtemps possible. La puissance maximale est typiquement limitée par la tension minimale de l’élément, sa température et sa résistance à l’état passant.
Pour ce faire, on estime, pour chaque élément, un SoC minimum (SoCmin) qui lui permet de fournir la puissance .
Ensuite, on définit un coefficient de priorité qui correspond à un écart entre le SoC actuel et ce SoC min pour chaque brique : [MATH 4] Le mécanisme d’équilibrage cherchera alors à équilibrer les et donc l’écart d’état de charge entre l’état actuel et l’état limite qui ne permet plus de fournir la puissance .
Il est possible de rajouter par ailleurs un coefficient k de pondération avec la température T pour limiter la dispersion en température: [MATH 5] Dans un exemple, on prend en compte l’état de santé (SoH) des éléments, en plus de leur état de charge (SoC) : [MATH 6] Si on peut supposer que les éléments d’un pack batterie neuf ont toutes un état de santé égal (à 100%), cela n’est pas forcement vrai avec un pack qui a été utilisé. En effet, les éléments d’un pack ne vieillissent pas de la même manière et des écarts de SoH entre les éléments peuvent se créer au fur et à mesure de l’utilisation du pack.
Cette solution permet de normaliser l’état de charge d’un élément par rapport à son état de santé et de solliciter en priorité les éléments en meilleure santé.
Le mode de fonctionnement, charge ou décharge, peut être aussi pris en compte ; par exemple, on peut avoir : , avec :
11 : roulette 12 : bras coulissant
13 : rail horizontal de la structure de stockage 14 : bâti de l’élévateur vertical
15 : cadre de la plateforme 16 : traverse inférieure de l’organe de stockage
17 : vélo 18 : bâti de la structure de stockage
19 : glissière à crémaillère
20 : plateau amovible
21 : râtelier
22 : utilisateur
23 : sas de chargement/déchargement
24 : support
25 : portion d’ancrage
Actionneur électromécanique comportant un moteur électrique sans capteurs, installation de fermeture comportant un tel actionneur électromécanique La présente invention concerne un actionneur électromécanique, en particulier pour une installation de fermeture, d’occultation ou de protection solaire, notamment pour un bâtiment, ainsi qu’une installation de fermeture, d’occultation ou de protection solaire comprenant un écran mobile, en particulier enroulable sur un tube d’enroulement entraîné en rotation, par un tel actionneur électromécanique. La présente invention concerne un procédé de pilotage d’un actionneur électromécanique.
Un dispositif d’entraînement motorisé au sens de la présente demande peut comporter un actionneur électromécanique d’un élément mobile de fermeture, d’occultation ou de protection solaire tel qu’un volet, une porte, une grille, un store ou tout autre matériel équivalent, appelé par la suite écran.
L’invention est applicable aux actionneurs électromécaniques comprenant un moteur électrique sans balais à commutation électronique, appelé également « BLDC » (acronyme du terme « BrushLess Direct Current ») ou de manière plus générale un moteur électrique synchrone à aimants permanents, appelé également « PMSM » (acronyme du terme « Permanent Magnetic Synchronous Motor »).
L’invention est plus particulièrement applicable au cas où ces moteurs électriques sont dépourvus de capteurs de position.
Description détaillée Selon des modes de réalisation particuliers de l’invention, un procédé de gestion des gains de jeux de loterie digitaux d’argent et de hasard multi-joueurs comprend une première phase durant laquelle un joueur participe à un ou plusieurs jeux digitaux élémentaires de hasard, dont l’un au moins est multi-joueurs, tous les jeux ayant un taux de retour aux joueurs de cent pour cent (on parle de jeux à redistribution totale), et une seconde phase durant laquelle le joueur participe à un jeu élémentaire de hasard, mono-joueur, qui a un taux de retour aux joueurs inférieur à cent pour cent. Ce taux de retour aux joueurs inférieur à cent pour cent est représentatif du taux de retour aux joueurs des jeux de la première phase que l’opérateur de jeux aurait normalement appliqué.
Le ou les jeux élémentaires d’argent de la première phase s’effectuent, de préférence, avec une monnaie virtuelle, obtenue par exemple par conversion de devises (monnaie réelle) en une monnaie virtuelle, par exemple en jetons, avant la participation aux jeux élémentaires de la première phase. De même, le jeu élémentaire d’argent mono-joueur de la seconde phase s’effectue également, de préférence, avec la monnaie virtuelle, une conversion des gains exprimés en monnaie virtuelle en devises (monnaie réelle) étant effectuée à l’issue du jeu élémentaire d’argent mono-joueur.
Les jeux de la première phase sont par exemple regroupés sur une plateforme de jeux digitale alimentée par des opérateurs de jeux de plusieurs juridictions, les jeux pouvant alors être partagés par tous les opérateurs de jeux, de sorte à étoffer leurs offres de jeux. On dira donc que cette plateforme de jeux est multi-juridictionnelles. Un joueur peut alors avoir accès à des jeux conçus par divers opérateurs de jeux, en utilisant son opérateur de jeux habituel, par exemple l’opérateur de loterie de la juridiction dans laquelle il habite. Le jeu mono-joueur de la deuxième phase est, quant à lui, spécifique à l’opérateur de jeux par lequel le joueur est passé pour accéder aux jeux de la première phase, dans le sens où le taux de retour aux joueurs dudit jeu est déterminé par cet opérateur de jeux. Les taux de change associés aux conversions monnaie réelle vers monnaie virtuelle et inversement, sont également déterminés par cet opérateur de jeux. Ainsi, la gestion des jeux multi-juridictionnels de la plateforme digitale, c’est-à-dire les jeux de la première phase, n’implique pas la prise en compte de multiples devises et/ou de TRJ.
La illustre un exemple d’environnement 100 dans lequel l’invention peut être mise en œuvre selon des modes de réalisation particuliers. Comme représenté, un joueur peut participer à des jeux digitaux d’argent et de hasard, notamment multi-joueurs, par l’intermédiaire d’un opérateur de jeux, à partir d’un terminal 105, par exemple un terminal d’un point de vente (aussi appelé POS, acronyme de point of sale en terminologie anglo-saxonne), d’un smartphone 110, d’une tablette 115 ou d’un ordinateur personnel (non représenté). Ce terminal, ce smartphone, cette tablette et/ou cet ordinateur personnel sont connectés à un ou plusieurs serveurs 120, par exemple un serveur de l’opérateur de jeux, via un réseau de communication 125. Ces serveurs mettent en œuvre différents modules tels que des gestionnaires de jeux, des moteurs de jeux, des gestionnaires de comptes joueurs et des gestionnaires de requêtes de joueurs. Des exemples de tels modules sont décrits plus en détail en référence aux figures 3 à 6.
Le terminal 105, le smartphone 110 et la tablette 115 comprennent des moyens de communication filaires ou sans fil, par exemple des moyens de communication conformes aux standards WiFi, Bluetooth ou Ethernet (WiFi et Bluetooth sont des marques). De même, le serveur 120 comprend des moyens de communication. A nouveau, il peut s’agir, par exemple, de moyens de communication conformes aux standards WiFi, Bluetooth ou Ethernet. Les moyens de communication de ces dispositifs peuvent s’appuyer sur des protocoles de communication standard, par exemple le protocole TCP/IP (sigle de Transmission Control Protocol / Internet Protocol en terminologie anglo-saxonne).
Pour participer aux jeux, le terminal 105, le smartphone 110 et/ou la tablette 115 peuvent utiliser des applications spécifiques ou une interface web, notamment pour choisir le ou les jeux auxquels souhaite participer le joueur, indiquer des montants de mise, obtenir des résultats de jeux et le paiement de gains.
La illustre un exemple d’étapes d’un procédé de gestion des gains de jeux digitaux d’argent et de hasard, selon des modes de réalisation particuliers de l’invention.
Comme illustré, une première étape (étape 200) a pour objet la conversion d’un montant exprimé en monnaie réelle en un montant exprimé en monnaie virtuelle, utilisé par un joueur pour participer à des jeux, le joueur accédant à ces jeux par l’intermédiaire d’un opérateur de jeux. Cette étape peut comprendre le débit d’un premier compte joueur géré par l’opérateur de jeux, par exemple un compte joueur en euros, et le crédit d’un second compte joueur en monnaie virtuelle, par exemple en jetons. A titre d’illustration, la conversion peut être réalisée par un simple taux de change, par l’application d’un taux de change après retrait d’un montant forfaitaire de frais de conversion prélevés par l’opérateur de jeux ou selon des offres forfaitaires. Le second compte joueur, en monnaie virtuelle, peut être un compte temporaire, lié à une session de jeux, ou non.
Une seconde étape vise la participation du joueur à un ou plusieurs jeux digitaux élémentaires de hasard (comme suggéré par la flèche en trait pointillé), dont le taux de retour aux joueurs est ici de cent pour cent (étape 205). Au moins l’un de ces jeux est multi-joueurs. A ces fins, chaque joueur choisit le ou les jeux auxquels il souhaite participer, indique le montant de la mise et fournit une information relative au compte joueur à utiliser. Les mises sont ici effectuées dans la monnaie virtuelle, à partir du second compte joueur. De même, les gains sont attribués dans cette monnaie virtuelle et sont crédités sur le second compte joueur.
Après qu’un joueur ait participé à un ou plusieurs jeux élémentaires d’argent en utilisant sa monnaie virtuelle, il participe à un jeu élémentaire d’argent mono-joueur, toujours en utilisant sa monnaie virtuelle (étape 210). Le taux de retour aux joueurs de ce jeu est inférieur à cent pour cent. Le joueur indique le montant de la mise et fournit une information relative au compte joueur à utiliser. De même, les mises et les gains sont ici effectués dans la monnaie virtuelle. Le jeu élémentaire d’argent mono-joueur peut être déterminé par l’opérateur de jeux ou choisi par le joueur.
Dans une étape suivante, le montant du gain éventuel est converti en monnaie réelle (étape 215) pour être crédité sur le compte joueur en monnaie réelle correspondant, selon un taux de change déterminé par l’opérateur de jeux.
L’ensemble du processus depuis la mise en monnaie virtuelle au jeu mono-joueur jusqu’au gain en monnaie réelle, c’est-à-dire les étapes 210 et 215, forme un jeu appelé jeu de conversion, référencé 220.
La illustre un premier exemple d’architecture logique d’un système informatique pour mettre en œuvre un procédé de gestion des gains de jeux digitaux d’argent et de hasard multi-joueurs, selon des modes de réalisation particuliers de l’invention.
Comme illustré, cette architecture repose ici sur trois modules distincts, un module de jeux 300, un module de gestion des participations 305 et un module de stockage des comptes joueurs en monnaie réelle 310. Naturellement, le nombre de modules n’est pas limité à trois, il peut y en avoir plus ou moins. La répartition des fonctions dans les modules peut également être différente de celle illustrée sur la .
Le module de jeux 300 comprend ici des moteurs de jeux mono-joueur 315 et des moteurs de jeux multi-joueurs 320 ainsi qu’un sous-module de gestion des sessions de jeux 325. Selon l’exemple illustré, le module de gestion des participations 305 comprend un sous-module de réception des requêtes issues de dispositifs de joueurs ou de dispositifs sous leur contrôle, référencé 330, un sous-module de gestion de routage de transactions 335, un sous-module de gestion de comptes joueurs en monnaie virtuelle 340 et un sous-module de conversion de montants exprimés en monnaie virtuelle en monnaie réelle et réciproquement, référencé 345. Les comptes joueurs en monnaie réelle sont ici stockés dans le module de stockage des comptes joueurs en monnaie réelle, comprenant un sous-module de gestion des comptes joueurs en monnaie réelle 350.
Comme illustré, les requêtes reçues de joueurs pour participer à des jeux d’argent sont transmises au sous-module de gestion des sessions de jeux du module de jeux ainsi qu’au sous-module de gestion de routage de transactions du module de gestion des participations qui gère les mises et les gains, dans les monnaies virtuelle et réelle. Le sous-module de gestion des sessions de jeux gère les jeux selon les participations et transmet les résultats de jeux au sous-module de gestion de routage de transactions qui gère les transactions relatives aux mises et aux gains, en lien avec le sous-module de gestion des compteurs joueurs et avec le sous-module de conversion entre les monnaies virtuelle et réelle, comme décrit plus en détail en référence aux figures 4 à 6.
Dans un mode de réalisation, le procédé comprend l’interruption de la boucle d’itération en l’absence dudit ajout du récepteur sélectionné au sous-ensemble courant au cours d’une itération.
Ainsi, on sort de l’itération au moment où ajouter un nouveau récepteur au sous-ensemble courant n’est plus avantageux au sens de la métrique de performance et/ou si cet ajout excède le nombre de couches spatiales disponibles. Cette interruption de la boucle d’itération évite de dégrader les performances d’émission à force de vouloir inclure trop de récepteurs. L’émetteur est ainsi quasi-optimal au sens de la métrique de performance, tout en respectant les contraintes de couches spatiales ci-dessus.
Dans un mode de réalisation, la sélection du récepteur dont l’ajout au sous-ensemble courant maximise la métrique de performance comprend
- l’obtention de la métrique de performance pour le sous-ensemble courant ,
- le calcul, pour au moins un récepteur candidat extérieur au sous-ensemble courant , d’une métrique candidate égale à la métrique de performance de l’union du sous-ensemble courant et dudit récepteur candidat , et
- la détermination, comme récepteur sélectionné , du récepteur candidat présentant la métrique candidate la plus grande.
L’étape de calcul peut être réalisée pour tous les récepteurs extérieurs au sous-ensemble courant. En variante, on pourrait envisager un pré-tri des récepteurs extérieurs, de sorte à diminuer la complexité de la sélection du meilleur récepteur candidat, en éliminant (pour le cycle de sélection du meilleur candidat en cours) les récepteurs dont il est évident qu’ils ne seront pas de bons candidats.
Dans un mode de réalisation, ladite au moins une ressource temps-fréquence associée à une sous-trame et une sous-bande , le calcul de la métrique candidate pour le récepteur candidat comprend le calcul d’une métrique partielle pour chaque récepteur courant appartenant à l’union du sous-ensemble courant et du récepteur candidat , la métrique candidate étant égale à la somme des métriques partielles calculées, ledit calcul de la métrique partielle comprenant
- l’estimation d’un débit pour le récepteur courant pour ladite sous-trame et ladite sous-bande ,
Ici, on utilise une métrique « proportional fair », notée métrique PF. L’objectif de cette métrique de performance est double : maximiser la bande passante de l’émetteur, sans pour autant léser les récepteurs, en assurant à chacun une qualité de service (par exemple un débit) minimale. A chaque sous-trame, l’émetteur prend ainsi en compte, pour différents récepteurs, leurs débits passés ( i.e. débits moyens pondérés jusqu’à la sous-trame précédente), leur débit présent ( i.e. débit sur la sous-bande donnée et sur les sous-bandes déjà allouées) et leurs débits potentiels (débits sur les sous-bandes non encore allouées) pour sélectionner le meilleur récepteur possible (au sens de la métrique PF).
La pondération par le premier paramètre permet de régler finement le poids que l’on accorde aux débits passés (synthétisés dans la fonction ) et potentiels (synthétisés dans la moyenne ).
Dans un mode de réalisation, le débit moyen pondéré par sous-trame est déterminé récursivement pour chaque récepteur de l’ensemble de récepteurs par l’initialisation et par la récursion suivante, où :
si le récepteur appartient au sous-ensemble à la sous-trame , où est le débit pour la sous-trame et pour toutes les sous-bandes allouées audit récepteur , , et où est un deuxième paramètre,
Les figures 4 à 6 illustrent un exemple de diagramme temporel d’étapes d’un procédé de gestion de gans et prélèvements de jeux digitaux d’argent et de hasard multi-joueurs, selon des modes de réalisation de l’invention. Ce diagramme temporel illustre notamment des interactions entre un dispositif utilisé par un joueur pour participer à des jeux (ou un dispositif utilisé sous son contrôle), un module ou sous-module de gestion de requêtes (correspondant par exemple à une combinaison des sous-modules 330, 335 et 345 de la ), un module ou sous-module de gestion de comptes joueurs en monnaie virtuelle (correspondant par exemple au sous-module 340 de la ), un moteur de jeux élémentaires d’argent multi-joueurs (correspondant par exemple au sous-module 320 de la ), un moteur de jeux élémentaires d’argent mono-joueur (correspondant par exemple au sous-module 315 de la ) et un module ou sous-module de gestion de comptes joueurs en monnaie réelle (correspondant par exemple au sous-module 350 de la ).
La illustre un exemple de diagramme temporel d’étapes d’un procédé de gestion d’un compte de monnaie virtuelle selon des modes de réalisation particuliers de l’invention.
Une première étape a ici pour objet une requête visant l’achat de monnaie virtuelle par un joueur (étape 400), par l’intermédiaire d’un opérateur de jeux. Cette requête est ici adressée par le dispositif d’un joueur (ou sous son contrôle) au module ou sous-module de gestion de requêtes. Elle comprend par exemple un identifiant du joueur et un montant à transférer exprimé en monnaie réelle ou en monnaie virtuelle ainsi que, de préférence, un identifiant du compte en monnaie réelle à débiter et/ou un identifiant du compte en monnaie virtuelle à créditer. Cette requête est de préférence cryptée selon des moyens connus ou adressée via un lien de communication sécurisée. De même, toutes ou certaines des requêtes décrites ci-après sont, de préférence, cryptées ou échangées via des liens sécurisés. Il est observé ici que les identifiants des comptes à débiter et/ou à créditer peuvent être obtenus à partir d’un identifiant du joueur ou qu’un compte en monnaie virtuelle peut être créé temporairement, par exemple le temps d’une session de jeux, et associé à l’identifiant du joueur.
Une étape suivante vise le débit du compte joueur en monnaie réelle. Elle comprend notamment la transmission d’une requête de débit par le module ou sous-module de gestion de requêtes au module ou sous-module de gestion de comptes joueurs en monnaie réelle (étape 405). Cette requête comprend par exemple un identifiant du compte en monnaie réelle à débiter et un montant à débiter, exprimé en monnaie réelle. Si le module ou sous-module de gestion de comptes joueurs en monnaie réelle peut effectuer le débit, par exemple si le compte joueur est suffisamment crédité, le débit est effectué et un message de validation est transmis du module ou sous-module de gestion de comptes joueurs en monnaie réelle au module ou sous-module de gestion de requêtes (étape 410).
En réponse à la réception de validation du débit, le module ou sous-module de gestion de requêtes adresse une requête de crédit du compte joueur en monnaie virtuelle (étape 415). Cette requête est adressée au module ou sous-module de gestion de comptes joueurs en monnaie virtuelle et comprend, par exemple, un identifiant du compte en monnaie virtuelle à créditer et un montant à créditer, exprimé en monnaie virtuelle. Lorsque le compte joueur en monnaie virtuelle est crédité, un message de confirmation est adressé par le module ou sous-module de gestion de comptes joueurs en monnaie virtuelle au module ou sous-module de gestion de requêtes (étape 420) qui, à son tour, adresse un message de confirmation au dispositif utilisé par le joueur ou sous son contrôle (étape 425).
A titre d’illustration, un module de gestion de participations permettant la mise en œuvre des étapes illustrées sur la peut offrir à un joueur la possibilité de choisir un ou plusieurs forfaits parmi plusieurs forfaits prédéterminés, par exemple choisir un ou plusieurs forfaits parmi un ensemble de forfaits comprenant un forfait à 1 € comprenant 100 jetons et un forfait à 5 € comprenant 550 jetons. Toujours à titre d’illustration, après avoir choisi deux forfaits à 5 €, le compte en monnaie réelle du joueur est débité de 10 € et son compte en monnaie virtuelle est crédité de 1 100 jetons. Dans tous les cas, le taux de change appliqué à la conversion monnaie réelle vers monnaie virtuelle est défini par l’opérateur de jeux.
La illustre un exemple de diagramme temporel d’étapes d’un procédé de participation à un ou plusieurs jeux élémentaires, dont l’un au moins est multi-joueurs, selon des modes de réalisation particuliers de l’invention. Ces étapes correspondent à la première phase du procédé. Ces jeux sont accessibles au joueur par l’intermédiaire de l’opérateur de jeux susmentionné. On note toutefois que ces jeux peuvent être hébergés sur une plateforme de jeux digitale multi-juridictionnelles alimentée par des opérateurs de jeux de plusieurs juridictions. Via l’opérateur de jeux susmentionné, le joueur peut donc avoir accès à des jeux proposés par d’autres opérateurs de jeu, ces opérateurs de jeux pouvant éventuellement opérer dans des devises différentes ou utiliser des taux de retour aux joueurs différents de l’opérateur de jeux susmentionné.
Les jeux élémentaires n’utilisent ici que la monnaie virtuelle. Les mises sont ainsi effectuées avec la monnaie virtuelle. De même, les gains éventuels sont versés en monnaie virtuelle. Le taux de retour aux joueurs est ici de cent pour cent, la redistribution est donc totale. En environnement multi-juridictionnel, les problématiques de devises différentes et/ou de TRJ différents ne sont donc pas gérées lors de cette première phase.
Une première étape a ici pour objet une requête de participation à un jeu élémentaire digital de hasard (étape 500). Cette requête est ici adressée par le dispositif d’un joueur (ou sous son contrôle) au module ou sous-module de gestion de requêtes. Elle comprend par exemple un identifiant du joueur, un identifiant du jeu élémentaire d’argent auquel le joueur veut participer ainsi qu’une mise exprimée en monnaie virtuelle.
Dans une étape suivante, une requête est transmise à un moteur de jeux du jeu auquel souhaite participer le joueur (étape 505). Il est représenté ici un moteur de jeux multi-joueurs, mais il pourrait s’agir d’un moteur de jeux mono-joueur. Cette requête est transmise par le module ou sous-module de gestion de requêtes au moteur de jeux concerné. Elle comprend par exemple un identifiant du joueur, un identifiant du jeu et un montant de mise exprimé en monnaie virtuelle. Si le moteur de jeu accepte la requête de participation, il adresse, en retour, une requête de débit correspondant à la mise (étape 510). Elle est ici transmise au module ou sous-module de gestion de requêtes.
Suite à la réception d’une requête de débit, le module ou sous-module de gestion de requêtes transmet une requête de débit équivalente au module ou sous-module de gestion de comptes joueurs en monnaie virtuelle (étape 515). Si ce dernier valide la requête, par exemple si le compte du joueur en monnaie virtuelle est suffisamment crédité, le débit est effectué et un message de confirmation est transmis au module ou sous-module de gestion de requêtes (étape 520). Un message de confirmation correspondant est alors transmis au moteur de jeux (étape 525) qui valide la participation du joueur ainsi qu’au dispositif de ce dernier ou contrôlé par ce dernier (étape 530).
A l’issue d’une session du jeu élémentaire d’argent, le ou les gagnants sont identifiés (étape 535), par exemple à l’aide de leurs identifiants transmis dans les requêtes de participation.