La présente invention concerne un système, un serveur et un procédé de gestion de services dans un réseau, au moins un service étant réalisé par l'exécution d'au moins deux actions fournies par des systèmes prestataires différents.

De nombreux protocoles et architectures existent pour permettre le paiement en ligne de biens ou services fournis pour un client par une application. Cependant il existe de plus en plus de services qui, pour être réalisés, nécessitent la mise en œuvre de plusieurs fonctions de base, ou actions, fournies par des prestataires différents.

Ainsi, par exemple, un service d'envoi de SMS localisé avec information de présence nécessite l'utilisation d'une fonction de gestion de SMS, d'une fonction de localisation et d'une fonction de présence. Pour réaliser ce service, le fournisseur de services doit donc coordonner l'exécution des actions de chaque prestataire ainsi que les facturations afférentes.

Actuellement, trois architectures de facturation sont utilisées. Dans la première architecture, chaque prestataire facture sa prestation indépendamment les uns des autres. Chaque prestataire a donc une liaison directe avec le serveur de gestion des comptes des utilisateurs, ou serveur de facturation.

Cette architecture a l'inconvénient de générer une micro facturation de chaque action alors que l'utilisateur a demandé un service unique et global. De plus, en cas d'échec d'une action située en aval du flux successif d'actions, le client est débité du prix des actions réussies en amont alors que le service n'a pas été obtenu. Pour éviter cela, une corrélation doit être faite au niveau du serveur de facturation, corrélation en pratique très complexe à mettre en œuvre.

Aussi, dans une deuxième architecture, le fournisseur de services facture le service d'une manière globale. Celui-ci a donc une liaison directe avec le serveur de facturation.

Cependant, cette architecture a l'inconvénient de laisser aux prestataires la possibilité de facturer directement leur action, créant ainsi un

risque de double facturation. Ainsi un prestataire peut facturer son action pendant que le fournisseur de services facture globalement le service rendu, facture incluant le prix de l'action rendue par le prestataire.

Enfin, dans une troisième architecture, le prestataire de la dernière action facture globalement le service et est donc en relation avec le serveur de facturation.

Cette architecture a l'inconvénient d'obliger le dernier prestataire à adapter sa facturation au service demandé avec un système complexe de coordination et de recueil d'informations avec les autres prestataires. Le but de l'invention est donc de proposer un système et un serveur qui suppriment tous les inconvénients précités et qui donc permettent la mise en oeuvre d'une facturation de façon fiable et facile d'emploi.

L'objet de l'invention est donc un serveur d'orchestration d'un système de gestion de services pour un utilisateur dans un réseau, au moins un service étant réalisé par l'exécution d'au moins deux actions fournies par des systèmes prestataires différents, ledit serveur comportant

- des premiers moyens de communication avec des moyens d'interfaces, ces moyens d'interface étant adaptés pour permettre à l'utilisateur de demander l'exécution d'un service et pour présenter à l'utilisateur le résultat obtenu par le service demandé ;

- des deuxièmes moyens de communication avec un serveur de gestion de comptes, ledit serveur étant adapté pour créditer et/ou débiter le compte de l'utilisateur en fonction d'ordres de facturation ;

- des troisièmes moyens de communication avec les systèmes prestataires, caractérisé en ce qu'il comporte en outre :

- des moyens de stockage d'un flux de travail et d'un flux de facturation pour chaque service, le flux de travail définissant le cadencement des actions permettant de réaliser le service et le flux de facturation définissant les règles de facturation à appliquer pour le service, connectés à :

- des moyens d'activation de services aptes, pour chaque service demandé et en fonction du flux de travail stocké correspondant à ce service, à

séquencer des ordres d'exécution d'actions et à transmettre ces ordres aux systèmes prestataires, et à

- des moyens de gestion de la facturation de chaque service demandé aptes à déterminer, en fonction de la réussite ou de l'échec de l'exécution des actions réalisées pour le service et du flux de facturation défini, les ordres de facturation à envoyer au serveur de gestion de comptes.

Un autre objet de l'invention est un système de gestion de services pour un utilisateur dans un réseau, au moins un service étant réalisé par l'exécution d'au moins deux actions fournies par des systèmes prestataires différents, ledit système comportant :

