Identity authentication method, agent cross-domain calling method and agent network system

Abstract

The application relates to the technical field of communication, and discloses an identity authentication method, an intelligent agent cross-domain calling method and an intelligent agent network system. The system comprises an end-side device and a cloud-side processor. The end-side device prestores a digital identity certificate and cross-domain network registration information through an eSIM, completes identity authentication to a blockchain network, and obtains a cross-domain communication link and network resource access permission. The cloud-side processor matches and calls a cloud-side intelligent agent for processing according to a task request of the end-side device, executes privacy calculation on business data under the constraint of a compliance processing strategy, and returns a safe result that cannot be reversely pushed to the end-side device. The application realizes safe access and intelligent service calling of the end-side device across operators and across network domains, ensures identity credibility, data traceability and operation auditability in combination with the blockchain, and builds an end-cloud-chain cooperative decentralized intelligent agent network architecture.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an authentication method, a cross-domain invocation method for intelligent agents, and an intelligent agent network system. Background Technology

[0002] Traditional edge devices (such as IoT terminals and smartphones) typically rely on centralized roaming protocols or pre-built static identity credentials to complete identity verification and network registration in cross-domain network scenarios (such as cross-border roaming and cross-carrier switching).

[0003] However, the above approach has the following drawbacks: roaming protocols require establishing bilateral trust relationships between different operators one by one, which is complex to manage and has poor scalability, especially for a large number of IoT devices that are difficult to dynamically adapt to. Summary of the Invention

[0004] The purpose of this invention is to provide at least one authentication method, one method for cross-domain invocation of intelligent agents, and one intelligent agent network system. These methods can at least solve the technical problems of existing roaming protocols requiring the establishment of bilateral trust relationships between different operators one by one, which are complex to manage and have poor scalability. They can at least improve the flexibility of cross-domain network access.

[0005] To address the aforementioned technical problems, at least one embodiment of this application provides an authentication method applied to an information pre-installation device, comprising: Request the blockchain network to assign digital identity credentials for the hardware identification information of the edge device; The digital identity credential and cross-domain network registration information are written into the eSIM of the terminal device, so that the terminal device can initiate identity verification and cross-domain network connection to the blockchain network based on the digital identity credential and cross-domain network registration information; The association information between the digital identity credential and the hardware identification information, as well as the cross-domain network registration information, are recorded on the blockchain network.

[0006] In this embodiment, a pre-configured information device applies for a digital identity credential generated by the blockchain network for the end-device, and writes the credential and cross-domain network registration information into the eSIM. This enables the end-device to perform decentralized identity verification based on the blockchain in cross-domain scenarios, while simultaneously storing the association information between the credential and the hardware identifier on the blockchain. This not only simplifies the cross-domain trust establishment process but also achieves tamper-proof and traceable identity information, significantly improving the security and flexibility of cross-domain network access.

[0007] At least one embodiment of this application also provides a network handover method, applied to an end-side device, comprising: An authentication request is initiated to the blockchain network. The terminal device has completed cross-domain network registration and obtained a communication link through the cross-domain network registration information pre-stored in the eSIM. The authentication request includes the digital identity credential of the terminal device. The blockchain network pre-stores association information between the digital identity credentials of multiple terminal devices and the hardware identification information. After the blockchain network verifies the validity of the digital identity credential based on the associated information, it returns an access token and access permissions, and obtains the corresponding network resources based on the access token and access permissions.

[0008] In this application, the end device does not need to rely on the complex roaming protocols between traditional operators. Instead, it can quickly complete local network registration and obtain a basic communication link by directly using the cross-domain network registration information pre-stored in the eSIM. Then, it sends an identity verification request carrying digital identity credentials to the blockchain network. The blockchain network uses the association information between its pre-stored digital identity credentials and hardware identification information to verify the validity of the credentials. After successful verification, it returns an access token and access permission, which enables the end device to dynamically obtain the corresponding network resources based on the token and permission. This achieves decentralized cross-domain trust establishment, significantly simplifies the authentication process, and reduces the interoperability costs of operators.

[0009] At least one embodiment of this application also provides a method for cross-domain invocation of intelligent agents, applied to a cloud-side processor, including: The receiving end-side device initiates a task request. The end-side device completes identity authentication with the blockchain network and obtains network resources after obtaining network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. In the cloud-side intelligent agent, a target knowledge module is matched for the task request, wherein the cloud-side intelligent agent pre-stores multiple knowledge modules obtained by standardizing and encapsulating knowledge. The target knowledge module is invoked to process the task request, and the processing result is returned to the end device.

[0010] In this embodiment, cross-domain trusted access (based on eSIM and blockchain) and intelligent agent capability orchestration (based on standardized knowledge modules) are organically integrated. On the one hand, this ensures that only external domain devices that have undergone strict identity authentication and authorization can call cloud-side intelligent agent capabilities, effectively preventing unauthorized access and malicious calls. On the other hand, through the standardized encapsulation of knowledge modules, the business logic and the underlying implementation are decoupled, improving the accuracy of task matching and the efficiency of calling.

[0011] At least one embodiment of this application also provides a data processing method applied to a cloud-side processor, comprising: The receiving end-side device sends service data. The end-side device completes identity authentication with the blockchain network and obtains network resource access to the current network domain through cross-domain network registration information and digital identity credentials pre-stored in eSIM. A compliance processing strategy for the business data is determined so that the cloud-side intelligent agent performs corresponding calculations on the business data under the constraints of the compliance processing strategy, and returns the calculation results to the edge device. The compliance processing strategy includes the types of calculations allowed to be performed on the business data and the constraints. The behavioral data generated during the compliance process is recorded on the blockchain network.

[0012] In this embodiment, the edge device authenticates its identity with the blockchain network and obtains network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. It then securely accesses the current network domain and sends business data. The cloud-side processor determines a compliance processing strategy based on the attributes of the business data, clearly defining the permitted computation types and constraints. This ensures that the cloud-side intelligent agent executes data processing under the strict constraints of the strategy, thereby preventing unauthorized cross-border data flows or computational activities and effectively meeting the compliance requirements for data sovereignty in different countries and industries. Furthermore, the cloud-side processor stores the behavioral data generated during the compliance processing on the blockchain network, forming an immutable audit log for easy post-event supervision, traceability, and accountability.

[0013] At least one embodiment of this application also provides a network access method, applied to an end-side device, comprising: Network handover process: In the state of being connected to the first network domain of the first operator, according to the current network cross-domain handover requirements, a second network domain is selected from the candidate operator list using a preset handover strategy. The second network domain belongs to the same or different operator as the first operator. Activate the cross-domain network registration information pre-stored in the eSIM corresponding to the second operator, obtain the communication link that accesses the second network domain, and perform access to the second network domain; Identity verification process: Based on the communication link of the second network domain accessed, an identity and permission verification request is initiated to the blockchain network to obtain an access token and access permission for specific network resources provided by the second operator after successful verification; wherein, the identity verification request includes the digital identity credential of the end device, and the blockchain network pre-stores the association relationship between the hardware identity information of multiple end devices and distributed identity identifiers; Access to specific network resources of the second operator is granted based on the access token and the access permission.

