METHOD AND SYSTEM FOR MANAGING ACCESS CONTROL FOR MULTIPLE DIGITAL TwININS INTERACTED IN A COMPUTER SIMULATION ENVIRONMENT OVER A

Abstract

The present invention provides a system (100), apparatus (110) and method (400) of a method for managing access control of a digital twin (104-1 to 104-N) interacting in a computer simulation environment over a distributed network. The method includes receiving, by a processing unit (302), a request from a user (608) for accessing a digital twin (102-1 to 102-N) corresponding to one or more assets in a computer simulated environment; identifying entities (104-1 to 104-N) corresponding to the digital twin requested to be accessed by the user based on a unique identifier token associated with the digital twin; sending an approval request to the identified entity of the digital twin; and generating an authorization token upon approving a request from an entity associated with the digital twin, wherein the authorization token includes one or more operating parameters of the digital twin as identified according to the associated unique identifier token of the digital twin.

Description

[0001] This invention generally relates to digital twin systems, and more specifically to a method and system for managing access control of multiple digital twins interacting in a computer-simulated environment via a distributed network.

[0002] Industrial environments encompass multiple machines or assets within automated factories, or interconnected IoT devices. Therefore, industrial environments typically include multiple interconnected components that communicate directly or via networks. An emerging concept complementing rapid industrial development is the "industrial metaverse." The industrial metaverse is a next-generation, fully immersive, 3D collaborative space integrating multiple technological directions such as digital twins, the Internet of Things (IoT), the Industrial Internet, augmented reality, virtual reality, mixed reality, and similar technologies. The metaverse is a virtual universe with shared 3D virtual spaces where users can own, place, and interact with virtual assets. It also allows different users to interact with each other within a collaborative environment. These virtual assets can be simple entities like chairs or tables, or complex entities like industrial machines.

[0003] For this purpose, a typical IIoT (Industrial Internet of Things) solution in the metaverse would involve creating digital twins of one or more assets in an industrial environment. For example, a digital twin can represent a real-world power plant, car, or aircraft, replicating the characteristics and parameters of these real-world entities. Conventional digital twins (DTs) in analog environments are used for only a specific processing equipment component. However, it is recognized that providing DTs with interconnected processing equipment is beneficial for industrial facilities. Therefore, for various processing equipment deployed on a wide variety of infrastructures, multiple different DTs from different equipment vendors are needed. These multiple DTs can be owned by several entities.

[0004] Furthermore, digital twins can be achieved by receiving data via sensors and IoT devices positioned on a real-world twin and then transmitting the data to the digital twin. These sensors can be owned by different entities. For example, suppose we want to test a new machine design composed of previously unexplored components. These components have already been used individually on different machines. The new design can be tested by creating digital twins based on multiple sources. The immediate data sources for the components are free from the different machines owned by different entities. It should be understood that each sensor is essentially an asset owned by its owner.

[0005] Several challenges exist in creating and operating such digital twins in the metaverse. One major challenge is managing ownership of the components of the digital twin. Another major challenge is access control over the different components of the digital twin. Ownership of components needs to be retained by the original owner, and access should only be granted to the requester. Furthermore, the access control mechanism should be easily integrated with existing legacy systems. Additionally, current operational challenges related to digital twins in the metaverse include transferring ownership of a digital twin from one user to another, leasing a digital twin for a limited time, providing access to a digital twin for a limited time according to a defined set of criteria, providing access to a digital twin to multiple users simultaneously, and so on. Currently, no system can address these challenges in the metaverse in a secure and seamlessly interoperable manner.

[0006] In view of the above, there is a need to provide a system and method for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network in a secure and reliable manner.

[0007] Therefore, the object of the present invention is to provide a system and method for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network.

[0008] Throughout this disclosure, the term "industrial environment" can refer to multiple industrial assets that are interconnected to achieve a function. An industrial environment may include industrial assets such as industrial machinery, industrial equipment, industrial controllers, etc.

[0009] Throughout this disclosure, the term "one or more assets" refers to any equipment, system, instrument, or machine manufactured or used in an industry that can be used to perform operations. Examples of assets include any machine in an industrial environment or technical production installation / facility, such as motors, gears, bearings, shafts, switchgear, rotors, circuit breakers, protection devices, remote terminal units, transformers, reactors, disconnecting switches, gear drives, gradient coils, magnets, radio frequency coils, etc. Exemplary technical systems include turbines, large powertrains, magnetic resonance imaging (MRI) scanners, etc. Example facilities / technical production equipment can be complex industrial production setups with multiple assets, such as power plants, wind farms, power grids, manufacturing facilities, refineries, etc.

[0010] Throughout this disclosure, the term "computational simulation environment," as used herein, refers to a three-dimensional (3D) representation of the real or physical world. It can be understood as a virtual world. A computer-simulated environment is accessible to a user; that is, it is accessible from the real / physical world. This includes data exchange between the computer-simulated environment and the real / physical world. Specifically, a computer-simulated environment can be understood as a "metaverse." Interaction with the computer-simulated environment is also possible, i.e., influencing or using processes, components, and / or functions within the computer-simulated environment. Therefore, processes in a computer-simulated environment may have a direct impact on processes in the real / physical world, for example, by virtually modeling and controlling processes.

[0011] For example, a user can access a computer-simulated environment via an interface such as a virtual reality (VR) or augmented reality (AR) interface. The counterpart to the computer-simulated environment does not necessarily have to exist, but can be, for example, a 3D model. Physical forces and phenomena, such as gravity, can also be represented in the computer-simulated environment in a different way than in the real world, such as gravitational acceleration. For the purposes of this invention, the metaverse comprises multiple digital twins corresponding to one or more assets in a real-world industrial environment.

[0012] The metaverse can include multiple computer-simulated components. These computer-simulated components can be understood as representations of real or physical components, particularly in 3D. For example, a component could be a room, building, project, or object. Computer-simulated components can have different functionalities / features, such as access interfaces. Computer-simulated components also include component-specific data that can be retrieved, for example, via the access interface, such as sensor data from a virtual sensor. Access to computer-simulated components can include, for example, the use, modification, and connection to other computer-simulated components. Computer-simulated components can interact with a computer-simulated environment. For the purposes of this invention, computer-simulated components can be a computer-simulated collaborative environment or a digital twin or multiple digital twins within the metaverse.

[0013] The metaverse can be implemented through a managed environment. The managed environment can be implemented, for example, as a cloud environment, an edge cloud environment, and / or on a specific device (e.g., a mobile device).

[0014] Throughout this disclosure, the term "distributed network," as used herein, refers to a network system that provides decentralized control and storage of a ledger at one or more entities (which may be considered "nodes" of the system). The number of "nodes" may be fixed or vary over time, and increasing or decreasing the number of "nodes" may affect the performance and / or security of the system. The ledger copies stored and maintained at each "node" provide cross-verification in the event of conflicts between ledgers, and various cryptographic and / or hashing algorithms can be utilized during the generation, updating, linking, etc., of ledger entries, making the ledger entries more resilient to unauthorized tampering or modification.

[0015] Throughout this disclosure, the term "one or more entities" as used herein refers to the owner of one or more digital twins. One or more entities can be individuals, businesses, organizations(s), institutions(s), manufacturers, service providers, data managers, etc.

