FR2985050A1 - Procede de reveil d'un ordinateur, et systeme de reveil correspondant - Google Patents

Abstract

Il est proposé un procédé de réveil d'un ordinateur (PC) se trouvant dans un état éteint ou de veille, comprenant les étapes suivantes : - réception d'un événement déclencheur par une entité de commande (R) ; - l'entité de commande envoie à travers un réseau de télécommunication une requête de réveil vers un périphérique (K) de l'ordinateur, apte à communiquer via ledit réseau de télécommunication, connecté via un connecteur à l'ordinateur, le périphérique étant alimenté par le connecteur, le connecteur restant alimenté quand l'ordinateur est dans l'état éteint ou de veille ; - le périphérique transmet au connecteur un signal de réveil, permettant de réveiller l'ordinateur.

Description

Procédé de réveil d'un ordinateur, et système de réveil correspondant. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des ordinateurs et des réseaux de télécommunication.

Plus précisément, l'invention concerne une technique de réveil à distance, via un réseau de télécommunication, d'un ordinateur se trouvant dans un état éteint ou de veille. La technique de réveil à distance selon l'invention s'applique notamment, mais non exclusivement, dans le cadre de la mise en oeuvre par un serveur d'un service à disponibilité permanente, avec lequel communiquent des applications clientes exécutées par des ordinateurs. On entend par « service à disponibilité permanente » un service devant pouvoir se connecter à tout moment à des applications clientes (exécutées par des ordinateurs) qui utilisent ou sont utilisées par ce service. Citons à titre d'exemples de tels services : - un service de sauvegarde par le réseau, utilisé par des applications clientes souhaitant sauvegarder de manière externe des données stockées sur les ordinateurs qui exécutent ces applications clientes, et/ou utilisant des applications clientes acceptant de sauvegarder des données d'autrui sur les ordinateurs qui exécutent ces applications clientes ; - un service de diagnostic à distance, utilisé par des applications clientes souhaitant obtenir un diagnostic du fonctionnement matériel et/ou logiciel des ordinateurs qui exécutent ces applications clientes ; - un service collaboratif de calcul scientifique réparti, utilisé par des applications clientes souhaitant externaliser (hors des ordinateurs qui les exécutent) des calculs, et/ou utilisant des applications clientes acceptant d'effectuer des calculs d'autrui sur les ordinateurs qui exécutent ces applications clientes ; - un service de jeu en réseau, utilisé par des applications clientes se faisant notifier de nouveaux éléments ; - etc.