[0014] In this embodiment, the terminal device, already connected to the first operator's network domain, autonomously selects a second network domain from the candidate operator list based on a preset switching strategy according to cross-domain handover requirements. It then quickly obtains a communication link to the second network domain by activating the cross-domain network registration information pre-stored in the eSIM, without needing to replace the physical card or require manual intervention. This achieves smooth and dynamic network handover between different operators or even different domains within the same operator. After obtaining the basic link, the terminal device immediately initiates an identity and permission verification request to the blockchain network based on this link. The blockchain network uses the association between its pre-stored hardware identity information and distributed identity identifier to verify the terminal device's digital identity credentials. Upon successful verification, it returns an access token and access permission for specific network resources provided by the second operator, thereby enabling the terminal device to securely and controllably obtain the differentiated network capabilities of the target operator.

[0015] In some optional embodiments, it also includes: Identity registration process: The system receives and stores digital identity credentials sent by the information pre-configuration device in the eSIM, wherein the digital identity credentials are assigned by the information pre-configuration device to the blockchain network for the hardware identification information of the end-side device.

[0016] In this embodiment, the digital identity credential assigned by the blockchain network to the hardware identifier is pre-securely written into the eSIM, enabling the terminal device to obtain an immutable on-chain identity. This provides a trusted root for subsequent cross-domain switching and rapid authentication, simplifies the device network access process, and improves the security of identity initialization.

[0017] In some optional embodiments, it also includes: During the network switching process, behavioral data is collected and uploaded to the blockchain network.

[0018] In this embodiment, the switching behavior is made traceable, which facilitates post-event auditing, fault diagnosis, and accountability for security incidents.

[0019] At least one embodiment of this application also provides a method for cross-domain invocation of intelligent agents, applied to a cloud-side processor, including: Knowledge encapsulation stage: The knowledge pre-stored on the cloud side is standardized and encapsulated to obtain multiple knowledge modules, and each knowledge module serves as a cloud-side intelligent agent for invocation. To generate business association relationships between each of the multiple preset business processes and the multiple knowledge modules, the business association relationships are used to describe the knowledge modules associated with each business process; Task invocation phase: The receiving end-side device initiates a task request. The end-side device completes identity authentication with the blockchain network and obtains network resources after obtaining network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. Based on the business relationship, a target knowledge module is matched for the task request, the target knowledge module is invoked to process the task request, and the processing result is returned to the end device.

[0020] In this embodiment, pre-stored knowledge in the cloud is standardized and encapsulated into multiple flexibly invoked knowledge modules. Business relationships between these knowledge modules are pre-generated for each business process. This allows the cloud processor to quickly and accurately match the target knowledge module based on these relationships when receiving task requests from the edge device. This avoids the complex process of retrieving or understanding the entire knowledge set each time, as is common in traditional methods, significantly improving task response speed and invocation accuracy. Simultaneously, the edge device securely accesses the current network domain after completing identity authentication and obtaining network resources through cross-domain network registration information and digital identity credentials pre-stored in the eSIM. This ensures that only devices with trusted verification can initiate task calls, effectively preventing unauthorized access and malicious requests.

[0021] In some optional embodiments, the business data included in the task request carries classification tags, source identifiers, and / or sensitivity levels, and the task invocation process further includes: Based on the classification label, source identifier, and / or sensitivity level, a compliance processing strategy is determined for the business data, so that the cloud-side intelligent agent performs privacy computation on the business data under the constraints of the compliance processing strategy, generating an irreversible security result to be returned to the edge device. The compliance processing strategy includes the types of computations allowed to be performed on the business data and the constraints.

[0022] In this embodiment, compliance processing strategies are automatically matched by classifying business data by labels, source identifiers, or sensitivity levels. This constrains cloud-side intelligent agents to perform only permitted privacy-preserving computations, generating irreversible security results. This achieves compliant data processing while fully protecting data privacy, effectively preventing sensitive data leakage or unauthorized cross-border computations, and meeting the regulatory requirements of multiple countries and industries.

[0023] In some optional embodiments, it also includes: Generate a data lineage record for the business data, the data lineage record including data source, transformation chain and / or usage trajectory; The call records of the knowledge modules, the summary of the task requests, the data lineage records, the compliance check summary, and / or the privacy computing task summary are uploaded to the blockchain network.

[0024] In this embodiment, a traceable and tamper-proof audit log for the entire data processing process is implemented, which facilitates compliance verification and security incident tracing in cross-border data scenarios, and significantly improves the transparency and credibility of data flow.

[0025] At least one embodiment of this application also provides an intelligent agent network system, including: an edge device and a cloud-side processor. The end-side device is used to execute any of the network handover method and network access method described above; The cloud-side processor is used to execute the aforementioned cross-domain invocation method for intelligent agents.

[0026] In this embodiment, through the collaborative cooperation between the edge device and the cloud processor, the identity credentials carried by the eSIM, the decentralized trust storage of the blockchain, and the standardized capability encapsulation and secure data computation of the cloud-side intelligent agent are organically integrated. This achieves a secure closed loop throughout the entire process of device identity authentication, network access, intelligent task invocation, and compliant data processing in cross-domain scenarios. It significantly improves the overall efficiency of the cross-domain intelligent agent network system while ensuring high security and traceability. Attached Figure Description

[0027] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0028] Figure 1 This is a flowchart of an authentication method provided in one embodiment of this application. Figure 1 ; Figure 2 This is a flowchart of an authentication method provided in one embodiment of this application. Figure 2 ; Figure 3 This is a flowchart of a network handover method provided in one embodiment of this application. Figure 1 ; Figure 4 This is a flowchart of a network handover method provided in one embodiment of this application. Figure 2 ; Figure 5 This is a flowchart of a cross-domain invocation method for intelligent agents provided in one embodiment of this application. Figure 1 ; Figure 6 This is a flowchart of a data processing method provided in one embodiment of this application. Figure 1 ; Figure 7 This is a flowchart of a network access method provided in one embodiment of this application; Figure 8This is a flowchart of a cross-domain invocation method for intelligent agents provided in one embodiment of this application. Figure 2 ; Figure 9 This is a schematic diagram of the network architecture of an intelligent agent network system provided in one embodiment of this application; Figure 10 This is a flowchart of the end-side device identity binding process provided in one embodiment of this application; Figure 11 This is a flowchart illustrating cross-border network access provided in one embodiment of this application; Figure 12 This is a flowchart of a cross-domain invocation method for intelligent agents provided in one embodiment of this application. Figure 3 ; Figure 13 This is a flowchart of a data processing method provided in one embodiment of this application. Figure 2 ; Figure 14 This is a structural diagram of an intelligent agent network system provided in one embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0030] This invention proposes an authentication method, a cross-domain invocation method for intelligent agents, and an intelligent agent network system. The implementation details of the network switching method in this embodiment are described below. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0031] Example 1: The authentication method of this embodiment can be applied to information pre-installed devices with communication, computing, and data storage capabilities. Its specific process can be as follows: Figure 1 As shown, it includes: Step 110: Request the blockchain network to assign a digital identity credential to the hardware identification information of the end device; In this embodiment, the information pre-configuration device is a device used to perform initial configuration of the end-side device during the production, delivery, or deployment phase. It can be a production line programming tool, a security programmer, a management server, etc., and has the ability to communicate with the blockchain network.