[0016] Throughout this disclosure, the term "one or more data sources" as used herein refers to an electronic device that provides data relating to one or more assets in an industrial environment. Non-limiting examples of data sources include sensors, controllers, edge devices, databases, and simulators. In examples, one or more sources can be sensors, such as temperature sensors, velocity sensors, acceleration sensors, pressure sensors, and force sensors. The output from the sensors can be in the form of temperature data, velocity data, acceleration data, or pressure data. In an embodiment, sensor data is obtained via a data acquisition interface. In another example, the data source can be a simulation model configured to predict one or more parameters in the asset. In yet another example, the data source can be a database storing data from sensors, simulation models, and data manually entered by a user. In yet another example, the data source is an input device that enables a user to enter requirements and available data via a web-based interface.

[0017] Throughout this disclosure, the term "digital twin," as used herein, refers to a digital copy of a physical object (e.g., a real machine) created to support data access, command and control, remote configuration, and simulation and analysis. DTs are typically created concurrently with real-world devices and systems, such as processing equipment and sensors in a facility. Once a DT has been created by a particular vendor for their own specific equipment, these DTs can be used to represent the machine as a digital representation of a real-world system. DTs are created such that they are identical to the corresponding machine in form and behavior. DTs can be supported by the vendor's own IIoT infrastructure. Therefore, each DT is associated with one asset and only one asset. Consequently, customers deploying IIoT may deploy many such DTs across a wide variety of infrastructures, as IIoT vendors generally host their solutions on various cloud platforms (e.g., Microsoft's Azure, Amazon's AWS, their own or third-party data centers) and may use a wide variety of open-source and other components to create their digital twin solutions.

[0018] Throughout this disclosure, the term "unique identifier token" as used herein refers to a token or value that uniquely identifies an asset in an industrial environment. In embodiments, the unique identifier token is a nonfungible token or NFT.

[0019] Throughout this disclosure, the term "authorization token" refers to a token or function that implements access control for one or more digital twins in a writing simulation environment. In embodiments, the authorization token is a JSON web-based token or JWT.

[0020] Throughout this disclosure, as used herein, the term "user" refers to any person, avatar, virtual assistant, or any other device or system configured to make requests to a means for managing access control of multiple digital twins.

[0021] The method includes a processing unit receiving a request from a user for accessing one or more digital twins corresponding to one or more assets in a computer simulation environment. Each of the one or more digital twins is tokenized using a unique identifier token. The request includes one or more requirements for simulating one or more scenarios within the one or more digital twins.

[0022] According to an embodiment, a method for tokenizing multiple digital twins in a computer-simulated environment includes identifying one or more components of each of the multiple digital twins, wherein each component is a digital twin coupled to other components of the digital twin. The method for tokenizing multiple digital twins in a computer-simulated environment includes identifying an entity associated with each of the one or more components of the multiple digital twins. The method for tokenizing multiple digital twins in a computer-simulated environment includes assigning a unique identifier token to each of the components of the multiple digital twins. In this document, the unique identifier token includes ownership information of the digital twin.

[0023] According to one embodiment, the unique identifier token is a simple token associated with a single component of the digital twin. According to another embodiment, the unique identifier token is a composite token associated with multiple components of the digital twin, wherein the composite token comprises multiple simple tokens.

[0024] According to an embodiment, one or more components of a digital twin correspond to functional components of a digital twin in the real world, wherein the functional components are components that are indispensable to the asset.

[0025] According to an embodiment, one or more components of a digital twin correspond to non-functional components of a digital twin in the real world, wherein the non-functional components are data sources used to collect real-world behavior of one or more assets.

[0026] The method includes a processing unit identifying one or more entities corresponding to one or more digital twins requested by a user, based on a unique identifier token associated with one or more digital twins.

[0027] According to an embodiment, the method further includes selecting one or more digital twins from a plurality of digital twins required to simulate one or more scenarios, based on one or more requests received from a user.

[0028] The method includes sending an approval request from a processing unit to one or more entities identified by one or more digital twins.

[0029] This method includes generating an authorization token upon approving a request from one or more entities associated with one or more digital twins. In this document, the authorization token includes one or more operational parameters of the digital twin, such as those identified by a unique identifier token associated with the digital twin.

[0030] According to an embodiment, a method for generating an authorization token for a simple token associated with a single component of a digital twin includes initiating an authorization token creation transaction request to the entity identified by the component of the digital twin, and signing the authorization token creation transaction request. The method also includes generating the authorization token upon approval of a request from the owner of the single component of the digital twin.

[0031] According to an embodiment, a method for generating an authorization token for a composite token associated with multiple components of a digital twin includes initiating an authorization token creation transaction request to each of the identified entities of the respective components of the digital twin to sign the authorization token creation transaction request. The method further includes generating the authorization token upon approval of a request from each of the entities corresponding to the respective components of the digital twin.

[0032] According to an embodiment, the method further includes determining the validity of an authorization token based on a ledger comprising the validity status of multiple authorization tokens issued by one or more entities associated with the digital twin. Furthermore, the method includes providing access control to a user for accessing the digital twin based on the validity of the authorization token.

[0033] According to an embodiment, the method further includes providing access control to a user for accessing a digital twin that is subject to one or more operational parameters specified in an authorization token.

[0034] The object of the present invention is also achieved by an apparatus for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network. The apparatus includes one or more processing units and a memory communicatively coupled to the one or more processing units. The memory includes modules stored in the form of machine-readable instructions executable by the one or more processing units. These modules are configured to perform the aforementioned method steps.

[0035] The object of the present invention is also achieved by a system for managing access control of multiple digital twins interacting in a computer-simulated environment via a distributed network. The system includes a distributed network communicatively coupled to the computer-simulated collaborative environment. Herein, the distributed network includes one or more nodes for storing identification information of one or more entities. The system also includes a device as mentioned above. This device is communicatively coupled to the distributed network and the computer-simulated collaborative environment. The device is configured to manage access control of multiple digital twins according to the method steps described above.

[0036] The object of the present invention is also achieved by a computer program product comprising machine-readable instructions that, when executed by one or more processing units, cause one or more processing units to perform the above-described method steps.

[0037] The object of the present invention is also achieved by a computer-readable medium on which a program code segment of a computer program is stored, the program code segment being loadable into and / or executable in a system such that when the program code segment is executed in the system, the system performs the method steps described above. This overview is provided to introduce, in a simplified form, a series of concepts further described below. It is not intended to identify features or essential features of the claimed subject matter. Furthermore, the claimed subject matter is not limited to embodiments that address any or all the disadvantages specified in any part of the invention.

[0038] The invention is further described below with reference to the illustrated embodiments shown in the accompanying drawings, wherein: Figure 1 This is a block diagram of a system for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network, according to an embodiment of the present invention. Figure 2 This is a block diagram of an exemplary distributed ledger according to an embodiment of the present invention, which is implemented for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network; Figure 3 This is a block diagram of an exemplary apparatus for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network, according to an embodiment of the present invention. Figure 4 This is a flowchart depicting the steps of a method for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network, according to an embodiment of the present invention. Figure 5 These are exemplary block diagrams of simple tokens and composite tokens according to embodiments of the present invention; and Figure 6 This is an exemplary system workflow for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network, according to an embodiment of the present invention.

[0039] The embodiments for carrying out the invention are described in detail below. Various embodiments are described with reference to the accompanying drawings, wherein similar reference numerals are always used to refer to similar elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of one or more embodiments. It will be apparent that such embodiments may be practiced without these specific details.

