A private cloud dynamic permission generation system and method

Abstract

This invention proposes a dynamic permission generation system and method for private clouds, relating to the field of cloud computing permission management. The method constructs a ternary graph structure to represent the relationships between tenants, resources, and context; it uses graph search algorithms (such as Depth-First Search) to reverse-engineer legitimate access paths; it automatically generates permission sets based on the path results; and it implements permission merging, least privilege, and signature verification mechanisms; enabling its application in cloud systems. This invention effectively solves the problems of mixed permission usage among tenants, configuration lag, and fine-grained access control, improving the dynamism, security, and scalability of permission management.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing permission management technology, and in particular to a private cloud dynamic permission generation system and method. Background Technology

[0002] With the continuous evolution of cloud computing technology, private cloud platforms, as an important carrier for enterprise-level IT resource management, are widely used in complex business environments shared by multiple tenants. Among related technologies, the MCP (Model Context Protocol), as a standardized interface connecting large language models with external resources, has implemented context-aware resource invocation capabilities in private clouds. Specifically, this technology system covers the entire process from tenant identification and resource access control to context operation binding, including key aspects such as permission configuration, policy management, and access verification. Among these, permission control, as the core mechanism for ensuring tenant isolation and resource security, relies heavily on static policy tables or role-based permission models in traditional methods, which are difficult to adapt to the complex needs of dynamic resource changes and contextual relationships.

[0003] However, existing access control methods directly use preset permission tables for access control without dynamically deriving permissions based on request context. This can lead to problems such as delayed permission configuration, unauthorized access by tenants, or failure of resource isolation. Especially in scenarios with frequent resource creation, deletion, or migration, permission synchronization mechanisms cannot respond in real time, posing security risks. Furthermore, traditional methods lack a systematic model of the tenant-resource-context ternary relationship, making it difficult to achieve fine-grained, structured permission expression and verification, thus affecting the scalability and security of private cloud platforms in large-scale concurrent environments. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose a dynamic permission generation system for a private cloud MCP Server. For the implementation of MCP Server, it introduces a ternary graph structure to model the tenant-resource-context relationship for the first time; constructs a path verification mechanism based on depth-first graph search; implements permission merging, least privilege, and signature verification mechanisms for MCP server; and introduces a permission and request binding mechanism for the authentication process.

[0006] The second objective of this invention is to propose a method for generating dynamic permissions for a private cloud MCP Server.

[0007] A third objective of this invention is to provide a computer-readable storage medium.

[0008] To achieve the above objectives, a first aspect of the present invention provides a private cloud MCP Server dynamic permission generation system, comprising:

[0009] The graph construction module is used to construct a tenant, resource, and context ternary graph structure, which includes tenant nodes, resource nodes, context nodes, and directed edges representing deducible paths between the three.

[0010] The request parsing and context extraction module is used to parse MCP Client requests, extract tenant identifiers, resource identifiers and context operations from the requests, and map them as triple nodes in the graph structure.

[0011] The path reasoning and permission generation module is used to infer whether there is a legitimate access path from the tenant node to the context node based on the triple node using a graph search algorithm, and automatically generate a permission set containing operation type, resource identifier and constraint conditions based on the legitimate access path.

[0012] The permission verification and injection module is used to perform triple signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server.

[0013] The graph dynamic maintenance module is used to detect state changes and trigger dynamic updates of the graph structure and permission verification through a message queue.

[0014] In one embodiment of the present invention, the graph construction module is further configured to:

[0015] Tenant nodes, resource nodes, and context nodes are stored as entities in a graph database, and attribute information is added to each directed edge, including validity period, operation type, and signature information.

[0016] By subscribing to change events in the configuration center or CMDB database, the graph structure can be initialized and continuously maintained, ensuring real-time synchronization of tenants, resources, and context relationships.

[0017] In one embodiment of the present invention, the request parsing and context extraction module is further configured to:

[0018] The context field in the request is normalized and mapped to a predefined context operation node in the graph structure.

[0019] If the request does not contain a resource_id, then based on the tenant identifier and context operation node, a possible set of resource nodes is derived through the relationships in the graph structure.

[0020] In one embodiment of the present invention, the path reasoning and permission generation module is further configured to:

[0021] A depth-first search algorithm is used to traverse the graph structure, verify whether there is a valid path from the tenant node to the context node, and record the resource nodes involved in the path.

[0022] If multiple valid paths exist, the minimum scope merge algorithm is used to deduplicate and merge the permission sets, ensuring the minimization and security of permission expression.

[0023] In one embodiment of the present invention, the generated permissions are bound to a request or used in an authentication process; the injection methods for the generated permissions include:

[0024] The permission result is embedded as a token in the response header and returned to the client.

[0025] The permissions are appended to the MCP context structure and passed to the subsequent processing flow.

[0026] In one embodiment of the present invention, verification is performed based on a preset permission verification function. If the verification fails, the system returns an HTTP 403 access denied response and records an audit log. At the same time, the MCP Client receives permission failure information.

[0027] In one embodiment of the present invention, the graph dynamic maintenance module is further configured to:

[0028] When the graph dynamic maintenance module detects a change in the status of a tenant or resource, it obtains the change event through a message queue listening mechanism and triggers a dynamic update of the graph structure, including adding, deleting, or modifying tenant nodes, resource nodes, or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

[0029] To achieve the above objectives, a second aspect of the present invention provides a method for generating dynamic permissions for a private cloud MCP Server, comprising:

[0030] S1, construct a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing deducible paths between the three;

[0031] S2, parses the MCP Client request, extracts the tenant identifier, resource identifier and context operation from the request, and maps them to triple nodes in the graph structure;

[0032] S3. Based on the triplet node, a graph search algorithm is used to reverse the process to determine whether there is a legal access path from the tenant node to the context node, and a permission set containing operation type, resource identifier and constraint conditions is automatically generated according to the legal access path.

[0033] S4, perform triplet signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server;

[0034] S5 detects state changes and triggers dynamic updates to the graph structure and permission verification via message queues.

