Methods, apparatuses, storage media, and program products for communication

Abstract

A method, apparatus, storage medium, and program product for communication are provided. According to the proposed method, a first email can be received, the first email including an operation request, the recipient of the first email being a first email address of a first smart component, the sender of the first email being a second email address of an object, the first smart component being associated with a first domain, and the object being associated with a second domain; and a first operation can be performed using the first smart component, the first operation corresponding to the operation request.

Description

Technical Field

[0001] The examples in this article generally relate to the field of computers, and in particular to methods, apparatuses, devices, and computer-readable storage media for communication. Background Technology

[0002] With the development of artificial intelligence and network communication technologies, intelligent components with processing capabilities are increasingly being applied in various scenarios. For example, in some scenarios, intelligent components can respond to external requests to perform tasks, process data, or provide services, thereby assisting users in completing complex operations. In this process, intelligent components may need to communicate with other objects to achieve information exchange and collaborative processing. Summary of the Invention

[0003] In a first aspect, a method for communication is provided. The method includes: receiving a first email, the first email including an operation request, the recipient of the first email being a first email address of a first smart component, the sender of the first email being a second email address of an object, the first smart component being associated with a first domain, and the object being associated with a second domain; and performing a first operation using the first smart component, the first operation corresponding to the operation request.

[0004] In a second aspect, a method for communication is provided. The method includes: obtaining the email address of a first smart component, the first smart component being associated with a first domain; and sending a first email, the recipient of which is the first email address of the first smart component, the sender of which is a second email address of an object, the object being associated with a second domain, the first email including an operation request indicating a first operation, and the first email being used to instruct the first smart component to perform the first operation.

[0005] In a third aspect, an apparatus for communication is provided. The apparatus includes: a receiving module configured to receive a first email, the first email including an operation request, the recipient of the first email being a first email address of a first smart component, the sender of the first email being a second email address of an object, the first smart component being associated with a first domain, and the object being associated with a second domain; and an execution module configured to perform a first operation using the first smart component, the first operation corresponding to the operation request.

[0006] In a fourth aspect, an apparatus for communication is provided. The apparatus includes: an acquisition module configured to acquire the email address of a first intelligent component, the first intelligent component being associated with a first domain; and a sending module configured to send a first email, the recipient of which is the first email address of the first intelligent component, the sender of which is a second email address of an object being associated with a second domain, the first email including an operation request instructing a first operation, the first email being used to instruct the first intelligent component to perform the first operation.

[0007] In a fifth aspect, an electronic device is provided. The device includes at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor. When executed by the at least one processor, the instructions cause the device to perform the methods of the first or second aspect.

[0008] In a sixth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that can be executed by a processor to implement the methods of the first or second aspect.

[0009] In a seventh aspect, a computer program product is provided, which is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect or the second aspect.

[0010] Based on the various aspects presented in this paper, by encapsulating communication requests as emails and communicating based on email addresses, cross-domain interaction and invocation can be achieved, thereby reducing the resource overhead of communication establishment and maintenance, and improving communication stability and execution efficiency in heterogeneous network environments. Furthermore, since relevant email transmission infrastructure can be reused for message passing, system deployment and integration costs can be reduced, and the computational and implementation overhead caused by additional communication protocol adaptation can be minimized, thus improving the overall system's scalability and resource utilization efficiency.

[0011] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1A Examples of communication schemes from related solutions discovered by the inventors of this paper are shown; Figure 1B A schematic diagram of an example environment based on some examples is shown; Figure 2 A schematic diagram of a mail-based communication system based on some examples is shown; Figure 3 A schematic diagram illustrating the communication process under several scenarios is shown; Figure 4 A schematic diagram illustrating the process of verifying the first email under certain circumstances is shown; Figure 5 Flowcharts illustrating example processes for communication in several scenarios are shown; Figure 6 Flowcharts of example processes for communication in several other scenarios are shown; Figure 7 Schematic block diagrams of example devices for communication in some scenarios are shown; Figure 8 Schematic block diagrams of example devices for communication in several other scenarios are shown; and Figure 9 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

[0013] The examples in the text will now be described in more detail with reference to the accompanying drawings. While some examples are shown in the drawings, it should be understood that solutions can be implemented in various forms and should not be construed as limited to the examples presented herein. Rather, these examples are provided to provide a more thorough and complete understanding of the solutions. It should be understood that the drawings and examples in this document are for illustrative purposes only and are not intended to limit the scope of protection of the solutions.

[0014] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

[0015] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0016] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and provisions. In the examples presented herein, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.

[0017] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0018] In this paper, intelligent components are implemented based on machine learning models. Intelligent components can also be referred to as intelligent systems, intelligent modules, AI modules, AI systems, AI components, etc. For example, intelligent components can make decisions and autonomously execute actions based on machine learning models to achieve preset goals or complete preset tasks. An intelligent component can be an automated program that understands the user's intent and can use models or invoke tools to complete various types of tasks. In some cases, examples of intelligent components may include, but are not limited to: agents, bots, chatbots, digital avatars, intelligent customer service, digital assistants, etc. Alternatively, an intelligent component can also be an intelligent role implemented based on a machine learning model. "Intelligent components" can process user requests based on generative models (e.g., language models, multimodal models) to perform specified types of tasks. Intelligent components can be deployed on local devices, cloud servers, or any other suitable computing environment.

[0019] As used in this article, the term "domain" refers to a logical boundary or scope of ownership for managing and classifying a type of computing resource, communication address, or entity. Different domains can correspond to different email providers; for example, different domains can correspond to domains belonging to different email service providers. For instance, related intelligent components or business systems deployed on the same device but registered through different email service providers and obtaining email addresses with different domains can be classified as belonging to different domains. Different domains can also correspond to different entities. Entities can include objects with independent management or usage boundaries, such as different organizations, different devices, or different geographical locations. For example, different enterprises or institutions can correspond to different domains; intelligent components running on different terminal devices can also correspond to different domains; systems located in different network environments or geographical locations can also be classified as different domains. Entities in different domains are typically under different management or control scopes. Therefore, communication between objects associated with different domains can be called cross-domain communication.

[0020] As used in this document, the term "business system" refers to a software platform or application used to perform specific business functions. Business systems can be deployed in server or cloud environments to process business processes, manage tasks, or provide services. In some examples, a business system may send operation requests to intelligent components to trigger corresponding operations. In other examples, a business system may obtain operation execution results or execution status information from intelligent components.

[0021] In this article, the term "machine learning model" can refer to a computational model that performs tasks by learning patterns and rules from data. Machine learning models can include, but are not limited to, neural network models, deep learning models, and large language models. In some cases, large language models are an example of machine learning models that can understand and generate natural language text and can be used to perform tasks such as task decomposition, tool invocation, and content generation.

[0022] As mentioned above, with the widespread deployment of intelligent components across different terminal devices and network environments, the demand from business systems for scheduling intelligent components and for collaborative execution between them is increasing. However, in some scenarios, intelligent components may be deployed in local or private network environments, lacking network addresses accessible from the public network side, or their network environment may limit their ability to provide services externally through predefined program interfaces. In such cases, relying on program interface calls to schedule intelligent components may result in scheduling failures.

[0023] Furthermore, if communication between business systems and intelligent components, as well as between intelligent components themselves, relies entirely on natural language, the identification of communication intent (such as whether it is a task assignment, a status query, or a task result feedback) and the extraction of structured information (such as task identifiers, priorities, deadlines, and contextual information) may depend heavily on the language understanding capabilities of the intelligent components themselves. This may lead to limitations in the consistency of cross-component communication.

[0024] Based on this, it is desirable to provide a communication method that can cross different network environments and has a consistent resolution basis to support the scheduling and collaborative execution of intelligent components.

[0025] Figure 1A Example 100A of a communication scheme from a related scheme discovered by the inventors of this paper is shown. For example... Figure 1A As shown, Example 100A involves user 101, business system 102, and intelligent component 103.

[0026] Business system 102 may have certain data processing capabilities or be considered a multi-functional collaboration platform. For example, business system 102 may possess any appropriate functions such as business management, business creation, and business planning. Within business system 102, people can systematically, standardizedly, and visually manage and collaborate on the entire lifecycle of a business, from initiation, planning, execution, monitoring to closure.

[0027] User 101's terminal device can, for example, provide the user with an interface to business system 102, through which user 101 can send commands to business system 102. Business system 102 can provide messages to the user via message notifications. Different business systems 102 can also communicate with each other through an API. User 101's terminal device can also provide an interactive interface between user 101 and intelligent component 103, through which user 101 can send commands to intelligent component 103. Intelligent component 103 can call tools or modules of business system 102 through the interface.

