An ai creative asset execution right transaction system based on macro instruction workflow
By encapsulating and parsing static creative assets with workflows defined by macro instruction protocols, an executable asset encapsulation encryption container is generated, which solves the problem of binding static assets with dynamic execution logic, realizes controlled execution rights transactions and traceable revenue settlement, and improves the security and controllability of commercial applications of AI workflow assets.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI SHENGCHUN SUHUIYUN TECHNOLOGY CO LTD
- Filing Date
- 2026-03-23
- Publication Date
- 2026-06-19
AI Technical Summary
In existing technologies, static creative assets and dynamic execution logic lack a unified protocol-based binding mechanism, making it difficult for assets to circulate as controlled execution objects. Workflow execution rights and workflow ontology lack technical separation and constraints, making it difficult to limit the number of executions, the scope of invocation, and the operating parameters. The lack of a transaction support mechanism makes it difficult to ensure that execution right transactions are traceable, verifiable, and settleable.
The workflow asset encapsulation module atomically encapsulates static assets and executable workflows defined by macro instruction protocols to generate asset encapsulation encryption containers. The protocol parsing and compilation module parses macro instruction steps and generates execution plans. The execution right control module restricts execution right transaction strategies. The unified orchestration execution module executes in a trusted execution environment and records audit logs. The settlement module performs revenue settlement.
It achieves a technical-level binding between static creative assets and dynamic execution logic, enhances the security, controllability, and auditability of execution right transactions, ensures the standardization and reusability of asset commercial applications, and provides a traceable revenue distribution mechanism.
Smart Images

