EP4649395A1 - Methode et serveur de gestion de droits d'acces a des ressources partagees - Google Patents

Methode et serveur de gestion de droits d'acces a des ressources partagees

Info

Publication number
EP4649395A1
EP4649395A1 EP24700230.6A EP24700230A EP4649395A1 EP 4649395 A1 EP4649395 A1 EP 4649395A1 EP 24700230 A EP24700230 A EP 24700230A EP 4649395 A1 EP4649395 A1 EP 4649395A1
Authority
EP
European Patent Office
Prior art keywords
server
client
access rights
clients
access
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24700230.6A
Other languages
German (de)
English (en)
Inventor
Thierry GAILLET
Sylvain LEROUX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4649395A1 publication Critical patent/EP4649395A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning

Definitions

  • the present disclosure relates to the field of sharing of computer resources. More particularly, it relates to the management of access rights to shared IT resources.
  • Sharing, or pooling, of IT resources consists of sharing, between several actors, resources held by the different actors.
  • Resource sharing can take place between several clients of at least one server, who send requests to the server to share their resources and access those of other clients.
  • clients can share files, but also training bases for machine learning engines in order to pool their learning bases.
  • the pooling of resources can still, for example, involve federated elements of digital twins.
  • sharing a resource by a client carries the risk of unwanted access to the resource by third parties, or abusive use of the resource by another client.
  • a method for managing at least one resource from a set of resources provided by a plurality of clients comprising: the definition, by the at least one server 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 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; the provision, by the at least one server, of access to the at least one resource to said second client if the access rights allow it.
  • “Structure” means an organization of data making it possible to formalize computer data.
  • a structure can for example be a table or a database.
  • Resource means an element usable by an application for its execution.
  • a resource can be: a hardware resource, such as a calculation resource, a memory resource, a network resource, etc. content that can be used by applications, such as multimedia content, lines of code, passwords, etc.
  • the content can for example be defined in files or databases, models trained using content provided by the first client, etc. an API allowing the execution of a specific function.
  • client is meant an entity sending requests to the server in order to provide content, define access rights and/or access content.
  • a client can for example be defined by a user terminal, a terminal user, a company or an application executed for example in a virtual machine or a container.
  • a server for managing at least one resource from 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 calculation 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; 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 the access rights allow it.
  • calculation unit means an electronic component capable of carrying out electronic or computer calculations to perform a specific function.
  • a calculation unit can designate any type of processor or electronic component capable of carrying out digital calculations.
  • a calculation unit can 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 calculation unit according to the invention is not limited to a particular type of computing architecture.
  • a processor can implement a Harvard or Von Neumann type architecture.
  • a computer program comprising instructions for the implementation of all or part of a method as defined herein when this program is executed by a processor.
  • a non-transitory recording medium is proposed, readable by a computer, on which such a program is recorded.
  • a computing device comprising at least one calculation unit configured to execute all or part of a method as defined herein.
  • the method is implemented by at least one calculation unit of a hypervisor of said server capable of reading and writing said structure.
  • the method includes electronic notarization of each request relating to a resource of said set by said at least one calculation unit of the hypervisor.
  • Electrode notarization means electronic certification and archiving of the date, origin and destination of a request.
  • the method comprises synchronization, by said at least one calculation unit of the hypervisor, of said access rights with at least one remote hypervisor executed by at least one remote calculation unit on at least one remote server .
  • the method comprises communication of the server with at least one central server configured to maintain a reference access rights structure.
  • central server is meant a server centralizing processing on behalf of several servers.
  • said method is implemented by at least one calculation 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.
  • Virtualization at the operating system level is meant a user instance providing a virtual operating system.
  • Virtualization at the operating system level can for example be named in some types of operating systems container, virtual private server, partition, virtual environment or virtual kernel.
  • a container contains the elements necessary for virtualization.
  • said at least one resource is a machine learning model trained with data provided by said first client.
  • the second request is a request for use of 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; reception, by said server, of feedback from said second client on said result; the triggering, by said server: of a phase of improvement of said model from said feedback, and of an association to said improved model of access rights granted by said second client.
  • Trigger means the training of one or more actions.
  • the triggering of actions by the at least one calculation unit may for example consist of the execution of the actions by the calculation unit, or the sending of instructions to a remote calculation unit to perform the actions.
  • 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 model improvement on the central server.
  • improvement phase is meant a training phase of the model comprising an improvement of the prior training of the model.
  • the improvement phase may be a reinforcement learning phase and said result may be a reward granted by the second client.
  • feedback we mean an indication provided by the second client of the quality of the result provided.
  • feedback can be a reward [0040] This makes it possible to train a model with data provided by several clients, while ensuring at all times that the use of the model is subject to the provision of access rights by all clients having contributed to the model. 'training.
  • the method comprises: reception, by said server, of said machine learning model from a central server; the provision, by said server, of said said feedback to the central server in order to trigger said improvement phase
  • 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 element of the physical world for all the federated models of said plurality for which the second client has access rights ; upon receipt of feedback 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” means a set of models jointly participating in the modeling of an element of the physical world. For example, federated templates can match templates from different parts of the element.
  • digital twin we mean a digital replica of an element of the physical world.
  • the method comprises: reception, by the server, of said federated models from a central server; the provision, by the server, of said feedback to the central server in order to trigger said update of the federated models
  • 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 of the second client of the pair to the first client of the pair. pair, authorizations belonging to a group including: a creation right; a reading right; a right to update; a right of deletion.
  • FIG. 1 shows an example of a server according to a 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 management of access to resources is carried out by a hypervisor.
  • FIG. 3 shows an example of a network of servers in which the management of access to resources 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 management of access to resources is carried out by a container.
  • FIG. 5 shows an example of a method for managing at least one resource from 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 of a structure defining access rights according to a set of embodiments.
  • Figure 1 represents a server according to a set of embodiments of the invention.
  • the servicing server is a server for managing at least one resource from a set of resources provided by a plurality of clients.
  • the Servi server is thus able to manage the set of resources, that is to say create, modify, or even provide access to the resources of the set.
  • the Servi server therefore allows a plurality of clients to exchange resources.
  • Figure 1 represents two clients Clt1 and Clt2.
  • Customers can be of different types.
  • a client can for example be a user terminal, a terminal user, a company or an application.
  • the Servi server may include one or more communication links to communicate with clients.
  • a communication link with a client may include any means of communication. Communication with customers can, for example, be carried out via an internet network or a mobile network.
  • the communication link with the clients thus allows the server to receive requests from clients.
  • Requests can for example consist of requests to add resources, modify access rights to resources, or even request access to a resource.
  • the Servi server can also include means of client authentication, in order to secure data exchanges between clients.
  • Figure 1 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 Servi server also includes access to a set of resources provided by the plurality of clients.
  • the resources can include any type of computing resource, for example hardware resources, software resources or content that can be exchanged between clients.
  • the resources can for example be stored in at least one Mem memory to which the Servi server has access.
  • the at least one Mem memory can belong to different types of data storage capable of storing resources. It can for example be a RAM, a ROM, 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 memory external to the Servi server.
  • An external memory can for example be a memory contained in a device connected to the Servi server by a wired connection, or a memory located in a server located on the same network as the Servi server, for example a central server.
  • access to at least one memory can be done via an internal connection to the Servi server, or a secure external connection to the device comprising the memory.
  • Figure 1 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.
  • the resources can also be duplicated on several memories, in order to guarantee their access in the event of failure of one of the memories. They can be stored directly in memories, but also encrypted, stored in databases, etc.
  • the servicing server also includes access to a Structl structure defining access rights for the set of resources.
  • the Structl structure can for example be stored on at least one Mem memory.
  • the resources Res1 and Res2 are located in the same memory as the Structl structure.
  • This example is provided as a non-limiting example only, and resources and structures may be stored on different memories.
  • the Structl structure can also be duplicated on several memories to guarantee its access in the event of failure of one of the memories, and/or be stored in parts on several memories.
  • the Servi server includes at least one Cale calculation unit.
  • the calculation unit is configured to receive requests from clients, and provide or not access to resources, for example by implementing the P5 method represented in Figure 5, or by participating in the implementation of the scenarios represented in Figure 6 and 7.
  • Managing access to resources by Clt1, Clt2 clients can be implemented at the hypervisor level (shown in Figure 2) or at the level of a container or virtual machine (shown in Figure 4).
  • Figure 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 implemented by a hypervisor.
  • the server Serv2 represented in figure 2 can for example be the server Servi represented in figure 1.
  • the Serv2 server implements several modules.
  • 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.
  • management of access to resources is therefore carried out at the level of the Hypvsr2 hypervisor which is configured to read and write the Struct2 structure and determine the access rights.
  • the Hypvsr2 hypervisor is also capable of controlling and managing one or more Cont12, Cont22, ... Contn2 containers or one or more virtual machines.
  • 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 instantiation of the operating system. Indeed, a container shares the same operating system with other containers.
  • This architecture makes it possible to reinforce the security of access rights. Indeed, if the hypervisor can control and manage the Cont12, Cont22, ... Contn2 containers executing third-party code, the management access rights is carried out at the level of the hypervisor itself, and can therefore be fully controlled.
  • the hypervisor can not only manage access to resources, but also perform electronic notarization of each request relating to a resource.
  • notarization makes it possible to archive the date, origin and destination of each request relating to a resource, for example requests for resource creation, modification of access rights, editing of a resource, access to a resource, etc.
  • 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.). Notarization of requests then makes it possible to check whether or not the number of access limits to a resource has been exceeded, and to provide access to the resource or not accordingly.
  • Figure 3 shows an example of a network of servers in which the management of access to resources is implemented by a hypervisor according to one embodiment.
  • a Res3 network of servers includes three servers servicing 3, Serv23 and Serv33.
  • Each of the three servers servicing 3, Serv23 and Serv33 is similar to the Serv2 server, having access to shared resources and including a hypervisor capable of managing access rights to resources and running containers.
  • the servers servicing 3, Serv23 and Serv33 are respectively capable of running the Hypvsr13, Hpyvsr23 and Hypvsr33 hypervisors.
  • the servicing 3 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 containers Contl 13, Cont213 and Contn13.
  • the Hypvsr23 and Hypvsr33 hypervisors are respectively capable of reading and writing the Struct23 and Struct33 structures defining access rights for the same set of resources.
  • the servers servicing 3, Serv23 and Serv33 are servers remote from each other, that is to say they are located in different physical locations.
  • the servers servicing 3, Serv23 and Serv33 are in communication via a network, for example an internal Intnt network.
  • the servers servicing 3, Serv23 and Serv33 are configured to provide access to the same set of resources, but can be in communication with different clients.
  • the resources can thus be shared on memory areas accessible to the three servers and/or duplicated on memory areas accessible to each of the servers.
  • the hypervisors Hypvsr13, Hypvsr23 and Hypvsr33 are configured to synchronize access rights to the set of resources, as defined in the respective structures Struct13, Struct23 and Struct33.
  • access rights can be shared and updated between the clients of several servers, which makes it possible to increase the number of clients and resources that can participate in resource sharing, since the clients of several servers , and the resources provided by these clients, can be involved in the sharing.
  • Figure 3 represents an example in which a server network includes three servers. This example is, however, provided as a non-limiting example only, and the invention is applicable to any number of network servers greater than or equal to two.
  • distributed synchronization algorithms can be implemented.
  • servers can maintain synchronization of access rights via a blockchain.
  • all servers can communicate with a central server configured to maintain a reference permissions structure.
  • the central server can be one of the servers, or another server dedicated to maintaining the reference structure.
  • Figure 4 shows an example of modules implemented by a server according to a set of embodiments of the invention, in which management of access to resources is carried out by a container.
  • the server Serv4 represented in figure 4 can for example be the server servicing represented in figure 1.
  • the Serv4 server implements several modules.
  • the server includes an OS4 operating system capable of implementing a Hypvsr4 hypervisor.
  • the Hypvsr4 hypervisor is able to execute one or more Cont14, Cont24, ... Contn4 containers.
  • one of the containers is able to read and write a Struct4 structure defining the access rights to the set of resources.
  • management of access to resources is therefore carried out at the level of the Contn4 container which is configured to read and write the Struct4 structure and determine access rights.
  • This example is provided as a limiting example, and the same principle can be applied to other types of virtualizations at the operating system level, such as virtual machines.
  • the management of access rights to resources can therefore be carried out within containers, or other virtualizations at the operating system level, executed by hypervisors already deployed, which allows great flexibility in the deployment of access rights to resources.
  • access rights management can be updated by modifying a container, without having to modify the hypervisor.
  • Figure 5 shows an example of method P5 for managing at least one resource from 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 Servi, Serv2, Servi 3, Serv4 to manage at least one resource such as the 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, access rights to at least one resource provided by said first client.
  • 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.
  • the access rights can be of different types.
  • the rights can for example be “CRUD” type rights (from the English Create, Read, Update, Delete”, in French “Creation, Reading, Update, Delete”).
  • Rights can be provided, for example, to specific customers or groups of customers.
  • the rights can also be accompanied by spatial, temporal conditions, number of uses, etc.
  • Access rights can be provided to other clients, but also to the servers themselves.
  • the method P3 then comprises a second step S52 of reception, by the at least one server, of a request from a second client of said plurality of clients, requesting access to at least one resource provided by the first customer.
  • a request for access to the resource can be of different types, depending on the type of resource concerned.
  • the request for access to the resource can be a request to read or modify a file, a request to access the 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 customer.
  • the at least one server provides in the fourth step S54 access to the at least one resource to said second client.
  • the at least one server rejects the access request in step S55.
  • the access rights defined by the first client are taken into account for the provision or not of access to the resources.
  • the steps of method P5 can be implemented by a single server, or a plurality of servers, for example a network of servers as shown in Figure 3.
  • step S51 can be carried out by a first server which receives a resource from a first client
  • steps S52 to S54 by a second server which receives a request for access to the resource from a second client.
  • Figure 6 shows an example of sharing resources relating to a machine learning model according to a set of embodiments of the invention.
  • the example in Figure 6 represents access to a resource, which is a Modi 6 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 connection with a ServCtr6 server, which centralizes machine learning models shared between several servers.
  • the Mod16 model is a model making it possible to detect people in an image, and to count the number of people in an image.
  • This example is provided as a non-limiting example, and the example in Figure 6 can be extended to other types of machine learning models.
  • Figure 6 describes a scenario P6 of use of the Mod16 model by a second client. In this scenario, the access rights of the Mod16 model defined by the first client Clt1 allow the second client Clt2 to use and update the Mod16 model.
  • the second client Clt2 sends to the server Serv6 a request Rq6 for use of the Mod16 model on the basis of an image that it provides.
  • 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 Ret6 return 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.
  • the return Ret6 triggers a phase of improvement of the model by the server from the return, to obtain an improved model Mod26 .
  • the improvement phase can in practice be carried out by the Serv6 server itself, or a remote server, such as for example the central server ServCtr6.
  • the central server ServCtr6 can thus centralize the learning of the models.
  • the Serv6 server can receive the Modi 6 model from the ServCtr6 central server, return the Ret6 feedback to the ServCtr6 central server, and receive the Mod26 enhanced model from the central server.
  • the central server can also centralize the models, without doing the learning itself.
  • the central server ServCtr6 can store the Mod16 model, send it in a TransMod16 step to the Serv6 server before use on the Serv6 server, the Serv6 server can do the update then send the updated Mod26 model back to the central server ServCtr6 in a TransMod26 step.
  • the improved model Mod26 is trained in part with data provided by the second client, the feedback Ret6 and the improvement of the model also result in an association with the improved model Mod26 of access rights granted by said second client.
  • the improved model Mod26 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 latter could use the Mod16 model, but not the improved Mod26 model for example.
  • This principle can more generally be applied to any model trained from data provided by several clients.
  • a resource is a model trained with data provided by a plurality of initial clients
  • access to the model cannot be provided to a final client, whether or not part of the plurality of initial clients, only if the access rights provided by each of the initial clients of said plurality allow it.
  • Figure 7 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 in Figure 7 represents access to a set of resources, which is a plurality of ModFedl 7 federated models of a digital twin of an element of the Elt7 physical world.
  • the physical world element Elt7 is a factory
  • ModFedl 7 federated models are stored on a central ServCtr7 server, and include a Mod7 model of a factory sub-item provided by the Clt7 client.
  • a plurality of clients participate in the federation of models by providing models of sub-elements of the Elt7 element.
  • the plurality of clients have mutually provided each other with rights to execute and update the federated models, such that each client can perform a simulation of the federated model, and update the models if the simulation does not match to observations from the physical world.
  • Customers can here correspond to different entities participating in the management of the factory.
  • client Clt7 may be a factory operator, and other clients providing federated models are suppliers of various factory equipment, and/or operators of identical factories.
  • Figure 7 more specifically represents a scenario P7, in which an incident has occurred in the factory.
  • the factory is equipped with sensors to monitor the operation of the factory, 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 client Clt7 sends to the server Serv7 a ReqSim7 request for simulation of the federation of models on the basis of the sensor measurements.
  • the Serv7 server performs a Sim7 simulation of the federated models including scenario evaluation and determination of a set of commands to terminate to the incident.
  • the Serv7 server sends back to the CI7 client a return of the simulation accompanied by the set of commands.
  • the client Clt7 then sends the set of Clt7 commands to the Elt7 factory, which will execute the Exec7 commands.
  • the Elt7 factory sends a new set of Sens27 sensor observations to the Clt7 client, which in turn sends a RetSim27 simulation return to the Serv7 server including the new set of observations Sens27.
  • the new set of Sens27 observations may be different from the predictions of the federated models.
  • the Serv7 server triggers Upd7 an update of the federated models based on the new set of observations.
  • the new observation set is transmitted to the central server ServCtr7, which will carry out the update.
  • the federated models are updated using data provided by the Clt7 client.
  • the update of the 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 capacity of the invention to allow 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 that 'he gives.
  • This example is, however, provided solely as an example 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 that it provides or helps to train, and in which a client cannot access a federation of models only if all the clients who contributed to providing or training the models give it permission.
  • Figure 8 shows an example of a structure defining access rights according to a set of embodiments.
  • the Tab8 structure is in the form of a two-dimensional table defining the access rights provided by each of the clients.
  • the clients are applications, represented by the letters "App 1", “App 2", “App n".
  • App 1 the access rights provided by each of the clients.
  • App 2 the access rights provided by each of the clients.
  • App n the access rights provided by each of the clients.
  • the letters “PCE” represent the server itself, which can also receive or provide access rights.
  • the rights granted can be of 4 types, depending on the name
  • Each box includes the letters corresponding to the rights among the 4 possible rights granted by the entity characterizing the row of the box to the entity characterizing the column of the box.
  • cell Cell 8 located on the 3rd line “App 2” and on the first column “PCE”, represents the rights granted by “App 2” to the server.
  • the 4 rights C, R, U and D are provided
  • cell Cel28 located on the 1st line “PCE” and the 3rd column “App 2”, represents the rights granted by the server to “App 2”.
  • only R reading permission is provided.
  • Rights are not necessarily granted symmetrically.
  • cells Cell 8 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. Likewise, access rights may use a different formalism and/or include a greater number of types of access rights. Access rights can also be associated with additional characteristics such as geographic zones, periods of time, a limited number of accesses, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Mathematical Physics (AREA)
  • Artificial Intelligence (AREA)
  • Storage Device Security (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention divulgue une méthode de gestion d'au moins une ressource d'un ensemble de ressources fournies par une pluralité de clients comprenant, ladite méthode étant mise en œuvre par un serveur et comprenant: la définition, par un serveur, dans une structure définissant des droits d'accès pour un ensemble de ressources fournies par une pluralité de clients, et à la réception d'une première requête d'un premier client de ladite pluralité de clients, des droits d'accès d'au moins une ressource fournie par ledit premier client; la réception d'une requête d'une premier client de ladite pluralité de clients, demandant l'accès à au moins une ressource fournie par un deuxième client, la fourniture, par ledit serveur de l'accès à ladite au moins une ressource audit premier client si les droits d'accès le permettent.

Description

Description
Titre : METHODE ET SERVEUR DE GESTION DE DROITS D’ACCES A DES RESSOURCES PARTAGEES
Domaine technique
[0001] La présente divulgation relève du domaine du partage des ressources informatiques. Plus particulièrement, elle relève du domaine de la gestion des droits d’accès à des ressources informatiques partagées.
Technique antérieure
[0002] Le partage, ou mutualisation, de ressources informatiques consiste à partager, entre plusieurs acteurs, des ressources détenues par les différents acteurs.
[0003] Le partage de ressources peut s’opérer entre plusieurs clients d’au moins un serveur, qui envoient des requêtes au serveur pour partager leurs ressources et accéder à celles d’autres clients.
[0004] Le partage de ressources apporte des bénéfices aux clients dans de nombreux domaines.
[0005] Par exemple, les clients peuvent partager des fichiers, mais aussi des bases d’entrainement de moteurs d’apprentissage automatique afin de mutualiser leurs bases d’apprentissage. La mutualisation de ressources peut encore par exemple porter sur des éléments fédérés de jumeaux numériques.
[0006] Cependant, le partage d’une ressource par un client comporte le risque d’accès non désiré à la ressource par des tiers, ou d’usage abusif de la ressource par un autre client.
[0007] Ce risque est particulièrement fort lorsqu’il existe une différence importante d’importance entre deux clients, et peut freiner l’adoption de solutions de mutualisation de ressources par des clients.
[0008] Il y a donc besoin de solutions de partage de ressource entre plusieurs clients, permettant à chaque client de contrôler les droits d’accès aux ressources qu’il fournit.
Résumé
[0009] La présente divulgation vient améliorer la situation.
[0010] Il est proposé une méthode de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients, ladite méthode étant mise en œuvre par au moins un serveur et comprenant : la définition, par l’au moins un serveur, dans une structure définissant des droits d’accès pour un ensemble de ressources fournies par une pluralité de client, et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client ; la réception, par l’au moins un serveur, d’une deuxième requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à l’au moins une ressource fournie par le premier client ; la fourniture, par l’au moins un serveur, de l’accès à l’au moins une ressource audit deuxième client si les droits d’accès le permettent. [0011] On entend par "structure" une organisation de données permettant de formaliser des données informatiques. Une structure peut par exemple être un tableau ou une base de données.
[0012] On entend par "ressource" un élément utilisable par une application pour son exécution. Une ressource peut être: 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.
[0013] On entend par "client" une entité envoyant des requêtes au serveur afin de fournir du contenu, définir des droits d'accès et/ou accéder à du contenu. Un client peut par exemple être défini par un terminal utilisateur, un utilisateur d'un terminal, une entreprise ou une application exécutée par exemple dans une machine virtuelle ou un conteneur.
[0014] Ceci permet un partage de ressources entre plusieurs clients, tout en permettant à chaque client de contrôler les droits d’accès aux ressources qu’il fournit. Dans d’autres termes, la méthode proposée permet d’orchestrer la mutualisation de ressources entre plusieurs clients avec une sécurité renforcée.
[0015] Selon un autre aspect, il est proposé un serveur de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients comprenant : un accès à un ensemble de ressources fournies par une pluralité de clients; un accès à une structure définissant des droits d’accès pour l’ensemble de ressources; au moins une unité de calcul configurée pour : définir dans ladite structure, à la réception d’une première requête d’un premier client de ladite pluralité de clients, les droits d’accès d’au moins une ressource fournie par ledit premier client; recevoir une requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par le premier client ; fournir l’accès à ladite au moins une ressource audit deuxième client si les droits d’accès le permettent.
[0016] On entend par « unité de calcul » un composant électronique apte à effectuer des calculs électroniques ou informatiques pour effectuer une fonction déterminée. Une unité de calcul peut désigner tout type de processeur ou composant électronique apte à effectuer des calculs numériques. Par exemple, une unité de calcul peut être un circuit intégré, un ASIC (de l’acronyme anglais « Application-Specific Integrated Circuit », littéralement en français « circuit intégré propre à une application », un microcontrôleur, un microprocesseur, un DSP (de l’acronyme anglais « Digital Signal Processor », littéralement en français « processeur de signal numérique »), un processeur, un GPU (de l’acronyme anglais « Graphics Processing Unit », littéralement en français « unité de calcul graphique »). Une unité de calcul selon l’invention n’est pas limitée à un type particulier d’architecture de calcul. Par exemple, un processeur peut mettre en œuvre une architecture de type Harvard ou Von Neumann.
[0017] Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’une méthode telle que définie dans les présentes lorsque ce programme est exécuté par un processeur.
[0018] Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme.
[0019] Selon un autre aspect, il est proposé un dispositif informatique comprenant au moins une unité de calcul configurée pour exécuter tout ou partie d’une méthode telle que définie dans les présentes.
[0020] Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre, indépendamment les unes des autres ou en combinaison les unes avec les autres :
[0021] Avantageusement, la méthode est mise en œuvre par au moins une unité de calcul d’un hyperviseur dudit serveur apte à lire et écrire ladite structure.
[0022] Ceci permet de renforcer la sécurité de la gestion des droits d’accès.
[0023] Avantageusement, la méthode comprend une notarisation électronique de chaque requête relative à une ressource dudit ensemble par ladite au moins une unité de calcul de l’hyperviseur.
[0024] On entend par "Notarisation électronique" une certification et un archivage électroniques de la date, de l'origine et de la destination d'une requête.
[0025] Ceci permet de conserver et de certifier un historique des droits d’accès, et des requêtes d’accès aux ressources.
[0026] Avantageusement, la méthode comprend une synchronisation, par ladite au moins une unité de calcul de l’hyperviseur, desdits droits d’accès avec au moins un hyperviseur distant exécuté par au moins une unité de calcul distante sur au moins un serveur distant.
[0027] Ceci permet de synchroniser des droits d’accès entre plusieurs serveurs, et donc de conserver des droits d’accès à jour entre les différents serveurs pour un nombre de ressources aussi élevé que possible entre des serveurs recevant des requêtes différentes sur en ensemble de ressources partagées.
[0028] Avantageusement, la méthode comprend une communication du serveur avec au moins un serveur central configuré pour maintenir une structure de droits d’accès de référence.
[0029] On entend par "serveur central" un serveur centralisant un traitement pour le compte de plusieurs serveurs.
[0030] Ceci permet de centraliser, pour le compte de plusieurs serveurs, la gestion de la synchronisation des droits des clients, et donc de faciliter la synchronisation de la gestion des droits d’accès entre les serveurs. [0031] Avantageusement, ladite méthode est mise en œuvre par au moins une unité de calcul d’une virtualisation au niveau du système d’exploitation exécutée par un hyperviseur, ladite virtualisation au niveau du système d’exploitation étant apte à lire et écrire ladite structure.
[0032] On entend par "virtualisation au niveau du système d'exploitation" une instance utilisateur fournissant un système d'exploitation virtuel. Une virtualisation au niveau du système d'exploitation peut par exemple être nommé dans certains types de systèmes d'exploitation conteneur, serveur privé virtuel, partition, environnement virtuel ou noyau virtuel. Un conteneur contient les éléments nécessaires à la virtualisation.
[0033] Ceci permet une grande flexibilité dans le déploiement des droits d’accès aux ressources, car la gestion des droits d’accès peut être implémentée au sein de systèmes d’exploitation virtuels exécutables par des hyperviseurs déjà déployés.
[0034] Avantageusement, ladite au moins une ressource est un modèle d’apprentissage machine entraîné avec des données fournies par ledit premier client.
[0035] Ceci permet de partager l’entraînement de modèles d’apprentissage machine tout en garantissant à chaque client fournissant des données d’apprentissage le contrôle sur les autres clients ayant accès au produit de l’entraînement.
[0036] Avantageusement, la deuxième requête est une requête d’utilisation du modèle d’apprentissage machine sur des données fournies par le deuxième client ; la méthode comprend : l’envoi, par ledit serveur, d’un résultat de ladite utilisation du modèle d’apprentissage machine au deuxième client ; la réception, par ledit serveur, d’un retour dudit deuxième client sur ledit résultat ; le déclenchement, par ledit serveur : d’une phase d’amélioration dudit modèle à partir dudit retour, et d’une association audit modèle amélioré de droits d’accès accordés par ledit deuxième client.
[0037] On entend par "déclenchent" l'entraînement d'une ou plusieurs actions. Le déclenchement d'actions par l'au moins une unité de calcul peut par exemple consister en l'exécution des actions par l'unité de calcul, ou l'envoi d'instructions à une unité de calcul distante d'effectuer les actions. Par exemple, l'unité de calcul distante peut être une unité de calcul d'un serveur central, et l'au moins une unité de calcul peut fournir le retour au serveur central pour réaliser l'amélioration du modèle sur le serveur central.
[0038] On entend par "phase d'amélioration" une phase d'entraînement du modèle comprenant une amélioration de l'entraînement préalable du modèle. Par exemple, la phase d'amélioration peut être une phase d'apprentissage par renforcement et ledit résultat peut être une récompense accordée par le deuxième client.
[0039] On entend par "retour" (en anglais "feedback") une indication fournie par le deuxième client de la qualité du résultat fourni. Par exemple, dans le cadre d'un apprentissage par renforcement, le retour peut être une récompense [0040] Ceci permet d’entraîner un modèle avec des données fournies par plusieurs clients, tout en s’assurant à tout moment que l’utilisation du modèle est subordonnée à la fourniture de droits d’accès par tous les clients ayant contribué à l’entraînement.
[0041] Avantageusement, la méthode comprend : la réception, par ledit serveur, dudit modèle d’apprentissage machine depuis serveur central ; la fourniture, par ledit serveur, dudit ledit retour au serveur central afin de déclencher ladite phase d’amélioration
[0042] Ceci permet de centraliser l’apprentissage du modèle auprès du serveur central.
[0043] Avantageusement, l’ensemble de ressources comprend une pluralité de modèles fédérés d’un jumeau numérique d’un élément monde physique ; la méthode comprend : à la réception de la deuxième requête, l’exécution, par le serveur, d’une fédération de simulations dudit élément du monde physique pour tous les modèles fédérés de ladite pluralité pour lesquels le deuxième client dispose des droits d’accès ; à la réception d’un retour du deuxième client, le déclenchement, par le serveur, : d’une mise à jour desdits modèles fédérés ; et d’une association audit modèles fédérés mis à jour de droits d’accès accordés par ledit deuxième client.
[0044] On entend par "modèles fédérés" un ensemble de modèles participant conjointement à la modélisation d'un élément du monde physique. Par exemple, les modèles fédérés peuvent correspondre à des modèles de différentes parties de l’élément.
[0045] On entend par "jumeau numérique" une réplique numérique d'un élément du monde physique.
[0046] Ceci permet de partager une fédération de modèles du monde physique entre plusieurs clients, et les retours permettant d’améliorer les modèles, tout en garantissant à chaque client fournissant des retours permettant d’améliorer les modes le contrôle sur les autres clients ayant accès modèles fédérés bénéficiant du retour.
[0047] Avantageusement, la méthode comprend : la réception, par le serveur, desdits modèles fédérés depuis un serveur central ; la fourniture, par le serveur, dudit retour au serveur central afin de déclencher ladite mise à jour des modèles fédérés
[0048] Ceci permet de centraliser la fédération des modèles auprès du serveur central.
[0049] Avantageusement, ladite structure est une table indiquant, pour chaque paire de client, les droits d’accès accordés par le premier client de la paire au deuxième client de la paire, et du deuxième client de la paire au premier client de la paire, les autorisations appartenant à un groupe comprenant : un droit de création ; un droit de lecture ; un droit de mise à jour ; un droit de suppression.
[0050] Ceci permet de définir de manière déterministe les droits d’accès donnés par les clients entre eux. Brève description des dessins
[0051] D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
Fig. 1
[0052] [Fig. 1] montre un exemple de serveur selon un ensemble de modes de réalisation.
Fig. 2
[0053] [Fig. 2] montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est effectuée par un hyperviseur.
Fig. 3
[0054] [Fig. 3] montre un exemple d’un réseau de serveurs dans lesquels la gestion de l’accès aux ressources est mis en œuvre par un hyperviseur selon un mode de réalisation.
Fig. 4
[0055] [Fig. 4] montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est effectuée par un conteneur.
Fig. 5
[0056] [Fig. 5] montre un exemple de méthode de gestion d’au moins une ressource d’un ensemble de ressource selon un ensemble de modes mode de réalisation de l’invention.
Fig. 6
[0057] [Fig. 6] montre un exemple de partage de ressources relatives à un modèle d’apprentissage machine selon un ensemble de modes de réalisation de l’invention.
Fig. 7
[0058] [Fig. 7] montre un exemple de partage de ressources relatives à des modèles fédérés d’un jumeau numérique selon un ensemble de modes de réalisation de l’invention.
Fig. 8
[0059] [Fig. 8] montre un exemple de structure définissant des droits d’accès selon un ensemble de modes de réalisation.
Description des modes de réalisation
[0060] Il est maintenant fait référence à la figure 1 .
[0061] La figure 1 représente un serveur selon un ensemble de modes de réalisation de l’invention.
[0062] Le serveur Servi est un serveur de gestion d’au moins une ressource d’un ensemble de ressources fournies par une pluralité de clients. [0063] Le serveur Servi est ainsi apte à gérer l’ensemble de ressources, c’est-à-dire créer, modifier, ou encore donner accès aux ressources de l’ensemble. Le serveur Servi permet donc à une pluralité de clients d’échanger des ressources.
[0064] La figure 1 représente deux clients Clt1 et Clt2. Les clients peuvent être de différents types. Un client peut par exemple être un terminal utilisateur, un utilisateur d'un terminal, une entreprise ou une application. Le serveur Servi peut comprendre un ou plusieurs liens de communication pour communiquer avec les clients. Un lien de communication avec un client peut comprendre tout moyen de communication. La communication avec les clients peut par exemple s’effectuer par le biais d’un réseau internet ou un réseau mobile.
[0065] Le lien de communication avec les clients permet ainsi au serveur de recevoir des requêtes des clients. Les requêtes peuvent par exemple consister en des requêtes d’ajout de ressources, de modification de droits d’accès aux ressources, ou encore de demande d’accès à une ressource.
[0066] Le serveur Servi peut également comprendre des moyens d’authentification des clients, afin de sécuriser les échanges de données entre clients.
[0067] La figure 1 représente deux clients distincts Clt1 et Clt2. Ce nombre est bien sûr fourni à titre d’exemple non limitatif uniquement, et l’invention est applicable à tout nombre de client supérieur ou égal à 2.
[0068] Le serveur Servi comprend également un accès à un ensemble de ressources fournies par la pluralité de clients.
[0069] Comme indiqué ci-dessus, les ressources peuvent comprendre tout type de ressource informatique, par exemple des ressources matérielles, logicielles ou du contenu pouvant être échangées entre les clients.
[0070] Les ressources peuvent par exemple être stockées dans au moins une mémoire Mem à laquelle le serveur Servi a accès. L’au moins une mémoire Mem peut appartenir à différents types de stockage de données apte à stocker les ressources. Il peut par exemple s’agir d’une mémoire vive, d’une mémoire morte, d’une mémoire volatile, d’une mémoire flash ou encore d’une mémoire virtuelle.
[0071] L’au moins une mémoire comprendre au moins une mémoire interne et/ou au moins une mémoire externe au serveur Servi . Une mémoire externe peut être par exemple une mémoire contenue dans un dispositif relié au serveur Servi par une connexion filaire, ou une mémoire située dans un serveur situé sur le même réseau que le serveur Servi , par exemple un serveur central. Ainsi, l’accès à l’au moins une mémoire peut se faire par le biais d’une connexion interne au serveur Servi , ou d’une connexion externe sécurisée vers le dispositif comprenant la mémoire.
[0072] La figure 1 représente deux ressources Res1 , Res2. Ce nombre est bien sûr fourni à titre d’exemple non limitatif uniquement, et l’invention est applicable à ensemble de ressources comprenant au moins une ressource. [0073] Les ressources peuvent également être dupliquées sur plusieurs mémoires, afin de garantir leur accès en cas de défaillance de l’une des mémoires. Elles peuvent être stockées directement dans les mémoires, mais également encryptées, stockées en bases de données, etc.
[0074] Le serveur Servi comprend également un accès à une structure Structl définissant des droits d’accès pour l’ensemble de ressources. La structure Structl peut par exemple être stockée sur l’au moins une mémoire Mem. Dans l’exemple de la figure 1 , les ressources Res1 et Res2 sont situées dans la même mémoire que la structure Structl . Cet exemple est fourni à titre d’exemple non limitatif uniquement, et les ressources et structures peuvent être stockées sur des mémoires différentes. La structure Structl peut par ailleurs être dupliquée sur plusieurs mémoires pour garantir son accès en cas de défaillance d’une des mémoires, et/ou être stockée par parties sur plusieurs mémoires.
[0075] Le serveur Servi comprend au moins une unité de calcul Cale. L’unité de calcul est configurée pour recevoir des requêtes de clients, et fournir ou non l’accès aux ressources, par exemple en mettant en œuvre la méthode P5 représentée en figure 5, ou en participant à la mise en œuvre des scénarios représentés en figure 6 et 7. La gestion de l’accès aux ressources par les clients Clt1 , Clt2 peut être mise en œuvre au niveau de l’hyperviseur (représenté à la figure 2) ou au niveau d’un conteneur ou d’une machine virtuelle (représenté à la figure 4).
[0076] Il est maintenant fait référence à la figure 2.
[0077] La figure 2 montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est mis en œuvre par un hyperviseur.
[0078] Le serveur Serv2 représenté en figure 2 peut par exemple être le serveur Servi représenté en figure 1 .
[0079] Le serveur Serv2 met en œuvre plusieurs modules.
[0080] Dans l’exemple de la figure 2, le serveur comprend un système d’exploitation OS2 apte à mettre en œuvre un hyperviseur Hypvsr2 apte à lire et écrire une structure Struct2 définissant les droits d’accès à l’ensemble de ressources.
[0081] Dans cet exemple, la gestion de l’accès aux ressources s’effectue donc au niveau de l’hyperviseur Hypvsr2 qui est configuré pour lire et écrire la structure Struct2 et déterminer les droits d’accès.
[0082] L’hyperviseur Hypvsr2 est également apte à contrôler et gérer un ou plusieurs conteneurs Cont12, Cont22, ... Contn2 ou une ou plusieurs machines virtuelles. On notera qu’une machine virtuelle est une virtualisation de ressources matérielles et logicielles dont un système d’exploitation, permettant d’exécuter une requête d’un client en s’exécutant sur l’hyperviseur. Un conteneur est une virtualisation des ressources matérielles et logicielles sans instanciation du système d’exploitation. En effet, un conteneur partage un même système d’exploitation avec d’autres conteneurs.
[0083] Cette architecture permet de renforcer la sécurité des droits d’accès. En effet, si l’hyperviseur peut contrôler et gérer les conteneurs Cont12, Cont22, ... Contn2 exécutant du code tiers, la gestion des droits d’accès s’effectue au niveau de l’hyperviseur lui-même, et peut donc être totalement contrôlée.
[0084] Dans cet exemple, l’hyperviseur peut non seulement gérer l’accès aux ressources, mais également effectuer une notarisation électronique de chaque requête relative à une ressource.
[0085] Ainsi, la notarisation permet d’archiver la date, de l'origine et de la destination de chaque requête relative à une ressource, par exemple les requêtes de création de ressource, de modification de droits d’accès, d’édition d’une ressource, d’accès à une ressource, etc.
[0086] Ceci permet notamment d’identifier a posteriori toute requête d’accès à une ressource. Ceci permet de garder trace de toute tentative d’accès ou de modification, autorisée ou non, aux ressources, mais également de quantifier l’accès aux ressources.
[0087] En effet, le partage de ressources par les clients peut s’effectuer dans le cadre de contrats commerciaux d’échanges de ressources entre les clients. La notarisation des requêtes permet ainsi le cas échéant de quantifier l’accès aux ressources par chaque client, qui peut être un objet du contrat.
[0088] L’accès à une ressource peut également être fourni par un premier client à un deuxième pour un nombre défini d’accès. Ce nombre défini peut être un nombre d’accès total, ou un nombre d’accès par unité de temps (par jour, par semaine, par mois, etc.). La notarisation des requêtes permet alors de vérifier si le nombre limite d’accès à une ressource est dépassé ou non, et de fournir ou non l’accès à la ressource en conséquence.
[0089] Il est maintenant fait référence à la figure 3.
[0090] La figure 3 montre un exemple d’un réseau de serveurs dans lesquels la gestion de l’accès aux ressources est mis en œuvre par un hyperviseur selon un mode de réalisation.
[0091] Dans l’exemple de la figure 3, un réseau Res3 de serveurs comprend trois serveurs Servi 3, Serv23 et Serv33. Chacun des trois serveurs Servi 3, Serv23 et Serv33 est semblable au serveur Serv2, ayant accès à des ressources partagées et comprenant un hyperviseur apte à effectuer la gestion des droits d’accès aux ressources et exécuter des conteneurs.
[0092] Par exemple, les serveurs les serveurs Servi 3, Serv23 et Serv33 sont respectivement aptes à exécuter les hyperviseurs Hypvsr13, Hpyvsr23 et Hypvsr33.
[0093] Par analogie avec le serveur Serv2, le serveur Servi 3 comprend un système d’exploitation OS3, l’hyperviseur Hypvsr13 apte à lire et écrire la structure Struct13 définissant des droits d’accès pour un ensemble de ressources, et à exécuter les conteneurs Contl 13, Cont213 et Contn13.
[0094] De même, les hyperviseurs Hypvsr23 et Hypvsr33 sont respectivement aptes à lire et écrire les structures Struct23 et Struct33 définissant des droits d’accès pour même ensemble de ressources. [0095] Les serveurs Servi 3, Serv23 et Serv33 sont des serveurs distants les uns des autres, c’est- à-dire qu’ils sont situés dans des emplacements physiques différents. Les serveurs Servi 3, Serv23 et Serv33 sont en communication par un réseau, par exemple un réseau internent Intnt.
[0096] Les serveurs Servi 3, Serv23 et Serv33 sont configurés pour fournir l’accès à un même ensemble de ressources, mais peuvent être en communication avec des clients différents.
[0097] Les ressources peuvent ainsi être partagées sur des zones mémoires accessibles aux trois serveurs et/ou dupliquées sur des zones mémoires accessibles à chacun des serveurs.
[0098] Cependant, les hyperviseurs Hypvsr13, Hypvsr23 et Hypvsr33 sont configurés pour synchroniser les droits d’accès à l’ensemble de ressources, tels que définis dans les structures respectives Struct13, Struct23 et Struct33.
[0099] Ainsi, les droits d’accès peuvent être partagés et mis à jour entre les clients de plusieurs serveurs, ce qui permet d’augmenter le nombre de clients et de ressources pouvant participer au partage de ressources, puisque les clients de plusieurs serveurs, et les ressources fournies par ces clients, peuvent intervenir dans le partage.
[0100] De plus, cela permet de mettre en œuvre des techniques de « edge computing », dans lesquelles des serveurs sont placés au plus près des clients tout en ayant accès à des ressources partagées de manière plus large, et en garantissant le respect des règles d’accès définies par chaque client entre les serveurs.
[0101] La figure 3 représente un exemple dans lequel un réseau de serveurs comprend trois serveurs. Cet exemple est cependant fourni à titre d’exemple non limitatif uniquement, et l’invention est applicable à tout nombre de serveur en réseau supérieur ou égal à deux.
[0102] La synchronisation des droits d’accès entre les serveurs peut s’effectuer de différentes manières.
[0103] Par exemple, des algorithmes de synchronisation distribués peuvent être mis en œuvre. Par exemple, les serveurs peuvent maintenir la synchronisation des droits d’accès via une blockchain.
[0104] Il est également possible de centraliser la gestion de la synchronisation. Par exemple, tous les serveurs peuvent communiquer avec un serveur central configuré pour maintenir une structure de droits d’accès de référence. Le serveur central peut être l’un des serveurs, ou un autre serveur dédié à la maintenance de la structure de référence.
[0105] Il est maintenant fait référence à la figure 4.
[0106] La figure 4 montre un exemple de modules mis en œuvre par un serveur selon un ensemble de modes de réalisation de l’invention, dans lequel la gestion de l’accès aux ressources est effectuée par un conteneur.
[0107] Le serveur Serv4 représenté en figure 4 peut par exemple être le serveur Servi représenté en figure 1 .
[0108] Le serveur Serv4 met en œuvre plusieurs modules. [0109] Dans l’exemple de la figure 4, le serveur comprend un système d’exploitation OS4 apte à mettre en œuvre un hyperviseur Hypvsr4.
[0110] L’hyperviseur Hypvsr4 est apte à exécuter un ou plusieurs conteneurs Cont14, Cont24, ... Contn4.
[0111] Dans cet exemple, l’un des conteneurs, le conteneur Contn4, est apte à lire et écrire une structure Struct4 définissant les droits d’accès à l’ensemble de ressources. Dans cet exemple, la gestion de l’accès aux ressources s’effectue donc au niveau du conteneur Contn4 qui est configuré pour lire et écrire la structure Struct4 et déterminer les droits d’accès.
[0112] Cet exemple est fourni à titre d’exemple on limitatif, et le même principe peut être appliqué à d’autres types de virtualisations au niveau du système d’exploitation, tels que des machines virtuelles.
[0113] La gestion des droits d’accès aux ressources peut donc s’effectuer au sein de conteneurs, ou d’autres virtualisations au niveau du système d’exploitation, exécutés par des hyperviseurs déjà déployés, ce qui permet une grande flexibilité dans le déploiement des droits d’accès aux ressources. Par exemple, la gestion des droits d’accès peut être mise à jour par la modification d’un conteneur, sans avoir à modifier l’hyperviseur.
[0114] IL est maintenant fait référence à la figure 5.
[0115] La figure 5 montre un exemple de méthode P5 de gestion d’au moins une ressource d’un ensemble de ressource selon un ensemble de modes mode de réalisation de l’invention.
[0116] La méthode P5 peut par exemple être mise en œuvre par l’un des serveurs Servi , Serv2, Servi 3, Serv4 pour gérer au moins une ressource telle que les ressources Res1 et Res2.
[0117] La méthode P5 comprend une première étape S51 de définition par l’au moins un serveur, dans une structure définissant des droits d’accès pour un ensemble de ressources fournies par une pluralité de clients, et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client.
[0118] En pratique, l’étape S51 peut par exemple s’effectuer : à 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.
[0119] Les droits d’accès peuvent être de différents types.
[0120] Par exemple, les droits peuvent par exemple être des droits de type « CRUD » (de l’anglais Create, Read, Update, Delete », en français « Création, Lecture, Mise à jour, Suppression »). Les droits peuvent être fournis par exemple à des clients ou groupes de clients spécifiques. Les droits peuvent également être assorties de conditions spatiales, temporelles, de nombre d’utilisations, etc. Les droits d’accès peuvent être fournis aux autres clients, mais également aux serveurs eux-mêmes. [0121] La méthode P3 comprend ensuite une deuxième étape S52 de réception, par l’au moins un serveur, d’une requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par le premier client.
[0122] Une requête d’accès à la ressource peut être de différents types, selon le type de ressource concernée.
[0123] Par exemple, la requête d’accès à la ressource peut être une requête de lecture ou de modification d’un fichier, une requête d’accès à des bases de données d’entraînement d’un modèle d’apprentissage machine, une requête d’utilisation d’un modèle fédéré d’un jumeau numérique, etc.
[0124] La méthode P3 comprend ensuite, à la réception de la requête d’accès, une troisième étape S53 de vérification par l’au moins un serveur de si les droits d’accès permettent l’accès à l’au moins une ressource par le deuxième client.
[0125] Si les droits d’accès le permettent, l’au moins un serveur fournit à la quatrième étape S54 l’accès à l’au moins une ressource audit deuxième client.
[0126] Sinon, l’au moins un serveur rejette la requête d’accès à l’étape S55.
[0127] Ainsi, les droits d’accès définis par le premier client sont pris en compte pour la fourniture ou non de l’accès aux ressources.
[0128] Selon différents modes de réalisation de l’invention, les étapes de la méthode P5 peuvent être mises en œuvre par un serveur unique, ou une pluralité de serveurs, par exemple un réseau de serveurs tels que représenté en figure 3.
[0129] Si la méthode est mise en œuvre par une pluralité de serveurs, les différentes étapes peuvent être réalisées par plusieurs serveurs distincts. Par exemple, l’étape S51 peut être réalisée par un premier serveur qui reçoit une ressource d’un premier client, et les étapes S52 à S54 par un deuxième serveur qui reçoit une requête d’accès à la ressource d’un deuxième client.
[0130] Il est maintenant fait référence à la figure 6.
[0131] La figure 6 montre un exemple de partage de ressources relatives à un modèle d’apprentissage machine selon un ensemble de modes de réalisation de l’invention.
[0132] L’exemple de la figure 6 représente l’accès une ressource, qui est un modèle d’apprentissage machine Modi 6 entraîné avec des données fournies par le premier client Clt1 .
[0133] Le modèle entraîné est dans cet exemple stocké sur le serveur Serv6, en relation avec un serveur ServCtr6, qui centralise des modèles d’apprentissage machine partagés entre plusieurs serveurs.
[0134] Dans cet exemple, le modèle Mod16 est un modèle permettant de détecter des personnes dans une image, et de compter le nombre de personnes dans une image. Cet exemple est fourni à titre d’exemple non limitatif, et l’exemple de la figure 6 peut être étendu à d’autres types de modèles d’apprentissage machine. [0135] La figure 6 décrit un scénario P6 d’utilisation du modèle Mod16 par un deuxième client. Dans ce scénario, les droits d’accès du modèle Mod16 définis par le premier client Clt1 permettent au deuxième client Clt2 d’utiliser et de mettre à jour le modèle Mod16.
[0136] Dans le scénario P6, le deuxième client Clt2 envoie au serveur Serv6 une requête Rq6 d’utilisation du modèle Mod16 sur la base d’une image qu’il fournit.
[0137] Comme les droits d’accès définis par le premier client le permettent, le serveur Serv6 utilise UtMod16 le modèle Mod16 sur l’image fourni par le deuxième client pour compter le nombre de personnes dans l’image, puis renvoie le résultat Res6 au deuxième client Clt2.
[0138] Le deuxième client Clt2 fournit alors un retour Ret6 au serveur sur ledit résultat. Le retour peut par exemple consister en une validation du nombre de personne, ou au contraire une indication que le nombre de personnes comptées est inexact, d’un nombre de personne exact, ou d’une localisation précise des personnes effectivement présentes sur la photo.
[0139] Comme les droits fournis par le premier client Clt1 permettent la mise à jour du modèle Mod26 par le deuxième client, le retour Ret6 déclenche une phase d’amélioration du modèle par le serveur à partir du retour, pour obtenir un modèle amélioré Mod26.
[0140] La phase d’amélioration peut en pratique être réalisée par le server Serv6 lui-même, ou un serveur distant, tel que par exemple le serveur central ServCtr6.
[0141] Le serveur central ServCtr6 peut ainsi centraliser l’apprentissage des modèles. Par exemple, le serveur Serv6 peut recevoir le modèle Modi 6 du serveur central ServCtr6, renvoyer le retour Ret6 au serveur central ServCtr6, et recevoir du serveur central le modèle amélioré Mod26.
[0142] Le serveur central peut aussi centraliser les modèles, sans faire l’apprentissage lui-même. Par exemple, le serveur central ServCtr6 peut stocker le modèle Mod16, l’envoyer dans une étape TransMod16 au serveur Serv6 avant utilisation sur le serveur Serv6, le serveur Serv6 peut faire la mise à jour puis renvoyer le modèle mis à jour Mod26 au serveur central ServCtr6 dans une étape TransMod26.
[0143] Comme le modèle amélioré Mod26 est entraîné en partie avec des données fournies par le deuxième client, le retour Ret6 et l’amélioration du modèle entraînent également une association au modèle amélioré Mod26 de droits d’accès accordés par ledit deuxième client.
[0144] Dit autrement, le modèle amélioré Mod26 ne pourra être utilisé par un troisième client que si les droits d’accès fournis à la fois par le premier client et le deuxième client le permettent. Si seuls les droits d’accès fournis par le premier client permettent l’accès au modèle par le troisième client, alors celui-ci pourrait utiliser le modèle Mod16, mais pas le modèle amélioré Mod26 par exemple.
[0145] Ce principe peut de manière plus générale être appliqué à tout modèle entraîné à partir des données fournies par plusieurs clients.
[0146] Ainsi, dans un mode de réalisation, si une ressource est un modèle entraîné avec les données fournies par une pluralité de clients initiaux, l’accès au modèle ne pourra être fourni à un client final, faisant partie ou non de la pluralité de clients initiaux, que si les droits d’accès fournis par chacun des clients initiaux de ladite pluralité le permettent.
[0147] Ceci permet à des clients de participer de manière collaborative à la création de modèles d’apprentissage communs, tout en permettant à chaque client de s’assurer des conditions d’accès aux modèles entraînées avec les données qu’il fournit.
[0148] Il est maintenant fait référence à la figure 7.
[0149] La figure 7 montre un exemple de partage de ressources relatives à des modèles fédérés d’un jumeau numérique selon un ensemble de modes de réalisation de l’invention.
[0150] L’exemple de la figure 7 représente l’accès à un ensemble de ressources, qui est une pluralité de modèles fédérés ModFedl 7 d’un jumeau numérique d’un élément du monde physique Elt7.
[0151] Dans l’exemple de la figure 7 :
L’élément du monde physique Elt7 est une usine ;
Les modèles fédérés ModFedl 7 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.
[0152] Dans cet exemple, une pluralité clients participent à la fédération de modèles en fournissant des modèles de sous-éléments de l’élément Elt7. Les clients de la pluralité se sont mutuellement fourni les droits d’exécution et de mise à jour des modèles fédérés, de sorte que chaque client peut effectuer une simulation de la fédération de modèle, et mettre à jour les modèles si la simulation ne correspond pas aux observations issues du monde physique. Les clients peuvent ici correspondre à différentes entités participant à la gestion de l’usine. Par exemple, le client Clt7 peut être un opérateur de l’usine, et les autres clients fournissant des modèles fédérés des fournisseurs de divers équipements de l’usine, et/ou des opérateurs d’usines identiques.
[0153] La figure 7 représente plus spécifiquement un scénario P7, dans lequel un incident est survenu dans l’usine. L’usine est équipée de capteurs permettant de suivre le fonctionnement de l’usine, et envoie Sens17 des mesures prises par les capteurs pendant l’incident, complétées au besoin par des mesures prises avant l’incident au client Clt7.
[0154] Le client Clt7 envoie au serveur Serv7 une requête ReqSim7 de simulation de la fédération de modèles sur la base des mesures capteurs. Comme les droits d’exécution de l’ensemble de la fédération de modèle ont été accordés au client Clt7, le serveur Serv7 effectue une simulation Sim7 des modèles fédérés comprenant une évaluation de scénarios et la détermination d’un jeu de commandes pour mettre un terme à l’incident. Le serveur Serv7 renvoie au client CI7 un retour de la simulation accompagné du jeu de commandes.
[0155] Le client Clt7 envoie ensuite le jeu de commandes Clt7 à l’usine Elt7, qui va procéder à l’exécution Exec7 des commandes. [0156] Une fois les commandes exécutées par l’usine, l’usine Elt7 renvoie un nouveau jeu d’observations de capteurs Sens27 au client Clt7, qui renvoie à son tour un retour RetSim27 de simulation au serveur Serv7 comprenant le nouveau jeu d’observations Sens27.
[0157] Le nouveau jeu d’observations Sens27 peut être différent des prédictions des modèles fédérés. Afin de mettre à jour les modèles, le serveur Serv7 déclenche Upd7 une mise à jour des modèles fédérés sur la base du nouveau jeu d’observations.
[0158] Dans l’exemple de la figure 7, le nouveau jeu d’observation est transmis au serveur central ServCtr7, qui va procéder à la mise à jour.
[0159] Dans d’autres modes de réalisation de l’invention, c’est le serveur Serv7 qui est en charge de la mise à jour.
[0160] Dans l’exemple de la figure 7, la mise à jour des modèles fédérés est faite à partir de données fournies par le client Clt7. La mise à jour des modèles fédérés s’accompagne donc d’une association aux modèles fédérés mis à jour ModFed27 de droits d’accès accordés par le client Clt7.
[0161] Cet exemple démontre la capacité de l’invention de permettre l’utilisation de modèles fédérés de jumeaux numériques d’éléments du monde physique, tout en permettant à chaque client de gérer les droits d’accès aux modèles entraînés avec les données qu’il fournit. Cet exemple est cependant fourni à titre d’exemple uniquement d’un scénario d’application de l’invention à des modèles fédérés. L’invention est de manière plus générale applicable à tout scénario basé sur des modèles fédérés, dans lequel chaque client peut définir les droits d’accès aux modèles qu’il fournit ou contribue à entraîner, et dans lequel un client ne peut accéder à une fédération de modèles que si tous les clients qui ont contribué à fournir ou entraîner les modèles lui en donnent la permission.
[0162] Il est maintenant fait référence à la figure 8.
[0163] La figure 8 montre un exemple de structure définissant des droits d’accès selon un ensemble de modes de réalisation.
[0164] La structure Tab8 se présente sous la forme d’un tableau à deux dimensions définissant les droits d’accès fournis par chacun des clients. Dans cet exemple, les clients sont des applications, représentées par les lettres « App 1 », « App 2 », « App n ». Par mesures de lisibilité, seuls trois clients sont représentés dans cet exemple, mais une structure de ce type est bien entendu applicable à un nombre de client plus élevé. Les lettres « PCE » représentent quant à elle le serveur lui-même, qui peut également recevoir ou fournir des droits d’accès.
[0165] Dans le tableau Tab8 : 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.
[0166] Dans cet exemple, les droits accordés peuvent être de 4 types, selon la dénomination
CRUD
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.
[0167] Chaque case comprend les lettres correspondant aux droits parmi les 4 droits possibles accordés par l’entité caractérisant la ligne de la case à l’entité caractérisant la colonne de la case.
[0168] Par exemple : la cellule Cell 8, située sur la 3e ligne « App 2 » et sur la première colonne « PCE », représente les droits accordés par I’ « App 2 » au serveur. Ici, les 4 droits C, R, U et D sont fournis ; la cellule Cel28, située sur la 1 e ligne « PCE » et la 3e colonne « App 2 », représente les droits accordés par le serveur à I’ « App 2 ». Ici, seul le droit de lecture R est fourni.
[0169] On peut ici remarquer que :
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 Cell 8 et Cel28 montrent que « App2 » accorde plus de droits au serveur que le serveur n’en accorde à « App2 ».
[0170] La table Tab8 fournit un exemple illustratif et non limitatif d’une structure définissant des droits d’accès selon l’invention. Selon d’autres modes de réalisation de l’invention, d’autres types de structures peuvent être mises en œuvre. De même, les droits d’accès peuvent utiliser un formalisme différent et/ou comprendre un plus grand nombre de types de droits d’accès. Les droits d’accès peuvent également être associés à des caractéristiques additionnelles telles que des zones géographiques, des périodes de temps, un nombre limite d’accès, etc.
[0171] La présente divulgation ne se limite pas aux exemples de méthode, serveur, dispositif informatique et programme informatique décrits ci-avant, seulement à titre d’exemple, mais elle englobe toutes les variantes que pourra envisager l’homme de l’art dans le cadre de la protection recherchée.

Claims

Revendications
[Revendication 1] Méthode (P5) de gestion d’au moins une ressource d’un ensemble de ressources (Res1 , Res2) fournies par une pluralité de clients (Clt1 , Clt2), ladite méthode étant mise en œuvre par au moins un serveur (Servi ; Serv2 ; Servi 3 ; Serv4) et comprenant : la définition (S51 ), par l’au moins un serveur (Servi ; Serv2 ; Servi 3 ; Serv4), dans une structure (Structl) définissant des droits d’accès pour un ensemble de ressources (Res1 , Res2) fournies par une pluralité de clients (Clt1 , Clt2), et à la réception d’une première requête d’un premier client de ladite pluralité de clients, des droits d’accès d’au moins une ressource fournie par ledit premier client ; la réception (S52), par l’au moins un serveur, d’une deuxième requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à l’au moins une ressource fournie par le premier client ; la fourniture (S54), par l’au moins un serveur, de l’accès à l’au moins une ressource audit deuxième client si les droits d’accès le permettent (S53).
[Revendication 2] Méthode selon la revendication 1 , ladite méthode étant mise en œuvre par au moins une unité de calcul d’un hyperviseur (Hypvsr2 ; Hypvsr13) dudit serveur apte à lire et écrire ladite structure.
[Revendication 3] Méthode selon la revendication 2, comprenant une notarisation électronique de chaque requête relative à une ressource dudit ensemble par ladite au moins une unité de calcul de l’hyperviseur.
[Revendication 4] Méthode selon l’une des revendications 2 et 3, comprenant une synchronisation, par ladite au moins une unité de calcul de l’hyperviseur, desdits droits d’accès avec au moins un hyperviseur distant (Hypvsr23 ; Hypvser33) exécuté par au moins une unité de calcul distante sur au moins un serveur distant (Serv23 ; Serv23).
[Revendication 5] Méthode selon l’une des revendications précédentes, comprenant une communication du serveur avec au moins un serveur central configuré pour maintenir une structure de droits d’accès de référence.
[Revendication 6] Méthode (Serv4) selon la revendication 1 , ladite méthode étant mise en œuvre par au moins une unité de calcul d’une virtualisation au niveau du système d’exploitation exécutée par un hyperviseur (Hypvsr4), ladite virtualisation au niveau du système d’exploitation étant apte à lire et écrire ladite structure.
[Revendication 7] Méthode selon l’une quelconque des revendications précédentes, dans lequel ladite au moins une ressource est un modèle d’apprentissage machine entraîné avec des données fournies par ledit premier client.
[Revendication 8] Méthode selon la revendication précédente, dans laquelle : la deuxième requête (Rq6) est une requête d’utilisation du modèle d’apprentissage machine (Modi 6) sur des données fournies par le deuxième client ; la méthode comprend : o l’envoi, par ledit serveur, d’un résultat (Res6) de ladite utilisation (UtMod6) du modèle d’apprentissage machine au deuxième client ; o la réception, par ledit serveur, d’un retour (Ret6) dudit deuxième client sur ledit résultat ; o le déclenchement, par ledit serveur :
■ d’une phase d’amélioration dudit modèle à partir dudit retour,
■ et d’une association audit modèle amélioré (Mod26) de droits d’accès accordés par ledit deuxième client.
[Revendication 9] Méthode selon la revendication précédente, comprenant : la réception, par ledit serveur, dudit modèle d’apprentissage machine depuis serveur central (ServCtr6); la fourniture, par ledit serveur, dudit ledit retour au serveur central afin de déclencher ladite phase d’amélioration.
[Revendication 10] Méthode selon l’une quelconque des revendications 1 à 6, dans lequel : l’ensemble de ressources comprend une pluralité de modèles fédérés (ModFed17) d’un jumeau numérique d’un élément (Elt7) monde physique ; la méthode comprend : o à la réception de la deuxième requête (ReqSim7), l’exécution, par le serveur, d’une fédération de simulations (Sim7) dudit élément du monde physique pour tous les modèles fédérés de ladite pluralité pour lesquels le deuxième client dispose des droits d’accès ; o à la réception d’un retour (RetSim27) du deuxième client, le déclenchement, par le serveur, :
■ d’une mise à jour desdits modèles fédérés ;
■ et d’une association audit modèles fédérés mis à jour (ModFed27) de droits d’accès accordés par ledit deuxième client.
[Revendication 11] Méthode selon la revendication précédente, comprenant : la réception, par le serveur, desdits modèles fédérés depuis un serveur central (ServCtr7) ; la fourniture, par le serveur, dudit retour au serveur central afin de déclencher ladite mise à jour des modèles fédérés.
[Revendication 12] Méthode selon l’une quelconque des revendications précédentes, dans lequel ladite structure est une table (Tab8) indiquant, pour chaque paire de client, les droits d’accès accordés par le premier client de la paire au deuxième client de la paire, et du deuxième client de la paire au premier client de la paire, les autorisations appartenant à un groupe comprenant : un droit de création ; un droit de lecture ; un droit de mise à jour ; un droit de suppression.
[Revendication 13] Programme informatique comportant des instructions pour la mise en œuvre du procédé selon la revendication 13 lorsque ce programme est exécuté par un processeur.
[Revendication 14] Dispositif informatique comprenant au moins une unité de calcul configurée pour exécuter une méthode selon l’une des revendications 1 à 12.
[Revendication 15] Serveur (Servi ; Serv2 ; Servi 3 ; Serv4) de gestion d’au moins une ressource d’un ensemble de ressources (Res1 , Res2) fournies par une pluralité de clients (Clt1 , Clt2) comprenant : un accès à un ensemble de ressources (Res1 , Res2) fournies par une pluralité de clients (Clt1 , Clt2) ; un accès à une structure (Struct"!) définissant des droits d’accès pour l’ensemble de ressources; au moins une unité de calcul (Cale) configurée pour : o définir dans ladite structure, à la réception d’une première requête d’un premier client de ladite pluralité de clients, les droits d’accès d’au moins une ressource fournie par ledit premier client; o recevoir une requête d’un deuxième client de ladite pluralité de clients, demandant l’accès à au moins une ressource fournie par le premier client ; o fournir l’accès à ladite au moins une ressource audit deuxième client si les droits d’accès le permettent.
EP24700230.6A 2023-01-09 2024-01-08 Methode et serveur de gestion de droits d'acces a des ressources partagees Pending EP4649395A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2300208A FR3144884A1 (fr) 2023-01-09 2023-01-09 Methode et serveur de gestion de droits d’acces a des ressources partagees
PCT/EP2024/050272 WO2024149701A1 (fr) 2023-01-09 2024-01-08 Methode et serveur de gestion de droits d'acces a des ressources partagees

Publications (1)

Publication Number Publication Date
EP4649395A1 true EP4649395A1 (fr) 2025-11-19

Family

ID=86604121

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24700230.6A Pending EP4649395A1 (fr) 2023-01-09 2024-01-08 Methode et serveur de gestion de droits d'acces a des ressources partagees

Country Status (3)

Country Link
EP (1) EP4649395A1 (fr)
FR (1) FR3144884A1 (fr)
WO (1) WO2024149701A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3851984B1 (fr) * 2020-01-15 2023-12-20 IDENTOS Inc. Des systèmes informatisés d'autorisation distribuée et d'échange fédéré de données sur la confidentialité

Also Published As

Publication number Publication date
WO2024149701A1 (fr) 2024-07-18
FR3144884A1 (fr) 2024-07-12

Similar Documents

Publication Publication Date Title
Solaiman et al. Implementation and evaluation of smart contracts using a hybrid on‐and off‐blockchain architecture
US11861200B2 (en) Data block-based system and methods for predictive models
US20200051069A1 (en) Upgradeable security token
US11870847B2 (en) Decentralized data flow valuation and deployment
US20230080927A1 (en) Database system public trust ledger token creation and exchange
WO2022072862A1 (fr) Système de gestion de données distribué poste à poste (p2p)
US11816069B2 (en) Data deduplication in blockchain platforms
US12095924B2 (en) System and method for generating blockchain token support from a set of declarations
US20240104653A1 (en) Method for digital asset transactions
WO2019106186A1 (fr) Plate-forme de tracabilite securisee de donnees
Drąsutis IOTA smart contracts
Ahmed et al. Big Data Analytics and Cloud Computing: A Beginner's Guide
Waddington et al. Cloud repositories for research data–addressing the needs of researchers
Khan et al. Big data provenance using blockchain for qualitative analytics via machine learning
US10956363B2 (en) Automated data management via machine-readable data definition files
Bhagavan et al. A primer on smart contracts and blockchains for smart cities
Austria Analysis of blockchain-based storage systems
US20210232703A1 (en) Systems and methods for domain-based smart contract execution governance in a dlt network
EP4649395A1 (fr) Methode et serveur de gestion de droits d'acces a des ressources partagees
Di Francesco et al. Kryptosafe: managing and trading data sets using blockchain and IPFS
Hatamian Technological barriers of (non) blockchain enabled IoT data marketplaces
Maxwell Azure Arc Systems Management
US12566747B2 (en) Recursive endorsements for database entries
Teng et al. A smart contract-based service platform for trustworthy crowd funding and crowd innovation
Ghosh Primer on Web3 and Distributed Systems

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250701

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)