[0028] refer to Figure 1A Within the same device or domain, intelligent components can interact through inter-process communication (IPC) or internal interfaces. For example, multiple intelligent components running on the same device can communicate via IPC protocols to achieve collaborative processing. Furthermore, intelligent components can call application programming interfaces (APIs) provided by the business system to obtain data or perform operations.

[0029] However, in some application scenarios, the objects that need to communicate with intelligent components are often distributed across different domains. For example, different intelligent components or intelligent components and business systems may belong to different organizations or correspond to different network address systems (e.g., different email domains). In this case, it is difficult to establish an effective communication mechanism between objects across domains.

[0030] refer to Figure 1A In some examples, intelligent components based on different instant messaging platforms cannot communicate directly. This is because different instant messaging platforms are often centralized systems. Different organizations may use different platforms, resulting in isolation between communication systems and making cross-platform and cross-organizational information exchange difficult.

[0031] In other examples, the communication between the business system and the intelligent component is typically a one-way call, meaning the intelligent component can call the business system, but the business system cannot proactively call the intelligent component to execute tasks. For instance, the intelligent component runs on a local device or in a restricted network environment, usually behind a firewall, and cannot provide an accessible interface to the outside world, making it difficult for external systems to directly send task requests to the intelligent component.

[0032] Continue to refer to Figure 1A In some examples, it is also difficult for users to establish direct interaction methods with intelligent components associated with different domains. For instance, within the same organization, users can interact with intelligent components within that organization using existing communication tools. However, if users need to communicate with intelligent components associated with other organizations, such communication is often difficult to achieve due to the lack of a unified cross-domain communication mechanism.

[0033] Based on the above research and analysis, the inventors have proposed a communication scheme. According to this scheme, a first email can be received, comprising an operation request. The recipient of the first email is a first email address of a first intelligent component, and the sender of the first email is a second email address of an object. The first intelligent component is associated with a first domain, and the object is associated with a second domain. Furthermore, a first operation can be performed using the first intelligent component, and the first operation corresponds to the operation request.

[0034] Previously, email was only used for sending and receiving information among users and was not applied to communication with intelligent components. This paper's solution innovatively uses email as the communication medium between users, business systems, and intelligent components. For example, users and business systems can use email as an information carrier to send operational information (such as scheduling instructions or task parameters) to intelligent components. Intelligent components can also communicate with each other via email. In this way, because email is a widely supported communication method, using it as the communication medium between users, business systems, and intelligent components enables communication. By defining the information and structure carried in emails, intelligent components and business systems can accurately understand and execute corresponding tasks.

[0035] By using email as a carrier, information can be transmitted between different domains, enabling objects associated with different domains to send operation requests to the first intelligent component. Leveraging the reachability of a decentralized email system across different domains, intelligent components located in different network environments or organizations can be remotely triggered to execute operations, thus achieving cross-domain communication and task scheduling capabilities. In this way, communication between objects distributed across different domains can be achieved without relying on pre-established interfaces or specific communication channels, thereby improving the flexibility and applicability of communication.

[0036] In some contexts, the term "domain" refers to the logical boundary or scope of an object's management and classification, such as the logical boundary or scope of a type of computing resource, communication address, or entity. Different domains can correspond to different object scopes. For example, different domains can correspond to different email providers, or different domains corresponding to different email service providers. For instance, related intelligent components or business systems deployed on the same device but registered through different email service providers and obtaining email addresses with different domains can be classified as belonging to different domains. Furthermore, different domains can correspond to different entities. Entities can include objects with independent management or usage boundaries, such as different organizations, different devices, or different geographical locations. For example, different enterprises or institutions can correspond to different domains; intelligent components running on different terminal devices can also correspond to different domains; systems located in different network environments or geographical locations can also be classified into different domains. Entities in different domains are typically under different management or control scopes. Therefore, communication between objects associated with different domains can be called cross-domain communication.

[0037] The following describes various examples of this scheme in further detail with reference to the accompanying drawings.

[0038] Figure 1BA schematic diagram of example environment 100B is shown, based on some examples. The proposed scheme will be implemented in environment 110B. For example... Figure 1B As shown, the example environment 100B may involve user 110, multiple business systems 120-1, 120-2, 120-3, etc. (for ease of description, they are collectively referred to as business system 120 or individually) and multiple intelligent components 130-1, 130-2, 130-3, etc. (for ease of description, they are collectively referred to as intelligent component 130 or individually).

[0039] Different business systems in multiple business systems 120 can be deployed on different electronic devices / computing environments, and can communicate with each other, for example, through interfaces. User 110 can send instructions to business system 120 and receive message notifications from business system 120 through the interface of the business system.

[0040] As used herein, the term "business system" refers to a software platform or application used to perform specific business functions. A business system can be deployed in a server or cloud environment to process business processes, manage tasks, or provide services. Different intelligent components among the multiple intelligent components 130 can also be deployed in different electronic devices / computing environments, and these different intelligent components can communicate with each other, for example, via email. User 110 can send instructions to intelligent component 130 through an interface associated with intelligent component 130, and receive information from intelligent component 130 via instant messaging or email. Business system 120 can, for example, send instructions to intelligent component 130 via email, and can receive information from intelligent component 130 via communication protocols or email.

[0041] In some examples, business system 120 or a user can send an operation request to intelligent component 120 to trigger intelligent component 130 to perform a corresponding operation. In other examples, business system 120 or a user can obtain operation execution results or execution status information from intelligent component 130.

[0042] In this paper, intelligent components can refer to program components with the capabilities of task understanding, task execution, and result feedback. Intelligent components can be implemented by programs deployed on terminal devices or servers, and can invoke computing resources, storage resources, model services, and various tools to assist in completing the received operations. A business system can refer to a software system that provides one or more business functions, and can provide services externally through predefined program interfaces.

[0043] The aforementioned email-based communication method can be based on a specific email protocol that supports email communication between intelligent components, between intelligent components and business systems, and between users and intelligent components. Such an email protocol can solve the problem of reliable asynchronous collaboration across organizations, platforms, and intelligent agents. By accessing an email service that supports this communication protocol and using registered email addresses, task collaboration can be completed between intelligent components, between intelligent components and business systems, and between users and intelligent components, including task assignment, task execution, result exchange, task assistance, and status monitoring. The email protocol treats each participant as a mailbox endpoint capable of sending, receiving, checking, and archiving task messages. In some examples, such an email protocol can be an asynchronous task collaboration protocol with mailboxes as the native control plane, used to complete task assignment, execution, manual escalation, and result exchange between independent intelligent components at runtime. In some examples, the email protocol can use standard internet email as an interoperable control plane to carry out the delegation, confirmation, clarification, cancellation, and result delivery of long-running tasks between independent participants.

[0044] In some scenarios, according to this email protocol, emails can carry natural language identifiers, attachments, and / or machine-readable information, enabling different participants to interpret the email and collaborate based on the information conveyed. In some examples, the protocol semantics of the email express machine-readable content through structured information in the email header, while human-oriented narrative content, contextual descriptions, and attachments remain in the email body. This preserves the advantages of email in terms of machine readability, cross-system accessibility, and human review, while also meeting the requirements for structured state and incremental progress visibility in collaboration with intelligent components. Therefore, regardless of whether business systems and intelligent components are located on the same device or belong to the same network, cross-domain communication can be achieved through emails conforming to the preset email protocol.

[0045] Figure 2 A schematic diagram of a mail-based communication system 200 according to some examples is shown. The communication system 200 involves a business system 120, a terminal device 201, a mailbox server 210, multiple tools 212 (e.g., tools 212-1, 212-2, 212-3, ...), and multiple smart components 130 (e.g., smart components 130-1, 130-2, 130-3, ...). User 110-1 can be a user operating the business system 120, and user 110-2 can be a user corresponding to the terminal device 201.

[0046] Email server 210 can provide email services. It can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. Email server 210 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Email server 210 can provide email services to business system 120 and / or intelligent component 130 on terminal device 201.

[0047] Terminal device 201 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, VR / AR devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some cases, terminal device 201 may also support any type of user-facing interface (such as "wearable" circuitry).

[0048] Business system 120, terminal device 201, and smart component 130 can all communicate with email server 210. Email server 210 acts as a communication hub, facilitating information exchange between business system 120, terminal device 201, and multiple smart components 130. Although shown as a single server, in some example application scenarios, it is understood that multiple email servers may exist, all conforming to email communication based on a preset email protocol. Different email servers can be provided by different email providers, which may provide the same or different email domains. However, since these email providers all support the preset email protocol (i.e., the protocol capable of enabling email communication with smart components), information exchange can be completed through the corresponding email server. Therefore, for smart platforms and smart components that support the preset email protocol, even if they are not on the same device or a unified network, cross-domain communication between the platform and smart components, as well as between smart components, can be achieved via the preset email protocol.