[0035] To achieve the above objectives, a third aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the second aspect of the present invention.

[0036] The system, method, and storage medium of this invention enable automatic generation and real-time verification of permissions in a multi-tenant private cloud MCP Server environment, effectively solving the problems of mixed permission use, configuration lag, and insufficient fine-grained control, and improving system security and scalability.

[0037] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0038] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0039] Figure 1 This is a structural diagram of a private cloud MCP Server dynamic permission generation system according to an embodiment of the present invention;

[0040] Figure 2 This is a data flow diagram of the graph dynamic maintenance module according to an embodiment of the present invention;

[0041] Figure 3 This is a flowchart of a method for generating dynamic permissions for a private cloud MCP Server according to an embodiment of the present invention. Detailed Implementation

[0042] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0043] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0044] The following description, with reference to the accompanying drawings, describes a private cloud MCP Server dynamic permission generation system, method, and computer-readable storage medium according to embodiments of the present invention.

[0045] The technical terminology of this invention is described below:

[0046] Cloud platform: A cloud computing platform, also known as a cloud computing service, refers to a service that provides computing, networking, and storage capabilities based on hardware and software resources.

[0047] MCP: Model Context Protocol (MCP) is an open-source protocol launched by Anthropic. It aims to integrate large language models with external data sources and tools, and to establish a secure, bidirectional connection between large models and data sources.

[0048] MCP Server: Provides AI MCP (Model Context Protocol) services, allowing AI to call tools more freely.

[0049] This invention, based on the implementation of a cloud operation intelligent agent (based on a private cloud MCP Server), proposes a dynamic permission generation method for a private cloud MCP Server based on a tenant resource mapping graph. The implementation of this method resides within the MCP Server, constructing a ternary graph structure that supports multi-level reasoning. By combining the request context, the set of valid access permissions is deduced, achieving automatic permission generation and real-time verification. This method, based on fast traversal of the graph structure, solves problems such as inconsistent permissions, lack of context, and lack of scalability. The main ideas are as follows:

[0050] First, define a tenant, resource, and context ternary graph structure G = (T, R, C, E), where:

[0051] T represents the set of tenant nodes (Tenant), and each node represents a tenant identifier (Tenant ID);

[0052] R stands for a collection of resource nodes, such as virtual machines, storage volumes, containers, models, etc.

[0053] C is a collection of context nodes, including function calls, system events, model names, inference scenarios, and control interfaces such as create_vm, delete_vm, and resize_vm.

[0054] E is a set of directed edges, representing the set of derivable paths such as T->R, R->C, C->R.

[0055] The permission reasoning path is as follows: When an MCP CLI request is connected to the MCP Server, its request context is extracted and mapped to the node set C in the graph structure. The system then executes a path backward algorithm to find all subgraphs that satisfy the following path condition: Treq → Ri → Creq, where Treq is the tenant node of the current request and Creq is the context node (such as create_vm). If there exists a path starting from Treq, passing through node Ri, and connecting to Creq, it indicates that the request has permission to access Creq, and the permission set Perm(Treq, Creq) can be automatically generated based on this path.

[0056] Permission set generation: Construct permission expressions based on the set of valid paths, for example: Perm(T123, Context['create_vm']) = { resource_id: Cluster_12, action: [vm.create,quota.assign], valid_scope: project['cloud-native-dev']}, and encapsulate the permission set as the token information in the MCP response header.

[0057] This method provides a permission cache refresh mechanism for real-time permission verification. When the tenant or resource status changes (such as creating a virtual machine or deleting a storage volume), the graph structure is dynamically updated and the permission inference path is synchronized in real time.

[0058] Each inference path must pass a triple signature verification mechanism: Sign(TID, RID, CID) to prevent path forgery or unauthorized access.

[0059] Figure 1 This is a structural diagram of the private cloud MCP Server dynamic permission generation system according to an embodiment of the present invention, as follows: Figure 1 As shown, it includes:

[0060] Graph construction module 100 is used to construct a tenant, resource and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes and directed edges representing deducible paths between the three.

[0061] This module is used to initialize and continuously maintain the graph structure relationships between tenants, resources, and context triples, and store them in a graph database, such as neo4j.

[0062] When the MCP Server starts, it connects to the database of the configuration center or CMDB (mostly relational databases) to obtain information about tenants, resources, and their operational capabilities.

[0063] Each tenant T_i is used as the starting node, each resource R_j is used as the intermediate node, and each context operation C_k is used as the target node to construct a ternary path T_i → R_j → C_k.

[0064] The graph structure G can be formally defined as a ternary directed graph: G = (V, E), where V = T ∪ R ∪ C, and E ⊆ V × V.

[0065] All edges E are persistently stored in the graph database. For example, in the Neo4j graph database, they are represented as follows:

[0066] MERGE (t:Tenant {id: 'T001'})

[0067] MERGE (r:Resource {id: 'VM001'})

[0068] MERGE (c:Context {action: 'create_vm'})

[0069] MERGE (t)-[:OWNS]->(r)-[:ALLOWS]->(c)

[0070] Each edge needs to have attributes added, such as expiry date, operation type, and signature.

[0071] Specifically, the three types of entities—tenants, resources, and contexts—and their operational relationships are abstracted as nodes and directed edges in a graph structure, thereby enabling structured reasoning and dynamic generation of permissions. Specifically, this ternary graph structure is defined as G = (T, R, C, E), where T is the set of tenant nodes, R is the set of resource nodes, C is the set of context nodes, and E is the set of directed edges representing inferable paths between tenants and resources, and between resources and contexts. Each tenant node T_i represents a tenant ID, resource nodes R_j represent specific resource instances in the cloud platform (such as virtual machines, storage volumes, containers, models, etc.), and context nodes C_k represent operational behaviors or control interfaces in the request (such as create_vm, delete_vm, resize_vm, etc.).