[0040] Figure 1This is a block diagram of a system 100 for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network, according to an embodiment of the present invention. System 100 includes multiple digital twins 102-1 to 102-N, one or more entities 104-1 to 104-N, and means 110 communicating via a communication network 106. Specifically, the multiple digital twins 102-1 to 102-N corresponding to one or more assets (not shown) cooperate in a meta-universe to achieve industrial digital twins. In one embodiment, one or more digital twins 102-1 to 102-N may constitute a portion corresponding to an asset. In another embodiment, one or more digital twins 102-1 to 102-N may constitute one or more data sources providing input data to generate digital twins 102-1 to 102-N. In one example, the one or more data sources may be sensing units associated with one or more assets. In another example, the one or more data sources may be a database including input data for generating digital twins. The data may be real-time data received from one or more data sources.

[0041] In one or more embodiments, one or more entities 104-1 to 104-N refer to the owners of one or more digital twins 102-1 to 102-N. In one example, one or more entities 104-1 to 104-N may be one or more manufacturers or organizations that own one or more digital twins 102-1 to 102-N.

[0042] One or more assets may be associated with a client device (not shown). Non-limiting examples of client devices include personal computers, workstations, personal digital assistants, and human-machine interfaces. The client device enables the owner or operator of one or more assets to view the digital certificates, licenses, access requests, etc., associated with them.

[0043] In one embodiment, apparatus 110 is deployed in a cloud computing environment. As used herein, a “cloud computing environment” refers to a processing environment that includes configurable physical and logical computing resources (e.g., networks, servers, storage devices, applications, services, etc.) and data distributed via network 108 (e.g., the Internet). The cloud computing environment provides on-demand network access to a shared pool of configurable physical and logical computing resources. Apparatus 110 may include modules for managing access control for multiple digital twins 102-1 to 102-N interacting in a computer-simulated collaborative environment via a distributed network.

[0044] Specifically, system 100 includes a cloud computing device configured to provide cloud services and manage access control for multiple digital twins 102-1 to 102-N interacting in a computer-simulated collaborative environment via a distributed network. The cloud computing device includes a cloud communication interface, cloud computing hardware and an operating system (OS), and a cloud computing platform. The cloud computing hardware and OS may include one or more servers on which an operating system (OS) is installed, and include one or more processing units, one or more storage devices for storing data, and other peripheral devices required to provide cloud computing functionality. The cloud computing platform is a platform that implements functions (such as data storage, data analysis, data visualization, and data communication) on the cloud hardware and OS via APIs and algorithms; and delivers the aforementioned cloud services using cloud-based applications.

[0045] In an exemplary embodiment, system 100 is implemented as a distributed ledger, wherein the distributed ledger has nodes. Each node may belong to an entity, and each of the nodes uses cloud computing hardware and an operating system to perform one or more actions in the distributed ledger. Each of the nodes includes a computing device having modules and a database. Figure 2 An exemplary embodiment of this invention is explained in further detail.

[0046] Figure 2 This is a block diagram of an exemplary distributed ledger 200 implemented using a system for managing access control of multiple digital twins 102-1 to 102-N interacting in a computer-simulated collaborative environment via a distributed network, according to embodiments of the present invention. Specifically, one or more distributed ledgers 200 (e.g., a blockchain network) can be provided across one or more entities via network 204. Exemplary entities 202A-N may include a first entity 102 and a second entity 104, parties to a transaction, individual computing devices associated with one or more contracting parties, operators, verification authorities, shared computing resources, smart devices (e.g., smartwatches, tablets, smartphones), etc. Entities 202A-N may store the distributed ledger on a computing system that can be used to maintain and / or update the distributed ledger. Each entity 202A-N may be configured to store a version of the distributed ledger or a portion thereof.

[0047] In some examples, distributed ledger 200 is a blockchain-based ledger where events and transactions are verified in a decentralized manner by network participants and recorded on all participant nodes. Each node is identified by its address, which is derived from its public-private key pair. All data is recorded on the blockchain and is accessible to all participants. This information is immutable and therefore provides accountability and audit trails.

[0048] A blockchain network (implemented via a distributed consensus mechanism) ensures that no single entity can control the network, and that the network will function fairly and justly as long as the majority of participants are honest. Blockchain also supports smart contracts, which allow business logic to be encoded in the form of deterministic computer programs. These programs execute in isolated, secure environments across all nodes and are verified in a distributed manner.

[0049] In some embodiments, entities 202A-N include a collection of at least computing devices 206A-N. For example, the ledger may be stored on a large number of publicly available devices, each device acting as a "node" for storing a copy of the ledger (e.g., collaboratively maintained by anonymous peers on a network). In some embodiments, the ledger is stored and maintained only on a set of trusted "nodes" (such as the computing systems of authorized users). In some embodiments, a combination and / or "hybrid" of both trusted and public nodes may be utilized to apply the same and / or different rules to activities performed at each node (e.g., different authentication processes may be used for untrusted nodes, or simply untrusted nodes may be unable to perform certain activities). In some embodiments, nodes with different characteristics and applied business logic may exist at different levels.

[0050] Ledgers, ledger entries, and / or the information stored on ledger entries can be used for asset information, contract information, contracting party information, operator information, and so on. Furthermore, ledgers can store digital certificates generated by first and second entities, operational requirements for assets, transactions involving different entities, automated "smart contracts" related to asset control, and so on. Smart contracts are computer instructions or code designed to facilitate, verify, or enforce the negotiation or execution of contracts. Additionally, ledgers and ledger entries can utilize cryptographic techniques to facilitate and / or verify digital signatures, for example, facilitating multi-signature documents and ensuring the authenticity and integrity of assets, operators, etc.

[0051] Each of one or more entities 202A-N may have versions of the ledger at different times, and the ledger can be maintained through the propagation of entries and / or updates across ledger copies. Ledger entries may contain informational elements (e.g., transaction records, document content, contract terms, version information). Various rules and / or logic may be involved in activities involving ledger entries (e.g., creation, updating, confirmation), such as an absolute majority or unanimous agreement among entities being enforced as a condition of activities involving entries. In some embodiments, a distributed ledger is utilized, and ledger entries are adapted to have various links to each other, such that the integrity of ledger entries can be strengthened and / or confirmed.

[0052] Ledgers can be maintained through, for example, a "distributed network system," which provides decentralized control and storage of the ledger at one or more entities (which can be considered "nodes" of the system). The number of "nodes" can be fixed or vary over time, and increasing or decreasing the number of "nodes" may affect the system's performance and / or security. The ledger copies stored and maintained at each "node" provide cross-verification in the event of conflicts between ledger entries, and various cryptographic and / or hashing algorithms can be used during the generation, updating, and linking of ledger entries, making the ledger entries more resilient to unauthorized tampering or modification.

[0053] For example, a distributed ledger can be distributed across entities 202A-N and used to securely provide control over assets to other assets, operators, or other entities. A distributed ledger can have entries linked together using cryptographic asset information, contractor information, and operator information, and entries in the blockchain can be ordered, timestamped, and / or associated with metadata, making the blockchain designed to protect it from “double-crossing” and unauthorized modification of ledger entries, such as policy violations.

[0054] In some embodiments, each block includes a unique identifier associated with one or more entities 202A-202N and corresponding transaction data. The block also includes a timestamp indicating when it was created. If there are more than one block in the blockchain, each block other than the first block also includes the hash of the previous block in the blockchain.

