FR 2906662 A1 20080404 FR 0706807 A 20070928 1 Domaine de l'invention La présente invention concerne un système et un procédé pour la gestion de mises à jour de sites Web. En particulier, la présente invention concerne un système et un procédé pour souscrire à des mises à jour et à des notifications et pour les envoyer à des utilisateurs de service mobile, en ce qui concerne un contenu nouveau ou modifié de sites Web. Arrière plan de l'invention Les progrès rapides dans les technologies liées à Internet et la prolifération subséquente des activités économiques sur Internet ont entraîné un développement phénoménal d'Internet, conduisant à l'âge de l'information numérique. Internet est maintenant la manière la plus rapide de diffuser des informations simultanément à de grands ensembles de personnes. Le nombre d'utilisateurs du Web a également plus que doublé depuis l'an 2000, et depuis 2006, il y a plus de 1,02 milliard d'utilisateurs d'Internet selon les Statistiques Mondiales sur Internet. Il y a de nombreux facteurs de croissance, et l'essentiel de ce développement se produira en utilisant des applications sans fil pour accéder à Internet. Les appareils mobiles et sans fil ont inondé le marché à grande échelle. Selon la société d'étude de marché Garter, les ventes globales de combinés téléphoniques ont atteint 205 millions en 2005. Actuellement, il y a 1,5 milliard d'utilisateurs estimés de téléphones portables GSM ("Global System for Mobile Communications", en anglais); de façon globale, l'estimation de ce nombre devrait atteindre 3 milliards en 2010. En outre, les dernières estimations prouvent que les expéditions globales d'appareils mobiles intelligents ont atteint 55% en 2006, avec une augmentation de 75% des expéditions de téléphones intelligents par rapport à l'année précédente, ceci illustrant un passage des appareils mobiles à des dispositifs convergents. Internet lui-même a déjà été transformé en un vaste terrain marketing pour de nombreuses compagnies. Certaines des plus grandes compagnies se sont développées en tirant profit du caractère efficace de la publicité peu coûteuse et en gérant le commerce électronique ("e-commerce") par Internet. Internet a également défié et révolutionné les concepts traditionnels d'achats et de diffusion. De plus, l'augmentation des communautés en ligne telles que les blogs et les réseaux sociaux sont également prêts à constituer le futur d'Internet. Ainsi, en raison du volume total et de la quantité 2906662 2 d'informations accessibles en ligne, vérifier les nouveaux événements et nouvelles mises à jour sur Internet devient petit à petit une tâche gigantesque pour les utilisateurs du Web. Actuellement, il y a déjà des systèmes qui permettent à des utilisateurs du Web de 5 vérifier les mises à jour disponibles des sites Web par lesquels ils sont intéressés. La technologie employée par ces systèmes se nomme "alerte poussée" ("push alert" en anglais, ci-après dénommé de cette façon) puisque des extraits de mises à jour sont préconisés à chaque fois que des mises à jour sont disponibles. Les systèmes de "push alert" autorisent par conséquent des serveurs applicatifs de confiance ("trusted 10 application servers" en anglais) à envoyer de manière proactive des contenus personnalisés aux utilisateurs du Web. Les systèmes de "push alert" complémentent le modèle traditionnel "pull" (tirer, en français) où les utilisateurs du Web vont chercher les informations spécifiques à partir des sites Web. Pour recevoir des mises à jour de sites Web par lesquels les utilisateurs du Web sont intéressés, ils doivent d'abord 15 souscrire aux alertes de mises à jour de sites Web. Ce processus est équivalent à la souscription aux accusés de réception de publipostage sur une liste de publipostage. Normalement, des informations telles qu'un nom d'utilisateur, une adresse e-mail ou un numéro de téléphone portable sont fournis par les utilisateurs d'Internet par l'intermédiaire de formulaires de souscription aux alertes fournies par les sites Web. 20 Les informations rassemblées sont alors enregistrées dans une base de données hébergée sur un serveur principal, qui est normalement administré et géré par un administrateur de sites Web. Un problème général avec les systèmes actuels de "push alert" est que l'administrateur de sites Web entretient physiquement la base de données pour assurer 25 l'exactitude des informations des utilisateurs. Par conséquent, pour d'importantes bases de données, le travail de maintenance requis devant être effectué est colossal et pénible. Bien que ces systèmes de "push alert" soient administrables par de grands organismes, le coût et la complexité rendent les systèmes de "push alert" non-viables pour des opérateurs de plus petites structures, pour des éditeurs particuliers de blogs et 30 similaires. De plus, les systèmes actuels de "push alert" requièrent souvent des serveurs de base de données coûteux. En outre, les systèmes actuels de "push alert" sont principalement utilisables pour envoyer des mises à jour uniquement vers des adresses e-mail. 2906662 3 Avec la prolifération des appareils mobiles, et leurs caractéristiques toujours allumé, toujours avec l'utilisateur , il a eu un nombre croissant d'utilisateurs du Web préférant être alertés par l'intermédiaire de leurs appareils mobiles. Des alertes pour, par exemple, un programme télévisé à venir, sont de préférence envoyées à l'appareil 5 mobile de l'utilisateur environ 15 à 30 minutes avant l'émission du programme. L'appareil mobile est susceptible de toujours accompagner l'utilisateur et de toujours être allumé par rapport aux navigateurs d'e-mails, auxquels on n'accède pas souvent au moment opportun. Il y a d'autres applications d'alertes mobiles telles que des alertes de surenchères pour les ventes aux enchères, des rappels de réunion, et plus encore. De 10 telles alertes sont de préférence envoyées par l'intermédiaire de messages "service de messages courts" ("Short Message Service" en anglais, ci-après dénommé SMS), de messages "service de transmission de messages multimédia" ("Multimedia Messaging Service" en anglais, ci-après dénommés MMS), ou de messages "protocole d'application sans fil" ("Wireless Application Protocol" en anglais, ci-après dénommé 15 WAP). Malgré les avantages manifestes d'utiliser les alertes mobiles, il demeure un certain nombre de raisons pour lesquelles les alertes mobiles ne sont pas aussi largement mises en application par les administrateurs de sites Web que les alertes par e-mails quasi omniprésentes. Un problème général avec la mise en application des alertes mobiles est le coût 20 cumulé élevé d'envoi des alertes mobiles. Usuellement, pour envoyer une alerte mobile, l'expéditeur de l'alerte mobile doit, soit être un abonné d'un opérateur de services mobiles et posséder l'équipement technique approprié nécessaire pour envoyer l'alerte mobile, soit posséder un quelconque moyen de délivrer le message aux destinataires par l'intermédiaire du réseau de l'opérateur de services mobiles. Dans l'un ou l'autre cas, des 25 coûts irrémédiables sont entraînés pour l'expéditeur. L'envoi d'alertes mobiles peut coûter une somme considérable à l'expéditeur n'ayant pas des capacités évidentes de revenu. Par exemple, il n'y a aucune incitation évidente pour les opérateurs tels que les chaînes de télévisions en clair supportées par de la publicité, les fournisseurs de services Web d'e-mails gratuits ou les éditeurs particuliers de blogs pour informer leurs 30 abonnés de présentations de programmes, de nouveaux e-mail ou de mises à jour de blogs par l'intermédiaire d'alertes mobiles. Une solution de rechange alternative pouvant être mise en application uniquement dans des conditions particulières existe suivant le modèle du récepteur-payeur, où le 2906662 4 destinataire du message paie un montant tarifaire significatif pour recevoir le message tandis que l'expéditeur n'est pas facturé. Les fournisseurs de contenu pour téléphones portable, distribuant par exemple, des sonneries de téléphones portables ou des fonds d'écran de téléphones portables, adoptent généralement le modèle commercial du 5 récepteur-payeur. Un utilisateur de téléphone portable est facturé du contenu mobile dans sa facture de téléphone mensuelle, les revenus étant partagés entre les opérateurs de services mobiles et les fournisseurs de contenu pour téléphones portable. En conséquence, le montant exact à facturer à l'utilisateur de téléphone portable et le pourcentage des revenus de ce montant à partager entre les opérateurs de services 10 mobiles et les fournisseurs de contenu pour téléphones portables est préalablement négocié par des accords. Les accords imposent aux fournisseurs de contenu pour téléphones portables d'envoyer un nombre minimum déterminé de messages de téléphone portable et imposent à la société fournisseuse de contenu pour téléphones de payer une commission d'engagement à l'opérateur de services mobiles. En outre, les 15 fournisseurs de contenu pour téléphones portables ont également l'obligation d'effectuer un travail sur mesure d'intégration des systèmes pour interconnecter leur système au réseau de l'opérateur de services mobiles. Un certain nombre de problèmes existent avec cette solution de rechange alternative, en particulier pour les expéditeurs de faibles volumes ne faisant pas de profit. 20 Un des problèmes est que ce modèle ne s'applique pas aux expéditeurs de faibles volumes puisqu'un volume minimum déterminé d'alertes mobiles, par exemple quelques dizaines ou centaines de milliers, doit être envoyé par l'expéditeur de messages. Un autre problème réside dans le fait que, puisque ce modèle est fondé sur la facturation au destinataire d'une cotisation significative et ensuite sur le partage des 25 revenus, cela demeure hors de propos pour les petits propriétaires de sites Web qui n'utilisent pas le processus d'alertes mobiles pour vendre leur contenu. En outre, les petits propriétaires de site Web qui veulent proposer des alertes mobiles comme offre de service sans revenus sont susceptibles de trouver la commission d'engagement prépayée, ce qui est injustifiable financièrement. Un autre problème encore avec ce 30 modèle réside dans le fait que l'expéditeur de messages doit intégrer ses systèmes avec les systèmes de transmission de messages de l'opérateur de services mobiles, nécessitant plus de temps, d'efforts et de coûts à la fois pour l'expéditeur de messages et l'opérateur de services mobiles. Pour finir, ce procédé est souvent victime de pratiques 2906662 5 trompeuses et de fausse facturation par l'expéditeur de messages, et influence ainsi de manière négative la relation entre l'opérateur de services mobiles et l'utilisateur de téléphone portable. Le procédé mentionné ci-dessus est parfois dépendant de l'expéditeur de messages 5 soumettant, à l'opérateur de services mobiles, une liste de numéros d'abonnés au téléphone portable qui doivent être facturés pour le service. Ceci est une conséquence du téléphone portable, seul le destinataire du contenu étant impacté, tandis que le contenu peut être demandé par l'utilisateur par l'intermédiaire d'un appel téléphonique en passant par un autre réseau d'opérateur de services mobiles ou à partir du site Web 10 de l'expéditeur (par l'utilisateur soumettant son numéro de portable directement par l'intermédiaire du site Web de l'expéditeur). Selon la technologie utilisée, l'opérateur de services mobiles ne peut pas s'assurer facilement de la validité de la liste de destinataires prétendue de l'expéditeur du message jusqu'à ce que le destinataire reçoive sa facture de téléphone portable et conteste le montant relevé sur la facture. Le 15 processus de résolution de conflit qui en découle dégrade alors la relation entre l'opérateur de services mobiles et le destinataire de messages qui est le client final. Encore un autre problème à toutes les approches mentionnées ci-dessus est qu'en général, l'expéditeur de messages aurait également besoin d'un accord avec chaque opérateur de service mobile des abonnés auxquels il a l'intention de délivrer des 20 messages. Puisque la plupart des opérateurs de services mobiles ont leurs propres systèmes de transmission de messages et contrats légaux, s'engager et s'interconnecter séparément avec chaque opérateur de service mobile prend du temps, est cher et peu pratique pour l'expéditeur de messages. Pour faire face à ce problème, l'expéditeur de messages peut passer un contrat avec un organisme fonctionnant comme un fournisseur 25 de service intermédiaire. L'organisme communique avec la plupart des opérateurs de service mobile pour gérer les issues contractuelles et techniques. Cependant, cet organisme exige des honoraires devant être payés par message envoyé, ce qui tend à être encore plus cher que ce que l'expéditeur de messages payerait à l'opérateur de service mobile si l'expéditeur de messages avait un contrat personnel avec les 30 opérateurs de service mobile. Ainsi, l'utilisation d'un fournisseur de service intermédiaire est, de cette manière, également chère et peu pratique pour l'expéditeur de message. 2906662 6 Un autre problème est le manque de clarté au destinataire de messages en ce qui concerne l'option de résiliation de réception des messages. Ceci est particulièrement important dans le cas de services d'abonnement comme, par exemple, les services de "blague du jour", où l'expéditeur de messages facture au destinataire de messages un 5 montant tarifaire, quotidiennement, pour envoyer une plaisanterie quotidienne à l'appareil mobile du destinataire. Puisqu'il ne s'agit pas d'une transaction unique, il doit y avoir une manière limpide pour le destinataire de messages de résilier ce service. Cependant, il n'est pas dans l'intérêt de l'expéditeur de messages de clarifier le processus d'option de résiliation pour le destinataire afin de se désabonner de ce 10 service. De plus, cela constitue un challenge du point de vue technologique que d'inclure des informations détaillées d'option de résiliation dans une alerte mobile, en particulier lorsque l'alerte mobile est envoyée par l'intermédiaire d'un SMS, puisqu'un SMS a une limite de 160 caractères dans laquelle le contenu doit également être inclus. Par conséquent, ceci confirme clairement le besoin d'un système et d'un procédé 15 pour délivrer des alertes mobiles à un destinataire sans obliger celui-ci à payer un montant tarifaire significatif pour recevoir les alertes mobiles et de préférence, ne pas imposer à l'expéditeur de messages de payer pour envoyer les alertes mobiles tout en pouvant envoyer des alertes mobiles aux abonnés d'autant d'opérateurs de service mobile que possible. 20 Résumé La présente forme de réalisation de l'invention divulguée ici fournit un système de gestion de mises à jour d'événements pour délivrer des alertes mobiles à un destinataire sans obliger le destinataire à payer un montant tarifaire significatif pour recevoir les alertes mobiles et, de préférence, sans imposer à l'expéditeur de messages de payer pour 25 envoyer les alertes mobiles, tout en pouvant envoyer des alertes mobiles aux abonnés d'autant d'opérateurs de service mobile que possible. Le système et le procédé sont de préférence faciles à utiliser et faciles à intégrer, cela permettant à des utilisateurs finaux avec peu de connaissances ou d'aptitudes techniques d'envoyer des alertes mobiles, alors qu'en même temps, le système et le 30 procédé sont de préférence compatibles et adaptables pour satisfaire les besoins de grands organismes qui peuvent vouloir délivrer des messages plus complexes avec des règles commerciales plus complexes. Une autre condition encore est que le système et 2906662 7 le procédé incorporent de préférence des paramètres de validation tels que la vérification de la demande du destinataire de recevoir des alertes mobiles, réduisant de ce fait le courrier indésirable (dénommé "Spam" ci-après), et présentant un processus d'option de résiliation clair, cela permettant facilement au destinataire d'empêcher un ou 5 plusieurs expéditeurs de messages de lui envoyer des alertes mobiles. Selon un premier aspect de l'invention, il est divulgué un système de gestion de mises à jour d'événements comprenant un module de données, un module de vérification, un module de traitement, une base de données et un module d'alerte. La base de données est hébergée sur le système de gestion de mises à jour d'événements. 10 Le module de données reçoit des données d'enregistrement d'alertes envoyées par un serveur Web hôte. Les données d'enregistrement d'alertes sont générées lorsqu'un utilisateur de service mobile soumet une demande d'inscription aux alertes correspondant à un événement par l'intermédiaire du serveur Web hôte. Le module de vérification compare ensuite l'identité de l'utilisateur de service mobile avec une liste 15 prédéfinie contenant une pluralité d'abonnés aux services mobiles. L'utilisateur de service mobile est un abonné aux services mobiles lorsqu'il concorde avec l'un parmi la pluralité des abonnés aux services mobiles. Un module de traitement traite alors les données d'enregistrement d'alertes et sauvegarde les données d'enregistrement d'alertes sur la base de données. Pour finir, le module d'alerte génère et envoie une alerte à 20 l'utilisateur de service mobile en réponse à une instruction envoyée par le serveur Web hôte ou par un administrateur de sites Web supervisant le serveur Web hôte. Selon un deuxième mode de l'invention, il est divulgué un procédé de gestion de mises à jour d'événements comprenant l'étape de réception de données d'enregistrement d'alertes envoyées par un serveur Web hôte par un module de données, les données 25 d'enregistrement d'alertes étant générées lorsqu'un utilisateur de service mobile soumet une demande d'inscription aux alertes correspondant à un événement par l'intermédiaire du serveur Web hôte ; et l'étape de traitement des données d'enregistrement d'alertes et de sauvegarde des données d'enregistrement d'alertes sur une base de données hébergée sur le système de gestion de mises à jour d'événements par un module de traitement. Le 30 procédé de gestion d'événements comprend de plus l'étape de génération, de traitement et d'envoi d'une alerte à l'utilisateur de service mobile par un module d'alerte en réponse à une instruction envoyée par un administrateur de sites Web supervisant le serveur Web hôte, par lequel le module de données, le module de vérification, le module de 2906662 8 traitement et le module d'alerte forme un système de gestion de mises à jour d'événements. Brève description des figures Les formes de réalisation de l'invention sont divulguées ci-après en référence aux 5 figures, parmi lesquelles : la figure 1 représente un schéma fonctionnel illustrant l'interaction entre différents composants système d'un système de gestion de mises à jour d'événements selon une forme de réalisation de l'invention ; la figure 2 est une vue schématique d'un formulaire d'inscription à l'usage d'un 10 expéditeur de faibles volumes de messages lors de son engagement avec un fournisseur de services applicatifs pour envoyer des alertes mobiles pour une utilisation combinée avec le système de gestion de mises à jour d'événements de la figure l ; la figure 3 est une vue schématique d'un formulaire d'inscription à l'usage d'un expéditeur de gros volumes de messages lors de son engagement avec un fournisseur de 15 services applicatifs pour envoyer des alertes mobiles pour une utilisation combinée avec le système de gestion de mises à jour d'événements de la figure 1 ; la figure 4 représente un organigramme illustrant un processus dans lequel un administrateur de sites Web s'engage avec le fournisseur de services applicatifs pour envoyer des alertes mobiles en utilisant le système de gestion de mises à jour 20 d'événements de la figure 1 ; la figure 5 est une vue schématique d'un formulaire d'inscription aux alertes pour une utilisation combinée avec le système de gestion de mises à jour d'événements de la figure 1; la figure 6 représente un organigramme illustrant un processus dans lequel un 25 utilisateur se service mobile souscrit aux alertes mobiles en utilisant le formulaire d'inscription aux alertes de la figure 5 pour recevoir des mises à jour d'un site Web en utilisant le système de gestion de mises à jour d'événements de la figure 1, un administrateur de sites Web supervisant le site Web étant un expéditeur de faibles volumes de messages ; 30 la figure 7 représente un organigramme illustrant un processus par lequel un utilisateur de service mobile souscrit aux alertes mobiles en utilisant le formulaire d'inscription aux alertes de la figure 5 pour recevoir des mises à jour du site Web en 2906662 9 utilisant le système de gestion de mises à jour d'événements de la figure 1, l'administrateur de sites Web supervisant le site Web étant un expéditeur de gros volumes de messages ; la figure 8 est une vue schématique d'un formulaire d'option de résiliation pour 5 une utilisation combinée avec le système de gestion de mises à jour d'événements de la figure 1 ; la figure 9 représente un organigramme illustrant un processus d'option de résiliation par lequel l'utilisateur de service mobile opte pour la résiliation pour ne plus recevoir d'alertes mobiles en utilisant le formulaire d'option de résiliation de la figure 8 10 par l'intermédiaire du système de gestion de mises à jour d'événements de la figure 1. Description détaillée Un système de gestion de mises à jour d'événements pour fournir des notifications de mises à jour et d'événements aux utilisateurs de service mobile qui ont souscrit à la réception de mises à jour de sites Web par l'intermédiaire d'alertes mobiles, est décrit 15 ci-après pour traiter les problèmes antérieurs. Une forme de réalisation de l'invention fournit un système et un procédé pour permettre aux administrateurs de sites Web d'envoyer des alertes mobiles aux utilisateurs de service mobile intéressés par le fait d'être alertés lorsqu'un contenu pertinent change sur le site Web administré par les administrateurs de sites Web. Le système et le procédé procèdent à des requêtes 20 d'inscription aux alertes des utilisateurs de mobiles aussi bien qu'à des requêtes d'envoi d'alertes par les administrateurs de sites Web, sauvegarde l'information d'inscription aux alertes, envoie les alertes mobiles aux utilisateurs de service mobile et facture au moins l'un des opérateurs de service mobile, les utilisateurs de service mobile et les administrateurs de sites Web pour l'utilisation des services. Le système et le procédé 25 permettent également aux administrateurs de sites Web d'utiliser facilement et rapidement le système à moindre coût ou sans coût. A des fins de concision et de clarté, la description de l'invention est limitée ci-après à une utilisation dans des systèmes pour fournir des notifications de mises à jour et d'événements aux utilisateurs de service mobile qui ont souscrit à la réception de 30 mises à jour de sites Web par l'intermédiaire d'alertes mobiles. Cependant, cela n'exclut pas diverses formes de réalisation de l'invention d'autres applications qui requièrent des systèmes ayant une exécution similaire de fonctionnement pour fournir des 2906662 10 notifications de mises à jour et d'événements aux utilisateurs de service mobile qui ont souscrit à la réception de mises à jour de sites Web par l'intermédiaire d'alertes mobiles. Les principes opérationnels et fonctionnels fondamentaux des formes de réalisation de l'invention sont communs aux diverses formes de réalisation. 5 Les formes de réalisation de l'invention sont décrites ci-après selon les figures 1 à 9, les éléments similaires étant numérotés avec des références numériques identiques. En référence à la figure 1, qui représente un schéma fonctionnel illustrant l'interaction entre différents composants système d'un système 100 de gestion de mises à jour d'événements, une forme de réalisation de l'invention est décrite. Le système 100 10 de gestion de mises à jour d'événements comprend un serveur 102 de gestion d'événements, des serveurs Web hôtes 104, des utilisateurs 106 de service mobile (ci-après désignés sous le nom des utilisateurs de mobiles) et des opérateurs 108 de service mobile. Le serveur 102 de gestion d'événements est de préférence situé et pré-installé dans les locaux d'un fournisseur de services applicatifs, le fournisseur de services 15 applicatifs (non représenté) supervisant le serveur 102 de gestion d'événements et se connectant à un ou plusieurs opérateurs 108 de service mobile par l'intermédiaire d'un premier ensemble de liaisons mobiles 110. Il peut y avoir de multiples fournisseurs de services applicatifs exécutant de multiples serveurs 102 de gestion d'événements, connectés à une pluralité de divers opérateurs 108 de service mobile et de serveurs Web 20 hôtes 104 et desservant divers utilisateurs 106 de mobiles. Les utilisateurs 106 de mobiles sont soit des abonnés, soit des non-abonnés aux services mobiles fournis par les opérateurs 108 de services mobiles avec lesquels le fournisseur de services applicatifs supervisant le serveur 102 de gestion d'événements est connecté ou avec qui le fournisseur de services applicatifs supervisant le serveur 102 de gestion 25 d'événements a un contrat. De plus, au moins un des opérateurs 108 de service mobile peut opérer comme fournisseur de services applicatifs. Les multiples serveurs 102 de gestion d'événements communiquent également de façon réciproque les uns avec les autres pour la coordination. Le serveur 102 de gestion d'événements traite et sauvegarde des informations 30 d'inscription aux alertes mobiles reçues par les serveurs Web hôtes 104. Les informations d'inscription aux alertes mobiles reçues peuvent alors être sauvegardées dans une base de données (non représentée) hébergée sur le serveur 102 de gestion d'événements. De plus, le serveur 102 de gestion d'événements assure également des 2906662 11 fonctions permettant aux administrateurs de sites Web qui souhaitent envoyer des messages mobiles aux utilisateurs 106 de mobiles de souscrire à des services d'alertes mobiles, fournit aux administrateurs de sites Web des outils et/ou des codes pour procurer à des visiteurs de sites Web de souscrire aux alertes mobiles, et fournit 5 également aux administrateurs de sites Web les outils administratifs pour administrer leurs propres comptes stockés sur le système 102 de gestion d'événements. Le terme "administrateurs de sites Web" est employé largement et non exclusivement pour se référer soit aux administrateurs réseaux, soit aux pages Web personnelles d'utilisateurs qui sont hébergées par un site Web, par exemple par un site Web dont les utilisateurs 10 publient et partagent des photographies ou tiennent un blog. L'utilisateur, dans ce cas-là, ayant des privilèges de compte pour publier et partager des images ou tenir un blog est alors considéré comme l'administrateur du site Web" sans se soucier si l'utilisateur possède des droits d'administrateur sur les serveurs qui accueillent ses pages Web personnelles aussi longtemps que l'utilisateur possède le droit de modifier ses pages 15 Web personnelles vues par des visiteurs. Le serveur 102 de gestion d'événements envoie des notifications aux utilisateurs 106 de mobiles et reçoit des réponses de ceux-ci, par l'opérateur 108 de service mobile, par l'intermédiaire d'alertes mobiles. L'opérateur 108 de service mobile est de préférence un opérateur 108 de service mobile de l'utilisateur 106 de mobile. Ce serveur 20 102 de gestion d'événements, de préférence, fournit de plus aux utilisateurs 106 de mobiles la possibilité de contrôler quels administrateurs de sites Web peuvent leur envoyercombien d'alertes dans une quelconque période de temps donnée, ceci incluant la possibilité de bloquer temporairement ou de manière permanente toute alerte supplémentaire des administrateurs de sites Web pour des alertes dont les utilisateurs 25 106 de mobiles ont pu souscrire auparavant. Les alertes mobiles sont de préférence des messages SMS, des messages MMS, ou des messages WAP de "push alert". Les administrateurs de sites Web supervisant les serveurs Web hôtes 104 sont déjà pré-engagés par contrat avec le fournisseur de services applicatifs pour l'utilisation des services mentionnés ci-dessus fournis par le serveur 102 de gestion d'événements. De la 30 même manière, les fournisseurs de services applicatifs sont également déjà pré-engagés par contrat avec les opérateurs 108 de service mobile afin de délivrer des alertes mobiles, qui peuvent être des alertes mobiles facturées à l'envers (le récepteur paie). La dernière fonction importante du serveur 102 de gestion d'événements est de facturer les 2906662 12 utilisateurs 106 de mobiles, les opérateurs 108 de service mobile et les administrateurs de sites Web pour les services mentionnés ci-dessus fournis par le serveur 102 de gestion d'événements. Les serveurs Web hôtes 104 fournissent des pages Web aux personnes naviguant 5 sur le Web ("Web-surfers" en anglais) visitant des sites Web (non représentés) qui sont hébergés sur les serveurs Web hôtes 104. Les utilisateurs 106 de mobiles accèdent aux pages Web hébergées sur les serveurs Web hôtes par l'intermédiaire de liaisons bidirectionnelles 112 câblées ou sans fil. Les pages Web accueillies par les sites Web sont hétérogènes et diverses dans leur contenu. Pour les serveurs Web hôtes 104 qui 10 communiquent avec le serveur 102 de gestion d'événements, les serveurs Web hôtes 104 doivent premièrement être enregistrés sur le serveur 102 de gestion d'événements. Les serveurs Web hôtes 104 communiquent avec le serveur 102 de gestion d'événements par l'intermédiaire de liaisons bidirectionnelles 114 qui sont câblées ou sans fil. Les serveurs Web hôtes 104 doivent également être préprogrammés avec des 15 fonctions logicielles définies dans un ensemble de structures logicielles d"'interface de programme d'application" ("application program interface" en anglais, ci-après dénommé API) et être intégrés avec des bibliothèques logicielles. Les bibliothèques logicielles sont des applications de fonctions définies dans l'ensemble de structures API fournies par le fournisseur de services applicatifs, compilé sous forme binaire. 20 Alternativement, les serveurs Web hôtes 104 peuvent communiquer avec le serveur 102 de gestion d'événements par la simple insertion d'un bloc de codes de lien de langage de marquage pour hypertexte ("Hyper Text Markup Language" en anglais, ci-après dénommé HTML) dans des codes de programmation définissant les sites Web ou par d'autres moyens techniques décidés de manière réciproque entre le fournisseur de 25 services applicatifs et l'administrateur de sites Web. Le fournisseur de services applicatifs fournit au moins l'un des ensembles de structures API, des bibliothèques logicielles et des codes de liens HTML. Le serveur 102 de gestion d'événements envoie des alertes mobiles pour informer les utilisateurs 106 de mobiles de mises à jour de sites Web par ses connections ou 30 contrats avec les opérateurs 108 de service mobile qui, à leur tour, délivrent des alertes mobiles aux utilisateurs 106 de mobiles par l'intermédiaire d'un deuxième ensemble de liaisons mobiles 116. Les alertes mobiles sont uniquement envoyées lorsque les administrateurs de sites Web se connectent sur le serveur 102 de gestion d'événements 2906662 13 pour donner l'ordre d'envoyer les alertes mobiles aux utilisateurs 106 de mobiles ou lorsque les systèmes informatisés supervisés par les administrateurs de sites Web se connecte automatiquement sur le serveur 102 de gestion d'événements en utilisant les codes API et/ou HTML et/ou d'autres moyens techniques fournis à l'administrateur de 5 sites Web par le fournisseur de services applicatifs comme décrit plus haut.. Afin que l'administrateur de sites Web envoie des alertes mobiles aux utilisateurs 106 de mobiles qui sont des visiteurs du site Web supervisé par l'administrateur de sites Web et qui sont également intéressés par la réception des alertes mobiles concernant les mises à jour du site Web, l'administrateur de sites Web doit souscrire aux services 10 appropriés proposés par le fournisseur de services applicatifs en remplissant un formulaire d'inscription au service. L'administrateur de sites Web peut souscrire en tant qu'expéditeur de faibles volumes de messages ou en tant qu'expéditeur de gros volumes de messages. La figure 2 représente un formulaire 200 d'inscription au service pour les 15 expéditeurs de faibles volumes de messages (ci-après désignés sous le nom de formulaire pour les faibles volumes) sur une vue schématique décrivant des champs d'entrée du formulaire 200 pour les faibles volumes. Le formulaire 200 pour les faibles volumes contient des champs d'entrée pour saisir un nom d'administrateur de sites Web, une adresse e-mail d'administrateur de sites Web, le nom d'un site Web, l'URL d'un site 20 Web. une requête No.l, une requête No.2, des cordonnées de paiement, un logo, un code de pays et un numéro de contact. Le code de pays et le numéro de contact fournissent un point de contact auquel l'expéditeur de faibles volumes de messages peut être joint, soit pour validation d'identité, pour résolution de conflit ou toute autre communication. Un logo peut de préférence être transmis sous le champ d'entrée de 25 logo pour être joint à un formulaire que l'utilisateur 106 de mobile peut voir lorsqu'il souscrit au service d'alertes mobiles de l'administrateur de sites Web, par lequel le logo donne à l'administrateur de sites Web la possibilité de personnaliser le formulaire. De plus, sous la requête No. 1, l'administrateur de sites Web est prié d'indiquer si l'administrateur de sites Web souhaite pouvoir envoyer des alertes mobiles aux 30 utilisateurs 106 de mobiles qui sont des abonnés des opérateurs 108 de service mobile sans contrat de facturation inversée ou accord similaire avec le fournisseur de services applicatifs. Si l'administrateur de sites Web décide de délivrer des alertes mobiles aux utilisateurs 106 de mobiles qui sont des abonnés des opérateurs 108 de service mobile 2906662 14 sans contrat ou accord similaire avec le fournisseur de services applicatifs, l'administrateur de sites Web est prié de décider en outre, sous la requête No. 2, s'il paie pour les frais résultant de l'envoi d'alertes mobiles ou si les utilisateurs 106 de mobiles sont facturés pour recevoir les alertes mobiles. De plus, si l'administrateur de 5 sites Web veut une sécurité d'envoi des alertes mobiles aux utilisateurs 106 de mobiles qui sont des abonnés des opérateurs 108 de service mobile sans contrat de facturation inversée ou accord similaire avec le fournisseur de services applicatifs, y compris ces utilisateurs 106 de mobiles qui ne souhaitent prendre en charge le coût de réception des alertes mobiles, les administrateurs de sites Web peuvent choisir de payer les alertes 10 mobiles envoyées. L'administrateur de sites Web a alors besoin de fournir les cordonnées de carte de crédit, les informations financières ou de fournir des cordonnées sur d'autres modes de paiement sous le champ de cordonnées de paiement. De la même façon, la figure 3 représente un formulaire 300 d'inscription au service pour les expéditeurs de gros volumes de messages (ci-après désignés sous le 15 nom de formulaire pour les gros volumes) sur une vue schématique décrivant des champs d'entrée du formulaire 300 pour les gros volumes. Le formulaire 300 pour les gros volumes contient des champs d'entrée pour saisir un nom d'administrateur de sites Web, une adresse e-mail d'administrateur de sites Web, le nom d'un site Web, l'URL d'un site Web, un code de pays, et un numéro de contact. Les définitions pour les 20 champs d'entrée du formulaire 300 pour les gros volumes sont semblables aux définitions pour les champs d'entrée similaires respectifs du formulaire 200 pour les faibles volumes comme représenté sur la figure 2. Un organigramme 400 de processus par lequel l'administrateur de sites Web s'engage avec le fournisseur de services applicatifs pour l'envoi d'alertes mobiles aux 25 utilisateurs 106 de mobiles est représenté sur la figure 4. Au cours d'une étape 402, l'administrateur de sites Web accepte les modalités et conditions imposées par le fournisseur de services applicatifs pour l'utilisation du système 100 de gestion de mises à jour d'événements. L'administrateur de sites Web est prié de décider de souscrire en tant qu'expéditeur de faibles volumes de messages ou en tant qu'expéditeur de gros 30 volumes de messages, cette décision étant alors prise au cours d'une étape 404. Les expéditeurs de faibles volumes de messages ont de préférence l'obligation d'envoyer moins de 1000 messages par mois. Avec les expéditeurs de faibles volumes de messages, le processus d'inscription et d'activation doit de préférence être 2906662 15 complètement automatisé, sans nécessiter une quelconque intervention humaine du fournisseur de services applicatifs. En raison du fait que le fournisseur de services applicatifs doit de préférence prédéterminer que le risque professionnel associé à l'activation immédiate posé, par exemple par des spammeurs ou des individus envoyant 5 des messages d'escroquerie, est justifié, le fournisseur de services applicatifs n'encourt aucun coût additionnel pour l'activation du service d'alertes mobiles aux expéditeurs de faibles volumes. De plus, le fournisseur de services applicatifs est susceptible à la place de recevoir des paiements des opérateurs de service mobile dont les abonnés reçoivent les alertes mobiles. En outre, afin d'atténuer le risque professionnel, le fournisseur de 10 services applicatifs peut également imposer des restrictions additionnelles aux expéditeurs de faibles volumes de messages, par exemple, en limitant une quelconque combinaison du nombre maximum de messages que l'expéditeur de faibles volumes de messages est autoriser à envoyer pendant une période temps donnée ou à un utilisateur 106 de mobile. Le fournisseur de services applicatifs doit également de préférence 15 présumer que l'expéditeur de faibles volumes de messages possède des compétences techniques limitées ou des capacités techniques limitées ou, d'une autre manière, ne veut pas ou n'est pas disposé à investir dans l'intégration de systèmes fermés. Un exemple d'un tel expéditeur de faibles volumes de messages est un bloggeur qui souhaite présenter aux lecteurs de blogs, des mises à jour d'alertes par l'intermédiaire de 20 téléphones portables mais qui manque de moyens techniques pour réaliser une intégration de systèmes. Pour l'expéditeur de faibles volumes de messages, le fournisseur de services applicatifs doit de préférence rendre accessible un bloc de codes de liens HTML généré automatiquement, que l'expéditeur de faibles volumes de messages peut facilement intégrer avec les pages Web du site Web par lequel le service 25 d'alertes mobiles doit être mis à disposition des visiteurs du site Web, cela autorisant une exécution facile. De plus, le fournisseur de services applicatifs peut également, de préférence, mettre à disposition des représentations illustratives de la façon dont effectuer l'intégration de codes de liens HTML en indiquant par exemple où insérer les codes de liens HTML dans la page Web. 30 Les expéditeurs de gros volumes de messages, d'autre part, envoient de préférence plus de 1000 messages par mois, avec des possibilités d'envoi de plus de 1000 messages par heure. Avec les expéditeurs de gros volumes de messages, le fournisseur de services applicatifs peut de préférence décider d'investir le temps et les efforts 2906662 16 nécessaires pour la validation de certains facteurs tels que l'identité de l'expéditeur de gros volumes de messages, la nature de l'activité, les informations d'inscription de la société, les garanties financières ou autres facteurs similaires de réduction des risques afin de superviser les risques professionnels. En retour de la procédure de conduite de 5 validation, le fournisseur de services applicatifs peut également imposer quelques, aucunes ou différentes restrictions à l'expéditeur de gros volumes de messages. En outre, il est également présumer que l'expéditeur de gros volumes de messages a les capacités techniques, l'intérêt et les moyens de permettre une meilleure intégration du site Web avec le système de fournisseur de services applicatifs, permettant ainsi à 10 l'expéditeur de gros volumes de messages de bénéficier de degrés plus élevés de personnalisation et d'automation. Un exemple non limitatif de l'expéditeur de gros volumes de messages est un site de vente aux enchères en ligne ou un service d'e-mails gratuit en ligne qui s'adresse à des millions d'utilisateurs du Web. L'administrateur de sites Web n'a pas besoin de négocier un contrat d'envoi de messages avec les opérateurs 15 108 de service mobile dans l'exemple, bien que des documentations de contrat électroniques ou en exemplaires papier puissent de préférence être exigées par les opérateurs 108 de service mobile. De plus, aucune intervention humaine n'est requise de la part des opérateurs 108 de service mobile avant l'activation des services d'envoi de messages proposés à l'administrateur de sites Web. 20 L'administrateur de sites Web remplit alors le formulaire 200 pour les faibles volumes au cours d'une étape 406 si l'administrateur de sites Web décide de souscrire en tant qu'expéditeur de faibles volumes de messages. Au cours d'une étape 408, l'administrateur de sites Web doit décider s'il peut lui être possible d'envoyer des alertes mobiles aux utilisateurs 106 de mobiles qui sont des abonnés des opérateurs 108 25 de service mobile qui n'ont pas d'accord de facturation inversée avec le fournisseur de services applicatifs. Normalement, dans l'exemple mentionné, le fournisseur de services applicatifs est chargé par l'opérateur 108 de service mobile, qui est la première partie à recevoir les alertes mobiles destinées aux utilisateurs 106 de mobiles, d'envoyer les alertes mobiles aux utilisateurs 106 de mobiles. Ainsi, le fournisseur de services 30 applicatifs peut de préférence souhaiter récupérer les frais encourus, et éventuellement une plus-value sur ceux-ci, de l'expéditeur de faibles volumes de messages ou des utilisateurs 106 de mobiles qui ont souscrit à la réception d'alertes mobiles par l'expéditeur de faibles volumes de messages. 2906662 17 Si l'administrateur de sites Web décide d'avoir la flexibilité de délivrer les alertes mobiles aux utilisateurs 106 de mobiles qui ne sont pas des abonnés aux opérateurs 108 de service mobile ayant un contrat de facturation inversée ou un accord similaire avec le fournisseur de services applicatifs, le fournisseur de services applicatifs requiert 5 ensuite que l'expéditeur de faibles volumes de messages procède à un dépôt monétaire, fournisse des cordonnées de carte de crédit vérifiables ou fournisse d'autres formes de garanties financières au cours d'une étape 410, permettant de ce fait au fournisseur de services applicatifs de récupérer les frais engagés. Au cours d'une étape 412, le fournisseur de services applicatifs vérifie la validité des informations financières 10 fournies par l'administrateur de sites Web au cours de l'étape 410 et fait payer un montant spécifique et convenu d'avance à l'administrateur de sites Web par carte de crédit ou exécute un débit direct à partir du compte bancaire de l'administrateur de sites Web ou, autrement, engage une transaction financière convenue d'avance réciproquement entre l'administrateur de sites Web et le fournisseur de services 15 applicatifs. Les modalités et conditions ont été acceptées par l'administrateur de sites Web dans les étapes 402 et 410, et déterminent dans quelle mesure les alertes mobiles telles que délivrées ne sont pas couvertes par les contrats de facturation inversée ou accords similaires. En conclusion, au cours d'une étape 414, le fournisseur de services applicatifs 20 sauvegarde les résultats de transaction qui ont eu lieu au cours de l'étape 412. Les résultats de transaction incluent de préférence des informations d'autorisation de l'administrateur de sites Web à envoyer ou non les alertes mobiles aux utilisateurs 106 de mobiles qui sont des abonnés des opérateurs 108 de service mobile n'ayant aucun contrat de facturation inversée ou accords similaires avec le fournisseur de services 25 applicatifs, les parties légitimes étant ensuite facturées pour les alertes mobiles et les informations d'inscription du formulaire 200 pour les faibles volumes. Par la suite, le fournisseur de services applicatifs fournit alors à l'administrateur de sites Web les informations telles que les codes de liens HTML, le code d'identifiant, le mot de passe, et l'une quelconques des documentations que l'administrateur de sites Web nécessite de 30 préférence afin d'utiliser le service d'envoi de messages. Les informations sont de préférence fournies par tout moyen utilisant les e-mails, directement à l'écran, par courrier recommandé et similaires. Le fournisseur de services applicatifs active alors 2906662 18 immédiatement le service d'envoi de messages pour l'expéditeur de faibles volumes de messages. L'administrateur de sites Web remplit le formulaire 300 pour les gros volumes au cours d'une étape 420 si l'administrateur de sites Web détermine que les besoins 5 nécessaires correspondent à un expéditeur de gros volumes de messages. Puisque les fournisseurs de services applicatifs ont déterminé que les expéditeurs de gros volumes de messages requièrent une vérification humaine, un représentant agréé du fournisseur de services applicatifs contacte alors l'administrateur de sites Web au cours d'une étape 422. Le fournisseur de services applicatifs détermine les besoins de l'administrateur de 10 sites Web, obtient les informations nécessaires au fournisseur de services applicatifs, et remplit toutes les autres conditions de paperasse au cours de l'étape 422. En conclusion, au cours d'une étape 424, le fournisseur de services applicatifs vérifie toutes les données pertinentes obtenues par l'expéditeur de gros volumes de messages. Lorsque toutes les obligations professionnelles internes requises sont accomplis, le fournisseur 15 de services applicatifs fournit à l'administrateur de sites Web les API appropriés, les codes, la documentation, le code d'identifiant, le mot de passe, et toute autre information et outil dont l'administrateur de sites Web nécessite de préférence afin d'utiliser le service d'envoi de messages. De plus, au cours de l'étape 424, le fournisseur de services applicatifs sauvegarde toutes les informations pertinentes, les lettres de 20 créance et les documentations concernant l'expéditeur de gros volumes de messages et active le service pour l'expéditeur de gros volumes de messages. En référence à l'organigramme 400 de processus de la figure 4, le fournisseur de services applicatifs peut de plus inclure un procédé de vérification (non représenté) de l'identité de l'administrateur de sites Web, en particulier dans le cas d'expéditeurs de 25 faibles volumes de messages où de la paperasse n'est de préférence pas exigée. Le procédé de vérification comprend de préférence au moins les étapes de demande d'un numéro de portable de l'expéditeur de faibles volumes de messages, d'envoi d'un message de confirmation au numéro de portable et de requête d'une réponse au message de confirmation. 30 L'utilisateur 106 de mobile qui est intéressé par la réception de mises à jour concernant les sites Web est prié de soumettre une demande d'inscription aux alertes en remplissant un formulaire 500 d'inscription aux alertes disponible sur les sites Web comme décrit sur la figure 5 exposant le formulaire 500 d'inscription aux alertes par 2906662 19 une représentation schématique décrivant des champs d'entrée du formulaire 500 d'inscription aux alertes. Cependant, pour empêcher l'abus d'utilisation, le fournisseur de services applicatifs peut prédéfinir une limite sur le nombre de sites Web auxquels l'utilisateur 106 de mobile peut s'inscrire pour recevoir des alertes mobiles. Le 5 formulaire 500 d'inscription aux alertes comprend les champs d'entrée pour définir un code de pays, un numéro de téléphone portable, une requête No. 1, une adresse e-mail et un opérateur de mobile. Le champ numéro de téléphone portable définit un numéro de téléphone portable, de préférence un numéro de téléphone portable appartenant à l'utilisateur 106 de mobile à qui envoyer les alertes mobiles. En outre, pour parer au 10 problème de fausses inscriptions, le serveur 102 de gestion d'événements valide la demande d'inscription aux alertes en envoyant un message de confirmation au numéro de téléphone portable. L'utilisateur 106 de mobile renvoie alors une réponse de validation. La réponse de validation se présente sous la forme d'un SMS de réponse ou de la saisie d'un code secret envoyé dans le message de confirmation sur une autre 15 partie du formulaire 500 d'inscription aux alertes, ou toute autre forme de vérification qui soit commode et fournisse une sécurité du non-exclusion. Le champ code de pays définit un pays dans lequel le numéro de téléphone portable est enregistré, lequel est en général le pays de résidence de l'utilisateur 106 de mobile. Le champ adresse e-mail définit une adresse e-mail appartenant à l'utilisateur 106 de mobile et l'utilisateur 106 de 20 mobile a également besoin de fournir le nom du fournisseur de services de mobile auquel l'utilisateur 106 de mobile est abonné sous le champ d'entrée d'opérateur de mobile. De plus, sous la requête No. 1, l'utilisateur 106 de mobile décide de payer ou non un prix tarifaire pour recevoir des alertes mobiles si l'opérateur 108 de service mobile 25 de l'utilisateur 106 de mobile n'a pas de contrat de facturation inversée ou d'accord similaire avec le fournisseur de services applicatifs. L'utilisateur 106 de mobile a alors besoin de fournir ses informations de carte de crédit, pour effectuer un dépôt ou pour fournir des détails sur d'autres modes de paiement au fournisseur de services applicatifs sous le champ d'entrée de cordonnées de paiement si l'utilisateur 106 de mobile accepte 30 les conditions. Pour finir, afin de proposer une méthode facile à l'utilisateur 106 de mobile de résilier le service d'alertes mobiles, les sites Web qui proposent le service d'alertes mobiles doivent de préférence être requis pour inclure des informations 2906662 20 d'option de résiliation sous le champ d'entrée d'option de résiliation comme représenté sur le formulaire 500 d'inscription aux alertes. Un organigramme illustrant un processus par lequel l'utilisateur 106 de mobile souscrit aux alertes mobiles pour recevoir des mises à jour du site Web par 5 l'intermédiaire du serveur 102 de gestion d'événements est représenté sur la figure 6. L'administrateur de sites Web supervisant le site Web est un expéditeur de faibles volumes de messages. Au cours de l'étape 602, l'utilisateur 106 de mobile remplit et soumet tout d'abord le formulaire 500 d'inscription aux alertes fourni par le site Web. Le site Web est de préférence l'un par lesquels l'utilisateur 106 de mobile est intéressé 10 pour recevoir des mises à jour de façon régulière. Le formulaire 500 d'inscription aux alertes est de préférence hébergé sur le site Web de l'expéditeur de faibles volumes de messages ou sur le site Web du fournisseur de services applicatifs ou sur un site Web qui est associé au fournisseur de services applicatifs de telle sorte que les informations d'inscription aux alertes générées en remplissant le formulaire 500 d'inscription aux 15 alertes peuvent être transmises au serveur 102 de gestion d'événements. Lorsque le serveur 102 de gestion d'événements reçoit les informations d'inscription aux alertes envoyées par le serveur Web hôte 104, le serveur 102 de gestion d'événements vérifie la validité des informations d'inscription aux alertes reçues au cours d'une étape 604. Le serveur 102 de gestion d'événements vérifie en outre 20 l'existence d'un accord de facturation au cours d'une étape 606 en contrôlant l'accomplissement d'au moins l'un des critères suivants : l'utilisateur 106 de mobile est abonné à un des opérateurs 108 de service mobile avec lequel le fournisseur de services applicatifs a un contrat de facturation inversée ou un accord similaire ou si l'administrateur de sites Web du serveur Web hôte 104 a indiqué le souhait d'envoyer 25 des alertes mobiles aux utilisateurs 106 de mobiles qui ne sont pas abonnés à l'un des opérateurs 108 de service mobile avec lesquels le fournisseur de services applicatifs a un contrat de facturation inversée ou un accord similaire et si l'administrateur de sites Web souhaite payer les frais des alertes mobiles et si l'utilisateur 106 de mobile a indiqué qu'il souhaitait recevoir des alertes mobiles bien que n'étant pas abonné à l'un 30 des opérateurs 108 de service mobile avec lesquels le fournisseur de services applicatifs a un contrat de facturation inversée et si l'utilisateur 106 de mobile a apporté des garanties financières telles que des informations de carte de crédit, des dépôts préalables ou a fourni des cordonnées sur d'autres modes de paiement, auquel cas le 2906662 21 coût de délivrance des alertes mobiles pourra être débité. Si aucun des critères mentionnés ci-dessus n'est rempli, le serveur 102 de gestion d'événements informe l'utilisateur 106 de mobile de l'impossibilité de poursuivre et rejette les informations d'inscription aux alertes au cours d'une étape 608. Le serveur 102 de gestion 5 d'événements peut alors temporairement interdire au numéro de portable d'être utilisé pour d'autres inscriptions à des alertes jusqu'à ce que l'opérateur 108 de service mobile, avec qui l'utilisateur 106 de mobile est engagé, signe un contrat de facturation inversée ou un accord similaire avec le fournisseur de services applicatifs. Cependant, si au moins l'un des critères mentionnés ci-dessus est rempli, le 10 serveur 102 de gestion d'événements renvoie un message de confirmation à l'utilisateur 106 de mobile au cours d'une étape 610. Le message de confirmation est de préférence un message SMS, un message MMS ou un message poussé WAP. L'objectif d'envoyer un message de confirmation est d'empêcher les fausses inscriptions dues aux requêtes d'inscription par du Spam par mobile ou par e-mail. Il y a deux types de réponses que 15 l'utilisateur 106 de mobile peut de préférence accepter de fournir à la réception du message de confirmation. Un premier type de réponse consiste en ce que l'utilisateur 106 de mobile est prié de prendre une mesure à la réception du message de confirmation, dans ce cas, cette mesure doit de préférence être de cliquer sur un lien sur une page affichée sur un dispositif mobile utilisé pour l'inscription aux alertes ou 20 répondre par SMS ou par MMS ou par tout autre message mobile ou répondre par l'intermédiaire du site Web lui-même, avec un mot, un caractère, un nombre ou toute autre combinaison de ceux-ci ou avec l'une quelconque des méthodes indiquées dans le message de confirmation envoyé à l'utilisateur 106 de mobile. À réception de la réponse, le serveur 102 de gestion d'événements procède à la validation de l'inscription 25 aux alertes au cours d'une étape 612. Un deuxième type de réponse ordonne à l'utilisateur 106 de mobile de ne pas prendre de mesure à la réception du message de confirmation. L'utilisateur 106 de mobile ne clique pas sur un lien sur une page affichée sur l'appareil mobile utilisé pourl'inscription aux alertes ou ne répond pas par SMS ou par MMS ou d'aucune autre façon avec un mot, un caractère, un nombre ou toute autre 30 combinaison de ceux-ci ou avec l'une quelconque des méthodes indiquées dans le message de confirmation envoyé à l'utilisateur 106 de mobile. En cas d'échec de réception d'une réponse, le serveur 102 de gestion d'événements procède alors à la validation de l'inscription aux alertes au cours de l'étape 612. 2906662 22 La validation d'inscription aux alertes sert d'indicateur important pour l'acceptation de l'utilisateur 106 de mobile d'être facturé à un tarif spécifique pour recevoir les alertes mobiles. Les tarifs sont généralement aussi bas que les tarifs habituels que l'utilisateur 106 de mobile paie si l'utilisateur 106 de mobile est 5 l'expéditeur d'un message mobile équivalent envoyé localement ou à l'attention de l'opérateur 108 de service mobile auquel l'utilisateur 106 de mobile est abonné, si l'utilisateur 106 de mobile a renoncé à une offre groupée de messages mobiles que le fournisseur de service 108 met à disposition des abonnés ou s'il est inclus dans cette offre groupée. Dans un cas plus mauvais, un prix tarifaire ou un tarif spécifique est 10 imposé à l'utilisateur 106 de mobile souhaitant recevoir des alertes mobiles bien que l'opérateur 108 de service mobile n'ait pas de contrat de facturation inversée ou d'accord similaire avec le fournisseur de services applicatifs. L'opérateur 108 de service mobile peut présenter de faibles tarifs pour les services d'envoi de messages puisque l'opérateur 108 de service mobile ne subit pas les coûts significatifs associés par 15 exemple en s'engageant avec des partenaires de contenu, en intégrant et en testant des relations de facturation des frais, et similaires. Une décision est prise au cours de l'étape 612 pour déterminer si l'inscription aux alertes est une demande authentique faite par un détenteur d'un numéro de portable utilisé par l'utilisateur 106 de mobile lors de sa souscription. Si l'inscription aux alertes 20 est déterminée comme étant une fausse inscription résultant de requêtes d'inscription par du Spam par mobile ou par e-mail, le serveur 102 de gestion d'événements rejette les informations d'inscription aux alertes au cours d'une étape 614. Si des inscriptions défaillantes aux alertes sont reçues à plusieurs reprises pour un numéro de téléphone portable donné, le serveur 102 de gestion d'événements peut alors temporairement 25 interdire au numéro de téléphone portable d'être utilisé pour d'autres inscriptions aux alertes pendant une période de temps prédéfinie. L'interdiction est exécutée lorsqu'un nombre prédéfini d'inscriptions défaillantes aux alertes, au cours desquelles un numéro de téléphone portable peut être utilisé pour inscription à des alertes mobiles, est excédé. La période de temps prédéfinie pour lever l'interdiction doit de préférence être de 24 30 heures. Cependant, si l'inscription aux alertes est déterminée comme étant authentique, le serveur 102 de gestion d'événements sauvegarde alors les informations d'inscription aux alertes reçues ainsi que les données et l'heure de l'inscription sur la base de 2906662 23 données hébergée sur le serveur 102 de gestion d'événements au cours d'une étape 616. Par conséquent, l'inscription aux alertes est considérée comme non-exclusive. Lorsque des mises à jour sont disponibles à partir d'un site Web, l'administrateur de sites Web se connecte alors au serveur 102 de gestion d'événements au cours d'une 5 étape 618 pour donner l'ordre au serveur 102 de gestion d'événements d'envoyer les alertes mobiles aux utilisateurs 106 de mobiles. L'administrateur de sites Web est de préférence autorisé à sélectionner les destinataires à qui les alertes mobiles doivent être délivrés, si une pluralité d'utilisateurs 106 de mobiles se sont inscrits pour recevoir les mises à jour de sites Web, par exemple en saisissant manuellement les numéros de 10 téléphones portables des destinataires ou en télétransmettant les numéros des destinataires dans un fichier. L'administrateur de sites Web est de préférence également autorisé à sélectionner le message à envoyer pour envoyer celui-ci à l'un des destinataires ou à tous les destinataires à qui l'administrateur de sites Web veut que l'alerte mobile soit délivrée. 15 Au cours d'une étape 620, le serveur 102 de gestion d'événements vérifie alors si tous les critères pour envoyer les alertes mobiles aux utilisateurs 106 de mobiles sont satisfaits avant d'envoyer les alertes mobiles. Les critères sont énumérés en conséquence. La vérification est conduite sur chacun des utilisateurs 106 de mobiles étant sélectionnés par l'administrateur de sites Web pour s'être effectivement inscrits 20 pour recevoir des alertes mobiles à partir du site Web concerné. En outre, l'opérateur 108 de service mobile auquel l'utilisateur 106 de mobile souscrit de préférence, a de préférence déjà signé un contrat de facturation inversée ou un accord similaire avec le fournisseur de services applicatifs. Autrement, l'administrateur de sites Web a pu de préférence indiqué la volonté de payer pour l'envoi des alertes mobiles, au cours de 25 l'inscription au service d'envoi des messages, ou, l'utilisateur 106 de mobile a pu indiqué la volonté de payer pour recevoir les alertes mobiles, au cours de l'inscription aux alertes mobile. De plus, un contrôle est également réalisé sur un certain nombre d'autres règles qui incluent de préférence des règles qui limitent le nombre d'alertes mobiles que le site Web est autorisé à envoyer pendant une période particulière ou à un 30 utilisateur 106 particulier de mobile, ou à une combinaison de ceux-ci. Pour finir, une vérification est de préférence réalisée pour s'assurer que les utilisateurs 106 de mobiles, à qui les alertes mobiles doivent être délivrées, n'ont effectué aucune restriction sur l'expéditeur de messages, ce qui aurait pour conséquence le rejet d'un message 2906662 24 spécifique, tout autre règle pouvant être mise en application dans l'intérêt de fournir un service de qualité aux utilisateurs 106 de mobiles et à l'administrateur de sites Web. Si l'un quelconque des critères mentionnés ci-dessus n'est pas rempli ou si la vérification échoue, le message spécifique pour l'utilisateur 106 de mobile est rejeté au 5 cours d'une étape 622. Cependant, si tous les critères mentionnés ci-dessus sont remplis, le serveur 102 de gestion d'événements envoie alors les alertes mobiles à l'utilisateur 106 de mobile au cours d'une étape 624, au cours de laquelle les alertes mobiles sont envoyées par l'intermédiaire du fournisseur 108 de service mobile approprié comme prédéfinis pour l'utilisateur 106 de mobile par le fournisseur de 10 services applicatifs. De plus, indépendamment du fait que les critères mentionnés ci-dessus soient remplis ou non, le serveur 102 de gestion d'événements sauvegarde de préférence la nature de l'alerte mobile, l'alerte mobile, un statut d'envoi, un statut de délivrance, et toute autre information concernant l'alerte mobile, dans une base de données hébergée sur le serveur 102 de gestion d'événements. La base de données peut 15 par la suite être mise à disposition de l'administrateur de sites Web. De la même façon, la figure 7 représente un organigramme illustrant un processus au cours duquel l'utilisateur 106 de mobile s'inscrit aux alertes mobiles pour recevoir des mises à jour de site Web par l'intermédiaire du serveur 102 de gestion d'événements. L'administrateur de sites Web supervisant le site Web est un expéditeur 20 de gros volumes de messages. Pour un expéditeur de gros volumes de messages, le site Web doit être préprogrammé avec l'ensemble de structures API fournies et être intégré avec les bibliothèques logicielles. Ainsi, l'expéditeur de gros volumes de messages peut personnaliser à souhait les alertes mobiles envoyées à l'utilisateur 106 de mobile en opposition à l'expéditeur de faibles volumes de messages qui peut seulement utiliser le 25 format substantiellement limité comme défini par le fournisseur de services applicatifs. Au cours d'une étape 702, l'utilisateur 106 de mobile remplit et soumet le formulaire 500 d'inscription aux alertes disponible sur le site Web. Le site Web est de préférence l'un par lequel l'utilisateur 106 de mobile est intéressé pour recevoir des mises à jour de façon régulière. Le formulaire 500 d'inscription aux alertes est de préférence hébergé 30 sur le serveur Web hôte 104 puisque le formulaire 500 d'inscription aux alertes est fortement personnalisé pour s'adapter aux exigences du serveur Web hôte 104. Au cours d'une étape 704, le serveur Web hôte 104 vérifie si le formulaire 500 d'inscription aux alertes est convenablement rempli. sauvegarde une copie sur le 2906662 25 serveur Web hôte 104 et transmet les informations d'inscription aux alertes au serveur 102 de gestion d'événements pour vérification de la validation de la facturation et de l'inscription aux alertes alors que les informations de facturation et les possibilités d'envoi de messages demeurent uniquement sur le serveur 102 de gestion d'événements. 5 Le serveur 102 de gestion d'événements vérifie alors l'existence d'un accord de facturation en contrôlant l'accomplissement d'au moins l'un des critères énumérés en conséquence au cours d'une étape 706: l'utilisateur 106 de mobile est abonné à un des opérateurs 108 de service mobile avec lequel le fournisseur de services applicatifs a un contrat de facturation inversée ou un accord similaire ou si l'administrateur de sites 10 Web du serveur Web hôte 104 a indiqué le souhait d'envoyer des alertes mobiles aux utilisateurs 106 de mobiles qui ne sont pas abonnés à l'un des opérateurs 108 de service mobile avec lesquels le fournisseur de services applicatifs a un contrat de facturation inversée ou un accord similaire et si l'administrateur de site Web mentionné ci-dessus est disposé à payer les frais d'envoi des alertes mobiles et si l'utilisateur 106 de mobile a 15 indiqué qu'il souhaitait recevoir des alertes mobiles bien que n'étant pas abonné à l'un des opérateurs 108 de service mobile avec lesquels le fournisseur de services applicatifs a un contrat de facturation inversée et si l'utilisateur 106 de mobile a apporté des garanties financières telles que des informations de carte de crédit, des dépôts préalable ou a fourni des cordonnées sur d'autres modes de paiement, auquel cas le coût de 20 délivrance des alertes mobiles pourra être débité. Si aucun des critères mentionnés ci-dessus n'est rempli, le serveur 102 de gestion d'événements informe le serveur Web hôte 104 de la défaillance de la condition de facturation au cours d'une étape 708. Le serveur Web hôte 104 informe alors l'utilisateur 106 de mobile de l'impossibilité de poursuivre le processus et rejette les 25 informations d'inscription aux alertes au cours de l'étape 708. Le serveur Web hôte 104, tout comme le serveur 102 de gestion d'événements interdit également de préférence temporairement au numéro de portable d'être utilisé pour d'autres inscriptions aux alertes jusqu'à ce que l'opérateur 108 de service mobile, avec qui l'utilisateur 106 de mobile est engagé, signe un contrat de facturation inversée ou un accord similaire avec 30 le fournisseur de services applicatifs. Cependant, si au moins un des critères mentionnés ci-dessus est rempli, le serveur 102 de gestion d'événements renvoie un message de confirmation à l'utilisateur 106 de mobile au cours d'une étape 710. Le message de confirmation est de préférence un message SMS, un message MMS ou un 2906662 26 message poussé WAP. L'objectif d'envoyer un message de confirmation est d'empêcher les fausses inscriptions dues aux requêtes d'inscription par du Spam par mobile ou par e-mail. Il y a deux types de réponses que l'utilisateur 106 de mobile peut de préférence accepter de fournir à la réception du message de confirmation. Le premier type de 5 réponse consiste en ce que l'utilisateur 106 de mobile est prié de prendre une mesure à la réception du message de confirmation, dans ce cas, cette mesure doit de préférence être de cliquer sur un lien sur une page affichée sur un dispositif mobile utilisé pour l'inscription aux alertes ou répondre par SMS ou par MMS ou par tout autre message mobile ou répondre par l'intermédiaire du site Web lui-même, avec un mot, un 10 caractère, un nombre ou toute autre combinaison de ceux-ci ou avec l'une quelconque des méthodes indiquées dans le message de confirmation envoyé à l'utilisateur 106 de mobile. À réception de la réponse, le serveur 102 de gestion d'événements procède à la validation de l'inscription aux alertes au cours d'une étape 712. Le deuxième type de réponse ordonne à l'utilisateur 106 de mobile de ne pas prendre de mesure à la 15 réception du message de confirmation. L'utilisateur 106 de mobile ne clique pas sur un lien sur une page affichée sur l'appareil mobile utilisé pour l'inscription aux alertes ou ne répond pas par SMS ou par MMS ou d'aucune autre façon avec un mot, un caractère, un nombre ou toute autre combinaison de ceux-ci ou avec l'une quelconque des méthodes indiquées dans le message de confirmation envoyé à l'utilisateur 106 de 20 mobile. En cas d'échec de réception d'une réponse, le serveur 102 de gestion d'événements procède alors à la validation de l'inscription aux alertes au cours de l'étape 712. La validation d'inscription aux alertes sert d'indicateur important pour l'acceptation de l'utilisateur 106 de mobile d'être facturé à un tarif spécifique pour 25 recevoir les alertes mobiles. Les tarifs sont généralement aussi bas que les tarifs habituels que l'utilisateur 106 de mobile paie si l'utilisateur 106 de mobile est l'expéditeur d'un message mobile équivalent envoyé localement ou à l'attention de l'opérateur 108 de service mobile auquel l'utilisateur 106 de mobile est abonné, si l'utilisateur 106 de mobile a renoncé à une offre groupée de messages mobiles que le 30 fournisseur de service 108 met à disposition des abonnés, ou s'il est inclus dans cette offre groupée. Dans un cas plus mauvais, un prix tarifaire ou un tarif spécifique est imposé à l'utilisateur 106 de mobile souhaitant recevoir des alertes mobiles bien que l'opérateur 108 de service mobile n'ait pas de contrat de facturation inversée ou d'accord 2906662 27 similaire avec le fournisseur de services applicatifs. L'opérateur 108 de service mobile peut présenter de faibles tarifs pour les services d'envoi de messages puisque l'opérateur 108 de service mobile ne subit pas les coûts significatifs associés par exemple en s'engageant avec des partenaires de contenu, en intégrant et en testant des relations de 5 facturation des frais, et similaires. Une décision est alors prise au cours d'une étape 712 en déterminant si l'inscription aux alertes est une demande authentique faite par un détenteur d'un numéro de portable utilisé par l'utilisateur 106 de mobile lors de sa souscription. Si l'inscription aux alertes est déterminée comme étant une fausse inscription résultant de 10 requêtes d'inscription par du Spam par mobile ou par e-mail, le serveur 102 de gestion d'événements retransmet les informations au serveur Web hôte 104 au cours d'une étape 714. Le serveur Web hôte 104 rejette alors les informations d'inscription aux alertes reçues au cours d'une étape 716. Si des inscriptions défaillantes aux alertes sont reçus à plusieurs reprises pour un numéro de téléphone portable donné, le serveur 102 de 15 gestion d'événements et le serveur Web hôte 104 peuvent alors temporairement interdire au numéro de téléphone portable d'être utilisé pour d'autres inscriptions aux alertes pendant une période de temps prédéfinie. L'interdiction est exécutée lorsqu'un nombre prédéfini de tentatives défaillantes d'inscription aux alertes, au cours desquelles un numéro de téléphone portable peut être utilisé pour inscription à des alertes mobiles, 20 est excédé. La période de temps prédéfinie pour lever l'interdiction est de préférence programmée, par exemple, pour être de 24 heures. Cependant, si l'inscription aux alertes est déterminée comme étant authentique, le serveur 102 de gestion d'événements, ensuite, au cours d'une étape 718, sauvegarde les informations d'inscription aux alertes reçues ainsi que les données et l'heure de l'inscription sur la 25 base de données hébergée sur le serveur 102 de gestion d'événements et le serveur Web hôte 104. De préférence, les informations sont également mises à disposition du serveur Web hôte 104 pour permettre au serveur Web hôte 104 de contrôler les informations d'inscription aux alertes comme appropriée aux lois économiques employées par le serveur Web hôte 104. L'inscription aux alertes est considérée comme non-exclusive. 30 Lorsque des mises à jour sont disponibles à partir d'un site Web, l'administrateur de sites Web se connecte alors au serveur 102 de gestion d'événements au cours d'une étape 720 pour donner l'ordre au serveur 102 de gestion d'événements d'envoyer les alertes mobiles à l'utilisateur 106 de mobile. Généralement, pour un expéditeur de gros 2906662 28 volumes de messages, l'administrateur de sites Web est autorisé à sélectionner les destinataires à qui les alertes mobiles doivent être délivrées, si une pluralité d'utilisateurs 106 de mobiles se sont inscrits pour recevoir les mises à jour de sites Web. Alternativement, un logiciel s'exécutant sur le serveur Web hôte 104 utilise les API ou 5 d'autres codes fournis par le fournisseur de services applicatifs pour se connecter automatiquement au serveur 102 de gestion d'événements. Le logiciel demande alors au serveur 102 de gestion d'événements d'envoyer des alertes mobiles aux utilisateurs 106 appropriés de mobiles. Avant d'envoyer les alertes mobiles, le serveur 102 de gestion d'événements 10 vérifie si tous les critères pour envoyer les alertes mobiles aux utilisateurs 106 de mobiles sont satisfaits au cours d'une étape 722. Les critères sont énumérés en conséquence. La vérification est conduite sur chacun des utilisateurs 106 de mobiles étant sélectionnés par l'administrateur de sites Web ou le code API ou code similaire pour s'être effectivement inscrits pour recevoir des alertes mobiles à partir du site Web 15 concerné. En outre, l'opérateur de service mobile auquel l'utilisateur 106 de mobile souscrit, a de préférence signé un contrat de facturation inversée ou un accord similaire avec le fournisseur de services applicatifs. Autrement, l'administrateur de sites Web a pu de préférence indiqué, dans la paperasse ou bien au cours de l'inscription, la volonté de payer pour l'envoi des alertes mobiles, ou, l'utilisateur 106 de mobile a pu indiqué la 20 volonté de payer pour recevoir les alertes mobiles, pendant l'inscription aux alertes mobile. De plus, un contrôle est également réalisé sur un certain nombre d'autres règles qui incluent de préférence des règles qui limitent le nombre d'alertes mobiles que le site Web est autorisé à envoyer pendant une période particulière ou à un utilisateur 106 particulier de mobile, ou à une combinaison de ceux-ci. Pour finir, une vérification est 25 de préférence réalisée pour s'assurer que les utilisateurs 106 de mobiles, à qui les alertes mobiles doivent être livrées, n'ont effectué aucune restriction sur l'expéditeur de messages, ce qui aurait pour conséquence le rejet d'un message spécifique, tout autre règle pouvant être mise en application dans l'intérêt de fournir un service de qualité aux utilisateurs 106 de mobiles et à l'administrateur de sites Web. 30 Si l'un quelconque des critères mentionnés ci-dessus n'est pas rempli ou si la vérification échoue, le message spécifique pour l'utilisateur 106 de mobile est rejeté au cours d'une étape 724. Cependant, si tous les critères mentionnés ci-dessus sont rencontrés, le serveur 102 de gestion d'événements envoie alors les alertes mobiles à 2906662 29 l'utilisateur 106 de mobile au cours d'une étape 726, au cours de laquelle les alertes mobiles sont envoyées par l'intermédiaire du fournisseur 108 de service mobile approprié comme prédéfinis pour l'utilisateur 106 de mobile par le fournisseur de services applicatifs. De plus, indépendamment du fait que les critères mentionnés ci- 5 dessus soient remplis ou non, le serveur 102 de gestion d'événements sauvegarde de préférence la nature de l'alerte mobile, l'alerte mobile, un statut d'envoi, un statut de délivrance, et toute autre information concernant l'alerte mobile, dans une base de données hébergée sur le serveur 102 de gestion d'événements. La base de données peut par la suite être mise à disposition de l'administrateur de sites Web. 10 Permettre à l'utilisateur 106 de mobile de résilier le service de réception de nouvelles alertes mobiles est un élément important du système 100 de gestion de mises à jour d'événements. La figure 8 représente un formulaire 800 de résiliation sur une vue schématique décrivant des champs d'entrée du formulaire 800 de résiliation. Dans le formulaire 800 de résiliation, il est donné à l'utilisateur 106 de mobile les options, sous 15 un champ d'entrée d'options, de limiter tout serveur Web hôte 104, temporairement ou de manière permanente, d'envoyer à l'utilisateur 106 de nouvelles alertes mobiles, auxquelles l'utilisateur 106 de mobile s'était précédemment inscrit par l'intermédiaire des serveurs Web hôtes 104 appropriés respectifs. Généralement, le formulaire 500 d'inscription aux alertes est prié de mentionner un lien vers le formulaire 800 d'option 20 de résiliation, cela permettant à l'utilisateur 106 de mobile de trouver facilement les informations d'option de résiliation. Dans le formulaire 800 de résiliation, l'utilisateur 106 de mobile est prié de fournir une information de numéro de téléphone portable comprenant l'indication du code de pays pour le service mobile avec lequel l'utilisateur 106 de mobile est engagé et un numéro de téléphone portable utilisé pour les 25 inscriptions aux alertes mobiles. Le serveur 102 de gestion d'événements utilise alors les informations de numéro de téléphone portable pour déterminer si l'utilisateur 106 de mobile s'est précédemment inscrit pour recevoir des alertes mobiles par les serveurs Web hôtes 104 spécifiques et utilise de plus les informations de numéro de téléphone portable pour valider la demande d'option de résiliation. En outre, l'utilisateur 106 de 30 mobile est également prié de fournir une adresse e-mail à laquelle le statut d'une demande d'option de résiliation est envoyé à la fin du processus d'option de résiliation. La figure 9 représente un organigramme d'un processus 900 d'option de résiliation, par lequel, au cours d'une étape 902, l'utilisateur 106 de mobile soumet le 2906662 30 formulaire 800 de résiliation par l'intermédiaire de l'un quelconque des serveurs Web hôtes 104 qui propose des alertes mobiles par le serveur 102 de gestion d'événements ou directement en visitant le site Web du fournisseur de services applicatifs, qui est également, de préférence, le site Web du serveur 102 de gestion d'événements. Au 5 cours d'une étape 904, le fournisseur de services applicatifs vérifie alors si le numéro de portable fourni par l'utilisateur 106 de mobile a été précédemment inscrit pour recevoir des alertes mobiles d'un serveur Web hôte 104 que l'utilisateur 106 de mobile souhaite limiter ou interdire temporairement ou de manière permanente, d'envoyer à l'utilisateur 106 de mobile de nouvelles alertes mobiles. Une décision est prise au cours d'une étape 10 906. S'il est déterminé que l'utilisateur 106 de mobile n'est pas inscrit pour recevoir des alertes mobiles du serveur Web hôte 404 spécifique, le serveur 102 de gestion d'événements informe l'utilisateur 106 de mobile, de préférence par l'intermédiaire d'une page de réponse de forme de Web, que l'utilisateur 106 de mobile n'est pas enregistré pour recevoir des alertes mobiles du serveur Web hôte 404 spécifique. Le 15 serveur 102 de gestion d'événements rejette alors, par la suite, la demande d'option de résiliation, au cours d'une étape 908. Cependant, s'il est déterminé que l'utilisateur 106 de mobile est enregistré pour recevoir des alertes mobiles du serveur Web hôte 404 spécifique, le serveur 102 de gestion d'événements valide alors que l'utilisateur 106 de mobile sollicitant l'option de résiliation est en effet le détenteur du numéro de portable 20 que l'utilisateur 106 de mobile a indiqué dans le formulaire 800 de résiliation. La validation requise mentionnée ci-dessus est importante pour empêcher l'arrêt frauduleux ou malfaisant de services à un utilisateur 106 légitime de mobile légitime. Afin de valider l'identité de l'utilisateur 106 de mobile, le serveur 102 de gestion d'événements envoie un message de confirmation au numéro de portable indiqué par 25 l'utilisateur 106 de mobile dans le formulaire 800 de résiliation, au cours d'une étape 910. Le procédé de validation est similaire aux étapes 610 à 616 représentées sur la figure 6. Au cours d'une étape 912, le serveur 102 de gestion d'événements détermine si la demande d'option de résiliation est valide. Si la demande d'option de résiliation est invalide, la demande d'option de résiliation est rejetée, au cours d'une étape 914 et 30 l'utilisateur 106 de mobile est informé, de préférence par l'intermédiaire de l'adresse e-mail fournie par l'utilisateur 106 de mobile dans le formulaire 800 de résiliation. Informer l'utilisateur 106 de mobile de son statut sur une page Web affichée comme réponse lorsque l'utilisateur 106 de mobile soumet au début le formulaire 800 de 2906662 31 résiliation, est considéré peu pratique en raison de la durée impliquée dans le processus d'option de résiliation. Cependant, si la demande d'option de résiliation est valide, la demande d'option de résiliation est alors sauvegardée dans les bases de données du serveur 102 de gestion d'événements. Au cours d'une étape finale 916, la demande 5 d'option de résiliation est immédiatement activée, et l'utilisateur 106 de mobile est informé du succès dans le processus d'option de résiliation ou dans la restriction de service par l'intermédiaire de l'adresse e-mail fournie par l'utilisateur 106 de mobile dans le formulaire 800 de résiliation. Informer l'utilisateur 106 de mobile de son statut sur une page Web affichée comme réponse lorsque l'utilisateur 106 de mobile soumet 10 au début le formulaire 800 de résiliation est considéré peu pratique en raison de la durée impliquée dans le processus d'option de résiliation. Le serveur 102 de gestion d'événements doit de préférence envoyer également une notification électronique au serveur Web hôte 104 approprié de l'option de résiliation ou de la restriction de service garantie par l'utilisateur 106 de mobile. 15 Selon l'exemple précédent, un système de gestion de mises à jour d'événements fournissant des notifications de mises à jour et d'événements aux utilisateurs de mobiles qui se sont inscrits aux alertes mobiles pour recevoir des mises à jour de sites Web est décrit, selon une forme de réalisation de l'invention, pour remédier aux inconvénients antérieurs des approches de gestion de mises à jour d'événements relatives à la 20 délivrance d'alertes mobiles. Bien qu'une seule forme de réalisation de l'invention soit révélée, il sera évident pour un homme du métier, aux suite de cette description, que de nombreux variantes et/ou modification peuvent être faites sans s'écarter de la portée et de l'esprit de l'invention. REVENDICATIONS 1. Système de gestion de mises à jour d'événements, caractérisé en ce qu'il comprend : un module de données pour recevoir des données d'inscription aux alertes, fourni par un serveur Web hôte, les données d'inscription aux alertes étant générées lorsqu'un utilisateur de service mobile soumet une demande d'inscription aux alertes correspondant à un événement par l'intermédiaire du serveur Web hôte ; une base de données pour sauvegarder les données d'inscription aux alertes ; et un module d'alerte pour générer une alerte en réponse à une instruction fournie par un administrateur de sites Web supervisant le serveur Web hôte, l'instruction étant associée à l'événement et également au module d'alerte pour envoyer l'alerte à l'utilisateur de service mobile correspondant aux données d'inscription aux alertes. 2. Système de gestion de mises à jour d'événements selon la revendication 1, caractérisé en ce qu'il comprend, en outre, un module de validation pour envoyer un message à l'utilisateur de service mobile pour valider la demande d'inscription aux alertes soumise par l'utilisateur de service mobile par l'intermédiaire du serveur Web hôte, ce message étant ladite alerte. 3. Système de gestion de mises à jour d'événements selon la revendication 1, caractérisé en ce que l'alerte est l'un quelconque des messages parmi un message SMS, un message MMS et un message WAP de "push alert". 4. Système de gestion de mises à jour d'événements selon la revendication 1, caractérisé en ce que le serveur Web hôte héberge un site Web étant préprogrammé avec un ensemble de fonctions API ou avec des codes sources fournis par le système de gestion de mises à jour d'événements. 5. Système de gestion de mises à jour d'événements selon la revendication 4, caractérisé en ce que l'ensemble de fonctions API comprend des fonctions d'intercommunication logicielle pour un usage avec le site Web afin de communiquer avec le système de gestion de mises à jour d'événements. 6. Système de gestion de mises à jour d'événements selon la revendication 4, caractérisé en ce que le serveur Web hôte pré-télécharge et pré-intègre des 2906662 33 bibliothèques logicielles avec le site Web, les bibliothèques logicielles étant fournies par le système de gestion de mises à jour d'événements. 7. Système de gestion de mises à jour d'événements selon la revendication 6, caractérisé en ce que les bibliothèques logicielles sont des applications 5 logicielles de l'ensemble de fonctions API. 8. Système de gestion de mises à jour d'événements selon la revendication 4, caractérisé en ce que le site Web héberge un formulaire d'inscription aux alertes pour un usage avec la demande d'inscription aux alertes. 9. Système de gestion de mises à jour d'événements selon la revendication 8, 10 caractérisé en ce que le formulaire d'inscription aux alertes comprend des champs d'entrée pour la saisie d'au moins l'une des coordonnées d'inscription et des coordonnées de facturation de l'utilisateur de service mobile pour générer des données d'inscription aux alertes à partir de celles-ci. 10. Système de gestion de mises à jour d'événements selon la revendication 1, 15 caractérisé en ce que le module d'alerte peut en outre suivre le cheminement d'au moins une alerte envoyée à l'utilisateur de service mobile. 11. Système de gestion de mises à jour d'événements selon la revendication 1, caractérisé en ce qu'il comprend en outre : une pluralité de comptes, l'un parmi cette pluralité de comptes 20 correspondant à l'administrateur de sites Web supervisant le serveur Web hôte pour réaliser au moins une des fonctions administratives concernant le compte parmi la pluralité de comptes et pour permettre à l'administrateur de sites Web de donner l'ordre au module d'alerte de générer et d'envoyer l'alerte à l'utilisateur de service mobile. 25 12. Système de gestion de mises à jour d'événements selon la revendication 1, caractérisé en ce qu'il comprend en outre : un module de facturation pour la gestion des coordonnées de facturation d'au moins l'un des utilisateurs de services mobiles et des serveurs Web hôtes, les coordonnées de facturation correspondant à l'alerte envoyée à l'utilisateur de 30 service mobile par le module d'alerte. 13. Système de gestion de mises à jour d'événements selon la revendication 1, caractérisé en ce que les données d'inscription aux alertes sont accessibles et 2906662 34 peuvent être éditées par l'un des utilisateurs de service mobile et par le serveur Web hôte. 14. Procédé de gestion de mises à jour d'événements caractérisé en ce qu'il comprend les étapes : 5 de réception des données d'inscription aux alertes fournies par un serveur Web hôte par un module de données, les données d'inscription aux alertes étant générées lorsqu'un utilisateur de service mobile soumet une demande d'inscription aux alertes correspondant à un événement par l'intermédiaire du serveur Web hôte ; 10 de sauvegarde des données d'inscription aux alertes dans une base de données ; de génération d'une alerte en réponse à une instruction reçue par le serveur Web hôte, l'instruction étant associée à un événement ; et d'envoi de l'alerte à l'utilisateur de service mobile correspondant aux 15 données d'inscription aux alertes. 15. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce qu'il comprend en outre l'étape de fourniture d'un module de validation pour envoyer un message à l'utilisateur de service mobile pour valider la demande d'inscription aux alertes soumise par l'utilisateur de service mobile 20 par l'intermédiaire du serveur Web hôte, le message contenant l'alerte. 16. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce que l'étape d'envoi de l'alerte comprend l'étape : de génération et d'envoi de l'un quelconque des messages parmi un message SMS, un message MMS et un message WAP de "push alert", comme 25 alerte. 17. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce qu'il comprend en outre l'étape d'hébergement d'un site Web par le serveur Web hôte, le site Web étant préprogrammé avec un ensemble de fonctions API ou avec des codes sources fournis par le système de gestion de 30 mises à jour d'événements. 18 Procédé de gestion de mises à jour d'événements selon la revendication 17, caractérisé en ce que l'étape d'hébergement d'un site Web par le serveur Web comprend l'étape : 2906662 de fourniture de l'ensemble de fonctions API comprenant des fonctions d'intercommunication logicielle pour un usage avec le site Web afin de communiquer avec le système de gestion de mises à jour d'événements. 19. Procédé de gestion de mises à jour d'événements selon la revendication 17, 5 caractérisé en ce que l'étape d'hébergement d'un site Web par le serveur Web hôte comprend l'étape de fourniture de bibliothèques logicielles par le système de gestion de mises à jour d'événements. 20. Procédé de gestion de mises à jour d'événements selon la revendication 19, caractérisé en ce que les bibliothèques logicielles sont des applications de 10 l'ensemble des fonctions API dans le logiciel. 21. Procédé de gestion de mises à jour d'événements selon la revendication 17, caractérisé en ce que l'étape d'hébergement d'un site Web par le serveur Web hôte comprend l'étape de fourniture d'un formulaire d'inscription aux alertes par le site Web pour un usage avec la demande d'inscription aux alertes. 15 22. Procédé de gestion de mises à jour d'événements selon la revendication 21, caractérisé en ce que l'étape de fourniture d'un formulaire d'inscription aux alertes comprend l'étape : de fourniture du formulaire d'inscription aux alertes comprenant des champs d'entrée pour la saisie d'au moins l'une des coordonnées d'inscription et 20 des coordonnées de facturation de l'utilisateur de service mobile pour générer des données d'inscription aux alertes à partir de celles-ci. 23. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce que l'étape de d'envoi de l'alerte comprend l'étape de cheminement d'au moins une alerte envoyée à l'utilisateur de service mobile. 25 24. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce qu'il comprend en outre l'étape : de fourniture d'une pluralité de comptes, l'un parmi cette pluralité de comptes correspondant à l'administrateur de sites Web supervisant le serveur Web hôte pour réaliser au moins une des fonctions administratives concernant le 30 compte parmi la pluralité de comptes et pour permettre à l'administrateur de sites Web de donner l'ordre au module d'alerte de générer et d'envoyer l'alerte à l'utilisateur de service mobile. 2906662 36 25. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce qu'il comprend en outre l'étape : de gestion des coordonnées de facturation d'au moins l'un des utilisateurs de services mobiles et des serveurs Web hôtes, les coordonnées de facturation 5 correspondant à l'alerte envoyée à l'utilisateur de service mobile par le module d'alerte. 26. Procédé de gestion de mises à jour d'événements selon la revendication 14, caractérisé en ce qu'il comprend en outre l'étape : de permission d'accès aux données d'inscription aux alertes par l'un des 10 utilisateurs de services mobiles et des serveurs Web hôtes pour éditer les données d'inscription aux alertes. 27. Support exploitable par une machine ayant une pluralité d'instructions de programmation stockées en lui, caractérisé en ce que, lorsqu'elles sont exécutées par une machine, les instructions entraînent la machine à : 15 recevoir les données d'inscription aux alertes fournies par un serveur Web hôte par un module de données, les données d'inscription aux alertes étant générées lorsque un utilisateur de service mobile soumet une demande d'inscription aux alertes correspondant à un événement par l'intermédiaire du serveur Web hôte ; 20 sauvegarder les données d'inscription aux alertes sur une base de données ; générer une alerte en réponse à une instruction reçue par le serveur Web hôte, l'instruction étant associée à l'événement ; et envoyer l'alerte à l'utilisateur de service mobile correspondant aux 25 données d'inscription aux alertes. 28. Support exploitable par une machine selon la revendication 27, caractérisé en ce que les instructions de programmation, lorsqu'elles sont exécutées par une machine, entraînent de plus la machine à fournir un module de validation pour envoyer un message à l'utilisateur de service mobile pour valider la demande 30 d'inscription aux alertes soumise par l'utilisateur de service mobile par l'intermédiaire du serveur Web hôte, ce message étant ladite alerte. 29. Support exploitable par une machine selon la revendication 27, caractérisé en ce que les instructions de programmation, lorsqu'elles sont exécutées par une 2906662 37 machine, entraînent la machine à générer et envoyer l'un quelconque des messages parmi un message SMS, un message MMS et un message WAP de "push alert", comme alerte. 30. Support exploitable par une machine selon la revendication 27, caractérisé en ce 5 qu'un site Web est hébergé par le serveur Web hôte, le site Web étant préprogrammé avec un ensemble de fonctions API ou avec des codes sources fournis par le système de gestion de mises à jour d'événements. 31 Support exploitable par une machine selon la revendication 30, caractérisé en ce que l'ensemble de fonctions API comprend des fonctions d'intercommunication 10 logicielle pour un usage avec le site Web afin de communiquer avec le système de gestion de mises à jour d'événements. 32. Support exploitable par une machine selon la revendication 30, caractérisé en ce que des bibliothèques logicielles peuvent être fournies par le système de gestion de mise à jour d'événement. 15 33. Support exploitable par une machine selon la revendication 32, caractérisé en ce que les bibliothèques logicielles sont des applications de l'ensemble des fonctions API dans le logiciel. 34. Support exploitable par une machine selon la revendication 30, caractérisé en ce qu'un formulaire d'inscription aux alertes est fourni par le site Web pour un 20 usage avec la demande d'inscription aux alertes. 35. Support exploitable par une machine selon la revendication 34, caractérisé en ce que le formulaire d'inscription aux alertes comporte des champs d'entrée pour saisir au moins l'une des coordonnées d'inscription et des coordonnées de facturation de l'utilisateur de service mobile pour générer des données 25 d'inscription aux alertes à partir de celles-ci. 36. Support exploitable par une machine selon la revendication 27, dans lequel les instructions de programmation, une fois exécutées par une machine, amènent la machine à suivre au moins une alerte envoyée à l'utilisateur de service mobile. 30 37. Support exploitable par une machine selon la revendication 27, dans lequel les instructions de programmation, une fois exécutées par une machine, amènent la machine à fournir en outre une pluralité de comptes, un compte parmi la pluralité de comptes correspondant au gestionnaire de site Web gérant le serveur 2906662 38 de Web hôte pour fournir au moins une fonction administrative en rapport à un compte parmi la pluralité de comptes et pour permettre au gestionnaire de site Web de donner des instructions au module d'alerte pour produire et envoyer l'alerte à l'utilisateur de service mobile. 5 38. Support exploitable par une machine selon la revendication 27, dans lequel les instructions de programmation, une fois exécutées par une machine, amènent la machine à gérer des coordonnées de facturation d'au moins un des utilisateurs de service mobile et du serveur de Web hôte, les coordonnées de facturation correspondant à l'alerte envoyée à l'utilisateur de service mobile par le module 10 d'alerte. 39. Support exploitable par une machine selon la revendication 30, dans lequel les instructions de programmation, une fois exécutées par une machine, amènent la machine à permettre l'accès aux données d'enregistrement d'alertes par l'un des utilisateurs de service mobile et du serveur de Web hôte pour éditer les données 15 d'alertes d'enregistrement.