[0072] At the parameter level, tenant nodes must include metadata such as tenant ID, project, and region; resource nodes must include attributes such as resource type, resource ID, cluster, and status; and context nodes must standardize their operational behavior to ensure consistency with request context fields (such as the context field). Furthermore, the edge signature mechanism employs an asymmetric encryption algorithm (such as RSA or ECDSA), generated through the `sign_edge(tid, rid, cid, private_key)` function, to prevent path forgery and unauthorized access.

[0073] In practical applications, it is primarily used in the access control system of private cloud MCP Servers, especially suitable for multi-tenant scenarios with frequent dynamic resource changes. Through the construction of a graph structure, the system can automatically deduce and instantly verify permissions without manual configuration of permission tables, significantly improving the real-time performance and scalability of access management. Technically, this graph structure provides the data foundation for subsequent path inference algorithms (such as DFS), enabling structured reasoning capabilities in the permission verification process. This achieves fine-grained, context-aware access control, effectively solving technical challenges in traditional access management such as inconsistent permissions, configuration lag, and lack of context awareness.

[0074] In one embodiment of the present invention, the graph construction module 100 is further configured to: store tenant nodes, resource nodes and context nodes as entities in a graph database, and add attribute information, including validity period, operation type and signature information, to each directed edge; and subscribe to change events in the configuration center or CMDB database.

[0075] At the technical implementation level, the system first defines three types of entities—tenants, resources, and contexts—as node types in the graph database. Tenant nodes typically contain unique identifiers such as a Tenant ID; resource nodes include resource types (e.g., virtual machines, storage volumes, containers) and resource IDs; context nodes represent specific operations, such as `create_vm` and `delete_vm`, and are usually composed of an action type and operation parameters (e.g., region, project). In the graph database, these nodes are connected by directed edges, forming a ternary path structure, such as T_i → R_j → C_k, indicating that tenant T_i has access to resource R_j through context C_k.

[0076] Furthermore, to enhance the security and timeliness of permission verification, the system attaches key attribute information to each directed edge. The expiry date controls the lifecycle of permissions, typically expressed in ISO 8601 time format (e.g., `2025-12-31T16:00:00Z`), ensuring permissions are valid within a specified time frame. The operation type (op_type) identifies the specific operation represented by the edge, such as `read`, `write`, `delete`, etc., supporting a hybrid RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) model. The signature information (signature) uses an asymmetric encryption algorithm (such as RSA or ECDSA) to digitally sign the triples (TID, RID, CID), preventing path tampering or forgery and ensuring the integrity and immutability of the graph structure.

[0077] In application scenarios, it is widely used in the permission initialization phase of private cloud MCP Servers and in the graph structure update process when resources dynamically change. For example, when a tenant requests to create a virtual machine, the system quickly determines whether the tenant has the `create_vm` permission by looking at the path relationships in the graph database, and performs permission verification based on the validity period and signature information in the edge attributes. It provides a structured and queryable graph model foundation for subsequent path reasoning and permission generation modules, and is a prerequisite for realizing automatic permission derivation and real-time verification.

[0078] Furthermore, the core implementation method of the graph dynamic maintenance and security verification module in this invention is based on the event-driven architecture (EDA) and the incremental update mechanism of the graph database to realize the automatic construction and dynamic evolution of the tenant resource mapping graph.

[0079] At the technical implementation level, the MCP Server subscribes to change event streams from the configuration center or CMDB database via message middleware (such as Kafka, RabbitMQ, etc.). The configuration center or CMDB typically uses relational databases (such as MySQL, PostgreSQL) to store metadata about tenants, resources, and their operational permissions. When tenant resource relationships change (such as adding virtual machines, deleting storage volumes, adjusting tenant permissions, etc.), the system publishes the change event to a message queue through database triggers or Change Data Capture (CDC) mechanisms. The MCP Server, acting as a consumer, listens to this queue in real time, parses the event content, and maps it to change operations on nodes and edges in a graph structure.

[0080] The specific operation methods include: for new resource events, the system creates a corresponding Resource node in the graph database and establishes a T→R edge through the tenant-resource relationship; for resource deletion events, the system performs a node deletion operation in the graph database and simultaneously cleans up related edges; for context operation extensions (such as adding a create_model interface), the system creates a new Context node in the graph and establishes an R→C edge. Each edge must be digitally signed using the Sign(TID, RID, CID) function when created or updated to ensure the integrity and tamper-proof nature of the graph structure.

[0081] At the parameter level, the system supports multiple message queue protocols, such as Kafka with the topic "resource_change" and a JSON message format containing fields such as event type, tenant ID, resource ID, and context action. Edge attributes in the graph database include expiry date, operation type, and signature. The signature is generated using asymmetric encryption algorithms (such as RSA or ECDSA) to ensure the verifiability of each edge. Furthermore, the system supports version control for the graph structure. After each change event is triggered, the graph database records the change timestamp and operator for auditing and backtracking.

[0082] At the application level, it is used in the permission management scenarios of MCP Server in private cloud platforms, especially in environments where tenant resources change frequently and context operations are dynamically expanded. For example, when the cloud platform performs elastic scaling, the system can automatically associate the newly added virtual machine resource nodes with the tenant nodes and add the corresponding create_vm or delete_vm permission paths in the context operations, thereby achieving real-time synchronization and effectiveness of permissions.

[0083] By leveraging an event-driven mechanism and the real-time update capabilities of a graph database, the system can dynamically maintain tenant-resource-context relationships, ensuring that the permission inference path always remains consistent with the actual resource state. This improves the real-time performance, accuracy, and security of access control, effectively preventing unauthorized access issues caused by configuration lag. Furthermore, this mechanism supports the evolution of permission models in high-concurrency, large-scale tenant environments, providing a reliable data foundation for subsequent permission verification and inference.

[0084] The request parsing and context extraction module 200 is used to parse MCP Client requests, extract tenant identifiers, resource identifiers and context operations from the requests, and map them to triple nodes in the graph structure.