Le terme « ordinateur » doit se comprendre comme désignant tout type d'ordinateur : ordinateurs de poche (assistant personnel, terminal de poche (smartphone)), ordinateurs portables (ultraportable, tablette PC, ordinateur portable), ordinateurs de bureau (mini PC, ordinateur de bureau, station de travail), ordinateurs intermédiaires (mini-ordinateur), etc. Le terme « serveur » doit être compris comme désignant une entité quelconque (aussi appelée « fournisseur de service ») disposant de moyens matériels et logiciels permettant de fournir un service via un réseau (Internet par exemple). 2. ARRIÈRE-PLAN TECHNOLOGIQUE La technologie « Wake-on-LAN », supportées par certaines cartes mères, permettent le réveil d'un ordinateur connecté à un réseau local (LAN, pour « Local Area Network » en anglais) filaire (typiquement Ethernet) par un autre appareil (terminal) de ce réseau qui supporte cette technologie. Dans la pratique, cette technologie est d'un usage encore restreint, car : - la carte-mère de l'ordinateur doit être compatible (elle doit avoir un connecteur WakeUp-Link auquel est branchée une carte réseau via un câblage spécial à trois fils (ou un câblage deux fils si l'alimentation est relayée par un bus PCI) ; - l'ordinateur doit être connecté en Ethernet (ce qui est de moins en moins le cas, du fait de la popularité des technologies WiFi) ; - l'appareil servant au réveil doit être allumé et également compatible.

Dans un usage à distance (typiquement, réveil d'un ordinateur à travers le réseau Internet), seule la passerelle domestique (routeur Internet auquel est relié le réseau local sur lequel se trouve l'ordinateur à réveiller) est susceptible de remplir ces conditions et d'être joignable. Ceci restreint les possibilités de mise en oeuvre de cette technique connue de réveil à distance d'un ordinateur, car l'implémentation de la technologie « Wake-on-LAN » n'est pas systématique ou parfois incorrecte. Par ailleurs, un inconvénient majeur des services à disponibilité permanente, dans leur mise en oeuvre actuelle, est que les applications clientes (qui utilisent ou sont utilisées par de tels services) ont pour contrainte, par nature, que l'ordinateur qui les exécute soit sans interruption allumé pour garantir une disponibilité permanente.

Ainsi, lorsque l'utilisateur d'une telle application cliente, par exemple un particulier, consent à laisser son ordinateur allumé (y compris la nuit), c'est au prix d'une consommation électrique augmentée, voire d'autres nuisances (chaleur, bruit, etc.). Réciproquement, tous les utilisateurs refusant (notamment pour des raisons de performances ou de sécurité) de consentir à laisser leur ordinateur allumé et connecté au réseau en permanence constituent une part de clientèle potentielle que l'exploitant du service ne peut capter, dans l'état de l'art actuel. Un tel refus est par exemple fréquent pour les utilisateurs de stations d'enregistrement musical, de retouche vidéo, etc. Il existe donc un besoin de pouvoir concevoir et exploiter des services à disponibilité permanente, tels que les ordinateurs (exécutant les applications clientes qui utilisent ou sont utilisées par ces services) n'aient pas besoin d'être allumés et connectés au réseau en permanence. 3. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de réveil d'un ordinateur se trouvant dans un état éteint ou de veille, caractérisé en ce qu'il comprend les étapes suivantes : - réception d'un événement déclencheur par une entité de commande ; - l'entité de commande envoie à travers un réseau de télécommunication une requête de réveil vers un périphérique de l'ordinateur, apte à communiquer via ledit réseau de télécommunication, connecté via un connecteur à l'ordinateur, le périphérique étant alimenté par le connecteur, le connecteur restant alimenté quand l'ordinateur est dans l'état éteint ou de veille ; - le périphérique transmet au connecteur un signal de réveil, permettant de réveiller l'ordinateur. Le principe général de ce mode de réalisation particulier de l'invention consiste donc, selon une approche tout à fait nouvelle et inventive, à baser le mécanisme de réveil d'ordinateur sur une coopération, via un réseau de télécommunication, entre une entité de commande et un périphérique de l'ordinateur. Ainsi, la présente technique n'est pas dépendante de la technologie « Wake-on-LAN » et de ses contraintes. Notamment, elle ne nécessite pas d'utiliser une passerelle domestique à laquelle est relié un réseau local sur lequel se trouve l'ordinateur à réveiller.

L'utilisation d'un périphérique apte à communiquer via un réseau de télécommunication, par exemple via un réseau cellulaire d'un opérateur (par exemple via un réseau GSM ou autre), permet de piloter facilement à distance le réveil de l'ordinateur, sans les contraintes actuelles de la solution Wake-on-LAN. En outre, elle pourra s'appliquer à un ordinateur mobile, indépendamment de son raccordement ou non à un réseau local. On bénéficie en outre d'une solution portable de réveil à distance, puisque le périphérique peut être enfiché dans n'importe quel ordinateur doté d'un connecteur compatible. Si le connecteur est par exemple un connecteur USB, très répandu, la solution sera transposable à tout équipement disposant d'un tel connecteur et apte à traiter le signal de réveil que lui envoie ce connecteur. Dans une application particulière, l'entité de commande comprend un bloc de commande qui émule une interface de commande d'une application cliente installée dans l'ordinateur et qui pilote un bloc d'envoi de requête de réveil.

La solution est donc applicable pour la mise en oeuvre d'un service distant, devant pouvoir se connecter à tout moment à une application cliente exécutée par un ordinateur, l'interface de commande émulée étant une interface de communication utilisée par l'application pour communiquer avec ce service distant. Selon une caractéristique particulière, l'exécution de l'application cliente est démarrée automatiquement après le réveil de l'ordinateur. Selon une caractéristique particulière, l'événement déclencheur est envoyé par un serveur mettant en oeuvre un service avec lequel l'application cliente est conçue pour communiquer via ladite interface de commande. Ainsi, le serveur peut se connecter à tout moment à l'application cliente, même quand l'ordinateur exécutant cette application cliente est dans un état éteint ou de veille (c'est-à-dire sans que l'ordinateur soit en permanence allumé et connecté au service, via le réseau). Ceci permet à l'application cliente d'être vue par le service (mis en oeuvre par le serveur) comme connectée en permanence, alors qu'en réalité ce n'est pas le cas. Selon une caractéristique particulière, l'événement déclencheur est un événement applicatif destiné à être traité par l'application cliente.

Selon une caractéristique particulière, l'interface de commande est connectée audit serveur avant réception dudit événement déclencheur, puis déconnectée du serveur après réception dudit événement déclencheur. Selon une première mise en oeuvre, l'entité de commande est comprise dans un réseau opérateur d'un opérateur dudit réseau de télécommunication. Dans ce cas, le mécanisme de réveil est entièrement implémenté par le réseau opérateur. Selon une caractéristique particulière, l'entité de commande est autorisée à réveiller l'ordinateur et lancer l'exécution de l'application cliente.

Selon une deuxième mise en oeuvre, l'entité de commande est comprise dans un terminal de communication d'un utilisateur autorisé à réveiller l'ordinateur et lancer l'exécution de l'application cliente. Dans ce cas, le mécanisme de réveil est entièrement implémenté par le terminal de communication.

Selon une caractéristique particulière de cette deuxième mise en oeuvre, le procédé comprend une étape de confirmation par l'utilisateur autorisé, et l'entité de commande envoie la requête de réveil vers le périphérique seulement en cas de confirmation par l'utilisateur autorisé. Ainsi, l'ordinateur n'est réveillé que si l'utilisateur autorisé confirme que c'est son souhait. Selon une caractéristique particulière, le procédé comprend une étape d'authentification de l'entité de commande ayant envoyé la requête de réveil vers le périphérique, et l'exécution de l'application cliente n'est lancée qu'en cas d'authentification réussie de l'entité de commande.

L'entité de commande joue le rôle de l'entité de confiance, il est donc important de l'authentifier, par exemple à partir de son numéro d'appelant. Selon une caractéristique particulière, l'étape d'authentification est effectuée par le périphérique, et en ce que le périphérique transmet au connecteur le signal de réveil seulement en cas d'authentification réussie de l'entité de commande.

Ainsi, en cas d'authentification manquée, on ne réveille pas inutilement l'ordinateur.

Selon une variante, l'étape d'authentification est effectuée par une application d'administration exécutée au réveil de l'ordinateur, et l'application d'administration lance l'exécution de l'application cliente seulement en cas d'authentification réussie de l'entité de commande.

Cette alternative permet de ne pas complexifier le périphérique (qui n'a pas à gérer l'authentification de l'entité de commande). Selon une caractéristique particulière, l'application cliente se connecte au serveur via un accès réseau dont dispose l'ordinateur ou le périphérique. L'utilisation d'un accès réseau dont dispose le périphérique permet de ne pas faire d'hypothèse sur l'accès réseau nominal de l'ordinateur (par exemple, l'ordinateur peut tout simplement ne pas être relié à Internet, ou être relié à Internet via un routeur lui-même hors tension). Selon une caractéristique particulière, après que l'application cliente s'est connectée au serveur, le procédé comprend une phase de réalisation d'au moins une action par le serveur et/ou l'application cliente, puis une phase de retour de l'ordinateur dans l'état éteint ou de veille. Ainsi, on optimise l'utilisation de l'ordinateur, en réduisant la consommation électrique et d'autres nuisances (chaleur, bruit, etc.). Dans un autre mode de réalisation de l'invention, il est proposé un système de réveil d'un ordinateur se trouvant dans un état éteint ou de veille. Ce système comprend une entité de commande et un périphérique de l'ordinateur, le périphérique étant apte à communiquer via un réseau de télécommunication, connecté via un connecteur à l'ordinateur, et alimenté par le connecteur, le connecteur restant alimenté quand l'ordinateur est dans l'état éteint ou de veille. L'entité de commande comprend des moyens de réception d'un événement déclencheur et des moyens d'envoi, à travers le réseau de télécommunication, d'une requête de réveil vers le périphérique. Le périphérique comprend des moyens de transmission au connecteur d'un signal de réveil, permettant de réveiller l'ordinateur. Avantageusement, le système comprend des moyens de mise en oeuvre des étapes du procédé de gestion d'un service, tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 4. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 présente un diagramme de séquence d'un premier mode de réalisation particulier de l'invention ; - la figure 2 présente un diagramme de séquence d'un deuxième mode de réalisation particulier de l'invention ; et - la figure 3 présente un diagramme de séquence d'un troisième mode de réalisation particulier de l'invention. 5. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. On décrit maintenant, en relation avec la figure 1, un premier mode de réalisation particulier de l'invention. Dans ce premier mode de réalisation, le système, qui met en oeuvre la logique de service complète, comprend un serveur SRV mettant en oeuvre un service S, un bloc de commande R2, un bloc d'envoi R1, un périphérique K et un ordinateur PC. Ces différents éléments sont détaillés ci-après. L'ordinateur PC possède un connecteur disponible, par exemple de type USB (pour « Universal Serial Bus »), ceci sans perte de généralité par rapport à une connectique offrant des fonctionnalités équivalentes. On suppose que la carte mère de l'ordinateur alimente le connecteur, même quand l'ordinateur est en état de veille (veille normale ou veille prolongée), voire en état totalement éteint. On suppose également que le connecteur permet de réveiller l'ordinateur, grâce à une séquence caractéristique d'impulsions ou de caractères transmise à ce connecteur par le périphérique K. Cette séquence caractéristique est par exemple identique à celle (classique) envoyée par un clavier ou une souris de type USB pour sortir un ordinateur d'un état de veille ou l'allumer. Dans une variante, le réveil de l'ordinateur par l'intermédiaire du connecteur est réalisé grâce à la technologie « Wake On Lan » qui, comme son nom l'indique, permet d'allumer un ordinateur cible à distance, à partir d'un ordinateur source, sous réserve que les ordinateurs source et cible soient sur le même réseau local (LAN, pour « Local Area Network »), typiquement un réseau Ethernet. Dans ce cas, l'ordinateur cible reçoit la séquence caractéristique (appelée « Magic Packet ») sur sa carte réseau. La présente invention s'applique quel que soit l'état « non réveillé » considéré. En effet, les distinctions entre les états de veille normale, veille prolongée et éteint modifient la mise en oeuvre pratique de l'invention, mais sont seulement liées à des fonctionnalités de la carte mère qui sont extérieures au principe de l'invention. L'ordinateur PC exécute une application d'administration (cette exécution est associée à un processus appelé ci-après pAdmin) et une application cliente (cette exécution est associée à un processus appelé ci-après pClient). L'application cliente (c'est-à-dire le processus pClient) utilise le service S ou est utilisé par le service S et communique dans ce but avec le serveur SRV. On suppose ici que, lors de la demande de connexion de l'application cliente au service, un compte utilisateur avec ses paramètres de connexion associés est utilisé par l'application cliente pour identifier l'utilisateur et/ou l'application cliente se connectant. Il n'est pas fait d'hypothèse sur la nature de l'application cliente (client lourd, navigateur, etc.). Par réveil de l'ordinateur, on entend notamment le réveil de la carte mère et du processus pAdmin. Le périphérique K est un équipement communiquant, apte à communiquer via un réseau de télécommunication, par exemple une clé 3G (généralement de type USB), qui peut accueillir une carte SIM (pour « Subscriber Identity Module »). Ce périphérique est par exemple apte à recevoir un appel et/ou un SMS. Le bloc de commande R2 émule une interface de commande de l'application cliente installée dans l'ordinateur PC et pilote le bloc d'envoi R1 conçu pour envoyer des requêtes de réveil. Le bloc de commande R2 sert à déclencher les appels/envois de messages du bloc d'envoi R1 vers le périphérique K. Dans ce premier mode de réalisation, le bloc de commande R2 comprend une machine virtuelle MV (par exemple, VMWare (marque déposée) ou équivalent) exécutant une copie de l'application cliente (cette exécution est associée à un processus appelé ci-après pClient') et une application de commande (cette exécution est associée à un processus appelé ci-après pCommande). Le bloc de commande R2 joue donc le rôle de l'ordinateur PC distant (et plus précisément de l'application cliente, et donc du processus pClient) vis-à-vis du service S, avec ses paramètres de connexion, propres à un compte utilisateur associé à cette application cliente. Le bloc de commande R2 agit donc comme un mandataire ou proxy, simulant la présence de l'application cliente, de telle sorte que le service S croie que cette application cliente est véritablement connectée avec le compte utilisateur qui lui est associé.

En pratique, le bloc de commande R2 met en oeuvre uniquement une interface de commande, pour la communication avec le serveur SRV et pour la réception de commande en provenance de ce serveur, cette interface de commande étant identique à celle mise en oeuvre par l'application cliente, de telle sorte que le service S puisse envoyer au bloc de commande R2 des commandes identiques à celles qu'il enverrait à l'application cliente si elle était connectée. Le bloc de commande R2 n'est cependant pas configuré pour exécuter une fonction de traitement de cette commande (par exemple une fonction de sauvegarde), comme le ferait l'application cliente si elle était connectée. L'interface de commande mise en oeuvre par le bloc de commande R2 est conçue pour recevoir un événement déclencheur, par exemple un événement déclencheur envoyé par le serveur SRV mettant en oeuvre le service S avec lequel l'application cliente est conçue pour communiquer via son interface de commande. Le bloc d'envoi R1 est configuré pour communiquer avec le périphérique K, par exemple pour émettre des appels et/ou envoyer des SMS vers la carte SIM du périphérique K.

L'ensemble constitué par les blocs R1 et R2 forme une entité de commande R, servant d'intermédiaire de confiance entre le serveur SRV et l'ordinateur PC à réveiller. Dans ce premier mode de réalisation, le bloc de commande R2 et le bloc d'envoi R1 sont compris dans un réseau opérateur RO. L'entité de commande R est une entité de confiance située chez l'opérateur. Le serveur SRV peut être extérieur au réseau opérateur RO, ou compris dans celui-ci. On décrit ci-après le séquencement du mécanisme complet de réveil et de (re)connexion de l'ordinateur PC au service S. On suppose que l'ordinateur PC distant qui est à réveiller est en état de veille. On peut distinguer un premier canal de communication établi (dénommé « interface amont ») entre le service S et le bloc de commande R2, et un deuxième canal de communication (dénommé « interface aval »), établi après le réveil de l'ordinateur PC, lors de la connexion de l'application cliente au service S. Dans une étape 11, le service S transmet via le premier canal un événement déclencheur, qui est par exemple un événement applicatif (par exemple une requête de démarrage d'une sauvegarde journalière, une requête de lancement d'un calcul, etc.), au bloc de commande R2. Cet événement déclencheur est reçu par le processus pClient'. Dans une étape 12, le processus pCommande est informé de la réception de l'événement déclencheur par le processus pClient'. Une fois le processus pCommande notifié de l'événement déclencheur, l'exécution du processus pClient' est terminée (ce qui a pour effet de provoquer sa déconnexion auprès du service S). La méthode de terminaison du processus pClient' est dépendante du mode de réalisation de ce processus pClient' et de la manière dont le processus pCommande est notifié de l'événement déclencheur : - soit le processus pClient' se termine de lui-même après réception d'un événement déclencheur puis retransmission de l'événement déclencheur par le processus pClient' au processus pCommande, car le processus pClient' est configuré pour effectuer cette retransmission et mettre fin automatiquement à son exécution après une telle retransmission ; - soit le processus pCommande analyse à la volée le flux des données parvenant au processus pClient' qui n'est pas configuré pour retransmettre l'événement déclencheur, la fin du processus pClient' étant dans ce cas commandée par le processus pCommande après détection par le processus pCommande de l'événement déclencheur dans ce flux (par exemple, par recherche d'une séquence prédéfinie de données dans ce flux).