- des moyens d'interface avec l'utilisateur adaptés pour permettre à celui-ci de demander l'exécution d'un service et pour présenter à l'utilisateur le résultat obtenu par le service demandé,

- un serveur de gestion de comptes de l'utilisateur apte à créditer et/ou à débiter ce compte en fonction d'ordres de facturation, caractérisé en ce qu'il comporte en outre, un serveur d'orchestration comme défini précédemment, ce serveur étant connecté aux moyens d'interface, au serveur de gestion de comptes et aux systèmes prestataires.

Un troisième objet de l'invention est un procédé de gestion de services par un serveur d'orchestration pour un utilisateur dans un réseau, au moins un service étant réalisé par l'exécution d'au moins deux actions fournies par des systèmes prestataires différents, ledit procédé comportant les étapes de : a) réception d'une demande de service provenant de l'utilisateur, puis b) sélection d'un flux d'exécution et d'un flux de facturation adaptés au service demandé, ledit flux d'exécution comportant un cadencement d'actions à exécuter, c) envoi d'un ordre d'exécution d'une action à un système prestataire, d) réception du résultat de l'action exécutée, les étapes c) et d) étant répétées autant de fois que défini dans le flux d'exécution sélectionné et dans l'ordre défini par celui-ci, e) envoi à l'utilisateur de la réponse correspondant au service demandé,

et ledit procédé comportant en outre au moins une étape d'émission d'au moins un ordre de facturation en fonction du flux de facturation sélectionné.

D'autres caractéristiques de ce troisième objet sont : - l'étape d'émission d'au moins un ordre de facturation comporte une première sous étape i) de demande d'autorisation pour vérifier que le compte de l'utilisateur est compatible avec l'ordre de facturation, cette première sous étape étant exécutée avant l'étape c), et une seconde sous étape ii) de confirmation pour déclencher ou annuler la facturation correspondante ; - la sous étape d'autorisation, respectivement la sous étape de confirmation, est exécutée avant chaque étape d'envoi d'un ordre d'exécution, respectivement après chaque étape de réception du résultat de l'action ;

- la sous étape d'autorisation, respectivement la sous étape de confirmation, est exécutée avant la première étape d'envoi d'un ordre d'exécution, respectivement après la dernière étape de réception, définie dans le flux ;

- la sous étape d'autorisation, respectivement la sous étape de confirmation, est exécutée avant la première étape d'envoi d'un ordre tel que défini dans le flux d'exécution, respectivement après chaque étape de réception de résultat d'une action ; et

- la sous étape d'autorisation initialise en outre un quota et la sous étape de validation transfère au serveur de gestion de comptes la quantité de quota consommée et l'étape d'envoi d'un ordre d'exécution envoie le quota au serveur prestataire et l'étape de réception de la réponse transmet au serveur d'orchestration la quantité de quota consommée.

Un quatrième objet de l'invention est un produit programme d'ordinateur comprenant des instructions de code de programme enregistrées sur un support lisible par un ordinateur, pour mettre en œuvre les étapes du procédé précédent lorsque ledit programme fonctionne sur un ordinateur. L'invention sera mieux comprise à la lecture de la description qui va suivre, faite uniquement à titre d'exemple, et en référence aux dessins en annexe dans lesquels :

- la figure 1 est un schéma simplifié d'un système et d'un serveur selon un mode de réalisation préféré de l'invention ; et

- la figure 2 est un schéma temporel des flux entre les différents éléments du système de la figure 1 lors de l'exécution d'un service. En référence à la figure 1 , un système de gestion de services comprend un serveur 1 d'orchestration.

Ce serveur 1 d'orchestration est connecté à des moyens SPi, SP ₂ , SP ₃ , d'interface, ou fournisseurs de service, par des premiers moyens 2 de communication. Ces fournisseurs de service SP-i, SP ₂ , SP ₃ permettent à un utilisateur de sélectionner un service, ou une prestation, et, en retour, lui fournissent le service sélectionné. Un tel service est, par exemple, un service d'envoi de SMS localisé.

Le serveur 1 d'orchestration est également connecté à un serveur SGC de gestion de comptes des utilisateurs par des deuxièmes moyens 3 de communication.