[0085] Specifically, in some implementations, parsing the MCP Client request and extracting the tenant identifier, resource identifier, and context operation, and mapping them to triple nodes in the graph structure, is the primary technical step in the dynamic generation and verification process of permissions in this invention. Its core lies in structuring the original request information and transforming it into a reasonable path in the graph model, thereby providing basic data support for subsequent permission verification.

[0086] This is achieved through a request parsing and context extraction module. The specific process includes: First, extracting the `tenant_id` field from the JSON format request sent by the MCP Client, which is used as the tenant node T in the graph structure; second, parsing the `context` field and standardizing it as a context operation node C, for example, mapping "create_vm" to a Context node in the graph; finally, if the request contains a `resource_id` field, it is used as a resource node R, and a triple (T, R, C) is constructed as input for graph path search. If the request does not specify a resource ID, the system will deduce a set of possible resource nodes based on the current tenant T's resource ownership relationship through the graph structure to support the validity verification of context operations.

[0087] During request parsing, the system must ensure standardized processing of fields. For example, the `context` field must conform to the predefined operation type enumeration (such as create_vm, delete_vm, etc.), and its standardization process must follow the specifications of the hybrid RBAC (Role-Based Access Control) and ABAC (Attribute-Based Access Control) model. Furthermore, the Tenant ID must strictly match the node ID in set T of the graph database, and the Resource ID must be consistent with the node ID in set R to ensure the correctness of the graph path. The response time should be controlled within 5ms to meet the real-time requirements of the MCP Server for context operations.

[0088] This module is widely used in the access control process of MCP Server in private cloud platforms, especially in multi-tenant environments. For example, when tenant T001 requests to create virtual machine VM001, the system needs to quickly identify whether the tenant has the corresponding resource and context operation permission path. This module can be deployed in the front gateway or API gateway of MCP Server as the first line of defense for access control, ensuring that all requests are structured and mapped with permission paths before entering the core processing flow.

[0089] Through this system, a precise mapping between request context and graph structure is achieved, providing structured input for subsequent path reasoning and permission generation. This effectively avoids problems such as lagging permission configuration and missing context in traditional RBAC models. Simultaneously, it supports real-time identification of dynamic resources and context operations, laying the foundation for implementing the principle of least privilege and fine-grained access control, significantly improving the security and response efficiency of MCP Server in multi-tenant environments.

[0090] Furthermore, the request parsing and context extraction module 200 is also used to: standardize the context field in the request and map it to a predefined context operation node in the graph structure; if the request does not contain resource_id, then based on the tenant identifier and the context operation node, deduce the possible set of resource nodes through the association relationship in the graph structure.

[0091] This module is responsible for structuring the requests received by the MCP Server into node information in a graph. The entire processing flow is as follows: a. Extract the tenant_id from the request and use it as the starting node T; b. Parse the context field and normalize it to use it as the target context node C; c. If the request contains resource_id, use it as an intermediate node R, and the triple (T, R, C) is used as the input for path search; otherwise, deduce possible resources from the graph.

[0092] Specifically, the received MCP request is first processed by the request parsing and context extraction module. Requests are typically transmitted in JSON format, containing fields such as `tenant_id`, `context`, and `resource_id`. The system parses the `context` field and matches it against a predefined set of context operation nodes C in the graph structure. Nodes in set C represent specific context operations, such as `create_vm`, `delete_vm`, and `resize_vm`. Each node must meet certain naming conventions and operation semantic standards, such as following the operation naming rules in RBAC (Role-Based Access Control) or ABAC (Attribute-Based Access Control). To achieve standardized mapping, the system can use regular expression matching, natural language processing (NLP) classification models, or predefined mapping tables for field transformation. In some implementations, the system can introduce a context normalization engine to unify context fields with different formats or similar semantics into standard operation identifiers, such as normalizing "create virtual machine" to `create_vm`, to ensure the consistency and recognizability of nodes in the graph structure.

[0093] The mapping process needs to consider several key parameters, including the regular expression rules for field parsing, the accuracy of the context classification model (e.g., F1-score ≥ 0.95), the update frequency of the mapping table (it is recommended to synchronize configuration center data once an hour), and the unique identifier of the context node (e.g., the `action` field must be a globally unique string). In addition, the mapping result must include metadata of the context node, such as operation type (op_type), resource type (resource_type), and scope, to support subsequent permission constraint generation.

[0094] In the access control process of private cloud MCP Servers, especially in multi-tenant environments, the system needs to dynamically determine whether a tenant has the permission to perform a specific operation based on the request context. For example, when tenant T001 initiates a request to create a virtual machine, the system needs to map the `context` field to the `create_vm` node and perform path reasoning based on the tenant node T001 and the resource node VM001 to generate the corresponding permission set.

[0095] By mapping request contexts to standard nodes in a graph structure, the permission verification process is structured and automated, effectively improving the accuracy and real-time performance of permission judgments. Simultaneously, standardized processing provides a unified input format for subsequent pathfinding algorithms (such as Depth-First Search), enhancing the system's scalability and maintainability, and serving as a core prerequisite for achieving fine-grained, context-aware permission control.

[0096] Furthermore, in some implementations, if the request does not contain `resource_id`, the system derives a possible set of resource nodes based on the tenant identifier (`tenant_id`) and the context operation node (`context`) through the relationships in the graph structure. This is one of the core logics of the path reasoning and permission generation module in this invention. Its technical implementation is based on ternary relation modeling in the graph database, namely the directed edge relationship between tenant, resource, and context operation. Specifically, the system first maps `tenant_id` in the request to the tenant node `Treq` in the graph, parses and normalizes the `context` field to the context operation node `Creq`, and then uses a graph traversal algorithm (such as depth-first search, DFS) to find all resource node sets `{R_i}` that satisfy the path condition `Treq → R_i → Creq`.

[0097] The path reasoning and permission generation module 300 is used to infer whether there is a legitimate access path from the tenant node to the context node based on the triplet node using a graph search algorithm, and automatically generate a permission set containing operation type, resource identifier and constraint conditions according to the legitimate path.

