FR3144884A1 - METHOD AND SERVER FOR MANAGING ACCESS RIGHTS TO SHARED RESOURCES - Google Patents

Abstract

The invention discloses a method for managing at least one resource of a set of resources provided by a plurality of clients comprising, said method being implemented by a server and comprising: definition, by a server, in a structure defining access rights for a set of resources provided by a plurality of clients, and upon receipt of a first request from a first client of said plurality of clients, access rights of at least one resource provided by said first customer; receiving a request from a first client of said plurality of clients, requesting access to at least one resource provided by a second client, providing, by said server, access to said at least one resource to said first client if access rights allow it. Abstract Figure: Figure 2

Description

METHOD AND SERVER FOR MANAGING ACCESS RIGHTS TO SHARED RESOURCES

This disclosure relates to the field of sharing computing resources. More specifically, it relates to the field of managing access rights to shared computing resources.

Sharing, or pooling, of IT resources consists of sharing, between several actors, resources held by the different actors.

Resource sharing can occur between multiple clients of at least one server, which send requests to the server to share their resources and access those of other clients.

Resource sharing brings benefits to customers in many areas.

For example, customers can share files, but also training bases of machine learning engines in order to pool their learning bases. The pooling of resources can also, for example, concern federated elements of digital twins.

However, sharing a resource by a client carries the risk of unwanted access to the resource by third parties, or misuse of the resource by another client.

This risk is particularly high when there is a significant difference in importance between two customers, and can hinder the adoption of resource pooling solutions by customers.

There is therefore a need for resource sharing solutions between multiple clients, allowing each client to control the access rights to the resources it provides.

Summary

This disclosure improves the situation.

A method for managing at least one resource of a set of resources provided by a plurality of clients is proposed, said method being implemented by at least one server and comprising: defining, by the at least one server, in a structure defining access rights for a set of resources provided by a plurality of clients, and upon receipt of a first request from a first client of said plurality of clients, access rights for at least one resource provided by said first client; receiving, by the at least one server, a second request from a second client of said plurality of clients, requesting access to the at least one resource provided by the first client; providing, by the at least one server, access to the at least one resource to said second client if the access rights allow it.

A "structure" is an organization of data that allows computer data to be formalized. A structure can, for example, be a table or a database.

• une ressource matérielle, tel qu'une ressource de calcul, une ressource mémoire, une ressource réseau, etc.
• du contenu pouvant être utilisé par des applications, tels que du contenu multimédia, des lignes de codes, des mots de passe, etc. Le contenu peut être par exemple défini dans des fichiers ou bases de données, des modèles entraînés grâce à du contenu fourni par le premier client, etc.
• une API permettant l'exécution d'une fonction spécifique.

A "resource" is an element that can be used by an application to run it. A resource can be:

• a hardware resource, such as a computing resource, a memory resource, a network resource, etc.
• content that can be used by applications, such as multimedia content, lines of code, passwords, etc. Content can be for example defined in files or databases, models trained using content provided by the first client, etc.
• an API that allows a specific function to be executed.

A "client" is an entity that sends requests to the server to provide content, set access rights, and/or access content. A client can be defined as a user terminal, a user of a terminal, an enterprise, or an application running in a virtual machine or container, for example.

This allows for resource sharing between multiple clients, while allowing each client to control access rights to the resources it provides. In other words, the proposed method allows for orchestrating resource pooling between multiple clients with enhanced security.

In another aspect, a server is proposed for managing at least one resource of a set of resources provided by a plurality of clients comprising: access to a set of resources provided by a plurality of clients; access to a structure defining access rights for the set of resources; at least one computing unit configured to: define in said structure, upon receipt of a first request from a first client of said plurality of clients, the access rights of at least one resource provided by said first client; receive a request from a second client of said plurality of clients, requesting access to at least one resource provided by the first client; provide access to said at least one resource to said second client if the access rights allow it.