[0032] End-side devices refer to the terminal devices used by users, such as smartphones, IoT sensors, vehicle-mounted units, and low-altitude intelligent agents. Hardware identification information refers to the unique identifiers that can uniquely identify the hardware of the end-side device, such as IMEI (International Mobile Equipment Identity), MAC address, device serial number, and chip ID.

[0033] Digital identity credentials refer to the distributed digital identity identifier (such as DID) generated by the blockchain network for the end device, along with its associated public key, certificate, or metadata, used to uniquely and unforgeably represent the end device within the network.

[0034] The interaction flowchart between the execution entities involved in the network switching method of this embodiment is as follows: Figure 2 As shown, the pre-installed information device initiates a transaction or calls a smart contract to the blockchain network, submits hardware identification information, and requests the blockchain network to generate and return the corresponding digital identity credential.

[0035] Step 120: Write the digital identity credential and cross-domain network registration information into the eSIM of the terminal device, so that the terminal device can initiate identity verification and cross-domain network connection to the blockchain network based on the digital identity credential and the cross-domain network registration information; Specifically, the end-device has an eSIM (embedded subscriber identity module). The eSIM can be remotely written to the operator's configuration file and security data. Cross-domain network registration information refers to the configuration data (operator configuration file) required for the end-device to access the local network in cross-domain scenarios (such as cross-border or cross-operator scenarios). For example, the target operator's PLMN (Public Land Mobile Network) identifier, Access Point Name (APN), authentication parameters, etc.

[0036] The information pre-installed device writes cross-domain network registration information and digital identity credentials into the storage area of ​​the eSIM. The terminal device can then rely on the cross-domain network registration information pre-installed in the eSIM to independently initiate identity verification to the blockchain network and complete the cross-domain network connection without the need for manual configuration again.

[0037] Step 130: Record the association information between the digital identity credential and the hardware identification information, as well as the cross-domain network registration information, on the blockchain network.

[0038] Specifically, the associated information can be the binding relationship between digital identity credentials and hardware identification information. For example, it can be recorded as a key-value pair mapping of "device serial number-DID", or the hash of the concatenated two can be stored as evidence. The pre-installed device submits the above-mentioned associated information and cross-domain network registration information (or its digest) as transaction data to the blockchain network. After consensus, it is stored in the distributed ledger, forming an immutable record. This allows any entity (such as operators or regulators) to verify the legitimate identity of the device and the pre-installed cross-domain registration information through blockchain queries, preventing forgery and repudiation.

[0039] In summary, this embodiment uses a pre-configured information device to apply for a digital identity credential generated by the blockchain network for the end-device, and writes this credential and cross-domain network registration information into the eSIM. This enables the end-device to perform decentralized identity verification based on the blockchain in cross-domain scenarios, while simultaneously storing the association information between the credential and the hardware identifier on the blockchain. This not only simplifies the cross-domain trust establishment process but also achieves tamper-proof and traceable identity information, significantly improving the security and flexibility of cross-domain network access.

[0040] Example 2: The network switching method of this embodiment can be applied to end-side devices with communication, computing, and data storage capabilities. Its specific process can be as follows: Figure 3 As shown, it includes: Step 310: An authentication request is initiated to the blockchain network. The terminal device has completed cross-domain network registration and obtained a communication link through the cross-domain network registration information pre-stored in the eSIM. The authentication request includes the digital identity credential of the terminal device. The blockchain network pre-stores association information between the digital identity credentials of multiple terminal devices and the hardware identification information. Specifically, when a device enters a new network domain (such as across borders or between different operators), it activates the cross-domain network registration information pre-stored within its eSIM chip, completes the registration process with the local operator's basic network, and thus obtains a basic communication link that can be used for data transmission. This process does not rely on blockchain; it only utilizes the configuration capabilities of the eSIM to achieve traditional network access.