Dans une étape 13, le processus pCommande déclenche ensuite l'appel au bloc d'envoi R1. Plus précisément, le processus pCommande envoie une requête de réveil au bloc d'envoi Rl. Dans une étape 14, afin de propager la requête de réveil, le bloc d'envoi R1 établit un lien de communication avec le périphérique K, par exemple un appel ou un envoi d'un message court (SMS, pour « Short Message Service ») vers la carte SIM du périphérique K.

Dans une étape 15, à réception du SMS ou de l'appel, une séquence caractéristique d'impulsions ou de caractères est envoyée au connecteur de l'ordinateur PC par un programme spécifique, dit programme de réveil, stocké et exécuté dans le périphérique K, ce qui (dans une étape A) réveille la carte mère et des processus exécutés alors sur l'ordinateur, dont notamment le processus pAdmin. Le périphérique K transmet au processus pAdmin un identifiant du bloc d'envoi R, par exemple le numéro appelant du SMS ou de l'appel. Dans une étape B (authentification du bloc d'envoi R1), une fois réveillé, le processus pAdmin exécute automatiquement un module logiciel de réveil qui analyse le numéro appelant du SMS ou de l'appel reçu par la carte SIM du périphérique K. Si ce numéro appelant correspond bien à celui du bloc d'envoi R1 (authentification réussie), alors, dans une étape 16, le module logiciel de réveil valide l'action de réveil et déclenche l'exécution du processus pClient. Le processus dont l'exécution doit être déclenchée par le processus pAdmin est identifié par exemple : - à partir du numéro appelant : à un numéro appelant correspondant dans ce cas un ou plusieurs processus à déclencher ; et/ou - à partir de données de configuration du programme de réveil exécuté par le périphérique K et/ou de données de configuration du module logiciel exécuté par l'ordinateur PC. Le processus pAdmin peut également, le cas échéant, déclencher d'autres processus en fonction de différents critères (par exemple, selon la date, le jour de la semaine ou l'heure courante à laquelle est démarré le processus pAdmin, le ou les processus à déclencher peuvent être différents).

Si le numéro appelant ne correspond pas à celui du bloc d'envoi R1 ou ne correspond pas à un numéro appelant valide, (authentification manquée), le processus pAdmin remet en veille l'ordinateur (ou l'éteint définitivement). Dans une variante de réalisation, l'étape authentification du bloc d'envoi R1 (notée B' au lieu de B) est effectuée par le périphérique K à réception du SMS ou de l'appel émis par le bloc d'envoi R1. Dans ce cas, l'étape 15 et les suivantes ne sont effectuées qu'en cas d'authentification réussie. Ceci permet, en cas d'authentification manquée, d'éviter d'avoir à réveiller la carte mère et le processus pAdmin pour authentifier le SMS ou l'appel. Dans une étape 17, à réception du signal de réveil envoyé par le processus pAdmin, le processus pClient (qui est associé ou résulte de l'exécution de l'application cliente du service S) se connecte au service S, par exemple grâce à un accès Internet dont dispose l'ordinateur PC, par exemple et sans perte de généralité, via un routeur Internet d'un réseau domestique ou d'entreprise. Dans une variante de réalisation de l'étape 17, le périphérique K (par exemple une clé 3G) est lui-même reconnu par le système d'exploitation de l'ordinateur en tant que périphérique d'accès à un réseau, présentant une interface matérielle et logicielle d'accès au réseau. La connexion de l'application cliente au service S utilise alors cette interface d'accès au réseau. Les blocs de commande R2 et d'interrogation R1, qui sont compris dans le réseau opérateur RO, assurent en outre une fonction de routage de données et optionnellement de proxy vers le service S. Cette variante permet entre autres de ne pas faire d'hypothèse sur l'accès Internet nominal de l'ordinateur (le routeur peut être lui-même hors tension ; l'ordinateur n'est tout simplement pas relié à Internet ; etc.), et de faire apparaître la même adresse réseau que celle utilisée précédemment par la machine virtuelle, si le service S le nécessite (fonction proxy). Dans cette variante, le processus pClient' n'est pas interrompu après propagation de l'événement déclencheur vers le périphérique K. Le processus pCommande, qui pilote le bloc d'envoi R1 n'a pas besoin d'être interrompu : le processus pCommande peut être utilisé pour piloter le bloc d'envoi R1 sur demande d'un autre processus client pClient2' correspondant à une autre application cliente pClient2 exécutée sur l'ordinateur PC ou sur un autre ordinateur PC2. Il est à noter que les choix de réalisation sont ici fortement complémentaires, mais que les possibilités pratiques sont tributaires du volume de données échangées avec le service S. Ainsi, un service de sauvegarde réseau, même « différentielle », sera difficilement exploitable a priori, dans le cadre de la variante (en cas de faible bande passante du réseau mobile). Lorsque le service S n'a plus besoin d'interagir avec le processus pClient (fin d'une phase de réalisation d'une ou plusieurs actions par le service S), l'ordinateur peut retourner, dans une étape C, à l'état initial de veille. Ce retour est effectué automatiquement, au bout d'une période d'inactivité de l'ordinateur PC, ou bien sur demande du module logiciel de réveil, après que celui-ci a détecté la fin de l'exécution du processus pClient dont il a déclenché l'exécution. On décrit maintenant, en relation avec la figure 2, un deuxième mode de réalisation particulier de l'invention. Dans ce deuxième mode de réalisation (comme dans le premier), le système qui met en oeuvre la logique de service complète comprend un service S, un bloc de commande R2, un bloc d'envoi R1, un périphérique K et un ordinateur PC. Ce deuxième mode de réalisation se distingue du premier uniquement en ce que le bloc de commande R2 est réalisé au moyen d'une interface de programmation (API, pour « Application Programming Interface » en anglais), qui sert à émuler une interface de commande de l'application cliente et est accessible par le service S. Cette interface de programmation (de gestion d'événements applicatifs) permet de configurer et de personnaliser le fonctionnement de l'entité de commande R en cas de réception d'un événement déclencheur. Cette interface de programmation permet par exemple de définir si des informations sur l'événement déclencheur, ou plus généralement sur le contexte applicatif courant entre le service S et le bloc de commande R2, doivent ou non être transmises avec ou dans la requête de réveil. Cette interface de programmation permet plus généralement de définir quels sont les paramètres à envoyer avec ou dans la requête de réveil et/ou le mode d'envoi de cette requête de réveil (par SMS ou appel téléphonique, à quelle heure, etc). Dans ce deuxième mode de réalisation, on peut définir un fonctionnement différent pour chaque serveur SRV / service S distant susceptible d'envoyer un tel événement déclencheur. Ainsi, une intégration native avec le service S distant est possible, ce qui ne serait pas le cas avec une machine virtuelle exécutant l'application client. Il s'agit par exemple d'une interface de programmation publique standardisée, ayant fait l'objet d'une contractualisation entre le service S et l'opérateur du réseau RO. Le séquencement du mécanisme complet est le suivant. Dans une étape 21, le service S transmet un événement déclencheur au bloc de commande R2, c'est-à-dire à l'API.

Dans une étape 22, l'API déclenche ensuite l'appel au bloc d'envoi R1 (envoi à ce dernier d'une requête de réveil). Les étapes 23 à 26 sont identiques aux étapes 14 à 17 de la figure 1 et ne sont donc pas décrites à nouveau. Les étapes A, B (ou sa variante B') et C sont les mêmes que celles déjà décrites en relation avec la figure 1. On décrit maintenant, en relation avec la figure 3, un troisième mode de réalisation particulier de l'invention. Dans ce troisième mode de réalisation (comme dans le deuxième), le système qui met en oeuvre la logique de service complète comprend un service S, un bloc de commande R2, un bloc d'envoi R1, un périphérique K et un ordinateur PC. Ce troisième mode de réalisation se distingue du deuxième uniquement en ce que le bloc de commande R2 et le bloc d'envoi R1 ne sont pas compris dans le réseau opérateur RO mais dans un terminal de communication TC d'un utilisateur autorisé à réveiller l'ordinateur PC et lancer l'exécution de l'application cliente. Le terminal de communication TC est par exemple un téléphone mobile, un terminal de poche (smartphone) ou une tablette 3G. L'utilisateur autorisé est soit l'utilisateur de l'ordinateur à réveiller, soit une personne de confiance de l'utilisateur de l'ordinateur à réveiller. Il peut y avoir plusieurs utilisateurs autorisés. Dans une réalisation particulière, le système gère un « carnet d'adresse », contenant les numéros appelants autorisés. Il est à la portée de l'Homme du Métier de mettre en place, selon diverses implémentations, des procédures d'ajout/modification/suppression/consultation de tels numéros appelants autorisés, qui ne sont donc pas décrites dans le présent document. Notamment, la localisation organique du « carnet d'adresse » des numéros appelants autorisés peut être réalisée par exemple côté ordinateur/périphérique ou bien du côté réseau opérateur/Internet public (l'Homme du Métier saura adapter en conséquence les diagrammes de séquence correspondant au mécanisme de l'invention). Optionnellement, comme illustré sur la figure 3, le terminal de communication TC effectue une étape (référencée V) de confirmation par l'utilisateur autorisé. Dans ce cas, le bloc d'envoi R1 propage la requête de réveil vers le périphérique K (étape 33) seulement en cas de confirmation par l'utilisateur autorisé.

Dans une variante (non illustrée) des deuxième et troisième modes de réalisation, le bloc de commande R2 est compris dans le réseau opérateur RO et le bloc d'envoi R1 est compris dans le terminal de communication TC d'un utilisateur autorisé. Les entités mettant en oeuvre la logique de service complète (à savoir le serveur SRV, le bloc de commande R2, le bloc d'envoi R1, le périphérique K et le ordinateur PC) comprennent chacune des moyens matériels, combinés ou non avec des moyens logiciels, leur permettant d'assumer leur rôle dans le séquencement du mécanisme complet de réveil et de (re)connexion proposé par l'invention (dans l'un quelconque de ses modes de réalisation). Chaque entité comprend par exemple une mémoire RAM, une unité de traitement, équipée par exemple d'un processeur et pilotée par un programme d'ordinateur stocké dans une mémoire ROM. A l'initialisation de l'entité, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement. Chaque entité se réalise indifféremment : sur une machine de calcul reprogrammable (ordinateur, processeur DSP ou microcontrôleur) exécutant un programme comprenant une séquence d'instructions ; ou sur une machine de calcul dédiée, c'est-à-dire sous forme de matériel (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC). Dans le cas d'une réalisation sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) peut être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Claims (16)

1. REVENDICATIONS1. Procédé de réveil d'un ordinateur se trouvant dans un état éteint ou de veille, caractérisé en ce qu'il comprend les étapes suivantes : - réception d'un événement déclencheur par une entité de commande (R) ; - l'entité de commande envoie à travers un réseau de télécommunication une requête de réveil vers un périphérique (K) de l'ordinateur, apte à communiquer via ledit réseau de télécommunication, connecté via un connecteur à l'ordinateur, le périphérique étant alimenté par le connecteur, le connecteur restant alimenté quand l'ordinateur est dans l'état éteint ou de veille ; - le périphérique transmet au connecteur un signal de réveil, permettant de réveiller l'ordinateur.
2. 2. Procédé selon la revendication 1, dans lequel l'entité de commande comprend un bloc de commande (R2) qui émule une interface de commande d'une application cliente installée dans l'ordinateur et qui pilote un bloc d'envoi (R1) de requête de réveil.
3. 3. Procédé selon la revendication 2, dans lequel l'exécution de l'application cliente est démarrée automatiquement après le réveil de l'ordinateur.
4. 4. Procédé selon la revendication 2 ou 3, dans lequel l'événement déclencheur est envoyé par un serveur (SRV) mettant en oeuvre un service (S) avec lequel l'application cliente est conçue pour communiquer via ladite interface de commande.
5. 5. Procédé selon l'une quelconque des revendications 2 à 4, dans lequel l'événement déclencheur est un événement applicatif destiné à être traité par l'application cliente.
6. 6. Procédé selon la revendication 4, caractérisé en ce que l'interface de commande est connectée audit serveur avant réception dudit événement déclencheur, puis déconnectée du serveur après réception dudit événement déclencheur.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que l'entité de commande est comprise dans un réseau opérateur d'un opérateur dudit réseau de télécommunication.
8. 8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que l'entité de commande est autorisée à réveiller l'ordinateur et lancer l'exécution de l'application cliente.
9. 9. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que l'entité de commande est comprise dans un terminal de communication (TC) d'un utilisateur autorisé à réveiller l'ordinateur et lancer l'exécution de l'application cliente.
10. 10. Procédé selon la revendication 9, caractérisé en ce qu'il comprend une étape de confirmation par l'utilisateur autorisé, et en ce que l'entité de commande envoie la requête de réveil vers le périphérique seulement en cas de confirmation par l'utilisateur autorisé.
11. 11. Procédé selon l'une quelconque des revendications 2 à 10, caractérisé en ce qu'il comprend une étape d'authentification de l'entité de commande ayant envoyé la requête de réveil vers le périphérique, et en ce que l'exécution de l'application cliente n'est lancée qu'en cas d'authentification réussie de l'entité de commande.
12. 12. Procédé selon la revendication 11, caractérisé en ce que l'étape d'authentification est effectuée par le périphérique, et en ce que le périphérique transmet au connecteur le signal de réveil seulement en cas d'authentification réussie de l'entité de commande.
13. 13. Procédé selon la revendication 11, caractérisé en ce que l'étape d'authentification est effectuée par une application d'administration exécutée au réveil de l'ordinateur, et en ce que l'application d'administration lance l'exécution de l'application cliente seulement en cas d'authentification réussie de l'entité de commande.
14. 14. Procédé selon la revendication 4, caractérisé en ce que l'application cliente se connecte au serveur via un accès réseau dont dispose l'ordinateur ou le périphérique.
15. 15. Procédé selon la revendication 14, caractérisé en ce que, après que l'application cliente s'est connectée au serveur, il comprend une phase de réalisation d'au moins une action par le serveur et/ou l'application cliente, puis une phase de retour de l'ordinateur dans l'état éteint ou de veille.
16. 16. Système de réveil d'un ordinateur se trouvant dans un état éteint ou de veille, caractérisé en ce qu'il comprend une entité de commande (R) et un périphérique (K) de l'ordinateur, le périphérique (K) étant apte à communiquer via un réseau de télécommunication, connecté via un connecteur à l'ordinateur, et alimenté par leconnecteur, le connecteur restant alimenté quand l'ordinateur est dans l'état éteint ou de veille, en ce que l'entité de commande (R) comprend des moyens de réception d'un événement déclencheur et des moyens d'envoi, à travers le réseau de télécommunication, d'une requête de réveil vers le périphérique (K), et en ce que le périphérique comprend des moyens de transmission au connecteur d'un signal de réveil, permettant de réveiller l'ordinateur.