[0098] Specifically, in the path reasoning and permission generation module, the system, based on the constructed tenant-resource-context ternary graph structure, uses a depth-first search (DFS) algorithm to infer whether a legitimate access path exists from a tenant node to a context node, and automatically generates a permission set containing operation type, resource identifier, and constraints based on this path. This is the core logic for implementing dynamic permission control. Its technical implementation principle is based on path reachability analysis in graph theory, combined with context semantics and tenant resource ownership relationships, to achieve fine-grained, real-time permission inference.

[0099] In some implementations, the Depth-First Search (DFS) algorithm starts with the tenant node Treq in the request and traverses all possible directed edges in the graph (such as T→R, R→C, C→R) to search for a path that starts from Treq and eventually reaches the target context node Creq. This path must satisfy both resource ownership and context operation permissions. For example, if the request context is "create_vm", the system will search for the path Treq → R_i → Creq, where R_i is a resource node owned by the tenant Treq. If the path exists, it means that the tenant has the permission to execute the context operation.

[0100] Furthermore, after successful path verification, the system will generate a permission set Perm(Treq, Creq) based on the resource nodes, context operations, and edge attributes (such as validity period, operation type, signature, etc.) in the path. The permission set typically includes the tenant identifier, resource ID, operation type (such as vm.create, quota.assign), and constraints (such as region restriction, permission validity period valid_until). The generation of the permission set must follow the principle of least scope (MinScope), that is, selecting the permission set with the smallest scope from multiple valid paths to achieve the principle of least privilege.

[0101] Optionally, the system supports merging permission sets, using Union or Intersection algorithms to merge and deduplicate permissions generated from multiple paths, ensuring the uniqueness and consistency of permission representations. Furthermore, the permission set will be encapsulated as structured token information and injected into the MCP response header or context structure for use by subsequent authentication modules.

[0102] Playing a crucial role in private cloud MCP Servers, its technical advantages lie in enabling automatic permission derivation and real-time verification, effectively solving problems such as permission lag, unauthorized access, and high maintenance costs associated with traditional static permission configuration. Through rapid traversal and path verification of the graph structure, the system can complete permission determination within milliseconds, making it suitable for high-concurrency private cloud environments with dynamically changing resources. Furthermore, the integration of the triplet signature mechanism Sign(TID, RID, CID) prevents path forgery, enhancing system security and trustworthiness.

[0103] Furthermore, the path reasoning and permission generation module 300 is also used to: traverse the graph structure using a depth-first search algorithm, verify whether there is a valid path from the tenant node to the context node, and record the resource nodes involved in the path; if there are multiple valid paths, use the minimum scope merge algorithm to deduplicate and merge the permission set to ensure the minimization and security of permission expression.

[0104] Understandably, this module uses a depth-first search algorithm to identify legitimate access paths and outputs a permission expression for access control. After inputting the triple (T, R, C), the path verification algorithm expression is executed:

[0105] def verify_path(graph, T, C):

[0106] stack = [(T, [])]

[0107] while stack:

[0108] node, path = stack.pop()

[0109] if node == C:

[0110] return True, path

[0111] for neighbor in graph.successors(node):

[0112] if neighbor is not in path:

[0113] stack.append((neighbor, path + [neighbor]))

[0114] return False, []

[0115] If the path exists, construct the permission set Perm(T, C), with the expression:

[0116] {

[0117] "tenant": "T001",

[0118] "resource": "VM001",

[0119] "operation": "create_vm",

[0120] "constraints": {

[0121] "region": "cn-beijing",

[0122] "valid_until": "2025-12-31"

[0123] }

[0124] }

[0125] If multiple valid paths exist, a merge algorithm is needed to merge permissions, such as: Perm = Union(Perm_1,Perm_2, ..., Perm_n) or Perm = MinScope(Perm_i). After deduplication, the set with the smallest effective scope is selected.

[0126] Specifically, based on a pre-built ternary directed graph G = (T, R, C, E) in a graph database (such as Neo4j), where T is the set of tenant nodes, R is the set of resource nodes, C is the set of context nodes, and E is the set of directed edges between nodes, when MCPServer receives a request, it first extracts the tenant ID, resource ID, and context action through the request parsing and context extraction module, forming a triple (T, R, C) as input to the DFS algorithm. The DFS algorithm starts from the tenant node Treq, recursively traverses all its reachable resource nodes Ri, and further searches whether it can connect to the target context node Creq through the resource nodes. This algorithm achieves non-recursive traversal by maintaining a stack structure. Each time, the current node is popped and checked whether it is the target context node. If it is not found, the unvisited adjacent nodes are pushed onto the stack, and the visited path is recorded to prevent circular traversal.

[0127] The DFS algorithm requires a maximum traversal depth (default is 5 levels) to avoid getting stuck in infinite recursion or performance bottlenecks in large-scale graph structures. Each edge must carry metadata such as signature, expiry date, and operation type (op_type) for subsequent permission verification. The path verification result should return a boolean value (True / False) and a list of path nodes (path) to construct the permission set Perm(Treq, Creq). The permission set must contain key parameters such as resource ID, operation type, region constraint, and validity period (valid_until) to support fine-grained access control.

[0128] Widely used in the permission verification process of private cloud MCP Servers, especially when tenants initiate resource operation requests (such as creating virtual machines or deleting storage volumes), the system needs to determine in real time whether the operation has a valid path in the permission graph. For example, when tenant T001 requests to execute the create_vm operation, the system will automatically verify whether the path T001 → VM001 → create_vm exists, and record the resource node VM001 involved in the path, thereby generating the corresponding permission token.

[0129] Leveraging the efficient pathfinding capabilities of the DFS algorithm, the system can complete permission verification within milliseconds, significantly improving the real-time performance and accuracy of access control. Simultaneously, the path recording mechanism provides a structured basis for subsequent permission merging, minimum scope selection, and audit trails, enhancing system security and traceability. This method effectively solves the problems of permission synchronization lag and configuration complexity in traditional RBAC or ABAC models under multi-tenant, dynamic resource environments, achieving automated permission derivation and context-aware control.