[0055] Figure 3 This is a block diagram of an exemplary device 110 according to an embodiment of the present invention, which is used to improve access control management of multiple digital twins 102-1 to 102-N interacting in a computer-simulated collaborative environment via a distributed network. Device 110 may also be associated with different nodes in a distributed ledger to generate a decentralized network of one or more entities 104-1 to 104-N in an industrial environment. In an exemplary embodiment, device 110 is communicatively coupled to one or more digital twins 102-1 to 102-N and corresponding one or more entities 104-1 to 104-N in a computer-simulated collaborative environment. In another exemplary embodiment specific to a blockchain network, device 110 is associated with nodes 202A-N. Figure 2 The computing device 206A-N is integrated.

[0056] Device 110 may be a personal computer, laptop computer, tablet computer, server, virtual machine, etc. Device 110 includes a processing unit 302, a memory 304 including module 306, a storage unit 318 including database 320, an input unit 322, an output unit 324, and a bus 326.

[0057] As used herein, processing unit 302 refers to any type of computing circuit, such as, but not limited to, a microprocessor, microcontroller, complex instruction set computing microprocessor, reduced instruction set computing microprocessor, very long instruction word microprocessor, explicit parallel instruction computing microprocessor, graphics processor, digital signal processor, or any other type of processing circuit. Processing unit 302 may also include embedded controllers, such as general-purpose or programmable logic devices or arrays, application-specific integrated circuits, single-chip computers, etc.

[0058] Memory 304 may be non-transitory volatile memory and / or non-volatile memory. Memory 304 may be coupled for communication with processing unit 302, such as as a computer-readable storage medium. Processing unit 302 may execute instructions and / or code stored in memory 304. Various computer-readable instructions may be stored in and accessible from memory 304. Memory 304 may include any suitable elements for storing data and machine-readable instructions, such as read-only memory, random access memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, hard disk drive, removable media drive for processing optical discs, digital video discs, floppy disks, magnetic tape cartridges, memory cards, etc.

[0059] In this embodiment, the memory 304 includes a module 306 stored in the form of machine-readable instructions on any of the storage media mentioned above, and is communicable with and executed by the processing unit 302. When the machine-readable instructions are executed by the processing unit 302, the module 306 causes the processing unit 302 to verify ownership of the digital twin and, upon request, provide access control to the digital twin with the approval of the owner of the digital twin.

[0060] Module 306 also includes a tokenization module 308, a digital twin selection module 310, an ownership identification module 312, an access request creation module 314, and an authorization module 316.

[0061] Tokenization module 308 is configured to tokenize multiple digital twins 102-1 to 102-N in an industrial environment. Tokenization module 308 is configured to identify one or more components of each of the multiple digital twins. Each component is a digital twin communicatively coupled to other components of that digital twin. Furthermore, tokenization module 308 includes identifying an entity associated with each of the multiple digital twins based on ownership information stored in a distributed ledger. Additionally, tokenization module 308 is configured to assign a unique identifier token to each of the multiple digital twin components. Herein, the unique identifier token includes ownership information of the digital twin. Furthermore, tokenization module 308 is configured to create simple tokens for a single component of the digital twin. Furthermore, tokenization module 308 is configured to create composite tokens for multiple components of the digital twin.

[0062] The digital twin selection module 310 receives a request from a user for accessing one or more digital twins corresponding to one or more assets in a computer simulation environment. The request includes one or more requirements for simulating one or more scenarios within the one or more digital twins. It should be understood that the tokenization details of the one or more digital twins are received from the tokenization module 310. Therefore, the digital twin selection module 310 is configured to select one or more digital twins from a plurality of digital twins required for simulating one or more scenarios based on the one or more requirements received from the user.

[0063] Ownership identification module 312 is configured to determine one or more entities 104-1 to 104-N corresponding to one or more digital twins 102-1 to 102-N based on a unique identifier token associated with one or more digital twins 102-1 to 102-N. The one or more entities 104-1 to 104-N are one of the digital twins or their owners that the user requests to access. Ownership identification module 312 is configured to determine a single owner in the case of a simple token. Furthermore, ownership identification module 312 is configured to determine multiple owners in the case of a composite token.

[0064] The access request creation module 314 is configured to create an approval request and send the approval request to one or more entities 104-1 to 104-N of one or more digital twins 102-1 to 102-N. The approval request includes user information and one or more requirements for accessing a specific digital twin.

[0065] Authorization module 316 is configured to generate an authorization token upon approving a request from one or more entities 104-1 to 104-N associated with one or more digital twins 102-1 to 102-N. The authorization token includes one or more operational parameters of the digital twin, as identified by an associated unique identifier token of the digital twin. For a simple token, authorization module 316 is configured to initiate an authorization token creation transaction request to the identified entity of the digital twin component, sign the authorization token creation transaction request, and then generate an authorization token upon approving a request from the owner of a single component of the digital twin. For a composite token, authorization module 316 is configured to initiate an authorization token creation transaction request to each of the identified entities of the corresponding components of the digital twin, sign the authorization token creation transaction request, and generate an authorization token upon approving a request from each of the entities corresponding to the corresponding components of the digital twin.

[0066] Processing unit 302 is configured to perform all the functions of module 306. Processing unit 302 is configured to receive a request from a user for access to one or more digital twins 102-1 to 102-N corresponding to one or more assets in a computer simulation environment. Each of the one or more digital twins 102-1 to 102-N is tokenized using a unique identifier token. The request includes one or more requirements for simulating one or more scenarios of one or more digital twins 102-1 to 102-N. Processing unit 302 is configured to identify one or more entities 104-1 to 104-N corresponding to the one or more digital twins 102-1 to 102-N requested by the user, based on the unique identifier token associated with the one or more digital twins 102-1 to 102-N. Processing unit 302 is configured to send an approval request to the identified one or more entities 104-1 to 104-N of the one or more digital twins 102-1 to 102-N. Processing unit 302 is configured to generate an authorization token when approving a request from one or more entities associated with one or more digital twins 102-1 to 102-N, wherein the authorization token includes one or more operational parameters of the digital twin, such as those identified by an associated unique identifier token of the digital twin.

[0067] Storage unit 318 includes database 320, which is used to store digital certificates, authorization requests, operator-related data, and so on. Storage unit 318 and / or database 320 can be provided using various types of storage technologies (such as solid-state drives, hard disk drives, flash memory) and can be stored in various formats (such as relational databases, non-relational databases, flat files, spreadsheets, and extended tag files).

[0068] Input unit 322 may provide a port to receive input from input devices such as a keyboard, touch-sensitive display, or camera (e.g., a camera that receives gesture-based input) capable of receiving a set of digital signals from the digital twin in an industrial environment. Display unit 324 may provide a port to output data via an output device having a graphical user interface for displaying multiple digital twins in a computer-simulated virtual environment. Bus 326 serves as an interconnect between processing unit 302, memory 304, storage unit 318, input unit 322, and display unit 324.

[0069] What those skilled in the art will understand is that Figure 3 The hardware depicted may vary for specific implementations. For example, other peripheral devices, such as optical disc drives and the like, local area network (LAN) / wide area network (WAN) / wireless (e.g., Wi-Fi) adapters, graphics adapters, disk controllers, and input / output (I / O) adapters, may be used in addition to or in lieu of the hardware depicted. The examples depicted are provided for illustrative purposes only and are not intended to imply any architectural limitations with respect to this disclosure.