[0049] Communication connections can be established between the email server 210 and the terminal device 201, and between the email server 210 and the smart components 130-1 to 130-3. These communication connections can be established via wired or wireless means. The communication connections can include, but are not limited to, Bluetooth connections, mobile network connections, Universal Serial Bus (USB) connections, and Wireless Fidelity (WiFi) connections. In some cases, the email server 210 and the terminal device 201, and the email server 210 and the smart components 130-1 to 130-3, can use these corresponding communication connections to send and receive emails and exchange signaling.

[0050] User 110-2 can access communication system 200 through terminal device 201, which can communicate with email server 210. Business system 120 can dispatch tasks to multiple intelligent components 130 through email server 210. Email server 210 routes messages between business system 120 and multiple intelligent components 130, enabling platform-to-intelligent component communication even if the intelligent components 130 do not have publicly accessible application programming interface endpoints. In some cases, intelligent component 130 can invoke one or more tools (e.g., tools 212-1, 212-2, and 212-3) to access email server 210. Multiple tools 212 can provide access layer functionality to email services, allowing various types of intelligent components to be integrated into the communication network supported by email server 210.

[0051] In some examples, mailbox server 210 can implement the JSON Meta Application Protocol (JMAP). JMAP is more suitable for intelligent components to perform read and write operations than traditional email protocols because it uses JSON format for data exchange, making it easier for programs to parse and process. In the default email protocols, Simple Mail Transfer Protocol (SMTP) is responsible for email delivery, while JMAP is responsible for email retrieval, synchronization, and attachment processing. It is understood that mailbox server 210 can also support any other suitable data access protocols.

[0052] In some examples, tools 212-1, 212-2, and 212-3 may include a Software Development Kit (SDK), a Command Line Interface (CLI) tool, a protocol bridging tool, or a plugin. The protocol bridging tool can automatically scan for smart components installed on the local device that support specific protocols and connect them to the email-based communication network. For example, the protocol bridging tool can scan for smart components on the local device that support inter-process communication protocols, request a corresponding email address for each smart component, and establish a connection with the email server 210, thereby enabling these smart components to communicate across devices and networks via email. In some examples, the SDK-based runtime can automatically send a task confirmation email after receiving a task dispatch email. With these out-of-the-box tools, various smart components can quickly connect to the email service, reducing the complexity of the integration process.

[0053] In this document, "email address" refers to the address used to identify user 110, business system 120, or intelligent component 130 in communication system 200, and can be considered as the email identity of these participants. Thus, in email communication, each participant can be addressed through their email identity. Using the email address, one of the participants—user 110, business system 120, or intelligent component 130—can send emails to another, enabling email-based communication. For example, user 110 can send emails to the email addresses of business system 120 or intelligent system 130; business system 120 can also send emails to other business systems, user 110, or intelligent component 130; and intelligent component 130 can send emails to other intelligent components, business system 120, or user 110.

[0054] In some example application scenarios, user 110, business system 120, and intelligent system 130 can trigger or execute any appropriate operation via email. This operation may include one or more operation types. In some cases, the operation type may indicate the intent or semantics of the operation indicated by the email. Operation types will be illustrated exemplarily below. By way of example only, the operation type of the first operation may be represented by a specific field name, such as "X-Intent," whose field value may indicate the operation type of the first operation.

[0055] In some examples, the operation type may include a first type. The first type allows the sender of the email to assign a task to the recipient. For example, the field value indicating the first type could be "task.dispatch" or any other suitable value. In this document, the sender and recipient can be any one or more of user 110, business system 120, or intelligent component 130. In some cases, the first type of operation may be referred to as, for example, a task scheduling operation. For example, user 110 may assign a new task to intelligent component 130 or add supplementary instructions to an existing task. If supplementary instructions are added to an existing task, intelligent component 130 may treat the email content as additional instructions for that existing task. As another example, business system 120 may assign a new task to intelligent component 130 or add supplementary instructions to an existing task. Yet another example, intelligent component 130-1 may assign a new task to user 110, business system 120, or intelligent component 130-2 or add supplementary instructions to an existing task.

[0056] Alternatively and / or additionally, the operation type may include a second type. The second type indicates that the sender is requesting cancellation of a task assigned to the receiver. For example, the field value indicating the second type could be "task.cancel" or any other suitable value. In some cases, the second type of operation may be referred to as a task cancellation operation, for example. The receiver (also referred to as the task executor) may, in response to a task cancellation operation, stop a task that is about to be executed (e.g., in a queue) or is currently being executed. For example, user 110 may send an email to intelligent system 130 to request cancellation of a task assigned to intelligent system 130. As another example, business system 120 may send an email to intelligent system 130 to request cancellation of a task assigned to intelligent system 130.

[0057] Alternatively and / or additionally, the operation type may include a third type. A third type indicates that the recipient has received the email sent by the sender. For example, the field value indicating a third type could be "task.ack" or any other suitable value. In some cases, the email indicating a third type operation could be called an email acknowledgment receipt. For example, a sender might send an email to a recipient, and after receiving that email, the recipient might send another email to the sender. This other email serves to notify the sender that the recipient has received the previous email. In this case, the operation type corresponding to this other email is a third type.

[0058] Alternatively and / or additionally, the operation type may include a fourth type. The fourth type may indicate a question to the recipient of the email. For example, the field value indicating the fourth type could be "task.help_needed" or any other appropriate value. In some situations, if the executor of the task (e.g., user 110, intelligent component 130, or business system 120) believes that the task cannot continue due to missing information (e.g., reference information, confirmation, instructions, etc.), the executor may ask a question to other interacting parties (e.g., user 110, intelligent component 130, or business system 120). For example, if intelligent system 130 believes that missing information prevents the task from continuing, intelligent system 130 may send an email to user 110 instructing them to ask a question. User 110 may reply to the email to provide a response to intelligent system 130.

[0059] Alternatively and / or additionally, the operation type may include a fifth type. The fifth type indicates that the sender sends the result of the task's execution to the recipient. For example, the field value indicating the fifth type could be "task.result" or any other appropriate value. In some cases, the email sending the execution result may include status information and feedback information. The status information may indicate that the task has been completed, failed, or was rejected. If the status information indicates that the task has been completed, the feedback information may include the task's output, such as text, images, programs, or files in a specific format. The feedback information may be sent as the email body or as an attachment. If the status information indicates that the task was rejected, the feedback information may include the reason for rejecting the task.

[0060] Alternatively and / or additionally, the operation type may include a sixth type. A sixth type may instruct the sender to request capability information (such as capability cards or other information) from the receiver, which describes the receiver's capabilities. For example, the field value indicating the sixth type could be "card.query" or any other suitable value. In some cases, the sixth type operation may also be referred to as, for example, a capability query operation or a card query operation. For example, intelligent system 130-1 may send an email to intelligent system 130-2 requesting a capability card from intelligent system 130-2 to understand the operations that intelligent system 130-2 can perform. Of course, capability information may also be displayed in, for example, a list or other data format. This document does not impose any limitations on this.

[0061] Alternatively and / or additionally, the operation type may include a seventh type. The seventh type indicates response capability information. For example, the field value indicating the seventh type could be "card.response" or any other suitable value. In some cases, the seventh type operation may be referred to as, for example, a response operation or a card response operation. For example, smart system 130-2 sends an email to smart system 130-1, which may carry the capability card of smart system 130-2. In this case, the operation indicated by the email could be of the seventh type.

[0062] Alternatively and / or additionally, the operation type may include an eighth type. The eighth type indicates that the sender provides the receiver with a data stream identifier (e.g., a data stream number or a data stream address). For example, the field value indicating the seventh type could be "streamID" or any other suitable value. The receiver can obtain the task's execution status based on this data stream identifier. For example, during task execution by the intelligent system 130, the task's execution status can be updated in the storage space corresponding to the data stream identifier. The intelligent system 130 can provide the data stream number to the business system 120. The business system 120 can obtain the task's execution status in real time based on the data stream number. The business system 120 can also display the task's execution status to facilitate user 110's understanding of the task's execution progress.

[0063] In some examples, the email may include operation information related to the action. This operation information may include any appropriate information related to the action. In some cases, the operation information may include structured data, or the operation information may be stored as structured data. The following provides an illustrative example of the content of the operation information.