Le serveur SGC de gestion de comptes est également appelé, dans la littérature, serveur de facturation. Classiquement, le serveur SGC a trois rôles : la valorisation d'un événement, c'est-à-dire la fourniture d'un prix, la facturation et la gestion des comptes. Le serveur SGC de gestion de comptes reçoit des ordres de facturation du serveur 1 d'orchestration et débite ou crédite les comptes des utilisateurs en fonction de ces ordres. En particulier, il doit être remarqué que l'utilisation du terme « facturation » dans cette description n'implique pas nécessairement l'émission d'une facture mais correspond à un mouvement de valeurs.

Le serveur SGC de gestion de comptes est également capable de traiter des demandes d'autorisation ainsi que des demandes de confirmation provenant du serveur 1 d'orchestration. Bien qu'optionnels, ces deux types de demandes sont, dans la pratique, régulièrement mis en œuvre. Une demande d'autorisation permet de contrôler qu'un événement facturable associé à un utilisateur peut être réalisé. Elle permet donc de déterminer si l'utilisateur est suffisamment solvable pour lui accorder l'accès à une ressource. De façon non exhaustive, suite à une demande d'autorisation, le

serveur SGC de gestion de comptes vérifie que l'utilisateur est connu, qu'il a suffisamment de crédit et qu'il n'a pas dépassé des seuils de consommation qui lui ont été attribués, qu'il ne fait pas partie d'une liste d'utilisateurs interdits, qu'il a donné son accord pour être facturé,... Une demande de confirmation permet d'informer le serveur SGC de gestion de comptes qu'une action particulière a bien été réalisée et qu'elle peut être facturée. Cela correspond donc à un ordre de facturation proprement dit puisque, suite à la réception de cette demande de confirmation, le serveur SGC de gestion de comptes débite le compte de l'utilisateur du montant prévu. Une demande de confirmation n'est pas obligatoirement reliée à une demande d'autorisation, certaines actions pouvant être exécutées et facturées sans autorisation préalable.

Dans la suite de la description, on utilisera le terme de « demande de confirmation partielle » quand celle-ci correspond à l'exécution d'une partie seulement d'un service demandé par l'utilisateur.

Le serveur 1 d'orchestration est également connecté à des serveurs prestataires E-i, E ₂ , E ₃ , aussi appelés « enablers » dans la littérature technique anglo-saxonne, par des troisièmes moyens 4 de communication.

Il doit être compris que les premiers, deuxièmes et troisièmes moyens 2, 3, 4 de communication sont différenciés dans cette description au niveau fonctionnel. Dans une implémentation préférée, les différents serveurs sont connectés à un même réseau à la norme TCP/IP, les paquets de données étant dirigés en fonction des adresses de chaque serveur. Ainsi, physiquement, le serveur 1 d'orchestration a une seule carte réseau et une seule connexion physique avec le réseau TCP/IP. D'autres architectures de réseau peuvent être choisies par l'homme du métier pour obtenir les fonctionnalités désirées tout en s'adaptant aux contraintes locales comme, par exemple, le rattachement à plusieurs réseaux privés et/ou publics.

Le serveur 1 d'orchestration comporte des moyens 5 de stockage des flux de travail et du flux de facturation de chaque service.

Pour un service donné, un flux de travail (« workflow » en anglais), définit l'enchaînement des appels aux serveurs prestataires E-i, E ₂ , E ₃ permettant de réaliser le service demandé.

Ainsi, le flux de travail définit les différents serveurs prestataires E ₁ , E ₂ , E ₃ composant le service et l'ordre séquentiel de leurs appels.

Il définit également la façon dont chaque serveur prestataire E-i, E ₂ , E ₃ doit réaliser l'action demandée, c'est-à-dire son paramétrage. Le flux de facturation d'un service définit le scénario de facturation de ce service.