[0041] After the basic link is established, the end device sends a dedicated authentication request message to the blockchain network (such as a blockchain node deployed on the public network or the operator's intranet) through this link. The request carries a digital identity credential obtained by the end device during the manufacturing or pre-configuration stage. This credential is pre-assigned by the blockchain network based on the device's hardware identification information, such as a DID (Distributed Identity Authentication Code), and a challenge value or timestamp signed using the device's private key, which is used to prove that the device holds the private key corresponding to the credential.

[0042] The wallets in the blockchain network have been pre-written with information pre-installed devices, which bind the digital identity credentials of multiple end devices to their corresponding hardware identification information (such as IMEI, MAC address, etc.). This association information is immutable and can be queried during verification.

[0043] Step 320: After the blockchain network verifies the validity of the digital identity credential based on the association information, it returns an access token and access permission. Based on the access token and access permission, the corresponding network resources are obtained.

[0044] Specifically, if the blockchain network verifies the validity of the digital identity credentials, it generates an access token for the session (typically a short-lived timestamp or random number, signed with the blockchain's private key) and corresponding access permissions (such as the allowed bandwidth limit, accessible service types, and validity period). This information is returned to the end device in the form of a response message.

[0045] After obtaining the access token and access permissions, the end-device carries this token in subsequent network interactions and can initiate resource requests to the operator's network capability open platform (such as OpenGateway). After verifying the token's validity and the scope of permissions, the capability platform allocates promised network resources to the device (such as improving QoS levels, establishing dedicated bearers, and allowing access to specific service slices), thereby enabling differentiated network service acquisition based on blockchain authorization in cross-domain scenarios. A detailed interaction diagram of the parties involved in the network handover method is shown below. Figure 4 As shown.

[0046] In this application, the end device does not need to rely on the complex roaming protocols between traditional operators. Instead, it can quickly complete local network registration and obtain a basic communication link by directly using the cross-domain network registration information pre-stored in the eSIM. Then, it sends an identity verification request carrying digital identity credentials to the blockchain network. The blockchain network uses the association information between its pre-stored digital identity credentials and hardware identification information to verify the validity of the credentials. After successful verification, it returns an access token and access permission, which enables the end device to dynamically obtain the corresponding network resources based on the token and permission. This achieves decentralized cross-domain trust establishment, significantly simplifies the authentication process, and reduces the interoperability costs of operators.

[0047] Example 3: This embodiment also provides a method for cross-domain invocation of intelligent agents. This method can be applied to cloud-side processors with communication, computing, and data storage capabilities, and its specific process can be as follows: Figure 5 As shown, it includes: Step 510: Receive a task request initiated by the end device. The end device completes identity authentication with the blockchain network and obtains network resources after obtaining network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. In this embodiment, when the end device enters the current network domain (e.g., a new country or operator's coverage area), it first completes local network registration using the cross-domain network registration information pre-installed in its eSIM (such as the target operator's PLMN, authentication parameters, etc.) to obtain a basic communication link. Subsequently, the end device initiates an identity authentication request to the blockchain network based on the digital identity credentials in the eSIM. After verifying the validity of the credentials, the blockchain network issues an access token and access permissions, thereby enabling the end device to access the current network domain and use network resources (such as data connection, QoS guarantee, etc.). This process ensures that only legitimate devices can enter the network and send data. The generation process of cross-domain network registration information and digital identity credentials is similar to that in the above embodiment, and will not be described in detail here to avoid repetition.

[0048] Step 520: Match the target knowledge module for the task request in the cloud-side intelligent agent, wherein the cloud-side intelligent agent pre-stores multiple knowledge modules obtained by standardizing and encapsulating knowledge. Specifically, the cloud maintains a knowledge module library. These knowledge modules are obtained by standardizing and encapsulating various pre-stored knowledge in the cloud (such as algorithm models, business rules, data processing logic, API call templates, etc.). These standardized and encapsulated knowledge modules collectively constitute the cloud-side intelligent agent. The specific content of the standardized encapsulation includes: defining a unified interface description (such as input / output format, parameter type), calling method (synchronous / asynchronous), runtime constraints (timeout, resource requirements), and capability metadata (module function description, version number, business domain, etc.) for each module. The encapsulated modules can be automatically discovered, dynamically loaded, and combined for invocation.

[0049] After receiving a task request, the cloud-side processor parses the key information in the request (such as task type, required functions, input data characteristics, etc.), and then, based on pre-established business relationships or through semantic retrieval (such as vector similarity matching, knowledge graph query), selects one or more modules most suitable for handling the task as target knowledge modules from the knowledge module library. The matching process may consider factors such as module input / output compatibility, current load, and execution efficiency.

[0050] Step 530: Invoke the target knowledge module to process the task request and return the processing result to the end device.

[0051] Specifically, after receiving the call, the target knowledge module uses the logic encapsulated within the module (such as running a machine learning model, executing a piece of computational code, querying a database, etc.) to process the business data in the task request and generate corresponding output results (such as prediction scores, data summaries, control commands, etc.) to return to the end device.

[0052] In some optional embodiments, the cloud-side processor selects the Top-K knowledge modules or combinations of knowledge modules that best match the task request, processes the same task request separately, and outputs the confidence level of each processing result. Finally, the cloud-side processor returns the result with the highest confidence level to the edge device.

[0053] In this embodiment, cross-domain trusted access (based on eSIM and blockchain) and intelligent agent capability orchestration (based on standardized knowledge modules) are organically integrated. On the one hand, this ensures that only external domain devices that have undergone strict identity authentication and authorization can call cloud-side intelligent agent capabilities, effectively preventing unauthorized access and malicious calls. On the other hand, through the standardized encapsulation of knowledge modules, the business logic and the underlying implementation are decoupled, improving the accuracy of task matching and the efficiency of calling.

[0054] Example 4: This embodiment also provides a data processing method. The data processing method of this embodiment can be applied to cloud-side processors with communication, computing, and data storage capabilities, and its specific process can be as follows: Figure 6 As shown, it includes: Step 610: Receive service data sent by the end-side device. The end-side device completes identity authentication with the blockchain network and obtains network resource access to the current network domain through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. In this embodiment, when the end device enters the current network domain (e.g., a new country or operator's coverage area), it first completes local network registration using the cross-domain network registration information pre-installed in its eSIM (such as the target operator's PLMN, authentication parameters, etc.) to obtain a basic communication link. Subsequently, it initiates an identity authentication request to the blockchain network based on the digital identity credentials in the eSIM. After verifying the validity of the credentials, the blockchain network issues an access token and access permissions, thereby enabling the end device to access the current network domain and use network resources (such as data connection, QoS guarantee, etc.) with authorization. This process ensures that only legitimate devices can enter the network and send data. The generation process of cross-domain network registration information and digital identity credentials is similar to that in the above embodiment, and will not be described in detail here to avoid repetition.

[0055] Step 620: Determine the compliance processing strategy for the business data, so that the cloud-side intelligent agent performs corresponding calculations on the business data under the constraints of the compliance processing strategy, and returns the calculation results to the edge device. The compliance processing strategy includes the types of calculations allowed to be performed on the business data and the constraints. Specifically, defining a compliance processing strategy for the business data aims to automatically adapt to the legal, regulatory, and privacy protection requirements of different countries, industries, or business types in cross-domain (especially cross-border) data processing scenarios, avoiding legal risks or data leaks caused by unauthorized data processing. The compliance processing strategy specifies the types of computations allowed on the business data (e.g., only statistical analysis allowed, machine learning prohibited, only federated learning allowed, etc.) and specific constraints (e.g., results must be anonymized, data cannot leave the country, computation must be performed within a designated region, homomorphic encryption must be used, etc.). When executing data processing tasks, the cloud-based intelligent agent will adhere to these constraints, only calling computation modules permitted by the strategy (e.g., privacy-preserving computation operators), and all operations must be within the boundaries set by the strategy. For example, raw data cannot be written to external storage, and intermediate results cannot be sent to unauthorized addresses.

[0056] After the cloud-side intelligent agent performs calculations according to policy constraints, it obtains secure computation results. These results are then returned to the edge device via the cloud-side processor for use in the device's business decisions or user presentation.

[0057] Step 630: Record the behavioral data generated during the compliance process on the blockchain network.

[0058] Specifically, the behavioral data generated during compliance processing includes records of compliance inspection strategy decisions (which strategy was adopted, and the decision time), hash values ​​of business data, identifiers of the computing modules used, execution timestamps of computing tasks, and hashes of computing results. The cloud-side processor packages this behavioral data into transactions or notarized transactions and submits them to nodes in the blockchain network. After consensus is reached, the blockchain network writes the transaction data into a distributed ledger, forming immutable, timestamped records. Due to the decentralized and immutable nature of blockchain, any regulator or auditor can verify the compliance of the data processing process by querying on-chain records, and the edge device or cloud-side processor cannot subsequently deny or modify the records.

[0059] In this embodiment, the edge device authenticates its identity with the blockchain network and obtains network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. It then securely accesses the current network domain and sends business data. The cloud-side processor determines a compliance processing strategy based on the attributes of the business data, clearly defining the permitted computation types and constraints. This ensures that the cloud-side intelligent agent executes data processing under the strict constraints of the strategy, thereby preventing unauthorized cross-border data flows or computational activities and effectively meeting the compliance requirements for data sovereignty in different countries and industries. Furthermore, the cloud-side processor stores the behavioral data generated during the compliance processing on the blockchain network, forming an immutable audit log for easy post-event supervision, traceability, and accountability.

[0060] Example 5: This embodiment also provides a network access method. The network access method of this embodiment can be applied to end-side devices with communication, computing, and data storage capabilities, and its specific process can be as follows: Figure 7 As shown, it includes: Network handover process: Step 710: In the state of being connected to the first network domain of the first operator, according to the current network cross-domain handover requirements, a second network domain is selected from the candidate operator list using a preset handover strategy. The second operator to which the second network domain belongs may be the same as or different from the first operator. Specifically, cross-domain switching needs may be triggered by a variety of conditions, such as: the device moving to the edge of the first operator's signal coverage, entering a new country / region, the current network quality deteriorating (such as weak signal or insufficient bandwidth), the user actively requesting to switch operators to obtain better tariffs or services, or policy configuration requiring timed switching, etc.

[0061] The end-device stores a list of candidate operators locally or retrieves it from the network side. This list contains available operators and their corresponding network domain identifiers. A preset handover policy defines selection rules, such as prioritizing by signal strength, tariff, historical success rate, or security level requirements. The end-device executes the policy logic, selecting the most suitable second network domain from the list for the current needs. This second operator may be the same as the first operator (e.g., different frequency bands or regions of the same operator) or different (e.g., switching from China Unicom to Deutsche Telekom).

[0062] Step 720: Activate the cross-domain network registration information pre-stored in the eSIM corresponding to the second operator, obtain the communication link that accesses the second network domain, and perform access to the second network domain; Specifically, the eSIM pre-stores configuration files (cross-domain network registration information) for multiple operators, each containing the network access parameters for that operator. After activating the cross-domain network registration information corresponding to the second operator, the terminal device obtains a communication link that can be used for data transmission and reception, thus formally accessing the basic network of the second network domain.

[0063] Identity verification process: Step 730: Based on the communication link of the accessed second network domain, initiate an identity and permission verification request to the blockchain network to obtain an access token and access permission for specific network resources provided by the second operator after successful verification; wherein, the identity verification request includes the digital identity credential of the terminal device, and the blockchain network pre-stores the association relationship between the hardware identity information of multiple terminal devices and distributed identity identifiers; Specifically, the edge device constructs an identity verification request message and sends it to a pre-configured blockchain network node address. The goal of this request is to prove the edge device's legitimate identity and obtain access to specific network resources provided by a second operator. The request must include a digital identity credential (e.g., a DID string) obtained by the device during manufacturing or pre-installation, and may also include a random number or timestamp signed with the device's private key to prove that the credential is indeed held by the device. The blockchain network pre-stores the association between the hardware identity information (such as IMEI and MAC address) of multiple edge devices and their distributed identity identifiers (DIDs).

[0064] Upon receiving a request, the blockchain node searches for the relevant on-chain information based on the credentials in the request, verifying the validity of the credentials and the authenticity of the signature. Once verification is successful, it generates a short-term valid access token based on the device's geographical location, subscription policy, or permission contract, along with access permissions (such as allowed QoS levels, maximum bandwidth, and allowed service slice IDs), and returns this information to the end device.

[0065] Step 740: Access the specific network resources of the second operator based on the access token and the access permission.

[0066] Specifically, when a device subsequently sends a service request to a second operator's network capability open platform (such as OpenGateway), it includes the token in the request header or parameters, specifying the required permission scope. The OpenGateway platform verifies the token's signature, validity period, and its compatibility with the requested resources. Upon successful verification, the OpenGateway platform dynamically adjusts network policies for the end-device: for example, allocating guaranteed bit rate (GBR) bandwidth; or directing the device's data flow to a designated network slice. The end-device thus gains access to advanced network resources beyond the basic link.

[0067] In this embodiment, the terminal device, already connected to the first operator's network domain, autonomously selects a second network domain from the candidate operator list based on a preset switching strategy according to cross-domain handover requirements. It then quickly obtains a communication link to the second network domain by activating the cross-domain network registration information pre-stored in the eSIM, without needing to replace the physical card or require manual intervention. This achieves smooth and dynamic network handover between different operators or even different domains within the same operator. After obtaining the basic link, the terminal device immediately initiates an identity and permission verification request to the blockchain network based on this link. The blockchain network verifies the terminal device's digital identity credential using the association between its pre-stored hardware identity information and digital identity credential. Upon successful verification, it returns an access token and access permission for specific network resources provided by the second operator, thereby enabling the terminal device to securely and controllably obtain the differentiated network capabilities of the target operator.

[0068] In some optional embodiments, it also includes: Identity registration process: The system receives and stores digital identity credentials sent by the information pre-configuration device in the eSIM, wherein the digital identity credentials are assigned by the information pre-configuration device to the blockchain network for the hardware identification information of the end-side device.

[0069] In this embodiment, during the manufacturing stage, the manufacturer generates and writes hardware identity information, such as IMEI and MAC addresses, for the edge device using an information pre-configuration device. This information forms the hardware foundation for subsequent identity binding. The information pre-configuration device requests a digital identity credential from the blockchain network for the edge device's hardware identity information. Afterward, the information pre-configuration device writes the digital identity credential into the eSIM.

[0070] In this embodiment, the digital identity credential assigned by the blockchain network to the hardware identifier is pre-securely written into the eSIM, enabling the terminal device to obtain an immutable on-chain identity. This provides a trusted root for subsequent cross-domain switching and rapid authentication, simplifies the device network access process, and improves the security of identity initialization.

[0071] In some optional embodiments, the method further includes: collecting the generated behavioral data during the network switching process and uploading the data to the blockchain network. This embodiment ensures that the switching behavior is traceable, facilitating post-event auditing, troubleshooting, and assigning responsibility for security incidents.

[0072] Example 6: This embodiment also provides a method for cross-domain invocation of intelligent agents. This method can be applied to cloud-side processors with communication, computing, and data storage capabilities, and its specific process can be as follows: Figure 8 As shown, it includes: Knowledge encapsulation stage: Step 810: Standardize and encapsulate the pre-stored knowledge on the cloud side to obtain multiple knowledge modules, and each knowledge module serves as a cloud-side intelligent agent for invocation; Specifically, the cloud maintains a knowledge module library. These knowledge modules are obtained by standardizing and encapsulating various pre-stored knowledge in the cloud (such as algorithm models, business rules, data processing logic, API call templates, etc.). These standardized and encapsulated knowledge modules collectively constitute the cloud-side intelligent agent. The specific content of the standardized encapsulation includes: defining a unified interface description (such as input / output format, parameter type), calling method (synchronous / asynchronous), runtime constraints (timeout, resource requirements), and capability metadata (module function description, version number, business domain, etc.) for each module. In this embodiment, the MCP (Model Context Protocol) or ANP protocol can be used to structurally encapsulate the knowledge modules, enabling them to be reused across scenarios and systems.

[0073] Step 820: Generate a business association relationship between each of the preset multiple business processes and the multiple knowledge modules. The business association relationship is used to describe the knowledge module associated with each business process. Specifically, a business process refers to a set of predefined business scenarios by the cloud-side processor, such as "user authentication," "cross-domain roaming billing," "intelligent recommendation," and "privacy computing tasks." Each business process includes a series of business objectives, input / output requirements, and execution order. Business relationships describe which knowledge modules a business process depends on to complete. Relationships can be: Required / Optional: Some knowledge modules are mandatory for the process, while others are conditional branches; Sequential relationship: After knowledge module A is executed, the result is input into knowledge module B; Substitution relationship: Knowledge module A and knowledge module B are functionally equivalent and can be substituted for each other.

[0074] These relationships can be stored using edges in directed graphs, rule tables, or knowledge graphs.

[0075] When the cloud-side processor receives a task request belonging to a certain business process, it can quickly locate the relevant knowledge module based on the pre-established association, without having to perform semantic retrieval on all modules every time.

[0076] Task invocation phase: Step 830: Receive a task request initiated by the end device. The end device completes identity authentication with the blockchain network and obtains network resources after obtaining network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. Specifically, the device has completed local cross-domain network registration using the pre-configured eSIM information to obtain a basic link; then it submits digital identity credentials to the blockchain network to complete identity verification and obtain an access token and permissions; after that, the device securely accesses the current network domain (i.e., the trusted area where the cloud-side processor is located) based on this authorization.

[0077] Step 840: Based on the business association relationship, match the target knowledge module for the task request, call the target knowledge module to process the task request, and return the processing result to the end device.

[0078] Specifically, the cloud-side processor parses the business process identifier (e.g., "cross-domain roaming billing") from the task request, then queries the business relationships established in step 820 to find a list of knowledge modules directly related to that business process. If the request also contains additional parameters (such as region or device type), it further filters or sorts the data to select the most suitable target knowledge modules (one or more).

[0079] In this embodiment, pre-stored knowledge in the cloud is standardized and encapsulated into multiple flexibly invoked knowledge modules. Business relationships between these knowledge modules are pre-generated for each business process. This allows the cloud processor to quickly and accurately match the target knowledge module based on these relationships when receiving task requests from the edge device. This avoids the complex process of retrieving or understanding the entire knowledge set each time, as is common in traditional methods, significantly improving task response speed and invocation accuracy. Simultaneously, the edge device securely accesses the current network domain after completing identity authentication and obtaining network resources through cross-domain network registration information and digital identity credentials pre-stored in the eSIM. This ensures that only devices with trusted verification can initiate task calls, effectively preventing unauthorized access and malicious requests.

[0080] In some optional embodiments, the business data included in the task request carries a classification label, source identifier, and / or sensitivity level. The task invocation process further includes: determining a compliance processing strategy for the business data based on the classification label, source identifier, and / or sensitivity level, so that the cloud-side intelligent agent performs privacy computation on the business data under the constraints of the compliance processing strategy, generating an irreversible security result to be returned to the edge device. The compliance processing strategy includes the types of computations allowed to be performed on the business data and the constraints.

[0081] Specifically, category tags are used to identify the data type of business data, such as "Personally Identifiable Information (PII)," "Health and Medical Data," "Device Logs," "Geographic Location Information," and "Financial Transaction Records." Category tags can help quickly determine which regulations (such as GDPR, HIPAA, PCI-DSS) or internal corporate classification rules the data should comply with.

[0082] The source identifier indicates the origin of the business data, including the country or region of origin (such as "EU", "US", "China"), the specific edge device ID, and the application scenario (such as "vehicle sensor" or "wearable device"). The source identifier is used to determine the applicable data sovereignty requirements (such as data cannot leave the country and must be stored locally).

[0083] Sensitivity levels are categorized based on the privacy level or potential harm of the data, such as "highly sensitive" (e.g., ID card number, fingerprint), "medium sensitive" (e.g., device location), and "low sensitive" (e.g., device model). Sensitivity levels directly affect the allowed computational strength (e.g., whether homomorphic encryption is mandatory, whether aggregation is prohibited, etc.).

[0084] Determining a compliance processing strategy for the aforementioned business data is crucial for automatically adapting to the legal, regulatory, and privacy protection requirements of different countries, industries, or business types in cross-domain (especially cross-border) data processing scenarios. This helps avoid legal risks or data breaches caused by unauthorized data processing. The compliance processing strategy specifies the types of computations allowed on the business data (e.g., only statistical analysis allowed, machine learning prohibited, only federated learning allowed), as well as specific constraints (e.g., results must be anonymized, data cannot leave the country, computation must be performed within a designated region, homomorphic encryption must be used). When executing data processing tasks, the cloud-based intelligent agent adheres to these constraints, only calling computation modules permitted by the strategy (e.g., privacy-preserving computation operators), and all operations must remain within the boundaries set by the strategy. For example, raw data cannot be written to external storage, and intermediate results cannot be sent to unauthorized addresses.

[0085] After the cloud-side intelligent agent performs calculations according to policy constraints, it obtains secure computation results. These results are then returned to the edge device via the cloud-side processor for use in the device's business decisions or user presentation.

[0086] In this embodiment, compliance processing strategies are automatically matched by classifying business data by labels, source identifiers, or sensitivity levels. This constrains cloud-side intelligent agents to perform only permitted privacy-preserving computations, generating irreversible security results. This achieves compliant data processing while fully protecting data privacy, effectively preventing sensitive data leakage or unauthorized cross-border computations, and meeting the regulatory requirements of multiple countries and industries.

[0087] In some optional embodiments, the method further includes: generating a data lineage record for the business data, the data lineage record including data source, transformation chain and / or usage trajectory; and uploading the call record of the knowledge module, the summary of the task request, the data lineage record, the compliance check summary and / or the privacy computing task summary to the blockchain network.

[0088] Specifically, the data source can be obtained based on the aforementioned source identifiers, which are used to record the initial source of business data. Examples include the hardware identifier of the edge device (IMEI / eUICC ID), sensor type, data collection time, geographical location, and upload task ID. This information helps confirm whether the data originates from a legitimate device and a compliant region.

[0089] The transformation chain refers to all transformation operations that business data undergoes during cloud-side processing, including but not limited to: data format conversion, field mapping, anonymization / de-identification, feature extraction, and aggregation statistics. Each transformation operation must record the operation type, execution time, executor (knowledge module identifier), and input / output data hashes. The transformation chain can prove that the original data has not been maliciously tampered with or misused.

[0090] Usage trajectory refers to the business scenarios and knowledge modules in which business data is used, as well as the purpose and frequency of use. For example, if a piece of location data is used in the "Cross-Domain Roaming Strategy Decision" module and the "Anomaly Detection" module, the usage trajectory will record the call order, time, and result summary of these two modules.

[0091] By generating data lineage records, the system can reconstruct the complete processing path of data throughout its lifespan, meeting the requirements for transparency in data processing.

[0092] In this embodiment, a traceable and tamper-proof audit log for the entire data processing process is implemented, which facilitates compliance verification and security incident tracing in cross-border data scenarios, and significantly improves the transparency and credibility of data flow.

[0093] Example 7: Based on the above embodiments, this embodiment provides an authentication method, a cross-domain invocation method for intelligent agents, and an application example of an intelligent agent network system. Details are as follows: I. Network Architecture of Intelligent Agent Network System The architecture adopts a layered design concept, such as Figure 9 As shown, it includes the following core layers: 1. Agent Access Layer Supports access from various terminal devices (AI cloud phones, vehicle networking devices, embody intelligence, drones, AIoT devices, etc.); 2. Network transport layer (neural network) 1) Integrates eSIM technology to enable automatic switching between multiple operator networks and is compatible with high and low orbit satellite network access capabilities; 2) Software-defined networking (SDN) technology enables dynamic scheduling of network resources; 3) Blockchain networks provide a decentralized communication foundation; 4) Cross-border data routing optimization mechanism; 3. Blockchain authentication layer (security authentication) 1) A distributed identity management system based on smart contracts (gateway + hierarchical and regional division). 2) A lightweight consensus algorithm ensures authentication efficiency, and the online eSIM number database is periodically stored and backed up; 3) Cross-chain interoperability supports collaboration across multiple blockchain networks; 4. Intelligent agent control layer (brain) 1) A collaborative decision-making engine driven by a multimodal large model; 2) Knowledge encapsulation and sharing mechanisms supported by MCP or ANP protocols; 3) A spatiotemporal digital twin environment is used for simulation verification; 5. Data Space Layer (AI Illusion and AI Memory = Trustworthy AI) 1) Trusted data space enables secure data sharing 2) Privacy-preserving computing engines (federated learning, differential privacy, etc.) 3) Data lineage tracing and compliance checks.