[0064] In some examples, the operation information may include the operation type. In some cases, the operation information may include tags or other information that can identify the operation type. Tags may indicate the operation type corresponding to the email. For example, if the email indicates a task scheduling operation, the tag may include "task" or "task.dispatch". If the email indicates a task cancellation operation, the tag may include "task.cancel". If the email indicates a third type of operation, the tag may include "task.ack". If the email indicates a fourth type of operation, the tag may include "task.help_needed". If the email indicates a fifth type of operation, the tag may include "task.result", and so on. Of course, the above operation types and information indicating operation types are merely illustrative, and any appropriate operation type or information can be selected to indicate the operation type according to actual needs. This document does not impose any restrictions on this.

[0065] Alternatively and / or additionally, operation information may include an identifier for the operation (sometimes referred to herein as the "first identifier"), such as a task number, code, or identifier. The identifier for the operation may be represented by the field "X-TaskId," whose value indicates the identifier of the operation. In some examples, the value of this field may be a string of numbers or characters; this identifier may be user-specified or randomly generated by the sender. It is understood that each operation's identifier is unique, which helps distinguish different operations. It is important to note that if an operation is related to a second operation, and the execution of the second operation is based on the execution result of the first operation (in this case, the second operation can be referred to as the parent operation of the first operation, and the second operation as the child operation of the second operation), the operation request may also include the identifier of the second operation. In some examples, the field "X-ParentTaskId" may be used to indicate that the operation has a parent operation, and the value of this field is the identifier of the parent operation.

[0066] Alternatively and / or additionally, the operation information may include a descriptive description of the operation. For example, if the email instructs a task scheduling operation, the descriptive information may include a natural language-based task description. Alternatively and / or additionally, the operation information may include a time limit for the operation, which may include a deadline for the operation (e.g., XXXX year XX month XX day XX hour XX minute). The time limit may also indicate that the operation has no deadline (e.g., "no deadline"). The time limit for the operation may be represented as the field "X-Expires-At", whose value indicates the expiration time of the operation. This value may indicate a specific time or time period. For example, the field corresponding to the time limit may be "X-Expires-At: A year B month C day, aa:bb:cc", which indicates that the operation expires at aa:bb:cc on A year B month C day. As another example, the field corresponding to the time limit may be "X-Expires-At: one week", which indicates that the operation expires if the recipient has not completed the operation within one week of receiving the first email.

[0067] Alternatively and / or additionally, the operation information may include the operation's priority, such as urgent, high, normal, etc. This priority indicates the degree of priority of the operation. The priority can be represented as a field "X-Priority," whose value indicates the operation's priority. In some cases, this value may include, for example, urgent, high, or normal. For example, the priority field could be "X-Priority: high," indicating that the operation has a high priority. Of course, this value can also be a specific numerical value.

[0068] Alternatively and / or additionally, the operation information may indicate requirements for the output format of the operation, i.e., the format requirements for the execution result. For example, the operation information may indicate outputting a file in a specific format. Alternatively and / or additionally, the operation information may include reference information. In some cases, the reference information may include reference content or a reference file. In other cases, the reference information may indicate how to obtain the reference content or reference file; for example, the reference information may indicate a reference field in a node in the workflow, from which the sender or receiver can obtain the reference content. Another example is that the reference information may indicate the address of a reference file. Of course, the above operation information is merely exemplary, and any appropriate operation information can be selected according to actual needs. This document does not impose any limitations on this.

[0069] Alternatively and / or additionally, operation information may include operation context information. For example, operation context information may be represented as the field "X-Dispatch-Context," whose value may indicate one or more of the following: the source of the operation, the initiator of the operation, the operation associated with the operation, or the task node corresponding to the operation. It is understood that an operation request may include one or more fields; for example, an operation request may simultaneously include a field indicating the identifier of the operation and a field indicating the priority of the operation.

[0070] In some examples, an email may include an email header and an email body.

[0071] As used in this article, the term "email header" refers to the header portion of an email data packet, distinct from the email body. The email header may contain sender information, recipient information, sending date, signature, etc. While some content of the email header is not typically visible in regular email clients, it is transmitted and processed as part of the email data. The term "email body," as used in this article, refers to the body portion of an email data packet, containing user-visible content such as the email subject and body. The content of the email body may include natural language text or other user-readable information.

[0072] In some scenarios, during email communication between business system 120 and intelligent component 130, between intelligent components 130, and between a user and intelligent component 130, the email header can be expanded to include structured semantic information. Therefore, all or part of the operation information described above can be stored in the email header or email body. For example, at least one of the following—operation type, identifier, time limit, priority, reference information, context information, and requirements for the output format of the operation—can be recorded in the email header as structured data. The information in the email header is typically encapsulated as structured information, including one or more fields, each field name corresponding to an information type, and field values ​​that may include the corresponding information. By placing machine-readable semantics in the email header, such structured information can be processed and extracted more easily and quickly by the email recipient (e.g., business system, intelligent component), thereby improving communication efficiency. It should be understood that in other scenarios, this operation information can also be recorded in the email body. In the email body, this operation information can also be represented in a structured information format, or any other suitable format, to facilitate parsing by the email recipient.

[0073] In some situations, during email communications between business system 120 and intelligent component 130, between intelligent components 130, and between a user and intelligent component 130, descriptive information or at least some reference information related to the operation can be recorded in the email body. For example, task descriptions, outputs, reasons for blocking, and narrative context expressed in natural language can be placed in the email body. In other situations, this information can also be recorded in the email header.

[0074] Figure 3 A schematic diagram of a communication process 300 under certain circumstances is shown. This communication process may involve at least two clients, such as client 301 and client 302. Client 301 may be a terminal device deployed with a first intelligent component, and client 302 may be another terminal device that needs to communicate with the first intelligent component. For example, client 301 may be terminal device 201, and client 302 may be another terminal device deployed with or running a business system (e.g., business system 120) or an intelligent component (e.g., intelligent component 130).

[0075] like Figure 3 As shown, client 302 can obtain (311) the first email address of the first intelligent component. The email address can be used to identify the receiving end location of the first intelligent component in the communication system, thereby enabling client 302 to send information to the first intelligent component. In other words, the email address of the first intelligent component can be understood as the communication identifier of the first intelligent component in the cross-domain communication system, used to support communication with other objects.

[0076] In some examples, client 302 may pre-store the email address of the first intelligent component locally. Alternatively or additionally, client 301 may pre-register the first email address in a task scheduling platform or other business system. Client 302 can then query and retrieve the first email address from the task scheduling platform or other business system.

[0077] Continue to refer to Figure 3 Client 302 can send (312) the first email. The recipient of the first email can be the first email address of the first smart component, and the sender of the first email can be the second email address of the object.

[0078] In some scenarios, the object can be the one that triggers the sending of the first email. For example, the object can run on or be operated through client 302 to communicate with the first smart component. Alternatively, the object could include another smart component deployed on client 302 that can initiate a call request to the first smart component via email, thereby enabling collaborative processing between smart components.

[0079] In some examples, the object may include a business platform running on client 302 or a server connected to client 302, which can dispatch tasks to the first intelligent component via email and receive execution results. Alternatively or additionally, the object may include a user operating through client 302, who can trigger email sending through the user interface to initiate an operation request to the first intelligent component or receive information sent by the first intelligent component.

[0080] In some scenarios, a first intelligent component can be associated with a first domain, and an object can be associated with a second domain. The first and second domains can be different. In this case, using the email protocol as an intermediary for asynchronous data transmission can enable information exchange between different domains, thereby forming a cross-domain communication link.

[0081] In some examples, the above method enables communication across operating environments. The first intelligent component can be deployed on a local device or in a restricted network environment (e.g., behind a firewall). Communication requests to the first intelligent component can be made by sending an email to it. In other examples, the above method enables communication across organizations. Objects associated with different organizations (e.g., intelligent components belonging to different organizations) can communicate via email without establishing a unified interface or trust system.

[0082] In some examples, cross-protocol communication can be achieved through the above methods. Objects in different communication systems (e.g., smart components with different communication protocols) can undergo identifier conversion through access layers or gateway mechanisms, mapping their identifiers in their respective communication systems to corresponding email addresses, thereby enabling objects associated with different protocol domains to communicate based on email protocols.

[0083] In some examples, cross-email domain communication can be achieved using the methods described above. Objects in different email service systems (e.g., smart components or business systems using email addresses from different email providers) can interact via email protocols, thereby enabling cross-email domain communication.