Figure CN122243638A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of artificial intelligence workflow control and digital asset management technology, specifically relating to an AI creative asset execution right trading system based on macro instruction workflow. Background Technology
[0002] With the development of large language models, multimodal models, and automated workflow systems, more and more creative assets need to be combined with specific AI execution logic to realize their value in content generation scenarios. Static assets themselves cannot complete content production independently; they usually need to be combined with prompt word templates, model calling steps, external interface calls, code processing steps, or sub-workflows to form an executable content generation capability.
[0003] Currently, the main licensing methods for AI assets include file delivery and API call models. File delivery can only transfer static files or model parameters and cannot bind subsequent execution logic. While API call models can provide model services or API capabilities, they typically only expose a single interface, failing to unify the control of static assets, workflow steps, execution constraints, and call boundaries as an indivisible object. For scenarios that generate content using multi-step AI workflows, existing technologies lack an execution rights encapsulation and transaction mechanism oriented towards the workflow asset itself.
[0004] The existing technology still has the following shortcomings: First, there is a lack of a unified protocol binding mechanism between static creative assets and dynamic execution logic, which makes it possible for assets to be copied, but difficult to circulate as controlled execution objects; Second, there is a lack of technical separation and constraint between workflow execution rights and workflow ontology, making it difficult to limit the number of executions, the scope of invocation, and the running parameters; Third, there is a lack of a transaction support mechanism that can parse, compile, uniformly orchestrate and execute workflow assets and generate audit logs, making it difficult to make execution right transactions traceable, verifiable, and settlementable.
[0005] Therefore, how to uniformly encapsulate static creative assets with AI workflows defined using macro instruction protocols, and realize controlled operation of execution rights, audit records, and revenue settlement in a unified orchestration and execution environment, has become an important technical problem that urgently needs to be solved in the field of artificial intelligence content generation and digital creative asset management. Summary of the Invention
[0006] To address the aforementioned problems in the existing technology, this invention provides an AI-based creative asset execution right trading system based on macro instruction workflow. The objective of this invention can be achieved through the following technical solutions: Workflow Asset Encapsulation Module: Used to atomically encapsulate static asset data, executable workflows defined using macro instruction protocols, execution constraint information, and revenue distribution rules to generate an asset encapsulation encrypted container; Protocol parsing and compilation module: used to parse multiple macro instruction steps in the executable workflow, verify step identifiers, type identifiers, dependencies and input / output reference relationships, construct a directed acyclic graph, and compile and generate an execution plan based on the directed acyclic graph; Execution control module: used to generate execution right transaction strategy based on the risk quantification assessment results of the asset encapsulation encryption container, and limit at least one of the following: number of executions, call period, parameter boundaries, and scope of callable resources; Unified orchestration and execution module: used to distribute execution tasks to execution units of the corresponding type based on the type identifier and dependencies in the execution plan; Trusted Execution and Audit Module: Used to perform controlled decryption and execution of the asset encapsulation encryption container in a trusted execution environment, record the execution process and generate execution audit logs; Settlement module: Used to settle revenue with creative holders and workflow developers based on the execution audit logs and revenue distribution rules.
[0007] Specifically, the executable workflow adopts a macro instruction protocol format, and the macro instruction steps include at least the following fields: Step identifier field, type identifier field, resource definition field, input definition field, output definition field, and dependency field; The type identifier includes at least model call type, HTTP call type, MCP tool call type, code execution type, and workflow call type; The input definition field, output definition field, and dependency field are used to describe the data flow relationship and execution dependency relationship between macro instruction steps.
[0008] Specifically, the asset encapsulation encryption container includes at least: a static asset encryption layer, a workflow definition layer, an execution constraint layer, a key protection layer, and an audit verification layer; The static asset encryption layer is used to perform structured block processing on static asset data and control the on-demand decryption and minimum permission access of the static asset data during execution. The workflow definition layer is used to store executable workflows defined using a macro instruction protocol. The execution constraint layer is used to record at least one of the following: execution count, invocation period, parameter boundaries, and callable resource range; The key protection layer and audit verification layer are used to perform controlled activation of the encryption key and integrity verification of the execution process, respectively.
[0009] Specifically, the execution plan generated by the compilation module includes at least: The order of steps execution; Target execution unit address, call parameters, input source reference, and output target reference; Variable mapping relationships and step status feedback relationships.
[0010] Specifically, the execution control module generates risk differentiation parameters based on the risk quantification assessment results, and the risk quantification assessment includes at least: Extract at least one of the following characteristics based on historical execution records or simulated execution results: revenue volatility characteristics, call stability characteristics, and asset reuse characteristics; The features are compared with a preset risk threshold to generate risk differentiation parameters for adjusting the execution power strategy.
[0011] Specifically, the fault tolerance comparison method in the risk quantification assessment includes: Based on the corresponding return volatility threshold, execution stability threshold, or call deviation threshold in the built-in risk library, tolerance judgment is made on the execution result deviation and step call stability to generate structural risk indicators. Based on the aforementioned structural risk indicators, at least one of the following can be adaptively adjusted: the scope of execution authority authorization, the upper limit of invocation, or the risk warning level.
[0012] Specifically, the execution right transaction strategy includes at least one or more of the following: execution count constraints, call time period constraints, parameter boundary constraints, callable resource range constraints, and revenue settlement rules: The execution count constraint is used to count and control the number of times the asset encapsulation encryption container is called in the unified orchestration execution module, and to block subsequent execution requests when the preset call limit is reached. The call time period constraint is used to limit the execution plan to be triggered within a preset time interval, and to reject or delay execution requests during unauthorized time periods. The parameter boundary constraints are used to verify the range of input parameter values, parameter types, or parameter combination relationships in macro instruction steps. When the input parameters exceed the preset boundary conditions, the call of the corresponding execution unit is prevented. The callable resource scope constraints and revenue settlement rules are used to limit the access scope of the target execution resource or service interface corresponding to the resource definition field in the macro instruction step, and to intercept resource calls that exceed the authorized scope during execution.
[0013] Specifically, the process of injecting immutable parameters includes: prompt word template construction, parameter injection, context assembly, and model invocation; The process of constructing the prompt word template is as follows: using the guiding prompt words in static assets as system-level instructions and the few sample examples as context references to construct a multi-layer prompt word structure; The parameter injection process is as follows: the style parameter configuration limited by the execution right strategy is injected into the interface parameters of the model calling step, including at least one of temperature, maximum length, and repetition penalty; The context assembly process is as follows: assemble the complete prompt words in the order of system layer, reference layer, and input layer; The process of model invocation is as follows: the target model or target workflow step is invoked using the assembled prompts and parameters to ensure that the post-transaction asset execution process is subject to the authorized scope and the output results are auditable.
[0014] Specifically, the settlement module performs revenue settlement based on the execution audit log, and the revenue settlement method includes: Extract the number of calls, execution time, execution subject, and execution result summary from the execution audit log; The revenue share of the idea holder and the workflow developer is calculated according to the preset revenue distribution rules. Add structured identifiers to transaction records that meet risk warning conditions or abnormal execution conditions; Generate a settlement record associated with the execution audit log; Automatic settlement is performed for idea holders and workflow developers based on the settlement records.
[0015] Specifically, the unified orchestration and execution module binds the conditional triggering execution and output verification of workflow steps, and the binding process includes: The execution semantics of each macro instruction step in the executable workflow are parsed, conditional rule parameters are extracted, and a unique execution status identifier is established for each macro instruction step. The conditional rule parameters include step triggering conditions, input parameter constraints, and output data types; Based on the execution status identifier, the verification result and the step execution status are jointly recorded, and based on the execution dependencies and data flow paths between workflow steps, an association mapping table between step triggering rules and output verification rules is constructed. The association mapping table is used to bind the triggering conditions of each step with the corresponding output verification.
[0016] Specifically, the process of generating the execution audit log includes: In a trusted execution environment, execution events are captured during the execution of execution rights, and corresponding event data units are generated. The event data unit is time-series encoded to generate a digital signature identifier; Based on the digital signature identifier, each execution event is linked in a chain according to the execution order to form an audit log data chain with sequential dependencies; The execution event data associated with the audit log data chain and the corresponding execution result summary are uniformly encapsulated, and the encapsulated log structure is solidified to obtain the execution audit log.
[0017] Specifically, the trusted execution environment shall have at least the following characteristics: hardware isolation, memory encryption, remote authentication, and execution non-eavesdropping. The hardware isolation feature is: through an independent execution space, independent address space mapping and access control are performed on the execution code segment, data segment, and calling context; The memory encryption feature is as follows: lifecycle management is performed on the execution session key loaded into memory, and automatic encryption is performed when it is stored in dynamic random access memory; The remote proof feature is as follows: a cryptographic proof is generated at startup and signed by the hardware root key inside the trusted execution environment; The cryptographic proof is used to remotely verify the authenticity and integrity of the execution environment and whether the operating environment meets the authorization requirements; The non-eavesdropping feature is achieved by establishing a context isolation segment within the workflow asset execution process; The context isolation segment is used to prevent side-channel eavesdropping from capturing or inferring sensitive information during execution.
[0018] The beneficial effects of this invention are as follows: This invention provides an AI creative asset execution right trading system based on macro instruction workflow. By uniformly encapsulating static creative assets with executable workflows defined using macro instruction protocols, a parsable, compileable, and schedulable asset encapsulation encryption container is formed, thereby achieving a technical-level binding between static creative assets and dynamic execution logic.
[0019] Compared with existing technologies, this invention can integrate creative asset content with its workflow execution logic into a controllable transaction object, avoiding the problem of static assets and dynamic logic being separated in the traditional model, and making the commercial application of AI workflow assets more standardized and controllable.
[0020] By using protocol parsing, execution plan compilation, and unified orchestration and scheduling mechanisms, this invention can restrict the asset encapsulation encryption container to run under specified execution units and specified dependency sequences, and combine trusted execution environment technology to complete decryption and execution in a controlled environment, thereby improving the security and verifiability of workflow asset execution right transactions.
[0021] Each time an execution request occurs, the execution steps, call time, execution result summary, and number of calls are recorded, and the revenue settlement among multiple parties is automatically completed according to the preset revenue distribution rules, making the revenue distribution process among creators, workflow developers, and the platform transparent and traceable.
[0022] By technically separating the workflow entity from the workflow execution rights, creators can maintain ownership of static assets and control over the workflow while only trading out the restricted execution capabilities, thereby enhancing the reusability and commercial value of workflow assets.
[0023] In summary, this invention not only improves the security, controllability, and auditability of AI workflow asset execution rights during transactions and use, but also provides a more robust technical implementation path for the large-scale circulation of digital creative content. Attached Figure Description
[0024] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.
[0025] Figure 1 This is a schematic diagram of the structure of an AI creative asset execution right trading system based on macro instruction workflow according to the present invention.
[0026] Figure 2 This is a schematic diagram of the overall framework of an AI creative asset execution right trading system based on macro instruction workflow according to the present invention.
[0027] Figure 3 This is a schematic diagram of the asset transaction process of an AI creative asset execution right transaction system based on macro instruction workflow according to the present invention.
[0028] Figure 4 This is a schematic diagram illustrating parameter injection and execution in an AI creative asset execution right trading system based on macro instruction workflow according to the present invention. Detailed Implementation
[0029] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.
[0030] Please see Figure 1 An AI-powered creative asset execution rights trading system based on macro instruction workflow: Workflow Asset Encapsulation Module: Used to atomically encapsulate static asset data, executable workflows defined using macro instruction protocols, execution constraint information, and revenue distribution rules to generate an asset encapsulation encrypted container; Protocol parsing and compilation module: used to parse multiple macro instruction steps in the executable workflow, verify step identifiers, type identifiers, dependencies and input / output reference relationships, construct a directed acyclic graph, and compile and generate an execution plan based on the directed acyclic graph; Execution control module: used to generate execution right transaction strategy based on the risk quantification assessment results of the asset encapsulation encryption container, and limit at least one of the following: number of executions, call period, parameter boundaries, and scope of callable resources; Unified orchestration and execution module: used to distribute execution tasks to execution units of the corresponding type based on the type identifier and dependencies in the execution plan; Trusted Execution and Audit Module: Used to perform controlled decryption and execution of the asset encapsulation encryption container in a trusted execution environment, record the execution process and generate execution audit logs; Settlement module: Used to settle revenue with creative holders and workflow developers based on the execution audit logs and revenue distribution rules.
[0031] In this embodiment, the process of establishing the binding mapping relationship between the asset data object and the macro instruction step function attribute is as follows: Step identifier field, type identifier field, resource definition field, input definition field, output definition field, and dependency field; The type identifier includes at least model call type, HTTP call type, MCP tool call type, code execution type, and workflow call type; The input definition field, output definition field, and dependency field are used to describe the data flow relationship and execution dependency relationship between macro instruction steps.
[0032] In this embodiment, the asset encapsulation encryption container includes at least: a static asset encryption layer, a workflow definition layer, an execution constraint layer, a key protection layer, and an audit verification layer; The static asset encryption layer is used to perform structured block processing on static asset data and control the on-demand decryption and minimum permission access of the static asset data during execution. The workflow definition layer is used to store executable workflows defined using a macro instruction protocol. The execution constraint layer is used to record at least one of the following: execution count, invocation period, parameter boundaries, and callable resource range; The key protection layer and audit verification layer are used to perform controlled activation of the encryption key and integrity verification of the execution process, respectively.
[0033] In this embodiment, as Figure 2As shown, its core lies in encapsulating static creative assets and dynamic workflows defined using macro instruction protocols into atomic encrypted containers, where the transaction involves the constrained execution rights of the workflow rather than the ownership of the assets.
[0034] The specific content includes: Three types of roles: Creative asset holders, who own static creative assets such as portraits, voices, art styles, and text; Workflow developers, who are responsible for providing workflows and execution logic defined using macro instruction protocols; and consumers, who purchase execution rights and call upon the encapsulated workflow assets to generate content within the authorized scope.
[0035] The core modules include: a workflow asset encapsulation module, responsible for binding static assets with workflow definitions to generate asset encapsulation encryption containers; a protocol parsing and compilation module, responsible for parsing macro instruction protocol workflows and compiling them into execution plans; a unified orchestration and execution module, responsible for scheduling various execution units according to the execution plan; a trusted execution and auditing module, responsible for decrypting execution in a trusted execution environment and generating execution audit logs; and a settlement module, responsible for completing revenue settlement based on the execution audit logs.
[0036] like Figure 3 As shown, it receives static assets submitted by creative asset holders; This process is executed by the workflow asset encapsulation module, which receives static assets submitted by users through file uploads, API calls, or interface configuration. These static assets include, but are not limited to: portrait low-rank adapter models, voice models, art style models, novel text settings, and character settings. After a static asset is submitted, the system generates a unique asset identifier and performs preprocessing, such as format verification, virus scanning, and content review.
[0037] Receive workflow files submitted by workflow developers that are defined using a macro instruction protocol; The workflow definition is associated with static assets and describes how to generate content using the static assets. The workflow definition adopts a macro instruction protocol format and includes at least step identifiers, type identifiers, resource definitions, input definitions, output definitions, and dependencies. The type identifiers include at least model call type, HTTP call type, code execution type, MCP tool call type, and workflow call type. After parsing the workflow definition, the system constructs a directed acyclic graph and compiles it to generate an execution plan.
[0038] The static assets and the workflow defined using the macro instruction protocol are atomically encapsulated to generate an encrypted container encapsulated using an encryption algorithm.
[0039] The asset encapsulation encryption container adopts a layered encapsulation strategy: The first layer is the static asset encryption layer, which uses a symmetric encryption algorithm to encrypt the original creative assets. Symmetric encryption is an encryption algorithm that uses the same key for both encryption and decryption, ensuring both confidentiality and integrity. The encryption key is generated by a cryptographically secure random number generator, ensuring that the key is unique for each encapsulation. The encrypted ciphertext is stored in a server-side database, and the plaintext is never stored on the server.
[0040] The second layer is the key protection layer, where the symmetric key is further protected using an asymmetric encryption algorithm. Asymmetric encryption employs a cryptographic mechanism of public-key encryption and private-key decryption. The public key for asymmetric encryption is used to encrypt the symmetric key, while the private key is stored only within the trusted execution environment and is inaccessible externally. The key is injected into the trusted execution environment through a secure channel; the injection process does not leave any external memory, preventing memory dump attacks.
[0041] The third layer consists of the execution constraint layer and the audit verification layer. The system records the number of executions, the call period, parameter boundaries, and constraints such as the scope of callable resources. It also calculates a joint hash value for the static asset ciphertext, workflow definition, encapsulation timestamp, and encapsulator identity. During execution, the trusted execution environment verifies signature consistency to prevent any part from being tampered with or replaced individually.
[0042] The fourth layer consists of key protection and anti-extraction mechanisms. The decrypted plaintext exists only in a protected memory region within the trusted execution environment, and external software cannot access the data in this memory region. This memory region is immediately zeroed out after execution to prevent data residue.
[0043] The system receives an execution request from a consumer and decrypts the encrypted container within a trusted execution environment. The execution request includes an encrypted container identifier and user input parameters. The system first verifies the consumer's execution permissions, checking if execution rights have been purchased or if there are remaining execution attempts. Once permission verification is successful, the system starts the trusted execution environment instance.
[0044] The Trusted Execution Environment (TEX) employs hardware-level isolation technology, with core features including: hardware isolation, creating a TEX execution space through a central processing unit (CPU) extended instruction set, preventing even system administrators and cloud service providers from accessing data within the TEX; memory encryption, automatically encrypting data within the TEX using the CPU's built-in memory encryption engine, storing it as ciphertext in dynamic random access memory (DRAM) to prevent cold start attacks and physical probing; remote verification, generating a remote verification report upon startup, containing the TEX hash value, public key fingerprint, and platform health status, allowing consumers to verify the report and ensure the execution environment has not been tampered with; and non-eavesdropping execution, preventing external software from debugging, tracking, setting breakpoints, or monitoring the internal execution process, ensuring the confidentiality of creative assets and workflow logic.
[0045] After the Trusted Execution Environment (TEX) starts, the system uses the private key to decrypt the symmetric key, and then uses the symmetric key to decrypt static assets and workflow encapsulation information. The decryption process is completed entirely within the TEX; the key, static assets, and workflow runtime intermediate states do not leave the protected memory area.
[0046] The static assets are injected into the execution environment as immutable parameters, and the target model or target workflow step is invoked according to the execution plan to generate the results. See also Figure 4 This step is completed collaboratively by the unified orchestration and execution module and the trusted execution module. Its core is to integrate static assets, execution constraints and user input within the authorized scope.
[0047] For image generation assets, the specific implementation of parameterized injection includes: loading the portrait low-rank adapter model as part of the model weights into the image generation model, and using the low-rank adapter weights and the base model weights for inference; merging the user-input prompts with the keywords associated with the low-rank adapter model to form complete generation prompts; calling the image generation model to generate images, where the portrait of the person in the image is controlled by the low-rank adapter model, and the scene and actions are controlled by the user input.
[0048] For text-generated assets, the specific implementation of parameterized injection includes: using the character setting text as part of the system prompts to define the character's personality, speaking style, and behavioral characteristics; using the user-input dialogue content as user messages to construct the dialogue context; and calling a large language model to generate responses, with the model output content conforming to the speaking style and personality characteristics in the character setting.
[0049] For speech synthesis assets, the specific implementation of parameter injection includes: using the sound model as the weight or style vector of the speech synthesis model; converting the user-input text into speech features; calling the speech synthesis model to generate audio, where the timbre and pitch of the audio are controlled by the sound model.
[0050] When the features of static assets are fused with user input, the generated result cannot be used to infer the content of the original static assets. For example, in image generation, the generated image contains a portrait of a person controlled by a low-rank adapter model, but the weights of the original low-rank adapter model cannot be extracted from the image. Similarly, in text generation, the generated dialogue matches the character setting, but the complete character setting document cannot be extracted from the dialogue text.
[0051] The system records the number of times the execution request is invoked and settles revenue with creative asset holders and workflow developers according to a preset ratio. This step is performed by the settlement module, which includes a usage statistics unit and an automatic settlement unit.
[0052] The usage statistics unit records detailed information for each execution request, including the call timestamp, consumer identifier, encrypted container identifier, execution status, execution step summary, and output result summary. The statistical data is stored in an auditable database, supporting post-event auditing and reconciliation.
[0053] The automatic settlement unit calculates the revenue for each party according to preset revenue distribution rules. The revenue distribution rules are determined by the creative asset holder and workflow developer during asset packaging, and can adopt a pay-per-use model, a subscription model, or a quota-based model.
[0054] Settlement records can be stored using an auditable database or a chain-linked evidence storage mechanism to ensure that revenue records are tamper-proof and support subsequent audits.
[0055] Specific implementation examples: Example 1: Trading of Celebrity Digital Human Generation Workflow Execution Rights. In this example, celebrity A authorizes the right to use their image, and workflow developer B provides a dance video generation workflow defined using a macro instruction protocol. The system encapsulates both into a tradable workflow execution right object. The specific process is as follows: Step 1, celebrity A uploads a low-rank adapter model of their image, and the system generates an asset identifier; Step 2, developer B uploads a dance video generation workflow definition file, which includes macro instruction steps such as video segmentation, pose extraction, image generation, and video synthesis; Step 3, the system encapsulates the static asset and workflow definition into an asset encapsulation encryption container; Step 4, the consumer purchases 200 call rights; Step 5, the consumer initiates an execution request, and the unified orchestration execution module schedules the corresponding execution unit to generate the dance video according to the execution plan; Step 6, the system completes automatic settlement based on the execution audit log; Step 7, after the number of calls is exhausted, the execution right must be obtained again.
[0056] Example 2: Novel Character Dialogue Workflow Execution Rights Trading. In this example, the author authorizes character setting text, the workflow developer provides a character dialogue workflow defined using a macro instruction protocol, and consumers purchase execution rights in rounds. The specific process is as follows: Step 1, the author uploads the character setting text library; Step 2, the developer uploads the character dialogue workflow definition file containing macro instruction steps for context management, dialogue generation, and style control; Step 3, the system encapsulates and generates an asset encapsulation encryption container; Step 4, consumers purchase execution rights in rounds; Step 5, the unified orchestration execution module calls the target model according to the execution plan to generate responses that conform to the character settings; Step 6, the system settles accounts with the author and workflow developer proportionally based on the execution audit logs.
[0057] At the system level, the workflow asset encapsulation module is deployed on the server side, responsible for asset encryption and encapsulation; the protocol parsing and compilation module is deployed on the orchestration layer, responsible for parsing macro instruction protocol workflows and generating execution plans; the unified orchestration execution module is deployed on the scheduling layer, responsible for distributing execution tasks; the trusted execution and auditing module is deployed on a server that supports hardware-level isolation; and the settlement module is integrated with the payment system or an auditable database to support automatic settlement and audit tracing.
[0058] During system operation, data flow strictly adheres to timing and security constraints. Creative asset holders upload static assets, triggering encapsulation; workflow developers upload macro instruction protocol workflow definitions, triggering binding; consumers call execution interfaces, triggering unified orchestration; the trusted execution environment decrypts and executes workflow assets according to the execution plan; and the settlement module completes automatic settlement based on execution audit logs.
[0059] In this embodiment, the execution plan generated by the compilation module includes at least: The order of steps execution; Target execution unit address, call parameters, input source reference, and output target reference; Variable mapping relationships and step status feedback relationships.
[0060] In this embodiment, the execution control module generates risk differentiation parameters based on the risk quantification assessment results, wherein the risk quantification assessment includes at least: Extract at least one of the following characteristics based on historical execution records or simulated execution results: revenue volatility characteristics, call stability characteristics, and asset reuse characteristics; The features are compared with a preset risk threshold to generate risk differentiation parameters for adjusting the execution power strategy.
[0061] In this embodiment, the fault tolerance comparison method in the risk quantification assessment includes: Based on the corresponding return volatility threshold, execution stability threshold, or call deviation threshold in the built-in risk library, tolerance judgment is made on the execution result deviation and step call stability to generate structural risk indicators. Based on the aforementioned structural risk indicators, at least one of the following can be adaptively adjusted: the scope of execution authority authorization, the upper limit of invocation, or the risk warning level.
[0062] In this embodiment, the execution right transaction strategy includes at least one or more of the following: execution count constraints, invocation time period constraints, parameter boundary constraints, callable resource range constraints, and revenue settlement rules: The execution count constraint is used to count and control the number of times the asset encapsulation encryption container is called in the unified orchestration execution module, and to block subsequent execution requests when the preset call limit is reached. The call time period constraint is used to limit the execution plan to be triggered within a preset time interval, and to reject or delay execution requests during unauthorized time periods. The parameter boundary constraints are used to verify the range of input parameter values, parameter types, or parameter combination relationships in macro instruction steps. When the input parameters exceed the preset boundary conditions, the call of the corresponding execution unit is prevented. The callable resource scope constraints and revenue settlement rules are used to limit the access scope of the target execution resource or service interface corresponding to the resource definition field in the macro instruction step, and to intercept resource calls that exceed the authorized scope during execution.
[0063] In this embodiment, the process of injecting immutable parameters includes: prompt word template construction, parameter injection, context assembly, and model invocation; The process of constructing the prompt word template is as follows: using the guiding prompt words in static assets as system-level instructions and the few sample examples as context references to construct a multi-layer prompt word structure; The parameter injection process is as follows: the style parameter configuration limited by the execution right strategy is injected into the interface parameters of the model calling step, including at least one of temperature, maximum length, and repetition penalty; The context assembly process is as follows: assemble the complete prompt words in the order of system layer, reference layer, and input layer; The process of model invocation is as follows: the target model or target workflow step is invoked using the assembled prompts and parameters to ensure that the post-transaction asset execution process is subject to the authorized scope and the output results are auditable.
[0064] In this embodiment, the settlement module performs revenue settlement based on the execution audit log, and the revenue settlement method includes: Extract the number of calls, execution time, execution subject, and execution result summary from the execution audit log; The revenue share of the idea holder and the workflow developer is calculated according to the preset revenue distribution rules. Add structured identifiers to transaction records that meet risk warning conditions or abnormal execution conditions; Generate a settlement record associated with the execution audit log; Automatic settlement is performed for idea holders and workflow developers based on the settlement records.
[0065] In this embodiment, the revenue sharing persistence determination function can serve as an auxiliary function for the settlement module to identify abnormal revenue fluctuations. The system acquires the transaction revenue sequence within a time window T, calculates the mean and standard deviation of the revenue sequence within the window, and constructs a revenue outlier determination index Di and a revenue outlier composition feature function Fo to identify abnormal revenue records.
[0066] The specific calculation formula is as follows: , , Where, r i Let w be the revenue generated by the i-th creative asset execution right call, n be the number of transactions within the time window T, and w be the total revenue. i Let t be the profit weighting coefficient for the i-th transaction. i Let V be the timestamp of the i-th transaction. r β is the volatility indicator of the rate of change in returns, and β is the volatility adjustment parameter.
[0067] , Where, when D i When the return is greater than λ, the return of the i-th transaction is determined to be an outlier return, where λ is a preset percentage threshold. , Where, N o To satisfy D i The number of outlier transactions greater than λ, when F o When the threshold θ is exceeded, the system determines that there is abnormal fluctuation in the profit of the transaction window.
[0068] In this embodiment, the unified orchestration execution module binds the conditional triggering execution and output verification of workflow steps. The binding process includes: The execution semantics of each macro instruction step in the executable workflow are parsed, conditional rule parameters are extracted, and a unique execution status identifier is established for each macro instruction step. The conditional rule parameters include step triggering conditions, input parameter constraints, and output data types; Based on the execution status identifier, the verification result and the step execution status are jointly recorded, and based on the execution dependencies and data flow paths between workflow steps, an association mapping table between step triggering rules and output verification rules is constructed. The association mapping table is used to bind the triggering conditions of each step with the corresponding output verification.
[0069] In this embodiment, the process of generating the execution audit log includes: In a trusted execution environment, execution events are captured during the execution of execution rights, and corresponding event data units are generated. The event data unit is time-series encoded to generate a digital signature identifier; Based on the digital signature identifier, each execution event is linked in a chain according to the execution order to form an audit log data chain with sequential dependencies; The execution event data associated with the audit log data chain and the corresponding execution result summary are uniformly encapsulated, and the encapsulated log structure is solidified to obtain the execution audit log.
[0070] In this embodiment, the trusted execution environment has at least the following characteristics: hardware isolation, memory encryption, remote authentication, and execution non-eavesdropping. The hardware isolation feature is: through an independent execution space, independent address space mapping and access control are performed on the execution code segment, data segment, and calling context; The memory encryption feature is as follows: lifecycle management is performed on the execution session key loaded into memory, and automatic encryption is performed when it is stored in dynamic random access memory; The remote proof feature is as follows: a cryptographic proof is generated at startup and signed by the hardware root key inside the trusted execution environment; The cryptographic proof is used to remotely verify the authenticity and integrity of the execution environment and whether the operating environment meets the authorization requirements; The non-eavesdropping feature is achieved by establishing a context isolation segment within the workflow asset execution process; The context isolation segment is used to prevent side-channel eavesdropping from capturing or inferring sensitive information during execution.
[0071] In other embodiments, the trusted execution environment may also be linked with the unified orchestration execution module, allowing the execution plan to be started only after remote verification is successful.
[0072] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.
Claims
1. An AI-powered creative asset execution right trading system based on macro instruction workflow, characterized in that, include: Workflow Asset Encapsulation Module: Used to atomically encapsulate static asset data, executable workflows defined using macro instruction protocols, execution constraint information, and revenue distribution rules to generate an asset encapsulation encrypted container; Protocol parsing and compilation module: used to parse multiple macro instruction steps in the executable workflow, verify step identifiers, type identifiers, dependencies and input / output reference relationships, construct a directed acyclic graph, and compile and generate an execution plan based on the directed acyclic graph; Execution control module: used to generate execution right transaction strategy based on the risk quantification assessment results of the asset encapsulation encryption container, and limit at least one of the following: number of executions, call period, parameter boundaries, and scope of callable resources; Unified orchestration and execution module: used to distribute execution tasks to execution units of the corresponding type based on the type identifier and dependencies in the execution plan; Trusted Execution and Audit Module: Used to perform controlled decryption and execution of the asset encapsulation encryption container in a trusted execution environment, record the execution process and generate execution audit logs; Settlement module: Used to settle revenue with creative holders and workflow developers based on the execution audit logs and revenue distribution rules.
2. The system according to claim 1, characterized in that, The executable workflow adopts a macro instruction protocol format, and the macro instruction steps include at least: Step identifier field, type identifier field, resource definition field, input definition field, output definition field, and dependency field; The type identifier includes at least model call type, HTTP call type, MCP tool call type, code execution type, and workflow call type; The input definition field, output definition field, and dependency field are used to describe the data flow relationship and execution dependency relationship between macro instruction steps.
3. The system according to claim 1, characterized in that, The asset encapsulation encryption container includes at least: a static asset encryption layer, a workflow definition layer, an execution constraint layer, a key protection layer, and an audit verification layer; The static asset encryption layer is used to perform structured block processing on static asset data and control the on-demand decryption and minimum permission access of the static asset data during execution. The workflow definition layer is used to store executable workflows defined using a macro instruction protocol. The execution constraint layer is used to record at least one of the following: execution count, invocation period, parameter boundaries, and callable resource range; The key protection layer and audit verification layer are used to perform controlled activation of the encryption key and integrity verification of the execution process, respectively.
4. The system according to claim 1, characterized in that, The execution plan generated by the compilation module includes at least: The order of steps execution; Target execution unit address, call parameters, input source reference, and output target reference; Variable mapping relationships and step status feedback relationships.
5. The system according to claim 1, characterized in that, The execution control module generates risk differentiation parameters based on the risk quantification assessment results, wherein the risk quantification assessment includes at least: Extract at least one of the following characteristics based on historical execution records or simulated execution results: revenue volatility characteristics, call stability characteristics, and asset reuse characteristics; The features are compared with a preset risk threshold to generate risk differentiation parameters for adjusting the execution power strategy.
6. The system according to claim 5, characterized in that, The fault tolerance comparison method in the risk quantification assessment includes: Based on the corresponding return volatility threshold, execution stability threshold, or call deviation threshold in the built-in risk library, tolerance judgment is made on the execution result deviation and step call stability to generate structural risk indicators. Based on the aforementioned structural risk indicators, at least one of the following can be adaptively adjusted: the scope of execution authority authorization, the upper limit of invocation, or the risk warning level.
7. The system according to claim 1, characterized in that, The execution right transaction strategy includes at least one or more of the following: execution count constraints, invocation time period constraints, parameter boundary constraints, callable resource range constraints, and revenue settlement rules: The execution count constraint is used to count and control the number of times the asset encapsulation encryption container is called in the unified orchestration execution module, and to block subsequent execution requests when the preset call limit is reached. The call time period constraint is used to limit the execution plan to be triggered within a preset time interval, and to reject or delay execution requests during unauthorized time periods. The parameter boundary constraints are used to verify the range of input parameter values, parameter types, or parameter combination relationships in macro instruction steps. When the input parameters exceed the preset boundary conditions, the call of the corresponding execution unit is prevented. The callable resource scope constraints and revenue settlement rules are used to limit the access scope of the target execution resource or service interface corresponding to the resource definition field in the macro instruction step, and to intercept resource calls that exceed the authorized scope during execution.
8. The system according to claim 1, characterized in that, The execution control module is also used to constrain immutable parameters during workflow execution. The process of injecting immutable parameters includes: prompt word template construction, parameter injection, context assembly, and model invocation. The process of constructing the prompt word template is as follows: using the guiding prompt words in static assets as system-level instructions and the few sample examples as context references to construct a multi-layer prompt word structure; The parameter injection process is as follows: the style parameter configuration limited by the execution right strategy is injected into the interface parameters of the model calling step, including at least one of temperature, maximum length, and repetition penalty; The context assembly process is as follows: assemble the complete prompt words in the order of system layer, reference layer, and input layer; The process of model invocation is as follows: the target model or target workflow step is invoked using the assembled prompts and parameters to ensure that the post-transaction asset execution process is subject to the authorized scope and the output results are auditable.
9. The system according to claim 1, characterized in that, The settlement module performs revenue settlement based on the execution audit log, and the revenue settlement method includes: Extract the number of calls, execution time, execution subject, and execution result summary from the execution audit log; The revenue share of the idea holder and the workflow developer is calculated according to the preset revenue distribution rules. Add structured identifiers to transaction records that meet risk warning conditions or abnormal execution conditions; Generate a settlement record associated with the execution audit log; Automatic settlement is performed for idea holders and workflow developers based on the settlement records.
10. The system according to claim 1, characterized in that, The unified orchestration and execution module is also used to bind conditional triggering execution and output verification of workflow steps. The binding process includes: The execution semantics of each macro instruction step in the executable workflow are parsed, conditional rule parameters are extracted, and a unique execution status identifier is established for each macro instruction step. The conditional rule parameters include step triggering conditions, input parameter constraints, and output data types; Based on the execution status identifier, the verification result and the step execution status are jointly recorded, and based on the execution dependencies and data flow paths between workflow steps, an association mapping table between step triggering rules and output verification rules is constructed. The association mapping table is used to bind the triggering conditions of each step with the corresponding output verification.
11. The system according to claim 1, characterized in that, The process of generating the execution audit log includes: In a trusted execution environment, execution events are captured during the execution of execution rights, and corresponding event data units are generated. The event data unit is time-series encoded to generate a digital signature identifier; Based on the digital signature identifier, each execution event is linked in a chain according to the execution order to form an audit log data chain with sequential dependencies; The execution event data associated with the audit log data chain and the corresponding execution result summary are uniformly encapsulated, and the encapsulated log structure is solidified to obtain the execution audit log.
12. The system according to claim 1, characterized in that, The trusted execution environment shall have at least the following characteristics: hardware isolation, memory encryption, remote authentication, and execution non-eavesdropping. The hardware isolation feature is: through an independent execution space, independent address space mapping and access control are performed on the execution code segment, data segment, and calling context; The memory encryption feature is as follows: lifecycle management is performed on the execution session key loaded into memory, and automatic encryption is performed when it is stored in dynamic random access memory; The remote proof feature is as follows: a cryptographic proof is generated at startup and signed by the hardware root key inside the trusted execution environment; The cryptographic proof is used to remotely verify the authenticity and integrity of the execution environment and whether the operating environment meets the authorization requirements; The non-eavesdropping feature is achieved by establishing a context isolation segment within the workflow asset execution process; The context isolation segment is used to prevent side-channel eavesdropping from capturing or inferring sensitive information during execution.