[0070] Figure 4 This is a flowchart depicting the steps of method 400 according to an embodiment of the present invention, method 400 for managing access control of multiple digital twins 102-1 to 102-N interacting in a computer-simulated collaborative environment via a distributed network. Digital twins 102-1 to 102-N may correspond to real-world objects in an industrial environment, such as one or more assets, including but not limited to motors, gears, bearings, shafts, switchgear, rotors, circuit breakers, protection devices, remote terminal units, transformers, reactors, disconnect switches, gear drives, gradient coils, magnets, radio frequency coils, etc. Exemplary technical systems include turbines, large transmission systems, magnetic resonance imaging (MRI) scanners, etc. In one embodiment, one or more digital twins 102-1 to 102-N are assets such as motors. In another embodiment, one or more digital twins 102-1 to 102-N are components of assets such as power supplies, field magnets, rotors, commutators, brushes, axles, etc.

[0071] In yet another embodiment, one or more digital twins 102-1 to 102-N constitute multiple assets, such as a motor fleet in a factory workshop.

[0072] In yet another embodiment, one or more digital twins 102-1 to 102-N constitute one or more data sources that provide data for simulating one or more digital twins 102-1 to 102-N. Non-limiting examples of data sources include sensors, controllers, edge devices, databases, and simulators. In this particular example, the one or more digital twins can be sensors, such as temperature sensors, velocity sensors, acceleration sensors, pressure sensors, and force sensors. The output from the sensors can be in the form of temperature data, velocity data, acceleration data, or pressure data. In this embodiment, sensor data is obtained through a data acquisition interface. In another example, the data source can be a simulation model configured to predict one or more parameters in the asset. In yet another example, the data source can be a database storing data from sensors, simulation models, and data manually entered by the user. In yet another example, the data source is an input device that enables users to enter requirements and available data through a web-based interface.

[0073] Digital twins are typically generated simultaneously with real-world devices and systems, such as processing equipment and sensors in a facility. Once created by a specific vendor for their own specific equipment, a digital twin can be used to represent assets as a digital representation of a real-world system. The digital twin is created to be identical to the corresponding machine in form and behavior. Therefore, the generated digital twin can be a dynamic virtual copy based on one or more of the following: physically based models, computer-aided design (CAD) models, computer-aided engineering (CAE) models, one-dimensional (1D) models, two-dimensional (2D) models, three-dimensional (3D) models, finite element (FE) models, descriptive models, meta-models, stochastic models, parametric models, reduced-order models, statistical models, heuristic models, predictive models, aging models, machine learning models, artificial intelligence models, deep learning models, system models, knowledge graphs, and so on.

[0074] Multiple digital twins 102-1 to 102-N can correspond to one or more assets in an industrial environment. These digital twins 102-1 to 102-N interact collaboratively within a metaverse to achieve higher levels of digital twins. In one example, one or more digital twins 102-1 to 102-N corresponding to one or more components of an asset interact at a first layer to generate an equipment-level digital twin. In another example, one or more equipment-level digital twins 102-1 to 102-N interact collaboratively to generate a factory-level digital twin. In yet another example, one or more factory-level digital twins 102-1 to 102-N interact to form an industrial environment-level digital twin.

[0075] Multiple digital twins 102-1 to 102-N can be visualized in a computer-simulated virtual environment (e.g., in a metaverse). This can be understood as a virtual world within an industrial environment, where multiple digital twins 102-1 to 102-N interact with each other. Such digital twins 102-1 to 102-N are particularly accessible to users, meaning they are easily accessible from the real / physical world. For example, users can access multiple digital twins 102-1 to 102-N in the metaverse via an interface (e.g., a virtual reality (VR) or augmented reality (AR) interface). The counterparts in the computer-simulated environment do not necessarily have to exist, but can be, for example, three-dimensional models of assets in an industrial environment.

[0076] In this invention, the metaverse includes multiple digital twins 102-1 to 102-N. Digital twins 102-1 to 102-N can be understood, for example, as representations of real or physical components (such as one or more assets), particularly in 3D. Each component of the digital twin may have different functions / features, such as access interfaces. Digital twins 102-1 to 102-N also include asset-specific data, such as sensor data from a virtual accelerometer that can be retrieved, for example, via the access interface. Access to digital twins 102-1 to 102-N may include, for example, the use, modification, and connection to other digital twins 102-1 to 102-N. Digital twins 102-1 to 102-N can interact with the metaverse and other components within the metaverse.

[0077] At step 402, a request from a user is received for accessing one or more digital twins 102-1 to 102-N within a computer simulation environment. This request includes one or more requirements for simulating one or more scenarios from among the one or more digital twins 102-1 to 102-N. The user can issue the request within the metaverse to access a single digital twin or multiple digital twins 102-1 to 102-N in order to simulate avatars of one or more scenarios within the digital twins as required. The one or more requirements may include simulation scenario type, one or more simulation parameters, one or more simulation conditions, etc.

[0078] According to an embodiment, the method further includes selecting one or more digital twins 102-1 to 102-N from a plurality of digital twins 102-1 to 102-N required to simulate one or more scenarios based on one or more requirements. The one or more requirements are matched against the functionality and simulation of the plurality of digital twins 102-1 to 102-N to select one or more digital twins 102-1 to 102-N required to simulate one or more scenarios requested by a user or avatar. In an example, the user or avatar may request to simulate the remaining service life of a particular motor using a specific set of operating parameters of the motor. Each component of the motor, along with one or more sensors, is then selected for further processing.

[0079] It is noteworthy that each of the one or more digital twins is tokenized using a unique identifier token. The term "tokenization" is known in the field of blockchain technology. However, identifying and tokenizing each component of a digital twin based on ownership of the digital twin is within the scope of the current invention.

[0080] In embodiments, the unique identifier token is a non-fungible token. Throughout this disclosure, the term "non-fungible token or NFT" refers to a unit of data stored on a digital ledger, such as a blockchain, which proves that any digital file is unique. An NFT functions similarly to a cryptographic token but differs from cryptocurrencies (such as Bitcoin) in that it is not interchangeable; in other words, it is not fungible. An NFT is created when a blockchain strings records of cryptographic hashes (a set of characters whose verification data set is unique) onto previous records, thereby creating an identifiable block of data. This cryptographic transaction process ensures the authentication of each digital file by providing a digital signature used to track ownership of the NFT. NFTs can be used to represent items such as photos, videos, audio, and other types of digital files. While anyone can obtain a copy of these digital items, NFTs are tracked on the blockchain to provide the owner with proof of ownership separate from copyright.

[0081] According to an embodiment, a method for tokenizing multiple digital twins 102-1 to 102-N in a computer-simulated environment includes identifying one or more components of each of the multiple digital twins 102-1 to 102-N. Herein, each component is a digital twin communicatively coupled to other components of the digital twin. The method also includes identifying an entity associated with each of the one or more components of the multiple digital twins 102-1 to 102-N. In other words, ownership of each of the one or more components of the digital twins is identified based on details stored in a distributed ledger. The method also includes assigning a unique identifier token to each of the components of the multiple digital twins 102-1 to 102-N. Herein, the unique identifier token includes ownership information of the digital twin.