[0130] Furthermore, in the path reasoning and permission generation module, if multiple valid paths exist, the system employs a minimum scope merging algorithm to deduplicate and merge the permission sets, ensuring the minimization and security of permission expressions. This is one of the core components of this invention for achieving fine-grained permission control and context-aware access. Its technology implements path search results based on a graph structure, combined with semantic analysis and scope comparison of permission expressions, thereby generating the optimal and most secure permission set.

[0131] In some implementations, the system uses a depth-first search (DFS) algorithm to identify a set of all legal paths from the tenant node Treq to the context node Creq: PathSet = {P1, P2, ..., Pn}, where each path P_i corresponds to a permission expression Perm_i. Since different paths may involve different resource nodes R_j and their operational constraints (such as region, validity period, operation type, etc.), the system needs to merge these permission expressions to avoid permission redundancy, conflicts, or unauthorized access.

[0132] The specific operation is as follows: First, the system compares the scopes of all resource nodes R_j in Perm_i to determine whether their metadata, such as project, region, and tenant level, are consistent. If multiple paths point to the same context operation but involve different resource nodes, the system uses the minimum scope principle (MinScope) to merge them, that is, it selects the resource node with the smallest scope and the finest granularity of permissions as the basis for the final permission expression. For example, if path P1 involves resource Cluster_12 with a scope of project['cloud-native-dev'], while path P2 involves resource Cluster_13 with a scope of project['cloud-native-prod'], the system will prioritize Cluster_12 to ensure that permissions are minimized.

[0133] Furthermore, the system deduplicates and merges the action sets in the permission expressions to ensure that the final permission set contains only unique and valid action items. For example, if multiple paths contain both `vm.create` and `quota.assign` operations, the system will merge them into a unified action list to avoid duplicate authorization.

[0134] Optionally, the system can also introduce a priority strategy, such as sorting multiple paths based on path length, resource type, and operational risk level, prioritizing the shortest or safest path for permission merging. Furthermore, to ensure the immutability of permissions, the system performs triple signature verification on the merged permission set, i.e., Sign(TID, RID, CID), ensuring that the tenant, resource, and context triples in the permission expression exist in the graph structure and have not been illegally modified.

[0135] By employing a minimum scope merging algorithm, the system can automatically generate the minimum set of permissions when multiple paths exist, effectively reducing the risk of permission leakage and improving the accuracy and security of permission control. Simultaneously, this mechanism supports permission inference for high-concurrency, large-scale tenants and resources, meeting the real-time and scalability requirements of private cloud MCP Servers in dynamic resource management scenarios.

[0136] The permission verification and injection module 400 is used to perform triple signature verification on each path in the permission set to prevent path forgery or unauthorized access, and inject the verified permission set into the response header or context structure of the MCP Server for subsequent authentication process.

[0137] Specifically, this module binds the generated permissions to the request or uses them in the authentication process. Permission injection methods can include the following two: a. Embedding the permission result as a token in the response header and returning it to the client; b. Attaching the permission to the MCP context structure and passing it into the subsequent processing flow.

[0138] The permission verification function is described as follows:

[0139] def check_permission(perm, context):

[0140] return perm['operation'] == context['action']and \

[0141] perm['resource'] == context['resource_id']

[0142] If verification fails, the system returns an HTTP 403 access denied error and logs it in the audit log. At the same time, the MCP Client receives the permission failure information.

[0143] Specifically, this step involves performing triplet signature verification on each path in the permission set, and injecting the verified permission set into the response header or context structure of the MCP Server for subsequent authentication processes. Its technical implementation is based on the edge signature mechanism in a graph structure, using an asymmetric encryption algorithm to ensure the legitimacy and unforgeability of the path, thereby achieving fine-grained access control.

[0144] At the technical implementation level, each graph path consists of a triple (TID, RID, CID), where TID is the tenant identifier, RID is the resource identifier, and CID is the context operation identifier. To prevent path forgery or unauthorized access, the system generates a digital signature for each edge during the graph construction phase. The signature algorithm can employ standard asymmetric encryption algorithms such as RSA or ECDSA, using the tenant's private key to sign the triple, generating `signature = Sign(TID, RID, CID, private_key)`. This signature is stored as an edge attribute in a graph database (such as Neo4j) for subsequent verification.

[0145] Once the permission set is generated, the system performs a signature verification operation on each path. This involves decrypting and verifying the signature using the tenant's public key to confirm its consistency with the original triplet. If verification fails, the path is deemed invalid, the permission set is discarded, the system returns an HTTP 403 error, and logs it in the audit log. The verification process must meet standard requirements such as timestamp verification and signature algorithm consistency verification (e.g., SHA-256 + RSA) to ensure the timeliness of the signature and the compliance of the algorithm.

[0146] In application scenarios, this is mainly used by the MCP Server to perform real-time verification of the derived permission paths after receiving client requests, ensuring the legitimacy of the permission source. The verified permission set will be encapsulated into a JWT or custom token format and injected into the response header (such as `X-Perm-Token`) or MCP context structure for subsequent service modules (such as resource scheduler, model controller) to perform secondary authentication.

[0147] By introducing a triplet signature mechanism, security threats such as intermediate node tampering and path forgery are effectively prevented, improving the credibility of permission derivation results. Meanwhile, the signature verification process features low latency (typically completed within 1-5ms), supporting real-time permission control in high-concurrency scenarios, and providing secure and efficient technical assurance for dynamic permission management across multiple tenants and resources in private clouds.

[0148] The method for generating dynamic permissions for a private cloud MCP Server based on a tenant resource mapping graph, as described in this invention, enables automatic generation and real-time verification of tenant permissions in a private cloud MCP Server. This effectively solves the problems of delayed permission configuration, insufficient isolation, and lack of contextual association in a multi-tenant environment, thereby improving the dynamism and security of permission management.

[0149] The graph dynamic maintenance module 500 is used to detect state changes and trigger dynamic updates of the graph structure and permission verification through a message queue.