Pour chaque service, un scénario générique parmi trois est choisi. Le premier scénario générique fonctionne sur le mode « une autorisation globale - des confirmations partielles ». Dans ce scénario, le serveur 1 d'orchestration fait une demande d'autorisation globale pour tout le service, au serveur SGC de gestion de comptes et envoie des confirmations partielles pour la réalisation de chaque action d'un serveur prestataire. Cette demande d'autorisation globale est faite en général avant le début d'exécution du service et est réitérée autant de fois que nécessaire. Le deuxième scénario générique fonctionne sur le mode « une autorisation globale - une confirmation globale ». Dans ce scénario, le serveur 1 d'orchestration fait une demande d'autorisation globale pour tout le service au serveur SGC de gestion de comptes et envoie une confirmation globale pour tout le service. La demande d'autorisation globale est faite en général avant le début d'exécution des actions du service et est réitérée autant de fois que nécessaire. La confirmation globale a lieu en général après la fin d'exécution des actions du service.

Le troisième scénario générique fonctionne sous le mode « des autorisations partielles - des confirmations partielles ». Dans ce scénario, les demandes d'autorisation sont exécutées en général avant l'exécution d'une action, ou d'un groupe d'actions, du service et la confirmation est exécutée en général après l'exécution de cette action, ou groupe d'actions.

En plus de ces scénarios génériques, le flux de facturation définit pour chaque action son mode de facturation, voire sa gratuité ainsi que le comportement à tenir en cas d'échec : cette action peut être facturée quel que soit la réussite ou l'échec de l'action. Elle peut également être facturée, ou non, en fonction de la réussite des actions précédentes ou suivantes, indépendamment de la réussite globale du service.

En effet, la facturation d'une action peut avoir lieu indépendamment des résultats des autres actions du service, ou, au contraire être conditionnée au succès de l'ensemble des actions du service. Dans ce dernier cas, l'échec dans la réalisation d'une action entraîne l'annulation de la facturation des actions réussies en amont du flux d'exécution.

A titre d'exemple, supposons qu'un service X nécessite quatre actions A, B, C et D, les actions A, C et D étant payantes et l'action B gratuite.

La colonne « Dépendance » définit que la facturation de l'action C dépend du succès de l'action D. Ainsi, si les actions A et C ont été facturées mais que l'action D échoue, alors la facturation liée à l'action C est annulée et la facturation liée à l'action A est maintenue.

Le serveur 1 d'orchestration comporte également des moyens 6 d'activation de services qui, pour chaque service demandé, sélectionnent dans les moyens 5 de stockage le flux de travail correspondant et, en fonction du cadencement défini dans ce flux de travail émettent des ordres d'exécution des actions en direction des serveurs prestataires E1 , E2, E3, réceptionnent les réponses de ceux-ci et construisent ainsi le service.

Le serveur 1 d'orchestration comporte des moyens 7 de gestion de la facturation qui, pour chaque service demandé, sélectionnent le flux de facturation correspondant. En fonction des règles de ce flux de facturation et de la réussite ou de l'échec des actions cadencées par les moyens 6 d'activation, ces moyens 7 de gestion de la facturation émettent des ordres de facturation à destination du serveur SGC de gestion de comptes.

Le fonctionnement du serveur 1 d'orchestration et plus généralement du système de gestion de services va maintenant être explicité en relation avec la figure 2 qui représente un scénario de réalisation d'un service.

Sur cette figure, le déroulement temporel a lieu de haut en bas, les différentes flèches horizontales représentant les interactions entre les différents

serveurs. A partir de la gauche, la première colonne symbolise l'utilisateur U, la deuxième colonne, le fournisseur de service SP, la troisième colonne, le serveur 1 d'orchestration, la quatrième colonne, les différents serveurs prestataires et la cinquième colonne, le serveur SGC de gestion de comptes. Après une interaction 10 avec l'utilisateur U, le fournisseur de services

SP émet en 11 une demande de services auprès du serveur 1 d'orchestration.

Le serveur 1 d'orchestration recherche en 12 le flux d'exécution et le flux de facturation du service demandé.

Pour la clarté de l'exemple, on suppose que le flux de facturation correspond à un scénario « une autorisation globale - des confirmations partielles ». L'homme du métier sait, sans difficulté, adapter le scénario présenté aux autres types de scénarios génériques.

En 13, le serveur 1 d'orchestration envoie une demande d'autorisation globale au serveur SGC de gestion de comptes. Cette demande d'autorisation a, par exemple, la forme