The term “computing unit” means an electronic component capable of performing electronic or computer calculations to perform a specific function. A computing unit may designate any type of processor or electronic component capable of performing digital calculations. For example, a computing unit may be an integrated circuit, an ASIC (from the English acronym “Application-Specific Integrated Circuit”, literally in French “integrated circuit specific to an application”, a microcontroller, a microprocessor, a DSP (from the English acronym “Digital Signal Processor”, literally in French “digital signal processor”), a processor, a GPU (from the English acronym “Graphics Processing Unit”, literally in French “graphics computing unit”). A computing unit according to the invention is not limited to a particular type of computing architecture. For example, a processor may implement a Harvard or Von Neumann type architecture.

According to another aspect, there is provided a computer program comprising instructions for implementing all or part of a method as defined herein when this program is executed by a processor.

According to another aspect, there is provided a non-transitory, computer-readable recording medium on which such a program is recorded.

According to another aspect, there is provided a computing device comprising at least one computing unit configured to execute all or part of a method as defined herein.

The features set out in the following paragraphs may, optionally, be implemented, independently of each other or in combination with each other:

Advantageously, the method is implemented by at least one computing unit of a hypervisor of said server capable of reading and writing said structure.

This helps to strengthen the security of access rights management.

Advantageously, the method comprises an electronic notarization of each request relating to a resource of said set by said at least one computing unit of the hypervisor.

"Electronic Notarization" means an electronic certification and archiving of the date, origin and destination of a request.

This allows the retention and certification of a history of access rights and requests for access to resources.

Advantageously, the method comprises a synchronization, by said at least one computing unit of the hypervisor, of said access rights with at least one remote hypervisor executed by at least one remote computing unit on at least one remote server.

This allows access rights to be synchronized between multiple servers, and therefore to keep access rights up to date between different servers for as many resources as possible between servers receiving different requests on a set of shared resources.

Advantageously, the method comprises a server communication with at least one central server configured to maintain a reference access rights structure.

A "central server" means a server that centralizes processing on behalf of multiple servers.

This makes it possible to centralize, on behalf of several servers, the management of the synchronization of client rights, and therefore to facilitate the synchronization of the management of access rights between servers.

Advantageously, said method is implementation by at least one computing unit of a virtualization at the operating system level executed by a hypervisor, said virtualization at the operating system level being capable of reading and writing said structure.

"OS-level virtualization" means a user instance that provides a virtual operating system. An OS-level virtualization can be called, for example, in some types of operating systems, a container, virtual private server, partition, virtual environment, or virtual kernel. A container contains the elements necessary for virtualization.

This allows great flexibility in the deployment of resource access rights, as access rights management can be implemented within virtual operating systems executable by already deployed hypervisors.

Advantageously, said at least one resource is a machine learning model trained with data provided by said first client.

This allows the training of machine learning models to be shared while ensuring that each client providing training data has control over which other clients have access to the training product.

Advantageously, the second request is a request to use the machine learning model on data provided by the second client; the method comprises: sending, by said server, a result of said use of the machine learning model to the second client; receiving, by said server, feedback from said second client on said result; triggering, by said server: a phase of improving said model from said feedback, and an association with said improved model of access rights granted by said second client.

"Trigger" means to cause one or more actions to be performed. Triggering actions by the at least one computing unit may include, for example, the computing unit executing the actions, or sending instructions to a remote computing unit to perform the actions. For example, the remote computing unit may be a computing unit of a central server, and the at least one computing unit may provide feedback to the central server to perform the model improvement on the central server.

An "improvement phase" means a model training phase that includes an improvement of the prior training of the model. For example, the improvement phase may be a reinforcement learning phase and said outcome may be a reward granted by the second client.

"Feedback" is an indication provided by the second client of the quality of the result provided. For example, in reinforcement learning, the feedback can be a reward

This allows a model to be trained with data provided by multiple clients, while ensuring at all times that use of the model is conditional on the provision of access rights by all clients who contributed to the training.

Advantageously, the method includes: the reception, by said server, of said machine learning model from the central server; the provision, by said server, of said feedback to the central server in order to trigger said improvement phase

This allows the model training to be centralized with the central server.

Advantageously, the set of resources comprises a plurality of federated models of a digital twin of a physical world element; the method comprises: upon receipt of the second request, the execution, by the server, of a federation of simulations of said physical world element for all the federated models of said plurality for which the second client has access rights; upon receipt of a return from the second client, the triggering, by the server, of: an update of said federated models; and an association with said updated federated models of access rights granted by said second client.

Federated models are defined as a set of models that jointly participate in the modeling of an element of the physical world. For example, federated models may correspond to models of different parts of the element.

A "digital twin" is a digital replica of something in the physical world.

This allows a federation of physical world models to be shared across multiple clients, with feedback used to improve the models, while ensuring that each client providing feedback to improve the models has control over which other clients have access to federated models benefiting from the feedback.

Advantageously, the method comprises: receiving, by the server, said federated models from a central server; providing, by the server, said feedback to the central server in order to trigger said update of the federated models.

This allows the federation of models to be centralized with the central server.

Advantageously, said structure is a table indicating, for each pair of clients, the access rights granted by the first client of the pair to the second client of the pair, and from the second client of the pair to the first client of the pair, the authorizations belonging to a group comprising: a creation right; a reading right; an update right; a deletion right.

This allows the access rights granted by clients to each other to be defined in a deterministic manner.

Other features, details and advantages will become apparent upon reading the detailed description below, and upon analysis of the attached drawings, in which:

Fig. 1

shows an example server according to one set of embodiments.

Fig. 2

shows an example of modules implemented by a server according to a set of embodiments of the invention, in which the management of access to resources is carried out by a hypervisor.

Fig. 3

shows an example of a network of servers in which resource access management is implemented by a hypervisor according to one embodiment.

Fig. 4

shows an example of modules implemented by a server according to a set of embodiments of the invention, in which the management of access to resources is carried out by a container.

Fig. 5

shows an example method of managing at least one resource of a set of resources according to a set of embodiments of the invention.

Fig. 6

shows an example of sharing resources relating to a machine learning model according to a set of embodiments of the invention.

Fig. 7

shows an example of sharing resources relating to federated models of a digital twin according to a set of embodiments of the invention.

Fig. 8

shows an example structure defining access rights according to a set of embodiments.

Reference is now made to the .

There represents a server according to a set of embodiments of the invention.

Server Serv1 is a management server for at least one resource from a set of resources provided by a plurality of clients.

The Serv1 server is thus able to manage the set of resources, that is to say create, modify, or even give access to the resources of the set. The Serv1 server therefore allows a plurality of clients to exchange resources.

There represents two clients Clt1 and Clt2. Clients can be of different types. For example, a client can be a user terminal, a user of a terminal, a company or an application. The server Serv1 can include one or more communication links to communicate with the clients. A communication link with a client can include any means of communication. Communication with the clients can, for example, be carried out via an Internet network or a mobile network.

The communication link with clients thus allows the server to receive requests from clients. Requests may consist, for example, of requests to add resources, to modify access rights to resources, or to request access to a resource.

The Serv1 server can also include client authentication means, in order to secure data exchanges between clients.

There represents two distinct clients Clt1 and Clt2. This number is of course provided as a non-limiting example only, and the invention is applicable to any number of clients greater than or equal to 2.

The server Serv1 also includes access to a set of resources provided by the plurality of clients.

As noted above, resources can include any type of computing resource, such as hardware, software, or content that can be exchanged between clients.

The resources can for example be stored in at least one Mem memory to which the server Serv1 has access. The at least one Mem memory can belong to different types of data storage capable of storing the resources. It can for example be a random access memory, a read-only memory, a volatile memory, a flash memory or even a virtual memory.

The at least one memory comprises at least one internal memory and/or at least one external memory to the server Serv1. An external memory may be, for example, a memory contained in a device connected to the server Serv1 by a wired connection, or a memory located in a server located on the same network as the server Serv1, for example a central server. Thus, access to the at least one memory may be via an internal connection to the server Serv1, or a secure external connection to the device comprising the memory.

There represents two resources Res1, Res2. This number is of course provided as a non-limiting example only, and the invention is applicable to a set of resources comprising at least one resource.

Resources can also be duplicated across multiple memories, to ensure access to them in the event of a failure of one of the memories. They can be stored directly in the memories, but also encrypted, stored in databases, etc.

The server Serv1 also includes access to a structure Struct1 defining access rights for the set of resources. The structure Struct1 can for example be stored on the at least one memory Mem. In the example of the , the resources Res1 and Res2 are located in the same memory as the structure Struct1. This example is provided as a non-limiting example only, and the resources and structures may be stored on different memories. The structure Struct1 may further be duplicated across multiple memories to ensure its access in the event of a failure of one of the memories, and/or be stored in parts across multiple memories.

The server Serv1 comprises at least one computing unit Calc. The computing unit is configured to receive requests from clients, and to provide or not access to resources, for example by implementing the method P5 represented in , or by participating in the implementation of the scenarios represented in and 7. Management of access to resources by clients Clt1, Clt2 can be implemented at the hypervisor level (represented in ) or at the container or virtual machine level (represented in ).

Reference is now made to the .

There shows an example of modules implemented by a server according to a set of embodiments of the invention, in which the management of access to resources is implemented by a hypervisor.

The Serv2 server represented in can for example be the server Serv1 represented in .

The Serv2 server implements several modules.

In the example of the , the server includes an OS2 operating system capable of implementing a Hypvsr2 hypervisor capable of reading and writing a Struct2 structure defining the access rights to the set of resources.

In this example, resource access management is therefore carried out at the level of the Hypvsr2 hypervisor which is configured to read and write the Struct2 structure and determine access rights.

The Hypvsr2 hypervisor is also able to control and manage one or more Cont12, Cont22, … Contn2 containers or one or more virtual machines. Note that a virtual machine is a virtualization of hardware and software resources including an operating system, allowing a client request to be executed by running on the hypervisor. A container is a virtualization of hardware and software resources without instantiating the operating system. Indeed, a container shares the same operating system with other containers.

This architecture allows to reinforce the security of access rights. Indeed, if the hypervisor can control and manage the Cont12, Cont22, … Contn2 containers running third-party code, the management of access rights is carried out at the level of the hypervisor itself, and can therefore be totally controlled.

In this example, the hypervisor can not only manage access to resources, but also perform electronic notarization of each request for a resource.

Notarization therefore makes it possible to archive the date, origin and destination of each request relating to a resource, for example requests to create a resource, modify access rights, edit a resource, access a resource, etc.

This makes it possible, in particular, to identify a posteriori any request for access to a resource. This makes it possible to keep track of any attempt to access or modify, whether authorized or not, the resources, but also to quantify access to the resources.

Indeed, the sharing of resources by clients can be carried out within the framework of commercial contracts for the exchange of resources between clients. The notarization of requests thus makes it possible, where appropriate, to quantify access to resources by each client, which may be an object of the contract.

Access to a resource can also be provided by a first client to a second for a defined number of accesses. This defined number can be a total number of accesses, or a number of accesses per unit of time (per day, per week, per month, etc.). The notarization of requests then makes it possible to check whether the limit number of accesses to a resource is exceeded or not, and to provide or not access to the resource accordingly.

Reference is now made to the .

There shows an example of a network of servers in which resource access management is implemented by a hypervisor according to one embodiment.

In the example of the , a Res3 network of servers consists of three servers Serv13, Serv23 and Serv33. Each of the three servers Serv13, Serv23 and Serv33 is similar to the server Serv2, having access to shared resources and including a hypervisor capable of managing access rights to resources and running containers.

For example, servers Serv13, Serv23 and Serv33 are respectively capable of running the Hypvsr13, Hpyvsr23 and Hypvsr33 hypervisors.

By analogy with the Serv2 server, the Serv13 server includes an OS3 operating system, the Hypvsr13 hypervisor capable of reading and writing the Struct13 structure defining access rights for a set of resources, and of executing the Cont113, Cont213 and Contn13 containers.

Similarly, the Hypvsr23 and Hypvsr33 hypervisors are respectively able to read and write the Struct23 and Struct33 structures defining access rights for the same set of resources.

Servers Serv13, Serv23 and Serv33 are remote servers from each other, that is, they are located in different physical locations. Servers Serv13, Serv23 and Serv33 are in communication through a network, for example an Intnt internet network.

Servers Serv13, Serv23, and Serv33 are configured to provide access to the same set of resources, but may be communicating with different clients.

Resources can thus be shared across memory areas accessible to the three servers and/or duplicated across memory areas accessible to each of the servers.

However, the Hypvsr13, Hypvsr23 and Hypvsr33 hypervisors are configured to synchronize the access rights to the resource set, as defined in the respective Struct13, Struct23 and Struct33 structures.

Thus, access rights can be shared and updated between clients of multiple servers, which allows increasing the number of clients and resources that can participate in resource sharing, since clients of multiple servers, and the resources provided by these clients, can participate in the sharing.

In addition, this allows the implementation of “edge computing” techniques, in which servers are placed as close as possible to clients while having access to resources shared more widely, and ensuring compliance with the access rules defined by each client between the servers.

There represents an example in which a server network comprises three servers. This example is however provided as a non-limiting example only, and the invention is applicable to any number of networked servers greater than or equal to two.

Synchronization of access rights between servers can be done in different ways.

For example, distributed synchronization algorithms can be implemented. For example, servers can maintain synchronization of access rights via a blockchain.

It is also possible to centralize synchronization management. For example, all servers can communicate with a central server configured to maintain a reference access rights structure. The central server can be one of the servers, or another server dedicated to maintaining the reference structure.

Reference is now made to the .

There shows an example of modules implemented by a server according to a set of embodiments of the invention, in which the management of access to resources is carried out by a container.

The Serv4 server represented in can for example be the server Serv1 represented in .

The Serv4 server implements several modules.

In the example of the , the server includes an OS4 operating system capable of implementing a Hypvsr4 hypervisor.

The Hypvsr4 hypervisor is able to run one or more Cont14, Cont24, … Contn4 containers.

In this example, one of the containers, the Contn4 container, is able to read and write a Struct4 structure defining the access rights to the set of resources. In this example, the management of access to the resources is therefore carried out at the level of the Contn4 container which is configured to read and write the Struct4 structure and determine the access rights.

This example is provided as a non-limiting example, and the same principle can be applied to other types of operating system-level virtualizations, such as virtual machines.

Resource rights management can therefore be done within containers, or other operating system-level virtualizations, running on already deployed hypervisors, allowing for great flexibility in deploying resource rights. For example, rights management can be updated by modifying a container, without having to modify the hypervisor.

It is now referred to the .

There shows an example of method P5 for managing at least one resource of a set of resources according to a set of embodiments of the invention.

Method P5 can for example be implemented by one of the servers Serv1, Serv2, Serv13, Serv4 to manage at least one resource such as resources Res1 and Res2.

The method P5 comprises a first step S51 of definition by the at least one server, in a structure defining access rights for a set of resources provided by a plurality of clients, and upon receipt of a first request from a first client of said plurality of clients, of access rights for at least one resource provided by said first client.

• à la réception d’une requête d’ajout de la ressource, accompagnée de droits d’accès à la ressource ;
• à la réception d’une requête de modification des droits d’accès d’une ressource déjà existante fournie par le premier client.

In practice, step S51 can for example be carried out:

• upon receipt of a request to add the resource, accompanied by access rights to the resource;
• upon receipt of a request to modify the access rights of an already existing resource provided by the first client.

Access rights can be of different types.

For example, rights can be CRUD rights (Create, Read, Update, Delete). Rights can be provided, for example, to specific clients or groups of clients. Rights can also be subject to spatial, temporal, number of uses, etc. conditions. Access rights can be provided to other clients, but also to the servers themselves.

The method P3 then comprises a second step S52 of receiving, by the at least one server, a request from a second client of said plurality of clients, requesting access to at least one resource provided by the first client.

A resource access request can be of different types, depending on the type of resource involved.

For example, the resource access request could be a request to read or modify a file, a request to access training databases of a machine learning model, a request to use a federated model of a digital twin, etc.

The method P3 then comprises, upon receipt of the access request, a third step S53 of verification by the at least one server of whether the access rights allow access to the at least one resource by the second client.

If the access rights permit, the at least one server provides access to the at least one resource to said second client in the fourth step S54.

Otherwise, the at least one server rejects the access request in step S55.

Thus, the access rights defined by the first client are taken into account for the provision or not of access to the resources.

According to different embodiments of the invention, the steps of method P5 can be implemented by a single server, or a plurality of servers, for example a network of servers such as represented in .

If the method is implemented by a plurality of servers, the different steps can be performed by several distinct servers. For example, step S51 can be performed by a first server which receives a resource from a first client, and steps S52 to S54 by a second server which receives a request for access to the resource from a second client.

Reference is now made to the .

There shows an example of sharing resources relating to a machine learning model according to a set of embodiments of the invention.

The example of the represents access to a resource, which is a Mod16 machine learning model trained with data provided by the first client Clt1.

The trained model is in this example stored on the Serv6 server, in relation to a ServCtr6 server, which centralizes machine learning models shared between several servers.

In this example, the Mod16 model is a model for detecting people in an image, and counting the number of people in an image. This example is provided as a non-limiting example, and the example in the can be extended to other types of machine learning models.

There describes a P6 scenario of using the Mod16 model by a second client. In this scenario, the Mod16 model access rights defined by the first client Clt1 allow the second client Clt2 to use and update the Mod16 model.

In scenario P6, the second client Clt2 sends the server Serv6 a request Rq6 to use the Mod16 model based on an image it provides.

As the access rights set by the first client allow, the server Serv6 uses UtMod16 the Mod16 model on the image provided by the second client to count the number of people in the image, then returns the result Res6 to the second client Clt2.

The second client Clt2 then provides a return Ret6 to the server on said result. The return can for example consist of a validation of the number of people, or on the contrary an indication that the number of people counted is inaccurate, of an exact number of people, or of a precise location of the people actually present in the photo.

As the rights provided by the first client Clt1 allow the update of the Mod26 model by the second client, the return Ret6 triggers a phase of improvement of the model by the server from the return, to obtain an improved Mod26 model.

The improvement phase can in practice be carried out by the Serv6 server itself, or a remote server, such as for example the central ServCtr6 server.

The central server ServCtr6 can thus centralize the training of models. For example, the Serv6 server can receive the Mod16 model from the central server ServCtr6, send the feedback Ret6 to the central server ServCtr6, and receive from the central server the improved model Mod26.

The central server can also centralize the models, without doing the training itself. For example, the central server ServCtr6 can store the model Mod16, send it in a TransMod16 step to the server Serv6 before use on the server Serv6, the server Serv6 can do the update and then send the updated model Mod26 back to the central server ServCtr6 in a TransMod26 step.

As the improved Mod26 model is trained in part with data provided by the second client, the Ret6 feedback and the model improvement also result in an association with the improved Mod26 model of access rights granted by said second client.

In other words, the enhanced Mod26 model can only be used by a third client if the access rights provided by both the first client and the second client allow it. If only the access rights provided by the first client allow access to the model by the third client, then the third client could use the Mod16 model, but not the enhanced Mod26 model for example.

This principle can more generally be applied to any model trained from data provided by multiple clients.

Thus, in one embodiment, if a resource is a model trained with data provided by a plurality of initial clients, access to the model may only be provided to an end client, whether or not part of the plurality of initial clients, if the access rights provided by each of the initial clients of said plurality allow it.

This allows clients to collaboratively participate in the creation of common learning models, while allowing each client to ensure the conditions of access to the models trained with the data they provide.

Reference is now made to the .

There shows an example of sharing resources relating to federated models of a digital twin according to a set of embodiments of the invention.

The example of the represents access to a set of resources, which is a plurality of federated ModFed17 models of a digital twin of an element of the physical world Elt7.

• L’élément du monde physique Elt7 est une usine ;
• Les modèles fédérés ModFed17 sont stockés sur un serveur central ServCtr7, et comprennent un modèle Mod7 d’un sous-élément de l’usine fourni par le client Clt7.

In the example of the :

• The physical world element Elt7 is a factory;
• ModFed17 federated models are stored on a central ServCtr7 server, and include a Mod7 model of a plant sub-element provided by the Clt7 client.

In this example, a plurality of clients participate in the model federation by providing models of sub-elements of element Elt7. The plurality of clients have provided each other with the rights to run and update the federated models, such that each client can perform a simulation of the model federation, and update the models if the simulation does not match observations from the physical world. The clients here may correspond to different entities participating in the management of the plant. For example, client Clt7 may be an operator of the plant, and the other clients providing federated models may be suppliers of various equipment in the plant, and/or operators of identical plants.

There more specifically represents a P7 scenario, in which an incident has occurred in the plant. The plant is equipped with sensors to monitor the operation of the plant, and sends Sens17 measurements taken by the sensors during the incident, supplemented if necessary by measurements taken before the incident to the Clt7 client.

The Clt7 client sends the Serv7 server a ReqSim7 request to simulate the model federation based on the sensor measurements. Since the Clt7 client has been granted execution rights for the entire model federation, the Serv7 server performs a Sim7 simulation of the federated models including an evaluation of scenarios and the determination of a set of commands to end the incident. The Serv7 server returns to the Cl7 client a return of the simulation accompanied by the set of commands.

The Clt7 client then sends the Clt7 command set to the Elt7 factory, which will proceed to execute Exec7 the commands.

Once the factory executes the commands, the Elt7 factory sends a new set of sensor observations Sens27 to the Clt7 client, which in turn sends a simulation return RetSim27 to the Serv7 server including the new set of Sens27 observations.

The new Sens27 observation set may be different from the predictions of the federated models. In order to update the models, the Serv7 server triggers Upd7 an update of the federated models based on the new observation set.

In the example of the , the new observation set is transmitted to the central server ServCtr7, which will carry out the update.

In other embodiments of the invention, it is the Serv7 server which is in charge of the update.

In the example of the , the update of federated models is done from data provided by the Clt7 client. The update of federated models is therefore accompanied by an association with the updated federated models ModFed27 of access rights granted by the Clt7 client.

This example demonstrates the ability of the invention to enable the use of federated models of digital twins of elements of the physical world, while allowing each client to manage access rights to the models trained with the data it provides. This example is however provided as an example only of a scenario of application of the invention to federated models. The invention is more generally applicable to any scenario based on federated models, in which each client can define access rights to the models it provides or contributes to training, and in which a client can only access a federation of models if all the clients who contributed to providing or training the models grant it permission to do so.

Reference is now made to the .

There shows an example structure defining access rights according to a set of embodiments.

The Tab8 structure is presented as a two-dimensional table defining the access rights provided by each client. In this example, the clients are applications, represented by the letters "App 1", "App 2", "App n". For readability reasons, only three clients are represented in this example, but a structure of this type is of course applicable to a higher number of clients. The letters "PCE" represent the server itself, which can also receive or provide access rights.

• chaque ligne représente l’entité qui fournit des droits d’accès ;
• chaque colonne représente l’entité qui reçoit les droits d’accès.

In table Tab8:

• each line represents the entity providing access rights;
• Each column represents the entity that receives the access rights.

• « C » (de l’anglais « Create ») : un droit de création ;
• « R » (de l’anglais « Read ») : un droit de lecture ;
• « U » (de l’anglais « Update ») : un droit de mise à jour ;
• « D » (de l’anglais « Delete ») : un droit de suppression.

In this example, the rights granted can be of 4 types, depending on the “CRUD” name:

• “C” (from the English “Create”): a right of creation;
• “R” (from the English “Read”): a right to read;
• “U” (from the English “Update”): a right to update;
• “D” (from the English “Delete”): a right of deletion.

Each box includes the letters corresponding to the rights among the 4 possible rights granted by the entity characterizing the line of the box to the entity characterizing the column of the box.

• la cellule Cel18, située sur la 3^eligne « App 2 » et sur la première colonne « PCE », représente les droits accordés par l’ « App 2 » au serveur. Ici, les 4 droits C, R, U et D sont fournis ;
• la cellule Cel28, située sur la 1^eligne « PCE » et la 3^ecolonne « App 2 », représente les droits accordés par le serveur à l’ « App 2 ». Ici, seul le droit de lecture R est fourni.

For example :

• cell Cel18, located on the ^3rd row “App 2” and on the first column “PCE”, represents the rights granted by “App 2” to the server. Here, the 4 rights C, R, U and D are provided;
• Cell Cel28, located on the ^1st row “PCE” and the ^3rd column “App 2”, represents the rights granted by the server to “App 2”. Here, only the read right R is provided.

• Toutes les colonnes dans la diagonale de la table comprennent les 4 droits C,R,U,D. En effet, les cellules dans la diagonale définissent les droits donnés par une entité à elle-même ;
• Les droits ne sont pas nécessairement accordés de manière symétrique. Par exemple, les cellules Cel18 et Cel28 montrent que « App2 » accorde plus de droits au serveur que le serveur n’en accorde à « App2 ».

We can note here that:

• All columns in the diagonal of the table include the 4 rights C,R,U,D. In fact, the cells in the diagonal define the rights given by an entity to itself;
• Rights are not necessarily granted symmetrically. For example, cells Cel18 and Cel28 show that “App2” grants more rights to the server than the server grants to “App2”.

Table Tab8 provides an illustrative and non-limiting example of a structure defining access rights according to the invention. According to other embodiments of the invention, other types of structures can be implemented. Similarly, the access rights can use a different formalism and/or include a greater number of types of access rights. The access rights can also be associated with additional characteristics such as geographic areas, time periods, a limit number of accesses, etc.

This disclosure is not limited to the examples of method, server, computer device and computer program described above, only by way of example, but it encompasses all the variants that may be envisaged by those skilled in the art within the framework of the protection sought.

Claims (15)

Method (P5) for managing at least one resource from a set of resources (Res1, Res2) provided by a plurality of clients (Clt1, Clt2), said method being implemented by at least one server (Serv1; Serv2; Serv13; Serv4) and comprising:

• defining (S51), by the at least one server (Serv1; Serv2; Serv13; Serv4), in a structure (Struct1) defining access rights for a set of resources (Res1, Res2) provided by a plurality of clients (Clt1, Clt2), and upon receipt of a first request from a first client of said plurality of clients, access rights of at least one resource provided by said first client;
• receiving (S52), by the at least one server, a second request from a second client of said plurality of clients, requesting access to the at least one resource provided by the first client;
• the provision (S54), by the at least one server, of access to the at least one resource to said second client if the access rights allow it (S53).

Method according to claim 1, said method being implemented by at least one calculation unit of a hypervisor (Hypvsr2; Hypvsr13) of said server capable of reading and writing said structure. Method according to claim 2, comprising an electronic notarization of each request relating to a resource of said set by said at least one computing unit of the hypervisor. Method according to one of claims 2 and 3, comprising a synchronization, by said at least one computing unit of the hypervisor, of said access rights with at least one remote hypervisor (Hypvsr23; Hypvser33) executed by at least one remote computing unit on at least one remote server (Serv23; Serv23). Method according to one of the preceding claims, comprising communication of the server with at least one central server configured to maintain a reference access rights structure. Method (Serv4) according to claim 1, said method being implemented by at least one computing unit of a virtualization at the operating system level executed by a hypervisor (Hypvsr4), said virtualization at the operating system level being capable of reading and writing said structure. A method according to any preceding claim, wherein said at least one resource is a machine learning model trained with data provided by said first client. Method according to the preceding claim, in which:

• the second request (Rq6) is a request to use the machine learning model (Mod16) on data provided by the second client;
• The method includes:
  • sending, by said server, a result (Res6) of said use (UtMod6) of the machine learning model to the second client;
  • the reception, by said server, of a return (Ret6) from said second client on said result;
  • the triggering, by said server:
    • of a phase of improvement of said model from said feedback,
    • and an association with said improved model (Mod26) of access rights granted by said second client.

Method according to the preceding claim, comprising:

• the reception, by said server, of said machine learning model from central server (ServCtr6);
• the provision, by said server, of said feedback to the central server in order to trigger said improvement phase.

A method according to any one of claims 1 to 6, wherein:

• the resource set comprises a plurality of federated models (ModFed17) of a digital twin of a physical world element (Elt7);
• The method includes:
  • upon receipt of the second request (ReqSim7), the execution, by the server, of a federation of simulations (Sim7) of said element of the physical world for all the federated models of said plurality for which the second client has access rights;
  • upon receipt of a return (RetSim27) from the second client, the server triggers:
    • of an update of said federated models;
    • and an association with said updated federated models (ModFed27) of access rights granted by said second client.

Method according to the preceding claim, comprising:

• the reception, by the server, of said federated models from a central server (ServCtr7);
• the provision, by the server, of said feedback to the central server in order to trigger said update of the federated models.

Method according to any one of the preceding claims, in which said structure is a table (Tab8) indicating, for each pair of clients, the access rights granted by the first client of the pair to the second client of the pair, and from the second client of the pair to the first client of the pair, the authorizations belonging to a group comprising:

• a right of creation;
• a right to read;
• a right to update;
• a right of deletion.

Computer program comprising instructions for implementing the method according to claim 13 when this program is executed by a processor. Computing device comprising at least one computing unit configured to execute a method according to one of claims 1 to 12. Server (Serv1; Serv2; Serv13; Serv4) for managing at least one resource from a set of resources (Res1, Res2) provided by a plurality of clients (Clt1, Clt2) comprising:

• access to a set of resources (Res1, Res2) provided by a plurality of clients (Clt1, Clt2);
• access to a structure (Struct1) defining access rights for the set of resources;
• at least one calculation unit (Calc) configured for:
  • defining in said structure, upon receipt of a first request from a first client of said plurality of clients, the access rights of at least one resource provided by said first client;
  • receiving a request from a second client of said plurality of clients, requesting access to at least one resource provided by the first client;
  • provide access to said at least one resource to said second client if access rights permit.

.