[0150] Understandably, this module ensures the system's security and consistency in dynamic scenarios such as resource changes and context expansion. Figure 2 As shown.

[0151] Subscribe to message queues (such as Kafka) to listen for real-time operations, such as: adding / deleting virtual machines: triggering the addition / deletion of R nodes and the updating of their edges; context operation extension: updating C nodes and related R→C edges; tenant change: updating the binding of T nodes to R.

[0152] def sign_edge(tid, rid, cid, private_key):

[0153] message = f"{tid}|{rid}|{cid}"

[0154] Specifically, when a change in tenant or resource status is detected, the system obtains the change event in real time through a message queue listening mechanism (such as Kafka, RabbitMQ, etc.) and triggers a dynamic update of the graph structure accordingly. This includes adding, deleting, or modifying tenant nodes, resource nodes, or context nodes and their associated edges. Simultaneously, affected permission paths are re-verified and caches are refreshed. This is one of the core implementations of the graph dynamic maintenance and security verification module in this invention, ensuring strong consistency between the permission model and the actual resource status.

[0155] At the technical implementation level, the message queue listening mechanism captures change events from configuration centers, CMDBs, or resource scheduling systems by subscribing to specific topics. Event messages typically contain fields such as change type (e.g., create / delete / update), tenant ID, resource ID, and context action. Upon receiving an event, the system first parses the event type and related node information, then calls the update interface of the graph database (e.g., Neo4j, JanusGraph) to perform atomic operations on the nodes and edges in the graph structure. For example, when a new virtual machine resource is added, the system creates a corresponding Resource node and establishes an `OWNS` edge from the Tenant node to the Resource node, and an `ALLOWS` edge from the Resource node to the Context node (e.g., `create_vm`). Each edge carries metadata attributes, such as expiry date, operation type (op_type), and signature, to support subsequent permission verification.

[0156] Furthermore, after updating the graph structure, the system triggers a re-verification process for permission paths. This process, based on a depth-first search (DFS) algorithm, initiates path queries on affected tenant nodes to verify whether they still possess the permissions to access specific context operations. If the path verification result changes (e.g., permissions are removed or added), the system updates the permission cache (e.g., Redis or local cache) and refreshes the permission token associated with that tenant, ensuring the timeliness and accuracy of subsequent authentication requests.

[0157] Regarding parameter settings, the message queue listening module needs to be configured with appropriate consumer groups, offset strategies, and retry policies to ensure the reliability and order of event processing. Graph database update operations must adhere to ACID transaction principles to ensure the atomicity and consistency of node and edge updates. The permission cache refresh strategy can employ a TTL (Time to Live) mechanism or an event-based proactive invalidation strategy to balance performance and real-time requirements.

[0158] It plays a crucial role in the access control system of private cloud MCP Server. By responding in real time to changes in tenant and resource status, the system can dynamically adjust the permission model, avoiding unauthorized access or permission invalidation issues caused by configuration lag, thereby improving system security and responsiveness. Especially in cloud environments where resources change frequently, this mechanism significantly enhances the elasticity and automation of access control.

[0159] The method for generating dynamic permissions for a private cloud MCP Server based on a tenant resource mapping graph in this invention introduces a message queue listening mechanism to achieve real-time response to changes in tenant or resource status, dynamically updates the tenant resource mapping graph structure and re-verifies relevant permission paths, thereby further improving the real-time performance and accuracy of permission management and strengthening the system's permission isolation and context association capabilities in complex and ever-changing environments.

[0160] Through the synergy of the above modules and algorithms, this invention realizes automatic derivation, real-time authorization and dynamic control of cloud resource operation permissions under MCP Server. Moreover, it takes into account the context, making it particularly suitable for private cloud scenarios with frequent dynamic changes in resources and high tenant isolation requirements.

[0161] To achieve the above embodiments, such as Figure 3 As shown, this embodiment also provides a method for generating dynamic permissions for a private cloud MCP Server, including:

[0162] S1, construct a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing deducible paths between the three;

[0163] S2, parses the MCP Client request, extracts the tenant identifier, resource identifier and context operation from the request, and maps them to triple nodes in the graph structure;

[0164] S3. Based on the triplet node, a graph search algorithm is used to reverse the process to determine whether there is a legal access path from the tenant node to the context node, and a permission set containing operation type, resource identifier and constraint conditions is automatically generated according to the legal access path.

[0165] S4, perform triplet signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server;

[0166] S5 detects state changes and triggers dynamic updates to the graph structure and permission verification via message queues.

[0167] Further, S1 includes:

[0168] S11, store tenant nodes, resource nodes and context nodes as entities in the graph database, and add attribute information to each directed edge, including validity period, operation type and signature information;

[0169] S12 initializes and continuously maintains the graph structure by subscribing to change events in the configuration center or CMDB database, ensuring real-time synchronization of tenants, resources, and context relationships.

[0170] Further, S2 includes:

[0171] S21, standardize the context field in the request and map it to a predefined context operation node in the graph structure;

[0172] S22, if the request does not contain resource_id, then based on the tenant identifier and context operation node, the possible set of resource nodes is derived through the association relationship in the graph structure.

[0173] Further, S3 includes:

[0174] S31. The depth-first search algorithm is used to traverse the graph structure, verify whether there is a valid path from the tenant node to the context node, and record the resource nodes involved in the path.

[0175] S32. If multiple valid paths exist, the minimum scope merge algorithm is used to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

[0176] Furthermore, the generated permissions can be bound to requests or used in the authentication process; the injection methods for generated permissions include:

[0177] The permission result is embedded as a token in the response header and returned to the client.

[0178] The permissions are appended to the MCP context structure and passed to the subsequent processing flow.

[0179] Furthermore, the method also includes verification based on a preset permission verification function. If the verification fails, the system returns an HTTP 403 access denied error and records an audit log. At the same time, the MCP Client receives permission failure information.

[0180] Furthermore, state changes are detected by triggering dynamic updates to the graph structure and permission verification via message queues, including:

[0181] When a change in the tenant or resource status is detected, the change event is obtained through the message queue listening mechanism, and the dynamic update of the graph structure is triggered, including adding, deleting or modifying tenant nodes, resource nodes or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

[0182] The method for generating dynamic permissions for a private cloud MCP Server according to embodiments of the present invention enables automatic generation and real-time verification of permissions in a private cloud MCP Server, solving problems such as tenant and resource isolation, context association, and fine-grained permission control.

[0183] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method for generating dynamic permissions for a private cloud MCP Server.

[0184] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0185] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A private cloud MCP Server dynamic permission generation system, characterized in that, include: The graph construction module is used to construct a tenant, resource, and context ternary graph structure, which includes tenant nodes, resource nodes, context nodes, and directed edges representing deducible paths between the three. The request parsing and context extraction module is used to parse MCP Client requests, extract tenant identifiers, resource identifiers and context operations from the requests, and map them as triple nodes in the graph structure. The path reasoning and permission generation module is used to infer whether there is a legitimate access path from the tenant node to the context node based on the triple node using a graph search algorithm, and automatically generate a permission set containing operation type, resource identifier and constraint conditions based on the legitimate access path. The permission verification and injection module is used to perform triple signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server. The graph dynamic maintenance module is used to detect state changes and trigger dynamic updates of the graph structure and permission verification through a message queue.

2. The system as described in claim 1, characterized in that, The graph construction module is also used for: Tenant nodes, resource nodes, and context nodes are stored as entities in a graph database, and attribute information is added to each directed edge, including validity period, operation type, and signature information. By subscribing to change events in the configuration center or CMDB database, the graph structure can be initialized and continuously maintained, ensuring real-time synchronization of tenants, resources, and context relationships.

3. The system as described in claim 2, characterized in that, The request parsing and context extraction module is also used for: The context field in the request is normalized and mapped to a predefined context operation node in the graph structure. If the request does not contain a resource_id, then based on the tenant identifier and context operation node, a possible set of resource nodes is derived through the relationships in the graph structure.

4. The system as described in claim 3, characterized in that, The path reasoning and permission generation module is also used for: A depth-first search algorithm is used to traverse the graph structure, verify whether there is a valid path from the tenant node to the context node, and record the resource nodes involved in the path. If multiple valid paths exist, the minimum scope merge algorithm is used to deduplicate and merge the permission sets, ensuring the minimization and security of permission expression.

5. The system as described in claim 4, characterized in that, The system is also used to bind generated permissions to requests or for authentication processes; The methods for generating permissions to be injected include: The permission result is embedded as a token in the response header and returned to the client. The permissions are appended to the MCP context structure and passed to the subsequent processing flow.

6. The system as described in claim 5, characterized in that, The system is also used to perform verification based on a preset permission verification function. If the verification fails, the system returns an HTTP 403 access denied error and records an audit log. At the same time, the MCP Client receives permission failure information.

7. The system as described in claim 6, characterized in that, The graph dynamic maintenance module is also used for: When the graph dynamic maintenance module detects a change in the status of a tenant or resource, it obtains the change event through a message queue listening mechanism and triggers a dynamic update of the graph structure, including adding, deleting, or modifying tenant nodes, resource nodes, or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

8. A method for generating dynamic permissions for a private cloud MCP Server, characterized in that, include: S1, construct a tenant, resource, and context ternary graph structure, wherein the ternary graph structure includes tenant nodes, resource nodes, context nodes, and directed edges representing deducible paths between the three; S2, parses the MCP Client request, extracts the tenant identifier, resource identifier and context operation from the request, and maps them to triple nodes in the graph structure; S3. Based on the triplet node, a graph search algorithm is used to reverse the process to determine whether there is a legal access path from the tenant node to the context node, and a permission set containing operation type, resource identifier and constraint conditions is automatically generated according to the legal access path. S4, perform triplet signature verification on each path in the permission set, and inject the verified permission set into the response header or context structure of the MCP Server; S5 detects state changes and triggers dynamic updates to the graph structure and permission verification via message queues.

9. The method as described in claim 8, characterized in that, S1 includes: S11, store tenant nodes, resource nodes and context nodes as entities in the graph database, and add attribute information to each directed edge, including validity period, operation type and signature information; S12 initializes and continuously maintains the graph structure by subscribing to change events in the configuration center or CMDB database, ensuring real-time synchronization of tenants, resources, and context relationships.

10. The method as described in claim 8, characterized in that, The S2 includes: S21, standardize the context field in the request and map it to a predefined context operation node in the graph structure; S22, if the request does not contain resource_id, then based on the tenant identifier and context operation node, the possible set of resource nodes is derived through the association relationship in the graph structure.

11. The method as described in claim 8, characterized in that, The S3 includes: S31. The depth-first search algorithm is used to traverse the graph structure, verify whether there is a valid path from the tenant node to the context node, and record the resource nodes involved in the path. S32. If multiple valid paths exist, the minimum scope merge algorithm is used to deduplicate and merge the permission sets to ensure the minimization and security of permission expression.

12. The method as described in claim 8, characterized in that, Bind the generated permissions to the request or use them in the authentication process; The methods for generating permissions to be injected include: The permission result is embedded as a token in the response header and returned to the client. The permissions are appended to the MCP context structure and passed to the subsequent processing flow.

13. The method as described in claim 12, characterized in that, The method further includes: The system performs authentication based on a preset authentication function. If authentication fails, the system returns an HTTP 403 access denied error and records the audit log. At the same time, the MCP Client receives the authentication failure information.

14. The method as described in claim 8, characterized in that, Detecting state changes triggers dynamic updates to the graph structure and permission verification via message queues, including: When a change in the tenant or resource status is detected, the change event is obtained through the message queue listening mechanism, and the dynamic update of the graph structure is triggered, including adding, deleting or modifying tenant nodes, resource nodes or context nodes and their associated edges, and re-verifying and refreshing the cache of the affected permission paths.

15. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of claims 8-14.

Images