[0094] II. Device Identity Binding Process Integrating eSIM and Blockchain like Figure 10 As shown, based on the above network architecture, the device identity binding process of eSIM and blockchain integration in this embodiment is as follows: Step 1: Write device hardware information During the manufacturing phase, the manufacturer (i.e., the information pre-installation device in the above embodiment) generates and writes hardware identification information, such as IMEI, MAC address, and other basic feature codes, for the terminal. This information constitutes the hardware foundation for subsequent identity binding.

[0095] Step 2: Generate Digital Identity (DID) The manufacturer submits a digital identity application to the blockchain's identity management service. The identity service generates a unique DID for the device and returns the public key, certificate, or metadata associated with that DID.

[0096] Step 3: Register and bind information to the blockchain The manufacturer writes the DID along with a summary of the device's hardware characteristics into the blockchain network, forming an immutable binding record. The blockchain returns a confirmation result after reaching a consensus.

[0097] Step 4: Write eSIM information The manufacturer writes the DID, public key certificate, and lightweight on-chain verification configuration into the device's eSIM storage area, making the eSIM the "identity carrier" of the device during operation.

[0098] Step 5: Authentication upon first power-on After the device is powered on, it reads the DID data from the eSIM and initiates its first authentication with the blockchain to confirm the consistency between the factory information and the information bound to the blockchain. Once the authentication is successful, the device enters a usable state.