[0084] In some cases, the first domain and the second domain may correspond to at least one of the following: different entities or different email domains. An entity may refer to an object with independent management or usage boundaries. For example, an entity may correspond to different organizations, objects located in different geographical regions, or different devices. In some examples, intelligent components running on different devices may belong to different entities, and users in different geographical regions may belong to different entities. The term "organization" as used herein may refer to a set of objects with unified management boundaries, in which computing resources, users, or intelligent components may be subject to unified management policies or access control rules. For example, an organization may correspond to a business, institution, department, individual, or other entity with independent management boundaries. The first domain and the second domain may correspond to different entities and / or different email domains, thereby making the first intelligent component and the object considered to be in different domains.

[0085] In some situations, different email domains can be provided by different email service providers. For example, different users, intelligent components, or business systems can register email addresses through different email service providers, thereby obtaining email addresses with different domains. These email addresses correspond to different email service providers or mail servers, but these email service providers or mail servers can enable cross-domain communication between these objects by supporting or being compatible with the same email communication protocol (e.g., a default email protocol).

[0086] In some cases, a first email address may include a first identifier, and a second email address may include a second identifier. The first identifier may indicate a first domain, and the second identifier may indicate a second domain. Identifiers can be used to distinguish different domains during communication, thereby supporting routing, identification, or policy processing in cross-domain communication. In some examples, identifiers may include domain identifiers, tenant identifiers, organization identifiers, or other information that characterizes the affiliation of the communication environment. For example, an email address may include a structure of "user identifier@domain," where the domain portion is an identifier indicating the domain to which it belongs. Alternatively or additionally, a tenant identifier or organization identifier may be included in the email address or its extended information to distinguish different domains.

[0087] In some cases, the first email may include an operation request. This operation request instructs the first intelligent component to perform a first operation. For example, the first operation may include, but is not limited to: task assignment, task cancellation, capability query, request for assistance, data processing, tool invocation, or other operations related to business processing. By sending a first email containing the operation request to the first intelligent component, the first intelligent component can be triggered to perform the corresponding operation according to the operation request. In this process, the first intelligent component can act as a task execution node in the entire communication system, while the object on the client side (302) acts as the task initiator, remotely invoking the first intelligent component via email.

[0088] In the aforementioned communication process, emails can serve as information carriers transmitted between different domains, enabling objects associated with the second domain to send operation requests to the first intelligent component associated with the first domain. Thus, the first intelligent component can be invoked without relying on pre-established interface connections or direct network access capabilities, thereby supporting communication and task scheduling in cross-domain environments.

[0089] In some cases, after receiving the first email, client 301 can use the first smart component to perform (322) the first operation, which corresponds to the operation request. In this way, the first smart component can be triggered to perform the corresponding operation based on the operation request carried in the first email, thereby realizing cross-domain communication and remote invocation based on email.

[0090] In cross-domain communication scenarios, the first email can originate from an object in a different domain, and there is no need for a direct connection or pre-existing trust relationship between the sender and receiver. Therefore, the first email can be verified before performing any operations to improve the security and reliability of the communication process. (Continue to refer to...) Figure 3 In some cases, client 301 can perform verification (321) on the first email.

[0091] In some cases, verification includes verifying at least one of an object or an operation request. Verification of an object can be used to determine whether the sender of the first email is a trusted object. For example, it can be determined whether the sender's second email address falls within the permitted communication range, thereby determining whether the object has the permission to initiate a request to the first intelligent component. Verification of operation requests can be used for more granular permission verification. For example, even if the sender is a trusted object, the operation requests it initiates may differ in different scenarios; therefore, it can be further judged based on relevant information of the operation request to prevent unqualified requests from being executed.

[0092] In some cases, client 301 can respond to the first email passing verification by executing (322) the first operation. For example, if it is determined that the first email meets the predetermined verification conditions, the first intelligent component can execute the corresponding operation according to the operation request in the first email, thereby completing the process of task processing, data processing, or tool invocation. If the first email fails verification, the first operation can be refused to be executed, thereby avoiding potential abnormal behavior.

[0093] Figure 4 A schematic diagram illustrates a process 400 for verifying the first email under certain conditions. Process 400 can be executed by client 301 to verify the received first email. Figure 4 As shown in box 410, client 301 can verify the identity of the object based on the second email address and pre-defined verification conditions.

[0094] In some scenarios, the predefined verification conditions may include a first address list. In response to the first address list including a second email address, client 301 can determine that the identity has been verified. The first address list can be understood as a whitelist, indicating the set of email addresses allowed to communicate. For example, if the second email address is included in the first address list, client 301 can determine that the object's identity has been verified. In this way, only specific objects can be allowed to initiate operation requests to the first intelligent component, thereby implementing whitelist-based access control.

[0095] In some cases, the predefined authentication conditions may include a second address list. If the second email address is not included in the second address list, client 301 can determine that the identity has been authenticated. The second address list can be understood as a blacklist, a set of email addresses that are not allowed to communicate. For example, if the second email address is not included in the second address list, client 301 can determine that the object's identity has been authenticated. In this way, known untrusted objects can be excluded, thereby implementing blacklist-based access control.

[0096] In box 420, client 301 can determine whether the object's identity has been verified. If the object's identity has not been verified, process 400 can proceed to box 421. In box 421, client 301 can discard the first email. For example, client 301 can discard the first email or refuse to respond to it, thereby preventing an unauthorized object from triggering the first smart component to perform an operation.

[0097] In some cases, if the object's identity is verified, process 400 can proceed to box 430. In box 430, client 301 can verify the operation request based on the context information of the first operation and predefined verification conditions. In this way, after the sender's identity has been verified, the specific semantics of the operation request and its triggering conditions can be further determined, thereby avoiding execution of operations in inappropriate business scenarios.

[0098] In some cases, the first email may include context information for the first operation. Pre-defined verification conditions include this pre-defined context information. Client 301 can obtain the context information for the first operation from the first email and compare it with the pre-defined context information. If the context information at least partially matches the pre-defined context information, client 301 can determine that the operation request has been verified.

[0099] In some cases, the context information in the first email can refer to information describing the execution environment, source relationship, or business semantics of the first operation. Context information can be used to characterize the source, purpose, relationship, or process to which the operation request belongs, thereby supporting more granular verification of the operation request. Predefined context information can refer to the context conditions corresponding to allowed operation requests pre-configured or maintained by the client (e.g., 301 redirects), used to limit under what context conditions the corresponding operation is allowed to be executed. By performing verification based on context information, the precision of control over operation requests can be further improved on top of object authentication, thereby achieving fine-grained access control.

[0100] In some examples, contextual information can be used to identify the business and execution semantics associated with the first operation. Contextual information may include at least one of the following: the operating environment associated with the first operation, the initiator of the first operation, the operation associated with the first operation, the workflow to which the first operation belongs, the business system carrying the workflow, the task type of the first task corresponding to the first operation, the reason for initiating the first operation, or the type of the first operation. Client 301 can perform fine-grained authorization decisions based on this contextual information, such as allowing only operation requests from specific business spaces or specific users, thereby further improving the security and controllability of the system.

[0101] For example, the operating environment can include the execution scenario in which the object initiates the first operation, such as its business scope, application environment, or runtime context. The initiator can be the user who triggers the operation request. A workflow can be used to describe the position of the first operation within the overall business process. The business system hosting the workflow can be used to identify the application environment hosting the workflow. The task type can be used to distinguish different categories of task requests. The reason for initiation can be used to characterize the business requirement that triggers the operation request. The operation type can be used to indicate the functional category of the first operation (e.g., task dispatch, cancellation, query, or processing).

[0102] Continue to refer to Figure 4 In box 440, client 301 can determine whether the operation request has been validated. If the operation request has been validated, process 400 can proceed to box 450. In box 450, client 301 can determine that the first email has been validated and execute the first operation indicated by the first email. For example, client 301 can use a first smart component to invoke at least one tool associated with the first operation to process the corresponding operation request.

[0103] In some cases, if it is determined that the operation request has failed authentication, process 400 can proceed to box 441. In box 441, client 301 can refuse to perform the first operation. By refusing to execute the unauthenticated operation request, tasks that do not meet the requirements can be prevented from being executed, thereby improving the security of cross-domain communication.

[0104] In some scenarios, within box 442, client 301 can send a notification email to a second email address. This notification email can indicate verification failure. For example, if the object's identity has been verified but the operation request has failed, the notification email could include information explaining the reason for the verification failure, such as a specific field where the context information did not match or a condition that was not met. Since the object is an authenticated object, client 301 can send the verification result back to the sender while refusing to perform the first operation, allowing the sender to adjust subsequent requests based on the feedback. This approach provides a clearer feedback path, improving the debuggability and interaction efficiency of the communication process.