[0082] According to an embodiment, a unique identifier token is a simple token associated with a single component of a digital twin. A simple token is an individual token assigned to a single component of the digital twin, and the simple token corresponds to a single entity of owner. It should be understood that the simple token is assigned to the digital twin corresponding to the real-world portion of an asset that cannot be further broken down into another component. According to another embodiment, a unique identifier token is a composite token associated with multiple components of digital twins 102-1 to 102-N. In this document, a composite token includes multiple simple tokens. It should be understood that a composite token can be owned by multiple entities or owners because it is a combination of multiple simple tokens. The concepts of simple tokens and composite tokens are explained in... Figure 5 Further explanation is provided below. (See reference) Figure 5 The illustration shows an exemplary block diagram 500 of simple and composite tokens according to an embodiment of the present invention. Block 502 is a composite token corresponding to a factory digital twin token. Furthermore, the factory digital twin token 502 also includes a CNC machine digital twin token 504, which is also a composite token. Additionally, the CNC machine digital twin token 504 includes a spindle digital twin token 506, a servo motor digital twin token 508, and a ball screw digital twin token 510. It should be noted that the spindle digital twin token 506, the servo motor digital twin token 508, and the ball screw digital twin token 510 are also composite tokens. The spindle digital twin token 506 also includes a first sensor token 512A, a second sensor token 512B, a third sensor token 512C, and a fourth sensor token 512D. It should be noted that the first sensor token 512A, the second sensor token 512B, the third sensor token 512C, and the fourth sensor token 512D are simple tokens. Furthermore, the servo motor digital twin token 508 includes a fifth sensor token 514A and a sixth sensor token 514B. It should be noted that the fifth sensor token 514A and the sixth sensor token 514B are simple tokens. Additionally, the ball screw digital twin token 510 also includes a seventh sensor token 516A and an eighth sensor token 516B. It should be noted that the seventh sensor token 516A and the eighth sensor token 516B are simple tokens. It should be understood that the different components shown herein are for illustrative purposes only. The scope of the present invention is not limited to the number of digital twins, the type of assets, or the number of tokens therein.

[0083] According to an embodiment, one or more components of digital twins 102-1 to 102-N correspond to functional components of a digital twin in the real world, wherein the functional components are components indispensable to the asset. The functional components of digital twins 102-1 to 102-N are parts of the asset that are indispensable to the digital twin and are operated to have functionality in the digital twin. For example, in a CNC machine digital twin, the functional components are spindle digital twins, wheel axle digital twins, servo motor digital twins, ball screw digital twins, etc. One or more functional components may be owned by one or more entities 104-1 to 104-N. In the example, an entity is the individual digital twin owner of a specific digital twin (such as a digital twin of a motor, a digital twin of a turbine, a digital twin of a CNC machine, etc.). In another example, an entity is an organization or institution that owns digital twins for various assets in an industry, such as Siemens, which provides digital twins for various assets in a factory floor. In another example, the entity is a manufacturer of digital twins (such as sensors installed in industry) and has the authority to own and provide data to third parties. In yet another example, the entity is a service provider authorized to collect data and provide it to third parties for further processing and use.

[0084] According to embodiments, one or more components of digital twins 102-1 to 102-N correspond to non-functional components of the digital twin in the real world. A non-functional component is a data source used to collect real-world behavior data of one or more assets. A non-functional component is a component that may or may not be an integral part of the digital twin and provides input data relating to the behavior of one or more functional components of the asset. For example, some non-functional components may be sensors that provide the digital twin with data relating to the component behavior of the asset. In one example, an entity is an individual data provider for a specific part of the digital twin, such as a temperature sensor. In another example, an entity is an organization or institution that owns an industry and provides data on various assets within that industry. In yet another example, the entity is a manufacturer of a data source (such as sensors installed in an industry) and has the authority to own the data and provide it to third parties. In yet another example, the entity is a service provider authorized to collect data and provide it to third parties for further processing and use.

[0085] At step 404, one or more entities corresponding to the one or more digital twins 102-1 to 102-N requested by the user are identified based on a unique identifier token associated with one or more digital twins 102-1 to 102-N. One or more entities 104-1 to 104-N are the owners of the digital twins 102-1 to 102-N, and have ownership and control over access to and functionality of the digital twins. One or more entities can be identified based on the unique identifier token of the requested digital twin.

[0086] At step 406, an approval request is sent to one or more entities 104-1 to 104-N identified by one or more digital twins 102-1 to 102-N. The approval request includes information about the user's usage and one or more requests. For simple tokens, an authorization token creation request is created and sent to a single owner of the digital twin component for signing the authorization token. For composite tokens, an authorization token creation request is created and sent to multiple owners of different components of the digital twin for signing the authorization token individually.

[0087] At step 408, an authorization token is generated upon approval of a request from one or more entities 104-1 to 104-N associated with one or more digital twins 102-1 to 102-N. In this document, the authorization token includes one or more operational parameters of the digital twin, as identified by a unique identifier token associated with the digital twin. It will be understood that when an authorization token is generated by the owner of digital twins 102-1 to 102-N, the authorization token not only provides access control to the user but also ensures that the execution of the digital twin is within the operational parameters specified by the owner.

[0088] In this embodiment, the authorization token is a JSON Web Token (JWT). It's important to understand that a JSON Web Token, or JWT, is an open standard that defines a compact and self-contained way to securely transmit information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. A JSON Web Token consists of three parts: a header, a payload, and a signature. The header typically consists of two parts: the type of token (JWT in this context) and the hash algorithm used, such as HMAC, SHA256, or RSA. The second part of the token is the payload, which contains claims. Claims are statements about the entity (in this context, the owner of the digital twin) and additional metadata. There are three types of claims: reserved claims, public claims, and private claims. Reserved claims are a predefined set of claims that are not mandatory but rather advisory, providing a useful and interoperable set of claims. Some of the reserved claims are: iss (issuer), exp (expiration date), sub (subject), aud (audience), and others. Those using JWTs can define public claims as they wish. Private claims are custom claims created to share information among parties who agree to use them in a consistent manner. The third part of a JWT is the signature. To create the signature section, the encoded header, the encoded payload, the algorithm specified in the header, and the signature must be taken and signed. The signature is used to verify that the sender of the JWT is the one it claims to be and to ensure that the message is not altered along the way.

[0089] Specifically, for JWT authorization, when a user successfully logs in using their credentials, a JSON web token is returned, and this JSON web token must be stored locally, rather than the traditional method of creating a session on the server. This is a stateless authorization mechanism because user state is never stored in server storage. The server's protected route will check for a valid JWT in the authorization header, and if a valid JWT exists, the user will be allowed access to the protected resources. Because the JWT is self-contained, all the necessary information is there, reducing the need for multiple database queries.

[0090] According to an embodiment, a method for generating an authorization token for a simple token associated with a single component of a digital twin includes initiating an authorization token creation transaction request to the entity identified by the component of the digital twin, for signing the authorization token creation transaction request. The authorization token generation request is generated based on one or more requests received from a user. The authorization token request is sent to the owner of the digital twin who has requested access according to one or more requests. Furthermore, the method includes generating the authorization token upon approving the request from the owner of the single component of the digital twin. Notably, if the owner of the digital twin approves the access request, the authorization token is signed by that owner. Additionally, the authorization token is attached with one or more operational parameters to be performed simultaneously in one or more scenarios within the simulated digital twin.