[0099] The entire process is completed during the device manufacturing stage, aiming to ensure that each terminal possesses a unique and verifiable digital identity (DID) before being put into use, and to establish a one-to-one binding relationship between this identity and the device's hardware characteristics and eSIM configuration. Through the above process, this embodiment achieves consistent binding between the device-level, hardware-level, and on-chain identities, providing a trusted foundation for subsequent cross-border authentication and network access.

[0100] It should be noted that, Figure 10 Each interactive node in the system represents an execution step, such as identity. It is not a separate execution entity, but a functional step set up for ease of understanding.

[0101] III. Cross-border Access + eSIM Network Switching + Blockchain Authentication + OpenGateway Invocation Process Furthermore, this embodiment enables seamless switching and trusted access for different devices across different operators, countries, and regulatory regions, while simultaneously meeting the requirements for identity, permissions, and business continuity in cross-border scenarios. Figure 11 As shown, the specific process of cross-border access + eSIM network switching + blockchain authentication + OpenGateway call in this embodiment is as follows: Step 1: Detect the environment and scan for available networks The terminal determines that it has entered a new country or region based on location changes or signal status, and initiates a network scan request to the local access gateway. The gateway returns information on terrestrial networks and available satellite links.

[0102] Step 2: Try registering with a local carrier using eSIM The terminal selects a target operator according to the policy and triggers local network registration via eSIM. If registration is successful, it obtains the most basic network connection.