Authorize (service-id, actions, params) où « service-id » est l'identifiant du service, « actions » est la liste des serveurs prestataires impliqués et « params » représente tous les paramètres utiles à la valorisation du service. En cas de réponse positive, le serveur 1 d'orchestration reçoit un identifiant de transmission trx-id.

Puis, pour la première action à exécuter, celle-ci étant définie comme étant effectuée par le prestataire E ₁ , le serveur 1 d'orchestration envoie en 14 une requête d'exécution de l'action, par exemple sous la forme Function-E1-Request (trx-id, trx-id-E1 , actions, params) où « trx-id » est l'identifiant de transaction globale obtenu précédemment, « trx-id-E1 » est l'identifiant de la transaction spécifique à la facturation de l'action du serveur prestataire E1 , « actions » est l'action à exécuter et « params » les paramètres nécessaires à l'exécution et la valorisation de cette action. L'identifiant « trx-id-Ei » est créé par le serveur 1 d'orchestration et est lié à l'identifiant global « trx-id ».

En 15, le serveur prestataire E1 envoie la réponse correspondante. Celle-ci est positive ou négative en fonction de la réussite ou de l'échec de

l'action. Elle contient l'identifiant trx-id-E1 afin d'identifier la réponse et la relier au service adéquat.

En 16, le serveur 1 d'orchestration envoie une confirmation au serveur SCG de gestion de comptes. C'est une confirmation partielle qui ne concerne que l'action qui vient d'être effectuée. Il est à noter que, en cas d'échec de l'action, cette confirmation peut être en fait une annulation de facturation.

Pour l'action suivante qui doit être exécutée par le serveur prestataire E2, les étapes de demandes d'exécution en 17, de réponse en 18 et de confirmation partielle en 19 sont à nouveau exécutées. Ce cycle est répété autant de fois que nécessaire pour exécuter l'ensemble des actions définies pour le service demandé.

A titre illustratif, la figure 2 montre en 20 une étape d'autorisation optionnelle. Dans ce scénario générique, cette étape d'autorisation est exécutée quand le montant total autorisé par la précédente demande d'autorisation a été consommé. Le serveur 1 d'orchestration émet alors une nouvelle demande d'autorisation similaire à celle décrite à l'étape 13.

L'autorisation ayant été obtenue, la dernière action auprès du serveur prestataire E3 est demandée en 21 , la réponse étant faite en 22 et la confirmation de facturation en 23. Toutes les actions ayant été exécutées et le service pouvant être rendu à l'utilisateur, le serveur 1 d'orchestration retourne la réponse en 24 au fournisseur de services SP qui en informe l'utilisateur en 25.

En variante, ce système de gestion de services fonctionne également avec un serveur SGC de gestion de comptes adapté pour gérer des quotas c'est- à-dire des unités de service ou des droits d'accès au service. Un quota peut contenir plusieurs ressources monétaires ou non, telles que des tailles de mémoire, des temps d'utilisation, ... Par quota, il faut donc entendre une pluralité de variables de consommation.

On conçoit alors que la demande d'autorisation correspond à une demande de quota, la réponse étant un quota utilisable et la confirmation devient une information sur le quota consommé par l'action.

La requête d'exécution d'une action contient le quota disponible pour l'exécution de celle-ci et la réponse correspondante fournit le quota consommé et

le quota restant, celui-ci correspondant à la différence entre le quota disponible et le quota consommé.

Le système de gestion de services et le serveur d'orchestration décrits permettent avantageusement, par une centralisation des flux, et en particulier des flux de facturation, de simplifier et de fiabiliser la facturation de services mettant en œuvre des actions fournies par plusieurs serveurs prestataires.

Ce système et ce serveur permettent avantageusement de faire migrer les systèmes existants vers ce nouveau système car les interfaces avec les serveurs de gestion de comptes ne sont pas modifiées. Il en est de même pour les serveurs prestataires et les fournisseurs de services, l'adaptation étant gérée par le serveur d'orchestration.

Par la centralisation de la gestion de l'exécution et de la facturation des services, le système et le serveur d'orchestration permettent avantageusement une gestion précise de la facturation. Ainsi, les autorisations et les confirmations de facturation sont adaptables précisément aux besoins de chaque service.

De même, la gestion des quotas permet avantageusement une grande souplesse dans la gestion des ressources allouées.