[0105] In some cases, contextual information can be found in the email header of the first email. The email header can be a section of the email that carries structured information, such as fields describing email attributes or additional information. Compared to the email body, the information in the email header has a more explicit structure and semantics, making it easier for the client to parse using a 301 redirect, thus supporting automated processing. By setting contextual information in the email header, the client can obtain the contextual information in a machine-readable manner, thereby improving the efficiency and accuracy of parsing and validating operation requests. Alternatively or additionally, contextual information can be included in the email body of the first email. For example, contextual information can be carried in the email body in the form of structured text.

[0106] In some examples, context information can be represented in key-value pairs. For instance, context information may include one or more fields, each consisting of a key and a value, such as "key1=value1", "key2=value2", etc. This way, the relevant context of the operation request can be described in a structured form, making it easier for the client to parse and process it using a 301 redirect.

[0107] In some scenarios, context information can take the form of an extensible key-value pair structure, allowing different types of objects to define different context fields according to their own needs. For example, different business systems or different intelligent components can use different keys to describe their specific business information without pre-defining a unified set of fields. This extensible structure enables the transmission and verification of context information from multiple sources within the same communication system.

[0108] In some scenarios, client-side 301 statements can be configured with predefined verification conditions based on key-value pair structures. For example, value constraints can be set for specific keys, or matching conditions can be set for combinations of multiple keys, thereby defining the range of context information that satisfies the predefined conditions. This approach allows for flexible configuration of verification conditions, enabling verification logic to adapt to different business systems or communication scenarios.

[0109] In some scenarios, predefined verification conditions can be associated with a first intelligent component. For example, different intelligent components can be configured with different verification conditions to suit their own security needs or business scenarios. Predefined verification conditions can be configured by client 301 (e.g., the administrator of the first intelligent component) to limit the scope of operation requests that the intelligent component is allowed to receive and execute. Alternatively or additionally, predefined verification conditions can be common verification conditions shared by multiple intelligent components, such as a security policy uniformly configured by client 301, thereby achieving consistent access control rules among multiple intelligent components.

[0110] In some situations, client 301 may present a first interface. This first interface can be used to configure predetermined verification conditions for the first intelligent component. For example, predetermined verification conditions can be configured through the first interface in at least one of the following situations: the first intelligent component is deployed, the first intelligent component is registered to a cross-domain communication system, or the verification strategy is adjusted during operation. By configuring at different stages, the verification strategy can be adapted to different usage requirements.

[0111] Furthermore, client 301 can receive a first input on the first interface, the first input indicating the configuration of predetermined verification conditions for the first intelligent component. For example, the first input can be received through an input component on the first interface. The first input may include constraints on key-value pairs in the context information. For example, it may be specified that the value corresponding to a certain key must meet a predetermined value, or that the first operation is only allowed when it matches a specific key-value pair. In this way, the execution of the first operation can be triggered only when the operation request originates from a specific business scope.

[0112] In some cases, predefined verification conditions may include a first verification condition and a second verification condition, where the first verification condition corresponds to a first object category and the second verification condition corresponds to a second object. By setting different verification conditions for different object categories, the client 301 can adopt differentiated verification strategies based on object characteristics, thereby improving the flexibility and security of verification.

[0113] In some situations, object categories can be used to distinguish different types of objects that initiated the first email. Different object categories can correspond to different communication behavior characteristics and security requirements. For example, object categories may include users, intelligent components, or business platforms. Client 301 can determine the object category to which an object belongs based on the identification information in the first email.

[0114] In some scenarios, if the object belongs to a first object category, client 301 can perform verification on the first email based on a first verification condition. If the object belongs to a second object category, client 301 can perform verification on the first email based on a second verification condition. For example, for objects of the user category, client 301 can use an email address-based verification strategy to verify the user's identity. For objects of the business system or intelligent component category, client 301 can use a context-based verification strategy, matching key-value pairs in the context information to determine whether the operation request corresponds to an executable first operation.

[0115] In some scenarios, in response to the successful verification of the first email, client 301 can execute the first operation indicated by the operation request. The first intelligent component can complete the corresponding task processing based on the operation request, such as performing data processing, calling tools, or triggering subsequent processes. During or after the execution of the first operation, client 301 can send back the execution information or results to the sender via email, thus achieving a complete communication loop.

[0116] In some cases, client 301 can send (323) a second email. The recipient of the second email is a second email address. The second email may include response information of the first operation, which includes the execution result of the first operation. For example, the execution result may include processed data, task completion status, or call result, etc. By sending the second email, the execution result of the first intelligent component can be fed back to the object, thereby completing an email-based request and response process.

[0117] In some cases, in response to the failure of the first operation, the second email may also include information about the reason for the failure. For example, the reason for failure may include information about an exception that occurred during execution, information about unavailable resources, or a message indicating that the execution conditions were not met. By returning information about the reason for failure, the sender can understand the specific reason for the failure, thereby facilitating subsequent processing or adjustments to the request.

[0118] In some situations, a client-side 301 redirect can send a third email to a second email address. This third email includes the execution status information of the first operation. For example, if the first operation takes a long time to execute, the current execution status can be fed back to the sender via a third email. Passing status information improves the transparency of the communication process and enhances the user experience.

[0119] In some scenarios, client 301 can respond to the need for supplementary information in the first operation by sending a fourth email to the second email address. This fourth email includes a request for additional information. For example, if the operation request lacks necessary parameters or context information during the execution of the first operation, client 301 can request supplementary information from the sender via the fourth email. Furthermore, client 301 can receive a fifth email from the second email address, which may include supplementary information. Client 301 can then continue executing the first operation or complete subsequent processing based on the supplementary information. Through this method, multi-turn interactions can be achieved within the email communication mechanism, thereby supporting the execution of complex tasks.

[0120] In some scenarios, the execution of the first operation may involve the collaborative processing of multiple intelligent components. For example, when performing the first operation, the first intelligent component may determine that at least a portion of the first operation needs to be completed by other intelligent components, thereby triggering communication with other intelligent components. In this case, client 301 may send a sixth email in response to the first operation being associated with a third intelligent component. The recipient of the sixth email is the third email address of the third intelligent component. The sixth email includes instructions for at least one second operation associated with the first operation.

[0121] In some scenarios, a third intelligent component can be associated with a third domain. This third domain may differ from the first domain associated with the first intelligent component. Cross-domain collaboration among multiple intelligent components can be achieved by sending operation requests to intelligent components in different domains via email.

[0122] Furthermore, client 301 can receive a seventh email, sent to a third email address. This seventh email includes the execution result of at least one second operation by the third intelligent component, wherein the execution of the first operation is based at least on the execution result of at least one second operation. For example, after receiving the execution result returned by the third intelligent component, the first intelligent component can process the result and complete the remaining part of the first operation based on it, or integrate it as part of the overall result. In this way, an email-based collaborative mechanism can be established between multiple intelligent components, enabling intelligent components in different domains to participate in the execution process of the same operation.

[0123] In some examples, before executing at least one second action, a client with a third intelligent component can verify the sixth email and at least one second action based on context information in the sixth email and corresponding predefined verification conditions. By passing context information during multi-hop communication and performing verification separately at each intelligent component, consistency of security controls can be maintained during cross-domain collaboration.

[0124] In summary, by adopting an email-based communication mechanism, intelligent components, business systems, or users in different domains can communicate using a unified communication identifier (e.g., email address), enabling cross-domain communication between objects in different domains without establishing direct network connections or dedicated interfaces. This approach enhances communication capabilities and system integration flexibility in heterogeneous environments.

[0125] On the other hand, a multi-layered authentication mechanism is introduced during cross-domain communication, including email address-based authentication and context-based operation request authentication, combined with configurable authentication conditions. This approach allows the intelligent component itself to control the communication of received requests, thereby effectively improving the security and controllability of communication in an open cross-domain communication environment.

[0126] Figure 5 A flowchart of an example process 500 for communication is shown, based on some scenarios. Process 500 can be implemented at the client 301. See below for reference. Figure 3 To describe process 500.

[0127] In box 510, client 301 receives the first email, which includes an operation request. The recipient of the first email is the first email address of the first smart component, and the sender of the first email is the second email address of the object. The first smart component is associated with the first domain, and the object is associated with the second domain.

[0128] In box 520, client 301 uses the first smart component to perform the first operation, which corresponds to the operation request.

[0129] Through the above process, the first intelligent component can receive emails from objects associated with different domains via email addresses and perform corresponding operations based on the operation requests in the emails, thereby realizing cross-domain intelligent component communication.

[0130] In some cases, a first email address may include a first identifier, and a second email address may include a second identifier. The first identifier may indicate a first domain, and the second identifier may indicate a second domain. By including domain identifiers in the email addresses, the communicating parties can identify the domains they are associated with.