[0103] Step 3: Initiate Blockchain Authentication In order to establish a cross-border trust relationship, the terminal sends an authentication request to the blockchain network.

[0104] Blockchain nodes verify the DID status, device hardware feature summary, and cross-border permissions.

[0105] Step 4: The blockchain returns the access token and permission policy. The identity service returns the validity of the DID; the access contract generates an access policy based on geographical location and service type. The terminal can only use network capabilities after obtaining a token and permissions.

[0106] Step 5: Open up network capabilities through the OpenGateway API The terminal carries an on-chain token to call the OpenGateway platform to request operator network capabilities such as QoS guarantees, handover policies, and billing capabilities.

[0107] The SDN controller allocates routing resources for terrestrial and satellite links to terminals based on requests.

[0108] Step 6: Business data flows into the intelligent agent platform After the network policy takes effect, the terminal sends business data or task requests to the intelligent agent platform. The intelligent agent platform performs inference and decision-making based on a multimodal large model, and then returns the results to the terminal.

[0109] Step 7: Recording on the critical event chain The terminal and the intelligent agent platform write network switching behavior and business call summaries onto the blockchain for subsequent auditing and tracing.

[0110] Through the above process, this invention achieves continuity, trusted access capability, and manageability of cross-operator collaboration in cross-border intelligent agent networks.

[0111] IV. MCP Knowledge Module Registration and Invocation Process The agent control layer employs a multimodal large model to process data from various sources (text, images, sensor data, etc.). The control layer maintains a global knowledge graph and AI vector database, recording the capability descriptions and service status of each agent (or large model). MCP or ANP protocols are used to standardize the knowledge exchange format between agents, supporting modular encapsulation and dynamic combination of knowledge.

[0112] like Figure 12 As shown, the "registration-retrieval-calling-recording" process of the intelligent agent knowledge encapsulation system in this embodiment is as follows: This embodiment specifically uses the MCP (Model Context Protocol) or ANP protocol to structurally encapsulate the knowledge modules of the intelligent agent, enabling it to be reused across scenarios and systems.

[0113] Step 1: Module Registration Each knowledge module uploads its own interface description, input / output specifications, operational constraints, and capability metadata to the registration center.

[0114] Step 2: Vectorization and graph storage The registry center invokes the capability embedding algorithm to abstract module capabilities into vectors and store them in the vector library; Simultaneously, the semantic relationships of the modules in the business scenario are analyzed and written into the knowledge graph.

[0115] Step 3: Register the blockchain digest The registry writes the digest hash of module metadata to the blockchain for module versioning, accountability, and auditing.

[0116] Step 4: The agent initiates the task. The terminal or upper-layer system sends a task request to the intelligent agent orchestrator, requesting the scheduling of appropriate knowledge modules.

[0117] Step 5: Module Search and Matching The orchestrator first retrieves candidate modules with similar capabilities from the vector library, and then selects available modules from the graph based on scene constraints.

[0118] Step 6: Module Execution and Result Output The orchestrator calls the selected module to execute the task and returns the result of the module execution to the terminal.

[0119] Step 7: Record the call summary on the chain The orchestrator writes module call records and task summaries to the blockchain for transparency and accountability.

[0120] It should be noted that, Figure 12 The interaction nodes such as registration, vectorization, orchestration, and graph are not the actual execution entities, but rather functional components for ease of understanding. It can be assumed that the specific execution of registration, vectorization, orchestration, and graph is all implemented by the cloud-side processor described in the above embodiments.

[0121] V. Trusted Data Space + Privacy Computation + Compliance Check Process The data space layer provides a secure data sharing environment, employing technologies such as homomorphic encryption and secure multi-party computation, allowing agents to perform collaborative computations without exposing raw data. The data lineage tracking module records the source, transformation process, and access history of data, ensuring compliance with cross-border data regulations. For example... Figure 13 As shown, the process is as follows: Step 1: The agent submits data Intelligent agent terminals upload data or features to a trusted data space, and the data carries classification labels, source identifiers, and sensitivity levels.