[0091] According to an embodiment, a method for generating an authorization token for a composite token associated with multiple components of digital twins 102-1 to 102-N includes initiating an authorization token creation transaction request to each of the identified entities 104-1 to 104-N of the corresponding components of the digital twins, for signing the authorization token creation transaction request. The authorization token generation request is generated based on one or more requests received from a user. The authorization token request is sent to the corresponding owner of one or more components of the digital twins that have requested access according to one or more requests. Furthermore, the method includes generating the authorization token upon approval of a request from each of the entities corresponding to the corresponding components of the digital twins. Notably, if the owner approves the access request, the authorization token is signed by the corresponding owner of one or more components of digital twins 102-1 to 102-N. Additionally, the authorization token is appended with one or more operational parameters to be performed while simulating one or more scenarios in digital twins 102-1 to 102-N.

[0092] According to an embodiment, the method further includes providing access control to a user for accessing a digital twin subject to one or more operational parameters specified in an authorization token. It should be understood that each digital twin 102-1 to 102-N has operational restrictions or thresholds to be considered when accessing the digital twin. Therefore, digital twins 102-1 to 102-N must only be accessed within the permitted operational parameters. In this case, when providing access control to a user, the system must ensure that operations performed on the digital twin by a specific user or avatar are within the allowed operational parameters.

[0093] According to an embodiment, the method further includes determining the validity of an authorization token based on a ledger comprising the validity status of multiple authorization tokens issued by one or more entities associated with the digital twin. The method also includes providing access control to a user for accessing digital twins 102-1 to 102-N based on the validity of the authorization token. It should be understood that the validity of the authorization token is verified before any simulation is initiated in the digital twin to ensure that access that has not been revoked can continue into the system.

[0094] refer to Figure 6 The illustration depicts an exemplary system workflow 600 for managing access control of multiple digital twins interacting in a computer-simulated environment via a distributed network, according to an embodiment of the present invention. System 600 includes a simulator service platform 602, a computer-simulated environment or metaverse 604 hosting multiple digital twins, a distributed network 606 having ownership information for the multiple digital twins, and a user or avatar 608. The simulator service platform 602 is configured to manage access control of multiple digital twins 102-1 to 102-N interacting in the computer-simulated environment via the distributed network. The metaverse 604 hosts multiple digital twins having one or more components, which are tokenized as simple tokens and composite tokens in the form of NFTs. The distributed network 606 includes ownership information for the multiple digital twins and stores such data in a distributed ledger. In an exemplary embodiment, user 608 utilizes a request to access simulator service platform 602 to obtain access control to one or more digital twins in the metaverse based on one or more requests.

[0095] In this paper, JSON web tokens, or JWTs, are used for access control management of digital twins 102-1 to 102-N. Because JWTs are compatible with the OAuth authorization protocol widely used in prevalent systems, they can be easily integrated with existing systems. The JWT tokens in the proposed system have the following properties: 1. Each JWT token is linked to a digital twin represented by an NFT / capture access control to the digital twin represented by an NFT.

[0096] 2. JWT tokens can only be created with the approval of one or more owners of the corresponding NFT (who are also the owners of the asset).

[0097] 3. The purpose of an NFT is encoded within its form or operational parameters (e.g., the owner of a power plant DT might want to grant access to the DT only for simulating specific non-catastrophic scenarios).

[0098] It's important to note that a JWT token for a simple entity (with only a single Data Token) can be created by the NFT's owner and includes the owner's signature. However, a JWT token for a composite entity (with multiple Data Tokens) will carry the signatures of all owners of all the encompassing entities (together they constitute a composite token). This is achieved using multisignature or multisig transactions. (JWT / JWS inherently support multisignature, and the creation of multiple signatures is managed through voting and ledger on a distributed network). In the example, to grant approval, one of the owners creates a JWT token, signs the JWT token, and propagates the JWT token across the network in the transaction. The transaction (and the JWT token) await the required number of signatures (this could be m out of n, or n out of n). Upon approval, the signed JWT token is issued to the requester.

[0099] It is worth noting that the issueJWT() function takes the following additional parameters: parentTokenID — The existing token ID for NFT operations operatingParameters — Operating parameters that can be understood by the user application (the simulator service in the illustrated scenario).

[0100] The simulator service platform 602 can use JWTs, only for the specific purpose mentioned in the specified parameters of the JWT token (e.g., one or more operational conditions). Before creating the JWT token, the function verifies that the NFT owner is the caller. For composite tokens, an approval request is sent to the owner of the component NFT. A separate revocation list is maintained, listing JWT tokens revoked by one or more owners. User applications can refer to this list before starting a new workflow. The user application (in the illustrated case, simulator service platform 602) uses a valid token for interacting with the digital twin, and the digital twin environment enforces the restrictions specified in the token.

[0101] In one example, when simulator service platform 602 issues a service request (1) on behalf of user 608 to access a simple token "T", a JWT token creation transaction (2) with all details is then sent to owner "O" for signing via distributed network 606. Upon approval (3), a JWT token (4) with a list of operational parameters is created and assigned to user 608. Once simulator service platform 602 receives the JWT token (4), it issues a simulation task request (5) to the computer-simulated environment or metaverse 604. While verifying the validity of the JWT token, the metaverse runs the simulation according to one or more requests from user 608 and returns the simulation results (6) to simulator service platform 602. Furthermore, the simulation results are re-provided (7) to user 608 via simulator service platform 602. User 608 can then access the asset (digital twin) using the valid token T within the restrictions (encoded as parameters within the JWT token).

[0102] In another example, when simulator service platform 602 requests access to composite token T on behalf of user 608, a JWT token is created and propagated to all owners "O" of the token for signing. The JWT is assigned to user 608 only if all owners "O" sign. User 608 can then use the composite asset (composite digital twin) with the valid token T defined within the parameters defined in the JWT token.

[0103] Advantageously, the present invention provides a decentralized, secure, and efficient system for managing access control of multiple digital twins 102-1 to 102-N interacting in a computer simulation environment via a distributed network. Advantageously, the above-described method and system ensure digital rights management for multiple digital twins 102-1 to 102-N in an industrial environment. The present invention ensures that ownership of multiple digital twins 102-1 to 102-N is retained by the corresponding entities 104-1 to 104-N; ​​however, access control is simultaneously transferred to multiple users in a collaborative environment. Advantageously, the present invention manages controlled access to multiple digital twins 102-1 to 102-N for multiple users over varying time periods. Furthermore, the present invention achieves seamless interoperability with existing systems, thus making the solution easy to integrate with existing systems. Advantageously, even when different components of the digital twins may be owned by different entities, the present invention ensures that users are provided with secure and rapid access to individual components of the digital twins 102-1 to 102-N according to the requirements of the simulation. This invention is beneficial for combining multiple digital twins 102-1 to 102-N for complex use cases in a decentralized manner, while ensuring that ownership of the digital twins is retained. This invention also helps increase customer value when using the combined digital twins to provide value-added services to third parties in metaverse applications.

[0104] Advantageously, compared to the operability of digital twins in the metaverse, the present invention can have various applications, such as transferring ownership of a digital twin from one user to another, leasing a digital twin for a limited time period, providing access to a digital twin for a limited time period according to a defined criterion, providing access to a digital twin to multiple users simultaneously, and so on.