[0131] In some cases, the first and second domains can correspond to at least one of the following: different entities or different email domains. This allows for cross-domain communication between different entities or different email domains.

[0132] In some scenarios, an object can include at least one of the following: a second intelligent component, a business system, or a user. By supporting multiple object types, intelligent components can communicate with different types of objects.

[0133] In some cases, process 500 may further include at least one of the following: sending a second email, the recipient of which may be a second email address, and the second email may include response information for the first operation, which may include the execution result or execution status information of the first operation; or in response to the failure of the first operation, sending a third email, which includes information about the reason for the failure. By sending response emails or status emails, the object can be informed of the execution result or progress of the first operation.

[0134] In some cases, process 500 may further include: performing verification on the first email, which may include verifying at least one of the following: an object or an operation request; wherein performing the first operation may include: performing the first operation in response to the first email passing verification. By performing verification on the email, security can be provided for cross-domain communication.

[0135] In some scenarios, the verification object may include: verifying the object's identity based on a second email address and predetermined verification conditions. Verifying identity based on an email address ensures that only authorized senders can communicate with the smart component.

[0136] In some cases, the predefined verification conditions may include at least one of a first address list or a second address list, and the identity of the object to be verified may include at least one of the following: verification is confirmed if the first address list includes a second email address; or verification is confirmed if the second address list does not include a second email address. Flexible access control policies can be implemented through whitelists or blacklists.

[0137] In some scenarios, verifying an operation request may include: obtaining context information for a first operation from a first email; and determining that the operation request passes verification in response to a partial match between the context information and predetermined context information. Verifying operation requests based on context information allows for more granular access control.

[0138] In some cases, contextual information can be included in the header of the first email, and this contextual information can indicate at least one of the following: the operating environment associated with the first operation, the initiator of the first operation, the operation associated with the first operation, or the workflow to which the first operation belongs, the business system carrying the workflow, the task type of the first task, the reason for initiating the first operation, and the type of the first operation. By including structured contextual information in the email header, the reliability and accuracy of communication can be improved.

[0139] In some scenarios, verifying the first email may include: verifying the identity of the recipient based on a second email address and predetermined verification conditions; in response to successful identity verification, verifying an operation request based on the context information of the first operation and the predetermined verification conditions, where the context information of the first operation may be included in the operation request; and in response to successful operation request verification, determining that the first email has passed verification. This two-phase verification process provides more comprehensive security.

[0140] In some cases, verification can be performed on the first email based on predetermined verification conditions, which can be associated with the first smart component. By configuring independent verification conditions for each smart component, personalized security policies can be implemented.

[0141] In some cases, process 500 may further include: in response to a first operation associated with a third intelligent component, sending a sixth email, the recipient of which may be a third email address of the third intelligent component, the third intelligent component being associated with a third organization, and the sixth email may include an instruction for at least one second operation associated with the first operation; and receiving a seventh email, the sender of which may be a third email address, and the seventh email may include the result of the third intelligent component's execution of at least one second operation, wherein the execution of the first operation may be based at least on the result of the execution of at least one second operation. By supporting collaborative task execution between intelligent components, the capabilities of a single intelligent component can be extended.

[0142] In some scenarios, predetermined verification conditions may include a first verification condition and a second verification condition. The first verification condition may correspond to a first object category, and the second verification condition may correspond to a second object category. Performing verification on a first email may include: verifying the first email based on the first verification condition in response to the object belonging to the first object category; or verifying the first email based on the second verification condition in response to the object belonging to the second object category. By applying different verification strategies to different object categories, differentiated security controls can be achieved.

[0143] In some cases, the first operation may include invoking at least one tool to handle the operation request. By invoking tools, intelligent components can perform various types of processing tasks.

[0144] In some cases, in response to the failure of the first operation, the second email may also include information about the reason for the failure. By providing the reason for the failure, the recipient can understand why the operation failed and take appropriate action.

[0145] In some cases, process 500 may also include receiving a fifth email from a second email address, which may include supplementary information. Receiving supplementary information allows for handling situations where the intelligent component requires additional information during task execution.

[0146] In some cases, process 500 may further include: presenting a first interface; and receiving a first input on the first interface, the first input indicating the configuration of predetermined verification conditions for the first smart component. By providing a configuration interface, users can easily set security policies for the smart component.

[0147] Figure 6 A flowchart of an example process 600 for communication is shown, based on some scenarios. Process 600 can be implemented at the client 302. See below for reference. Figure 3 To describe process 600.

[0148] like Figure 6 As shown in box 610, client 302 obtains the email address of the first smart component, which is associated with the first domain.

[0149] In box 620, client 302 sends a first email. The recipient of the first email is the first email address of the first smart component, and the sender of the first email is the second email address of the object. The object is associated with the second domain. The first email includes an operation request, which instructs the first smart component to perform the first operation. Through the above process, the object can send operation requests to smart components associated with different domains via email, thereby achieving cross-domain communication.

[0150] In some cases, a first email address may include a first identifier, and a second email address may include a second identifier. The first identifier may indicate a first domain, and the second identifier may indicate a second domain. By including domain identifiers in the email addresses, the communicating parties can identify the domains they are associated with.

[0151] In some cases, the first and second domains can correspond to at least one of the following: different entities or different email domains. This allows for cross-domain communication between different entities or different email domains.

[0152] In some cases, process 600 may further include: receiving a second email, the sender of which may be the first email address of the first smart component. The second email may include response information for the first operation, and the response information may include the execution result of the first operation. By receiving the response email, the object can learn about the execution result of the first operation.

[0153] In some cases, the first email may also include context information about the first operation, and this context information can be in the email header of the first email. By including context information in the email header, the recipient's intelligent components can perform verification and decision-making based on the context information.

[0154] A corresponding apparatus for implementing the above methods or processes is also provided.

[0155] Figure 7 A schematic structural block diagram of an example device 700 for communication under certain circumstances is shown. Device 700 can be implemented as or included in client 301. The various modules / components in device 700 can be implemented by hardware, software, firmware, or any combination thereof.

[0156] like Figure 7As shown, the device 700 includes a receiving module 710 configured to receive a first email, the first email including an operation request, the recipient of the first email being a first email address of a first smart component, the sender of the first email being a second email address of an object, the first smart component being associated with a first domain, and the object being associated with a second domain; and an execution module 720 configured to perform a first operation using the first smart component, the first operation corresponding to the operation request.

[0157] In some cases, the first email address may include a first identifier, the second email address may include a second identifier, the first identifier may indicate a first domain, and the second identifier may indicate a second domain.

[0158] In some cases, the first and second domains can correspond to at least one of the following: different entities, or different mail domains.

[0159] In some cases, the object may include at least one of the following: a second intelligent component, a business system, or a user.

[0160] In some cases, the device 700 may also include a sending module configured to perform at least one of the following: sending a second email, the recipient of which may be a second email address, the second email may include response information of the first operation, the response information may include the execution result or execution status information of the first operation; or sending a third email, the third email including failure reason information.

[0161] In some cases, the device 700 may also include a verification module configured to perform verification on the first email, the verification including verifying at least one of the following: an object or operation request; wherein the execution module 720 may be further configured to perform a first operation in response to the first email passing verification.

[0162] In some cases, the verification module can be further configured to verify the identity of the object based on a second email address and predetermined verification conditions.

[0163] In some cases, the predetermined verification conditions may include at least one of a first address list or a second address list, and the verification module may be further configured to perform at least one of the following: in response to the first address list including a second email address, the identity can be determined to be verified; or in response to the second address list not including a second email address, the identity can be determined to be verified.

[0164] In some cases, the verification module can be further configured to: obtain context information of the first operation from the first email; and determine that the operation request passes verification in response to the context information at least partially matching the predetermined context information.

[0165] In some cases, contextual information may be in the header of the first email, and the contextual information may indicate at least one of the following: the operating environment associated with the first operation, the initiator of the first operation, the operation associated with the first operation, or the workflow to which the first operation belongs, the business system carrying the workflow, the task type of the first task, the reason for initiating the first operation, and the type of the first operation.

[0166] In some cases, the verification module can be further configured to: verify the identity of the object based on the second email address and predetermined verification conditions; in response to the identity verification being successful, verify the operation request based on the context information of the first operation and the predetermined verification conditions, wherein the context information of the first operation can be included in the operation request; and in response to the operation request being successfully verified, determine that the first email has been verified.

[0167] In some cases, the first email can be verified based on predetermined verification conditions, which can be associated with the first smart component.