[0122] Step 2: Generate bloodline information The trusted data space first generates a data lineage record, including the data source, transformation chain, usage trajectory, etc., and returns the lineage record number.

[0123] Step 3: Compliance Pre-check The data space invokes the compliance engine to determine whether the data can be used for specified calculations based on the country, industry, and business type, and returns the allowed scope and constraint policies.

[0124] Step 4: Execution of Privacy Computation Task Under the constraints of compliance policies, Data Space entrusts data to privacy computing engines to perform computations (federated learning, secure multi-party computation, or homomorphic encryption).

[0125] Step 5: Return to the security results view The privacy computing engine returns an irreversible, secure view of the results, and the data space returns the results to the agent.

[0126] Step 6: On-chain evidence storage Data lineage information, compliance check summaries, and privacy computation task summaries are written to the blockchain for easy auditing.

[0127] Through the above process, data has a complete and controllable path after entering the system, meeting the stringent requirements for cross-border data in terms of security, privacy, and regulation.

[0128] Example 8: Another embodiment of this application relates to an intelligent agent network system. The implementation details of this intelligent agent network system are described below. The following implementation details are provided for ease of understanding and are not essential for implementing this solution. A schematic diagram of the intelligent agent network system in this embodiment can be seen as follows: Figure 14 As shown, it includes an edge device 1410 and a cloud processor 1420. The edge device 1410 and the cloud processor 1420 work together to implement the method described in any of the above embodiments.

[0129] Example 9: Another embodiment of this application relates to an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the intelligent agent terminal network access management method in the above embodiments.

[0130] In this embodiment, the memory and processor are connected via a bus, which can include any number of interconnected buses and bridges, connecting various circuits of one or more processors and the memory together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be further described in this embodiment. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0131] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0132] Example 10: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.

[0133] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0134] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. An authentication method, characterized in that, Applied to information pre-installation equipment, including: Request the blockchain network to assign digital identity credentials for the hardware identification information of the edge device; The digital identity credential and cross-domain network registration information are written into the eSIM of the terminal device, so that the terminal device can initiate identity verification and cross-domain network connection to the blockchain network based on the digital identity credential and cross-domain network registration information; The association information between the digital identity credential and the hardware identification information, as well as the cross-domain network registration information, are recorded on the blockchain network.

2. A network handover method, characterized in that, Applied to end-side devices, including: An authentication request is initiated to the blockchain network. The terminal device has completed cross-domain network registration and obtained a communication link through the cross-domain network registration information pre-stored in the eSIM. The authentication request includes the digital identity credential of the terminal device. The blockchain network pre-stores association information between the digital identity credentials of multiple terminal devices and the hardware identification information. After the blockchain network verifies the validity of the digital identity credential based on the associated information, it returns an access token and access permissions, and obtains the corresponding network resources based on the access token and access permissions.

3. A method for cross-domain invocation of an intelligent agent, characterized in that, Applications in cloud-side processors include: The receiving end-side device initiates a task request. The end-side device completes identity authentication with the blockchain network and obtains network resources after obtaining network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. In the cloud-side intelligent agent, a target knowledge module is matched for the task request, wherein the cloud-side intelligent agent pre-stores multiple knowledge modules obtained by standardizing and encapsulating knowledge. The target knowledge module is invoked to process the task request, and the processing result is returned to the end device.

4. A data processing method, characterized in that, Applications in cloud-side processors include: The receiving end-side device sends service data. The end-side device completes identity authentication with the blockchain network and obtains network resource access to the current network domain through cross-domain network registration information and digital identity credentials pre-stored in eSIM. A compliance processing strategy for the business data is determined so that the cloud-side intelligent agent performs corresponding calculations on the business data under the constraints of the compliance processing strategy, and returns the calculation results to the edge device. The compliance processing strategy includes the types of calculations allowed to be performed on the business data and the constraints. The behavioral data generated during the compliance process is recorded on the blockchain network.

5. A network access method, characterized in that, Applied to end-side devices, including: Network handover process: In the state of being connected to the first network domain of the first operator, according to the current network cross-domain handover requirements, a second network domain is selected from the candidate operator list using a preset handover strategy. The second network domain belongs to the same or different operator as the first operator. Activate the cross-domain network registration information pre-stored in the eSIM corresponding to the second operator, obtain the communication link that accesses the second network domain, and perform access to the second network domain; Identity verification process: Based on the communication link of the second network domain accessed, an identity and permission verification request is initiated to the blockchain network to obtain an access token and access permission for specific network resources provided by the second operator after successful verification; wherein, the identity verification request includes the digital identity credential of the end device, and the blockchain network pre-stores the association relationship between the hardware identity information of multiple end devices and distributed identity identifiers; Access to specific network resources of the second operator is granted based on the access token and the access permission.

6. The network access method according to claim 5, characterized in that, Also includes: Identity registration process: The system receives and stores digital identity credentials sent by the information pre-configuration device in the eSIM, wherein the digital identity credentials are assigned by the information pre-configuration device to the blockchain network for the hardware identification information of the end-side device.

7. The network access method according to claim 5, characterized in that, Also includes: During the network switching process, behavioral data is collected and uploaded to the blockchain network.

8. A method for cross-domain invocation of an intelligent agent, characterized in that, Applications in cloud-side processors include: Knowledge encapsulation stage: The knowledge pre-stored on the cloud side is standardized and encapsulated to obtain multiple knowledge modules, and each knowledge module serves as a cloud-side intelligent agent for invocation. To generate business association relationships between each of the multiple preset business processes and the multiple knowledge modules, the business association relationships are used to describe the knowledge modules associated with each business process; Task invocation phase: The receiving end-side device initiates a task request. The end-side device completes identity authentication with the blockchain network and obtains network resources after obtaining network resources through the cross-domain network registration information and digital identity credentials pre-stored in the eSIM. Based on the business relationship, a target knowledge module is matched for the task request, the target knowledge module is invoked to process the task request, and the processing result is returned to the end device.

9. The method for cross-domain invocation of an intelligent agent according to claim 8, characterized in that, The business data contained in the task request carries classification tags, source identifiers, and / or sensitivity levels, and the task invocation process further includes: Based on the classification label, source identifier, and / or sensitivity level, a compliance processing strategy is determined for the business data, so that the cloud-side intelligent agent performs privacy computation on the business data under the constraints of the compliance processing strategy, generating an irreversible security result to be returned to the edge device. The compliance processing strategy includes the types of computations allowed to be performed on the business data and the constraints.

10. The method for cross-domain invocation of an intelligent agent according to claim 9, characterized in that, Also includes: Generate a data lineage record for the business data, the data lineage record including data source, transformation chain and / or usage trajectory; The call records of the knowledge modules, the summary of the task requests, the data lineage records, the compliance check summary, and / or the privacy computing task summary are uploaded to the blockchain network.

11. An intelligent agent network system, characterized in that, include: End-side devices and cloud-side processors, The end-side device is used to perform the method as described in any one of claims 2 and 5-7; The cloud-side processor is used to perform the method as described in any one of claims 3, 4, and 8-10.

Images