[0105] Those skilled in the art will recognize that, unless specifically indicated or required by the sequence of operations, certain steps in the process described above may be omitted, performed concurrently or sequentially, or performed in a different order.

[0106] While the invention has been described in detail with reference to certain embodiments, it should be understood that this disclosure is not limited to these embodiments. The foregoing examples are provided for illustrative purposes only and should not be construed as limiting the invention disclosed herein. Although the invention has been described with reference to various embodiments, it should be understood that the terms used herein are descriptive and illustrative, not restrictive. Furthermore, although the invention has been described herein with reference to specific means, materials, and embodiments, the invention is not intended to be limited to the specific contents disclosed herein; rather, the invention extends to all functionally equivalent structures, methods, and uses, such as those within the scope of the appended claims. Many modifications can be made to this invention by those skilled in the art, and changes can be made in various aspects thereto without departing from the scope of the invention, thanks to the teachings of this specification.

[0107] List of reference numerals 100 System Multiple digital twins from 102-1 to 102-N One or more entities from 104-1 to 104-N 106 Communication Network 110 device 200 Distributed Ledger 202A-N One or more entities 204 Network 206A-N One or more computing devices 302 One or more processing units 304 memory cell Module 306 308 Tokenization Module 310 Digital Twin Selection Module 312 Ownership Identification Module 314 Access Request Creation Module 316 Authorization Module 318 storage units 320 Database 322 Input Unit 324 output units 326 bus 400. A flowchart depicting the steps of a method for managing access control of multiple digital twins interacting in a computer-simulated collaborative environment via a distributed network. Exemplary block diagram of 500 simple tokens and composite tokens 600 An exemplary system workflow for managing access control of multiple digital twins interacting in a computer simulation environment via a distributed network.

Claims

1. A computer-implemented method (400) for managing access control of a plurality of digital twins (102-1 to 102-N) interacting in a computer simulation environment over a distributed network, the method comprising: receiving, by a processing unit (302), a request from a user (608) to access one or more digital twins (102-1 to 102-N) corresponding to one or more assets in the computer simulation environment, wherein each of the one or more digital twins (102-1 to 102-N) is tokenized using a unique identifier token, and wherein the request includes one or more requirements for simulating one or more scenarios in the one or more digital twins; identifying, by the processing unit (302), one or more entities (104-1 to 104-N) corresponding to the one or more digital twins (102-1 to 102-N) requested for access by the user based on the unique identifier token associated with the one or more digital twins; sending, by the processing unit (302), an approval request to the identified one or more entities (104-1 to 104-N) of the one or more digital twins (102-1 to 102-N); and generating, by the processing unit (302), an authorization token upon approval of the request from the one or more entities (104-1 to 104-N) associated with the one or more digital twins (102-1 to 102-N), wherein the authorization token includes one or more operational parameters of the digital twins (102-1 to 102-N) as identified from the associated unique identifier token of the digital twins.

2. The method (400) of claim 1, further comprising selecting one or more digital twins from a plurality of digital twins (102-1 to 102-N) required for simulating one or more scenarios based on the one or more requirements received from the user (608).

3. The method (400) of any one of claims 1 or 2, further comprising providing access control to the user (608) for accessing the digital twins (102-1 to 102-N) restricted to the one or more operational parameters specified in the authorization token.

4. The method (400) of any one of the preceding claims, wherein tokenizing the plurality of digital twins (102-1 to 102-N) in the computer simulation environment comprises: determining, by the processing unit (302), one or more components of each of the plurality of digital twins (102-1 to 102-N), wherein each component is a digital twin communicatively coupled to other components of the digital twin; identifying, by the processing unit (302), an entity (104-1 to 104-N) associated with each of the one or more components of the plurality of digital twins (102-1 to 102-N); and assigning, by the processing unit (302), a unique identifier token to each of the components of the plurality of digital twins (102-1 to 102-N), wherein the unique identifier token comprises ownership information of the digital twin (102-1 to 102-N).

5. The method (400) of any of the preceding claims, wherein the unique identifier token is a simple token associated with a single component of the digital twin.

6. The method (400) of any of claims 1 to 4, wherein the unique identifier token is a composite token associated with a plurality of components of the digital twin, wherein the composite token comprises a plurality of simple tokens.

7. The method (400) of any of the preceding claims, wherein the one or more components of the digital twin correspond to functional components of the digital twin in the real world, wherein the functional components are components that are integral to the asset.

8. The method (400) of any of the preceding claims, wherein the one or more components of the digital twin correspond to non-functional components of the digital twin in the real world, wherein the non-functional components are data sources for capturing real-world behavior of one or more assets.

9. The method (400) of any of the preceding claims, wherein generating the authorization token for the simple token associated with the single component of the digital twin comprises: initiating, by the processing unit (302), an authorization token creation transaction request to the identified entity (104-1 to 104-N) of the component of the digital twin for signing the authorization token creation transaction request; and generating the authorization token upon approval of the request from the owner of the single component of the digital twin.

10. The method (400) of any of claims 1 to 8, wherein generating the authorization token for the composite token associated with the plurality of components of the digital twin (102-1 to 102-N) comprises: initiating, by the processing unit (302), an authorization token creation transaction request to each of the identified entities (104-1 to 104-N) of the respective components of the digital twin (102-1 to 102-N) for signing the authorization token creation transaction request; generating the authorization token upon approval of the request from each of the entities (104-1 to 104-N) corresponding to the respective components of the digital twin.

11. The method (400) of any of the preceding claims, further comprising: determining validity of the authorization token based on a ledger comprising a validity status of a plurality of authorization tokens issued by the one or more entities (104-1 to 104-N) associated with the digital twin (102-1 to 102-N); providing access control to a user for accessing the digital twin based on the validity of the authorization token. ​ 12. The method (400) of any preceding claim, wherein the unique identifier token is a non-replaceable token and the authorization token is a Jason web based token.

13. An apparatus (110) for managing access control of a plurality of digital twins interacting in a computer simulated environment over a distributed network, the apparatus comprising: one or more processing units (302); and a memory (304) communicatively coupled to the one or more processing units (302), the memory (304) comprising modules (306) stored in the form of machine-readable instructions executable by the one or more processing units (302), wherein the modules (306) are configured to perform the method (400) steps of claims 1 to 12.

14. A system (100) for managing access control of a plurality of digital twins interacting in a computer simulated environment over a distributed network, the system comprising: a collaborative environment hosting a computer simulation of a plurality of digital twins (102-1 to 102-N), wherein each of the plurality of digital twins (102-1 to 102-N) corresponds to one or more assets in an industrial environment; a distributed network (106) communicatively coupled to the collaborative environment hosting the computer simulation, wherein the distributed network comprises one or more nodes (202A-202N) for storing identification information of one or more entities; and the apparatus (110) of claim 7 communicatively coupled to the distributed network (106) and the collaborative environment hosting the computer simulation, wherein the apparatus (110) is configured for managing access control of the plurality of digital twins (102-1 to 102-N) according to any of the method claims 1 to 12.

15. A computer program product having computer readable instructions stored therein, which, when executed by a processing unit (302), cause the processing unit (302) to perform the method (400) steps of any of claims 1 to 12.

16. A computer readable medium having program code sections of a computer program saved thereon, the program code sections being loadable into and / or executable within a system, so that the system (100), when executing the program code sections in the system (100), performs the method (400) steps of any of claims 1 to 12.

Images