[0168] In some cases, device 700 may further include a collaboration module configured to: in response to a first operation associated with a third smart component, send a sixth email, the recipient of which may be a third email address of the third smart component, the third smart component may be associated with a third organization, and the sixth email may include an instruction for at least one second operation associated with the first operation; and receive a seventh email, the sender of which may be a third email address, and the seventh email may include the result of the third smart component's execution of at least one second operation, wherein the execution of the first operation may be based at least on the result of the execution of at least one second operation.

[0169] In some cases, the predetermined verification conditions may include a first verification condition and a second verification condition. The first verification condition may correspond to a first object category, and the second verification condition may correspond to a second object category. The verification module may be further configured to: perform verification on the first email based on the first verification condition in response to the object belonging to the first object category; or perform verification on the first email based on the second verification condition in response to the object belonging to the second object category.

[0170] In some cases, the first operation may include invoking at least one tool to handle the operation request.

[0171] In some cases, in response to the failure of the first operation, the second email may also include information about the reason for the failure.

[0172] In some cases, the receiving module 710 can be further configured to receive a fifth email from a second email address, the fifth email of which may include supplementary information.

[0173] In some cases, device 700 may also include a configuration module configured to: present a first interface; and receive a first input on the first interface, the first input indicating that predetermined verification conditions are configured for a first smart component.

[0174] Figure 8 A schematic block diagram of an example communication device 800 is shown, according to several scenarios. Device 800 can be implemented as or included in client 302. The various modules / components in device 800 can be implemented by hardware, software, firmware, or any combination thereof.

[0175] like Figure 8 As shown, the device 800 includes an acquisition module 810 configured to acquire the email address of a first smart component, the first smart component being associated with a first domain; and a sending module 820 configured to send a first email, the recipient of which is the first email address of the first smart component, the sender of which is the second email address of an object, the object being associated with a second domain, the first email including an operation request, the operation request indicating a first operation, and the first email used to instruct the first smart component to perform the first operation.

[0176] In some cases, the first email address may include a first identifier, the second email address may include a second identifier, the first identifier may indicate a first domain, and the second identifier may indicate a second domain.

[0177] In some cases, the first and second domains can correspond to at least one of the following: different entities, or different mail domains.

[0178] In some cases, device 800 may also include a receiving module configured to receive a second email, the sender of which may be a first email address of the first smart component, and the second email may include response information of the first operation, the response information may include the execution result of the first operation.

[0179] In some cases, the first email may also include context information about the first operation, and this context information may be in the header of the first email.

[0180] The modules included in devices 700 and 800 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some cases, one or more modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in devices 600 and 700 can be implemented at least partially by one or more hardware logic components. By way of example, and not limitation, exemplary types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Parts (ASSPs), Systems on a Chip (SOCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0181] Figure 9 A block diagram of an electronic device 900 in which one or more examples may be implemented is shown. It should be understood that... Figure 9 The electronic device 900 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described herein. Figure 9 The electronic device 900 shown can be used to implement client 301 or client 302 as discussed above.

[0182] like Figure 9 As shown, electronic device 900 is in the form of a general-purpose electronic device. Components of electronic device 900 may include, but are not limited to, one or more processing units or processors 910, memory 920, storage devices 930, one or more communication units 940, one or more input devices 950, and one or more output devices 960. Processor 910 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 920. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 900.

[0183] Electronic device 900 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 900, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 920 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 930 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data and can be accessed within electronic device 900.

[0184] Electronic device 900 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 9 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 920 may include computer program product 925 having one or more program modules configured to perform various methods or actions of various examples.

[0185] The communication unit 940 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 900 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 900 can operate in a networked environment using logical connections to one or more other servers, networked personal computers, or another network node.

[0186] Input device 950 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 960 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 900 can also communicate with one or more external devices (not shown) via communication unit 940 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 900, or with any device that enables electronic device 900 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interfaces (not shown).

[0187] A computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. A computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above.

[0188] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0189] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0190] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0191] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0192] Various examples have been described above. The foregoing descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

1. A method for communication, comprising: Receive a first email, the first email includes an operation request, the recipient of the first email is the first email address of the first smart component, the sender of the first email is the second email address of the object, the first smart component is associated with a first domain, and the object is associated with a second domain. as well as The first intelligent component is used to perform a first operation, which corresponds to the operation request.

2. The method according to claim 1, wherein the first email address includes a first identifier, the second email address includes a second identifier, the first identifier indicates the first domain, and the second identifier indicates the second domain.

3. The method according to claim 1, wherein the first domain and the second domain correspond to at least one of the following: different entities, or different email domain names.

4. The method of claim 1, wherein the object comprises at least one of the following: The second intelligent component, business system, or user.

5. The method of claim 1, further comprising at least one of the following: Send a second email to the second email address. The second email includes at least one of the following: a response to the first operation or execution status information of the first operation, wherein the response information includes the execution result of the first operation; or In response to the failure of the first operation, a third email is sent to the second email address, and the third email includes information about the reason for the failure; or In response to the first operation requiring supplementary information, a fourth email is sent, the recipient of which is the second email address, and the fourth email includes a request for supplementary information; and a fifth email is received from the second email address, the fifth email including the supplementary information.

6. The method according to claim 1, further comprising: The first email is validated, and the validation includes validating at least one of the following: the object or the operation request. Performing the first operation includes: In response to the first email passing the verification, the first operation is performed, wherein the first operation includes invoking at least one tool to process the operation request.

7. The method of claim 6, wherein verifying the object comprises: The identity of the object is verified based on the second email address and the predetermined verification conditions.

8. The method of claim 7, wherein the predetermined verification condition includes at least one of a first address list or a second address list, and wherein verifying the identity of the object includes at least one of the following: In response to the first address list including the second email address, the identity is determined to be verified; or If the second email address is not included in the second address list, the identity is determined to be verified.

9. The method of claim 6, wherein verifying the operation request includes: Obtain the context information of the first operation from the first email; as well as In response to the context information matching at least partially with the predetermined context information, it is determined that the operation request has been verified.

10. The method of claim 9, wherein the context information indicates at least one of the following: The operating environment associated with the first operation, The initiator of the first operation, The operation associated with the first operation, or The workflow to which the first operation belongs The business system that carries the workflow, The first task type The reason for initiating the first operation, The type of the first operation.

11. The method of claim 6, wherein performing verification on the first email comprises: The identity of the object is verified based on the second email address and the predetermined verification conditions; In response to the identity being verified, the operation request is verified based on the context information of the first operation and the predetermined verification conditions, wherein the context information of the first operation is included in the operation request; as well as In response to the operation request being verified, it is determined that the first email has been verified.

12. The method of claim 6, wherein, Based on predetermined verification conditions, the first email is verified, wherein the predetermined verification conditions are associated with the first smart component, and the method further includes: Presenting the first interface; and The first input is received on the first interface, and the first input indicates that the predetermined verification conditions are configured for the first intelligent component.

13. The method of claim 1, further comprising: In response to the first operation being associated with a third intelligent component, a sixth email is sent, the recipient of which is a third email address of the third intelligent component, the third intelligent component being associated with a third domain, and the sixth email includes an indication of at least one second operation associated with the first operation. as well as A seventh email is received, the sender of which is the third email address, and the seventh email includes the execution result of the at least one second operation by the third intelligent component. The execution of the first operation is based at least on the result of the execution of the at least one second operation.

14. The method of claim 6, wherein, Based on predetermined verification conditions, the first email is verified. These predetermined verification conditions include a first verification condition and a second verification condition. The first verification condition corresponds to a first object category, and the second verification condition corresponds to a second object. The verification of the first email includes: In response to the object belonging to the first object category, perform verification on the first email based on the first verification condition; or In response to the fact that the object belongs to the second object category, the first email is validated based on the second validation condition.

15. A method for communication, comprising: Obtain the email address of the first smart component, which is associated with the first domain; as well as Send a first email, the recipient of which is the first email address of the first smart component, and the sender of which is the second email address of an object associated with a second domain. The first email includes an operation request, the operation request indicating a first operation, and the first email is used to instruct the first smart component to perform the first operation.

16. The method of claim 15, wherein the first email address includes a first identifier, the second email address includes a second identifier, the first identifier indicates the first domain, and the second identifier indicates the second domain.

17. The method of claim 15, wherein the first domain and the second domain correspond to at least one of the following: different entities, or different mail domain names.

18. The method of claim 15, further comprising: Receive a second email, the sender of which is the first email address of the first smart component, and the second email includes response information for the first operation, the response information including the execution result of the first operation.

19. The method of claim 18, wherein the first email further includes context information of the first operation.

20. An electronic device, comprising: At least one processor; as well as At least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to any one of claims 1 to 14 or 15 to 19 when executed by the at least one processor.

Images