Methods, devices, equipment, systems, and storage media for managing interaction contexts

Abstract

The present invention provides a method, apparatus, device, system, and storage medium for managing interaction contexts, and aims to improve the flexibility of managing interaction processes between suppliers and operators in the field of communications technology. The method includes obtaining the interaction context of a communication partner, wherein the interaction context of the communication partner includes a context identifier; performing processing based on the interaction context of the communication partner and obtaining the processing result; obtaining a local interaction context based on the processing result; and transmitting the local interaction context to the communication partner, wherein the local interaction context includes the context identifier. Embodiments of the present invention can improve the flexibility of managing interaction processes between suppliers and operators.

Description

Technical Field

[0001] (Cross - reference to related applications) This application is based on a Chinese patent application with application number 202310317358.6 filed on March 27, 2023, and claims the priority thereof. All the contents of the Chinese patent application are incorporated herein by reference. The present invention relates to the field of communication technologies, and particularly to a method, apparatus, device, system, and storage medium for managing interaction contexts.

Background Art

[0002] A development and operations integration framework (Development and Operations, DevOps, that is, a general term for a series of processes, methods, and systems) that supports the management of communication operations mainly includes two environments as shown in Figure 1(a), namely, the development environment on the supplier (also called provider or vendor) side and the development environment on the operator side. 1. Development environment on the supplier side: It refers to the development environment composed of the development pipelines of different telecommunications suppliers. Based on its own development pipeline, the supplier completes all processes from requirement management, design, development, construction, testing to delivery, and generates software products for delivery. 2. Development environment on the operator side: It includes a development and operations integration platform, a pre - production environment, and a production environment. Here, the development and operations integration platform provides development and operations management functions based on telecommunications software. The pre - production environment is used for pre - deployment and verification before the release of software products, and the production environment refers to the environment where software products officially provide services externally. The operator's production environment needs to meet the requirements of reliability and controllability. As shown in Figure 1(b), after the operator receives the software product delivered from the telecommunications supplier, the software is first synchronized with the supplier's pipeline. In the operator's development environment, related activities such as acceptance testing, launch deployment, and operational monitoring are completed through the automated pipeline. Acceptance testing phase: The DevOps server on the operator's integrated development and operations platform deploys the new software release to the test network environment and instructs the general-purpose test system to run pre-deployment validation tests. Deployment Phase: The DevOps server, part of the operator's integrated development and operations platform, deploys the new software release to the production environment. Operation and Monitoring Phase: The DevOps server subscribes to operational data of the deployed software in the production environment, instructs the data processing system to process the collected data as needed, generates data for feedback, and notifies the DevOps server of the feedback to the supplier. Request Feedback Phase: The DevOps server provides the supplier with feedback on the delivery (testing), deployment (operation) status, and necessary auxiliary information of the newly released software, which is used for the continuous optimization of the supplier's software. In a DevOps framework that supports the management of communications operations, after a telecommunications supplier completes the release of a software product, it promptly notifies the operator to acquire the software product via a software update notification interface. Upon receiving the supplier's software update notification, the operator acquires the software product via a software pull interface, triggering an internal pipeline within the operator. Test data, operational data, etc., generated by the telecommunications supplier's software product in the operator's production environment are collected by the operator's pipeline and then fed back to the supplier in a batch, completing a closed loop of software product request feedback. This is also called the feedback phase. In this process, data lifecycle management is necessary to ensure data security. In the DevOps process described above, any unexpected anomaly occurring at any stage could lead to the termination of that round of the process and an early transition to the feedback phase. Simultaneously, the operator provides necessary diagnostic support information to the telecommunications supplier to help them identify problems, update versions, and optimize iterations. However, existing technologies still lack a solution for how to manage interaction contexts across different iterations. [Overview of the Initiative]

[0003] Embodiments of the present invention provide methods, apparatus, devices, systems, and storage media for managing interaction contexts, with the aim of improving the flexibility of managing interaction processes between suppliers and operators.

[0004] In a first aspect, an embodiment of the present invention provides a method for managing interaction contexts applicable to a supplier or operator, the method for managing interaction contexts comprising: obtaining an interaction context of a communication peer, wherein the interaction context of the communication peer includes a context identifier; performing processing based on the interaction context of the communication peer and obtaining a processing result; obtaining a local interaction context based on the processing result; and transmitting the local interaction context to the communication peer, wherein the communication peer of the supplier is the operator, and the communication peer of the operator is the supplier. Optionally, a version identifier is used to identify version information of the software to be released; a defect identifier is used to identify defects that are expected to be resolved (defects that are intended to be resolved) in the current version of the software to be released, or defects that occurred during the testing or maintenance process of the current version of the software to be released; and a test identifier is used to identify test cases for verifying whether defects in the current version of the software to be released have been resolved, or test cases for verifying the presence or absence of defects in the current version of the software to be released. If the interaction context management method is optionally applied to the operator, the method further includes sending a subscription notification message to the supplier during the software delivery phase (also known as the "software onboarding phase"), the subscription notification message including the context identifier. Optionally, performing processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining a local interaction context based on the processing result, includes receiving a software update message sent from the supplier at the software delivery stage, wherein the software update message includes the interaction context of the communication partner, verifying the context identifier in the software update message, and after passing the verification of the context identifier, updating the local context and obtaining the local interaction context. Optionally updating the local context to obtain the local interaction context includes determining, based on the version identifier in the interaction context of the communication partner, that the current version is a test version of the target version of the software to be released, and if the interaction context of the communication partner includes a defect identifier and a test identifier, recording the test identifier in the local context, embedding a test case corresponding to the target version, and obtaining the local interaction context. Optionally, performing processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining a local interaction context based on the processing result, includes obtaining a software package sent from the supplier at the software delivery stage, wherein the software package includes the interaction context of the communication partner, and the interaction context of the communication partner includes the version identifier, the defect identifier, and the test identifier; verifying the version identifier in the software package; determining the validity of the test case template corresponding to the test identifier after passing the verification of the version identifier; and updating the context state in the local context and obtaining the local interaction context after passing the verification of the validity of the test case template. If the interaction context management method is optionally applied to the operator, the method further includes determining the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. Optionally determining the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner includes, if the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, the iteration type of the current pipeline is a test, deploy, and feedback pipeline; and if the version identifier in the interaction context of the communication partner indicates that the current version is the test version of the release software, the iteration type of the current pipeline is a test and feedback pipeline. If the interaction context management method is optionally applied to the operator, processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result, in the testing phase, includes verifying the completeness of the test case set corresponding to the test identifier based on the interaction context of the communication partner, if the verification of the completeness of the test case set corresponding to the test identifier is successful, executing a test on the test case set, if the test is successful, updating the context state in the local context to accepted and obtaining the local interaction context, and if the test is unsuccessful, recording a defect identifier in the local context and obtaining the local interaction context. If the interaction context management method is optionally applied to the operator, processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result, during the deployment phase, if the software upgrade is successful, updating the context state in the local context to deployed and obtaining the local interaction context, and if the software upgrade is unsuccessful, adding a defect identifier to the local context and obtaining the local interaction context. If the interaction context management method is optionally applied to the operator, transmitting the local interaction context to the communication partner includes, in the feedback phase, transmitting the local interaction context to the supplier, the local interaction context including a version identifier, a defect identifier, and a test identifier. If the interaction context management method is optionally applied to the operator, the interaction context of the communication partner further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and a defect identifier for a defect awaiting resolution in the current release subversion of the release-planned software. If the interaction context management method is optionally applied to the operator, the method further includes determining a test case corresponding to a test identifier based on a test identifier in the local context, and analyzing test topology information corresponding to the test case, wherein the test topology information is used by the operator and / or the supplier to perform root cause analysis of test anomalies. If the interaction context management method is optionally applied to the supplier, the method further includes, at the software delivery stage, receiving a subscription notification message sent by the operator, the subscription notification message including the context identifier, and transmitting the local interaction context to the communication partner, which includes transmitting a software update message to the operator based on the subscription notification message, the software update message including the local interaction context. If the interaction context management method is optionally applied to the supplier, processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result, includes obtaining a first defect identifier and / or a first test identifier in the interaction context of the communication partner, processing based on the first defect identifier and / or the first test identifier, and obtaining a second defect identifier and / or a second test identifier based on the processing result, recording the second defect identifier and / or the second test identifier in the local context, and obtaining the local interaction context. If the interaction context management method is optionally applied to the supplier, the local interaction context further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and defect identifiers of defects awaiting resolution in the current release subversion of the release-planned software. Optionally, the interaction context management method further includes verifying the interaction context of the communication partner, performing processing based on the interaction context of the communication partner and obtaining a processing result, and obtaining a local interaction context based on the processing result, which includes, if the verification of the interaction context of the communication partner is successful, performing processing based on the interaction context of the communication partner and obtaining a processing result, and obtaining a local interaction context based on the processing result. Optionally, the interaction context management method further includes obtaining a digest of the local interaction context and signing the digest using a secret key, and transmitting the local interaction context to the communication partner includes transmitting the signed local interaction context to the communication partner.

[0005] In a second aspect, an embodiment of the present invention further provides an interaction context management device applicable to a supplier or operator, the interaction context management device comprising an acquisition module, a processing module, and a transmission module, wherein the acquisition module is configured to acquire the interaction context of a communication partner, the interaction context of the communication partner includes a context identifier, the processing module is configured to perform processing based on the interaction context of the communication partner and acquire a processing result, and acquire a local interaction context based on the processing result, the transmission module is configured to transmit the local interaction context to the communication partner, the local interaction context includes the context identifier, where the communication partner of the supplier is the operator, and the communication partner of the operator is the supplier. Optionally, a version identifier is used to identify version information of the software to be released; a defect identifier is used to identify defects that are expected to be resolved (defects that are intended to be resolved) in the current version of the software to be released, or defects that occurred during the testing or maintenance process of the current version of the software to be released; and a test identifier is used to identify test cases for verifying whether defects in the current version of the software to be released have been resolved, or test cases for verifying the presence or absence of defects in the current version of the software to be released. If the interaction context management device is optionally applied to the operator, the device further comprises a transmission module configured to send a subscription notification message to the supplier during the software delivery phase, the subscription notification message including the context identifier. Optionally, the processing module is further configured to receive a software update message sent from the supplier during the software delivery phase, the software update message includes the interaction context of the communication partner, verify the context identifier in the software update message, and after passing the verification of the context identifier, update the local context to obtain the local interaction context. Optionally, the processing module is configured to determine, based on the version identifier in the interaction context of the communication partner, that the current version is a test version of the target version of the software to be released, and if the interaction context of the communication partner includes a defect identifier and a test identifier, to record the test identifier in the local context, embed a test case corresponding to the target version, and obtain the local interaction context. Optionally, the processing module is configured to further acquire a software package sent from the supplier during the software delivery phase, the software package containing the interaction context of the communication partner, the interaction context of the communication partner containing the version identifier, the defect identifier, and the test identifier, verify the version identifier in the software package, determine the validity of the test case template corresponding to the test identifier after passing the verification of the version identifier, update the context state in the local context after passing the verification of the validity of the test case template, and acquire the local interaction context. If the interaction context management device is optionally applied to the operator, the device further comprises a first decision module configured to determine the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. Optionally, the first decision module is further configured to determine that if the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, then the iteration type of the current pipeline is a test, deploy, and feedback pipeline, and if the version identifier in the interaction context of the communication partner indicates that the current version is the test version of the release software, then the iteration type of the current pipeline is a test and feedback pipeline. If the interaction context management device is optionally applied to the operator, the processing module is further configured to, during the testing phase, verify the integrity of the test case set corresponding to the test identifier based on the test identifier in the interaction context of the communication partner, and if the verification of the integrity of the test case set corresponding to the test identifier is successful, execute a test on the test case set, and if the test is successful, update the context state in the local context to accepted and obtain the local interaction context, and if the test is unsuccessful, record a defect identifier in the local context and obtain the local interaction context. If the interaction context management device is optionally applied to the operator, the processing module is further configured to, during the deployment phase, update the context state in the local context to deployed and obtain the local interaction context if the software upgrade is successful, and add a defect identifier to the local context and obtain the local interaction context if the software upgrade is unsuccessful. If the interaction context management device is optionally applied to the operator, the transmission module is further configured to transmit the local interaction context to the supplier during the feedback phase, the local interaction context including a version identifier, a defect identifier, and a test identifier. If the interaction context management device is optionally applied to the operator, the interaction context of the communication partner further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and defect identifiers of defects awaiting resolution in the current release subversion of the release-planned software. If the interaction context management device is optionally applied to the operator, the device further comprises a second decision module configured to determine a test case corresponding to a test identifier based on a test identifier in the local context, and an analysis module configured to analyze test topology information corresponding to the test case, the test topology information being used by the operator and / or the supplier to perform root cause analysis of test anomalies. If the interaction context management device is optionally applied to the supplier, the device further comprises a receiving module configured to receive subscription notification messages sent from the operator during the software delivery phase, the subscription notification messages including the context identifier, and the transmitting module configured to send a software update message to the operator based on the subscription notification message, the software update message including the local interaction context. If the interaction context management device is optionally applied to the supplier, the processing module is further configured to obtain a first defect identifier and / or a first test identifier in the interaction context of the communication partner, perform processing based on the first defect identifier and / or the first test identifier, obtain a second defect identifier and / or a second test identifier based on the processing result, record the second defect identifier and / or the second test identifier in the local context, and obtain the local interaction context. If the interaction context management device is optionally applied to the supplier, the local interaction context further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and a defect identifier for a defect awaiting resolution in the current release subversion of the release-planned software. Optionally, the interaction context management device further comprises a verification module configured to verify the interaction context of the communication partner, and the acquisition module is further configured to, if the verification of the communication partner's interaction context is successful, perform processing based on the communication partner's interaction context and acquire the processing result, and acquire a local interaction context based on the processing result. Optionally, the interaction context management device further comprises a signing module configured to obtain a digest of the local interaction context and sign the digest using a secret key, and the transmission module further comprises a signing module configured to transmit the signed local interaction context to the communication partner.

[0006] In a third aspect, an embodiment of the present invention further provides an interaction context management device applicable to a supplier or operator, the interaction context management device comprising a processor and a transceiver, wherein the processor is configured to acquire the interaction context of a communication partner, the interaction context of the communication partner includes a context identifier, perform processing based on the interaction context of the communication partner and acquire a processing result, and acquire a local interaction context based on the processing result, the transceiver is configured to transmit the local interaction context to the communication partner, the local interaction context includes the context identifier, the communication partner of the supplier is the operator, and the communication partner of the operator is the supplier. Optionally, a version identifier may be used to identify version information of the software to be released; a defect identifier may be used to identify defects expected to be resolved in the current version of the software to be released, or defects that occurred during the testing or maintenance process of the current version of the software to be released; and a test identifier may be used to identify test cases for verifying whether defects in the current version of the software to be released have been resolved, or test cases for verifying the presence or absence of defects in the current version of the software to be released. If the interaction context management device is optionally applied to the operator, the processor is further configured to send a subscription notification message to the supplier during the software delivery phase, the subscription notification message including the context identifier. Optionally, the processor is further configured to receive a software update message sent from the supplier during the software delivery phase, the software update message includes the interaction context of the communication partner, verify the context identifier in the software update message, and after passing the verification of the context identifier, update the local context to obtain the local interaction context. Optionally, the processor is configured to determine, based on the version identifier in the interaction context of the communication partner, that the current version is a test version of the target version of the software to be released, and if the interaction context of the communication partner includes a defect identifier and a test identifier, to record the test identifier in the local context, embed a test case corresponding to the target version, and obtain the local interaction context. Optionally, the processor is further configured to, during the software delivery phase, acquire a software package sent from the supplier, the software package includes the interaction context of the communication partner, the interaction context of the communication partner includes the version identifier, the defect identifier, and the test identifier, verify the version identifier in the software package, and after passing the verification of the version identifier, determine the validity of the test case template corresponding to the test identifier, and after passing the verification of the validity of the test case template, update the context state in the local context and acquire the local interaction context. If the interaction context management device is optionally applied to the operator, the processor is further configured to determine the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. Optionally, the processor is further configured to determine that if the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, the iteration type of the current pipeline is a test, deploy, and feedback pipeline, and if the version identifier in the interaction context of the communication partner indicates that the current version is the test version of the release software, the iteration type of the current pipeline is a test and feedback pipeline. If the interaction context management device is optionally applied to the operator, the processor is further configured to, during the test phase, verify the integrity of the test case set corresponding to the test identifier based on the test identifier in the interaction context of the communication partner, and if the verification of the integrity of the test case set corresponding to the test identifier is successful, execute a test on the test case set, and if the test is successful, update the context state in the local context to accepted and obtain the local interaction context, and if the test is unsuccessful, record a defect identifier in the local context and obtain the local interaction context. If the interaction context management device is optionally applied to the operator, the processor is further configured to, during the deployment phase, if the software upgrade is successful, update the context state in the local context to deployed and acquire the local interaction context, and if the software upgrade is unsuccessful, add a defect identifier to the local context and acquire the local interaction context. Optionally, the processor may be configured to send the local interaction context to the supplier during the feedback phase, the local interaction context including a version identifier, a defect identifier, and a test identifier. If the interaction context management device is optionally applied to the operator, the interaction context of the communication partner further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and defect identifiers of defects awaiting resolution in the current release subversion of the release-planned software. If the interaction context management device is optionally applied to the operator, the processor is further configured to determine a test case corresponding to the test identifier based on the test identifier in the local context, and to analyze test topology information corresponding to the test case, which the operator and / or the supplier use to perform root cause analysis of test anomalies. If the interaction context management device is optionally applied to the supplier, the processor is further configured to receive a subscription notification message sent from the operator during the software delivery phase, the subscription notification message including the context identifier, and to send a software update message to the operator based on the subscription notification message, the software update message including the local interaction context. If the interaction context management device is optionally applied to the supplier, the processor is further configured to obtain a first defect identifier and / or a first test identifier in the interaction context of the communication partner, process based on the first defect identifier and / or the first test identifier, obtain a second defect identifier and / or a second test identifier based on the processing result, record the second defect identifier and / or the second test identifier in the local context, and obtain the local interaction context. If the interaction context management device is optionally applied to the supplier, the local interaction context further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and a defect identifier for a defect awaiting resolution in the current release subversion of the release-planned software. Optionally, the processor is further configured to verify the interaction context of the communication partner, and if the verification of the interaction context of the communication partner is successful, perform processing based on the interaction context of the communication partner to obtain a processing result, and obtain a local interaction context based on the processing result. Optionally, the processor is further configured to obtain a digest of the local interaction context, sign the digest using a private key, and transmit the signed local interaction context to the communication partner.

[0007] In a fourth aspect, an embodiment of the present invention further provides a communication device, which includes a memory, a processor, and a program stored in the memory and executable by the processor. The processor is configured to execute the steps in the above-mentioned interaction context management method by executing the program.

[0008] In a fifth aspect, an embodiment of the present invention further provides a readable storage medium, on which a program is stored. The program is configured to cause a processor to execute the steps in the above-mentioned interaction context management method.

[0009] In the sixth aspect, an embodiment of the present invention further provides a management system for interaction context. The system includes a supplier and an operator. The supplier provides software to the operator, obtains the interaction context of the supplier, transmits the interaction context of the supplier to the operator, performs processing based on the feedback information transmitted from the operator, obtains the local interaction context of the supplier, and is configured to transmit the local interaction context of the supplier to the operator. The operator is configured to perform processing on the software based on the interaction context of the supplier, obtain feedback information, and transmit the feedback information to the supplier. The feedback information includes the local interaction context obtained by the operator.

Advantages of the Invention

[0010] In an embodiment of the present invention, in the process of a supplier or an operator communicating with its communication partner, the interaction context corresponding to the same context identifier as the partner is exchanged, thereby enabling both parties to negotiate based on the same interaction context and allowing multiple trial-and-error attempts, repeated debug adjustments, and optimization iterations through flexible orchestration. Therefore, according to the solution of the embodiment of the present invention, the flexibility of managing the interaction process between the supplier and the operator can be improved.

Brief Description of the Drawings

[0011] [Figure 1(a)] It is a schematic diagram of a DevOps framework for assisting in the management of communication operations. [Figure 1(b)] It is a schematic diagram of a DevOps framework for assisting in the management of communication operations. [Figure 2] It is a flowchart of a method for managing interaction context according to an embodiment of the present invention. [Figure 3] This is a flowchart of a method for managing interaction contexts according to an embodiment of the present invention. [Figure 4] This is a flowchart of another interaction context management method according to an embodiment of the present invention. [Figure 5] This is a configuration diagram of an interaction context management device according to an embodiment of the present invention. [Figure 6] This is a configuration diagram of another interaction context management device according to an embodiment of the present invention. [Figure 7] This is a configuration diagram of an interaction context management device according to an embodiment of the present invention. [Figure 8] This is a configuration diagram of another interaction context management device according to an embodiment of the present invention. [Modes for carrying out the invention]

[0012] In embodiments of the present invention, the term "and / or" is used simply to describe the relationship between related objects, indicating that three relationships may exist. For example, A and / or B can refer to three cases: A existing alone, both A and B existing, or B existing alone. Also, in this specification, the symbol " / " usually indicates that the relationship between related objects is "or". In embodiments of the present invention, the term "plural" refers to two or more, and the same applies to other quantifiers. The use of terms such as "first," "second," and "third" does not indicate any order. These words may be interpreted as names. The steps in the above embodiments should not be interpreted as limiting the order of execution unless otherwise specified. The technical solutions in embodiments of the present invention will be described more clearly and completely below with reference to the drawings of the embodiments. The embodiments described are only some, and not all, embodiments of the present invention. All other embodiments obtained by those skilled in the art without creative effort based on embodiments of the present invention are included within the scope of the present invention. Taking into account the shortcomings of prior art, embodiments of the present invention provide a method for managing interaction context. This method manages context for the integrated development and operations (DevOps) of communication network software, enabling suppliers and operators to collaborate, for example, to optimize different iterations for software with the same delivery target, while maintaining a unified context. This allows for the utilization of existing knowledge in subsequent stages to selectively optimize the closed loop of delivery, testing, maintenance (operational support), monitoring, and feedback, thereby enhancing security for cross-organizational information exchange and process coordination. Referring to Figure 2, Figure 2 is a schematic diagram of an interaction context management system according to an embodiment of the present invention. The system may include a supplier 201 and an operator 202. The supplier 201 is configured to provide software to the operator, acquire the supplier's interaction context, send the supplier's interaction context to the operator, process based on feedback information sent from the operator, acquire the supplier's local interaction context, and send the supplier's local interaction context to the operator. The operator 202 is configured to process the software based on the supplier's interaction context, obtain feedback information, and send the feedback information to the supplier. Here, the feedback information includes the local interaction context obtained by the operator. Here, the operator may include an operator DevOps server, and the operator may include a quasi-production environment, a production environment, etc. In embodiments of the present invention, the interaction context refers to basic information and the current state jointly maintained by a supplier or operator for a particular software. The basic information includes a context identifier, an operator identifier, a software specification identifier, etc., and the current state includes the pipeline status (new creation, delivery, acceptance, deployment, offline, etc.) and pipeline records (optional). The pipeline records include basic information (operation type, operation time, operation result, etc.) and optional auxiliary information of the currently running operation (delivery, test, deployment, monitoring, feedback). The process of realizing the present invention will be described in detail below with reference to various embodiments. Referring to Figure 3, Figure 3 is a flowchart of a method for managing interaction context according to an embodiment of the present invention, which is applied to an operator. As shown in Figure 3, the method may include the following steps. In step 301, the interaction context of the communication partner is obtained, and the interaction context of the communication partner includes a context identifier. Here, the operator may include an operator DevOps server, and the operator's communication partner may be the supplier. Here, the interaction context of the communication partner may be obtained from the supplier or newly generated by the operator. The context identifier is used to uniquely identify a particular interaction context, and for example, the context identifier may be a context number. During the software delivery phase, the operator sends a subscription notification message to the supplier, and this subscription notification message includes the context identifier. In other words, when the operator subscribes to a particular supplier's software for the first time, both parties agree to create a new, unique context identifier, and all subsequent information exchange between them involves this context identifier. Specifically, the operator can generate this context identifier using a digest algorithm, taking the current time, both parties' identifiers (publicly known identifiers from the operator's public key certificate and the supplier's public key certificate), and requirements specifications (e.g., a digest of the software function description) as input. In embodiments of the present invention, the interaction context of the communication partner further includes one or more of the following (1) to (3): (1) Version Identifier: Used to identify the version information of the software scheduled for release. The supplier generates this version identifier when releasing a new software delivery / test (or temporary) version. Here, the version identifier is generated by the supplier and is used to identify the target version (required) and the test (or temporary) version (optional), thereby indicating whether the currently released software version is a delivery version for production deployment or a temporary version for verifying the fix of a specific defect (set). The operator populates the interaction context by referencing the version identifier of the current delivery version in feedback messages. (2) Defect Identifier: Used to identify defects that are expected to be resolved in the current version of the software scheduled for release. The supplier embeds it in the interaction context in the iteration-optimized release notification message, representing a set of defect identifiers that are expected to be resolved in the current delivered version. (3) Test Identifier: Used to identify test cases for verifying whether defects in the current version of the software scheduled for release have been resolved. The supplier embeds this in the interaction context in the iteration-optimized release notification message and includes a set of test case identifiers for performing targeted verification tests on defects expected to be resolved in the current delivery version. Here, the test identifier is mainly applied when the supplier releases an interim version. Similarly, the interaction context that the operator sends to the supplier may also include the version identifier, defect identifier, and test identifier described above. The difference is that in this case, the defect identifier and test identifier are generated by the operator. Here, the defect identifier is used to identify defects that occurred during the testing or maintenance process of the current version of the software scheduled for release, and the operator embeds it in the interaction context in the information feedback message, representing a set of defect identifiers found in the current version during the testing / maintenance process. The test identifier is used to identify test cases for verifying the presence or absence of defects in the current version of the software scheduled for release, and the operator embeds it in the interaction context in the information feedback message, including a set of verification test case identifiers corresponding to defects found in the current version during the testing / maintenance process. Here, the test identifier is mainly applied when the operator provides feedback on software problems. When generating defect identifiers, operators or suppliers can use either a random method or a known consensus reference method. For example, a random method can use the current time, a context identifier, or problem description text as input and generate defect identifiers using a digest algorithm. A known consensus reference method can generate defect identifiers by referencing mutually known identifiers, such as a known defect identifier and a known test case identifier. When generating test identifiers, operators or suppliers can use a random method or a known consensus reference method. For example, in a random method, the current time, context identifier, or problem description text can be used as input, and a digest algorithm can be used to generate test identifiers. In a known consensus reference method, test identifiers can be generated by directly referencing identifiers known to both parties, such as known test case identifiers or agreed-upon test case identifiers. For example, for known test cases, or test cases that both parties have discussed and agreed upon through message exchange in a previous interaction, the feedback / release process directly references identifiers known to both parties, such as known test case identifiers or agreed-upon test case identifiers. In addition to providing test identifiers, test case templates can also be provided as part of supplementary feedback information / software release information. In embodiments of the present invention, by introducing a version identifier, defect identifier, or test identifier into the interaction context, operators and suppliers can implement a defect tracking and test consultation mechanism, thereby enabling them to establish an optimization iteration that allows for multiple trial-and-error, repeated debugging adjustments, and flexible organization after discovering a problem based on the same interaction context. Optionally, in embodiments of the present invention, the interaction context of the communication partner may also be verified. For example, the validity of the communication partner's interaction context, whether it is the current interaction context between the supplier and the operator, etc., may be verified. If the verification is successful, the subsequent process can be executed; otherwise, the process can be terminated. In step 302, processing is performed based on the interaction context of the communication partner and the processing result is obtained, and the local interaction context is obtained based on the processing result. As shown in Figure 1(a) or 1(b), after the software is delivered to the operator environment, processes such as verification, testing, deployment, and continuous monitoring after deployment to the production environment are required. These processes include five stages: delivery, testing, deployment, operation / monitoring, and feedback. Therefore, at different stages, the operator can obtain a local interaction context based on their actions. Throughout the entire process, the operator can perform operations such as recording based on the same interaction context. That is, in later stages, they can perform further recording based on the interaction context obtained in previous stages, thereby obtaining a local interaction context and making the obtained interaction context more accurate. Of course, at each stage, it is also possible to obtain an interaction context corresponding to that stage individually and use that as the local interaction context. For an operator, it is possible to maintain a local context (also called an interaction context) itself, and this local context may be the interaction context of the communication partner or another interaction context. In other words, an operator can obtain a local interaction context by performing operations such as recording based on the interaction context of the communication partner, or by referring to the communication partner's interaction context obtained based on another interaction context of a local context (different from the communication partner's interaction context), and performing operations such as recording based on the processing result to obtain a local interaction context. Specifically, at the delivery stage, the operator subscribes to software release / update notifications, which may include a context identifier. When there is a software release or update, the operator can receive a software update message sent from the supplier, which includes the interaction context of the communication partner. Here, the interaction context of the communication partner may further include a version identifier. Subsequently, the operator retrieves the context identifier in the interaction context of the communication partner and verifies the context identifier. After passing the verification of the context identifier, the operator updates the local context and obtains the local interaction context. For example, when verifying the context identifier, the operator can determine, based on the context identifier, whether a corresponding interaction context already exists locally, or whether the supplier corresponding to the context identifier is legitimate. After receiving a software update message, the operator obtains the context identifier (including the version identifier) ​​and the storage address of the update software, searches for the context identifier locally, and after passing the verification, either obtains the existing context or generates an initial context (state: newly created) for the software. Subsequently, the operator performs analysis and updates the version information and test information in the local context record as necessary. Specifically, if the operator determines that the current version is a test version of the target version of the software scheduled for release based on the version identifier in the interaction context of the communication partner, and the interaction context of the communication partner includes a defect identifier and a test identifier, the operator records the test identifier in the local context, embeds the test case corresponding to the target version, and obtains the local interaction context. In other words, the operator parses the version identifier in the context identifier, and if that version is a temporary test version for a specific target version, updates the local context record for the target version, and further parses whether the interaction context of the communication partner contains a defect identifier provided by the supplier. If a defect identifier is present, the operator further parses whether the interaction context of the communication partner contains a test identifier provided by the supplier. If no defect identifier is present, the operator can proceed with the subsequent processing. If it is determined that the interaction context of the communication partner contains a test identifier provided by the supplier, the operator embeds the test identifier provided by the supplier into the current local context and embeds the test cases executed in the previous iteration for the target version. If no test identifier is present, the operator can proceed with the subsequent processing.Subsequently, the operator can request to download the updated software package from the supplier's deliverable repository. During the software delivery (software acquisition) phase, the operator can acquire the software package sent from the supplier, which includes the interaction context of the communication partner (i.e., the supplier), and the interaction context of the communication partner includes the version identifier, the defect identifier, and the test identifier. Here, the digest and context identifier of the software package may be privately signed by the supplier. Subsequently, the operator can perform verification based on the version identifier, for example, checking the consistency between the version identifier in the software package and the version identifier in the local context. After passing the verification of the version identifier, the operator determines the validity of the test case templates corresponding to the test identifiers. For example, they determine whether these test case templates are executable, whether they are available, or whether the state of these test case templates is not invalid or unexecutable. After passing the verification of the validity of the test case templates (e.g., executable, valid state), the operator updates the context state in the local context (e.g., updates the state to delivered) and acquires the local interaction context. For example, during the configuration phase, the operator determines the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. Specifically, if the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, the iteration type of the current pipeline is a test, deploy, and feedback pipeline. If the version identifier in the interaction context of the communication partner indicates that the current version is a test version of the release software, the iteration type of the current pipeline is a test and feedback pipeline. In other words, the operator can determine the next step in the current step based on the version identifier, thereby improving processing efficiency. During the testing phase, the operator verifies the integrity of the test case set corresponding to the test identifier in the interaction context of the communication partner, based on the test identifier in the interaction context of the communication partner. If the verification of the integrity of the test case set corresponding to the test identifier is successful, the operator performs the test on the test case set; otherwise, an error is reported. If the test on the test case set is successful, the context state in the local context is updated to accepted, the next step in the current pipeline can be executed, and the local interaction context is obtained. If the test fails, a defect identifier is recorded in the local context, and the local interaction context is obtained. For example, during the testing phase, a general-purpose test framework is used to check the completeness of the test case set referenced by the test identifier in the interaction context, such as whether the test cases are complete and correct. If the check passes, the test execution system is invoked to run the tests; otherwise, an error is reported to the DevOps server. If the tests run against a test case pass, the context state is updated to accepted, and the next step in the pipeline is executed. This next step depends on the current pipeline iteration type determined above, and may involve notifying the network management system of a software upgrade deployment or entering the direct feedback phase. If the tests run against a test case fail, the operator checks the cause of the error and adds the cause of the error to the set of defect identifiers in the interaction context. If a specific test fails, a data processing component is triggered to perform the necessary data processing processes, such as masking the test data, to avoid any impact on the test process of the test data corresponding to that specific test. During the deployment phase, the operator notifies the network management system to perform a software upgrade deployment. If the software upgrade is successful, the operator updates the context state in the local context to deployed and retrieves the local interaction context. If the software upgrade is unsuccessful, the operator adds a defect identifier to the local context and retrieves the local interaction context. For example, the operator adds information about the deployment anomaly to the set of defect identifiers in the context and triggers data processing components to perform necessary data processing processes, such as masking test data. During the feedback phase, the operator transmits the local interaction context to the supplier, which includes a version identifier, a defect identifier, and a test identifier. Here, the local interaction context may be the final interaction context obtained through the aforementioned steps. In actual application, the supplier can further re-release targeted updates after completing software update optimization based on operator feedback. At this time, for example, during the iteration phase, the interaction context of the communication partner further includes information on the current release subversion of the software to be released, and an identifier for the test case corresponding to the subversion. The version number of the current release subversion of the software scheduled for release, and one or more defect identifiers of defects awaiting resolution in the current release subversion of the software scheduled for release, The above process enables software update iteration and optimization. In step 303, the local interaction context is sent to the communication partner, and the local interaction context includes the context identifier. In an embodiment of the present invention, during the process of a supplier or operator communicating with its communication partner, interaction contexts corresponding to the same context identifier are exchanged with the other party, thereby enabling both parties to consult based on the same interaction context, allowing for multiple trial-and-error iterations, repeated debugging adjustments, and optimization iterations with flexible organization. Therefore, according to the solution in the embodiment of the present invention, the flexibility of managing the interaction process between the supplier and the operator can be improved. In an embodiment of the present invention, in order to achieve traceability of pipeline management within the operator, a unique and tamper-proof pipeline (context) execution record is established for each network software entering the pipeline. Simultaneously, the test framework and data processing component within the operator pipeline agree to adopt a standard norm for standard-compliant test case descriptions. The data processing component queries a test case template corresponding to a test identifier in the context, and analyzes the test topology information (the network element under test in the test environment and the network configuration information of the test environment) described in the test case template. This is used to identify the root cause of failures / anomalies, and after confirming the cause of the test failure, the test data is fed back to the supplier of the network element where the problem occurred. Specifically, based on the test identifier in the local context, the system can determine the test case corresponding to the test identifier and analyze the test topology information corresponding to the test case. This test topology information is used by the operator and / or the supplier to perform root cause analysis of test anomalies. This method can improve the efficiency and accuracy of testing, analysis, and feedback on the operator's side. Here, each record at each stage consists of two parts: the body and the digest signature. The body contains the most recent execution record, and the digest signature is generated when the current stage executor signs a digest of the contents of the body using their private key, and is used by a third party to verify the integrity of the body contents and the authenticity of them being from the current stage executor. The executor at the current stage (test framework / network management system / data processing component), upon receiving a process task, first verifies the digest signature of the execution log before executing the corresponding task. It checks the completeness of the contents and the authenticity of the source. If it finds any anomalies that do not match expectations (process anomalies, signature anomalies, etc.), it rejects execution at the current stage and reports an execution check error. If no anomalies are found, it continues executing the corresponding task, appends the execution results to the end of the execution log, extracts the digest value again from the updated execution log, and signs it using its private key. Therefore, in the process described above, after obtaining the local context of each stage, its digest value can be extracted and signed using the private key corresponding to each stage. Optionally, in an embodiment of the present invention, a digest of the local interaction context may be obtained, the digest may be signed using a secret key, and the signed local interaction context may be sent to the communication partner. This method ensures the security of the communication. Referring to Figure 4, Figure 4 is a flowchart of an interaction context management method according to an embodiment of the present invention, which applies to suppliers. As shown in Figure 4, it may include the following steps. In step 401, the interaction context of the communication partner is obtained, and the interaction context of the communication partner includes a context identifier. Here, the supplier's communication partner is the operator. The operator may include an operator DevOps server. An interaction context refers to the basic information and status that a supplier or operator jointly maintains for specific software. This basic information includes a context identifier, operator identifier, software specification identifier, etc., and the current status includes the pipeline status (new creation, delivery, acceptance, deployment, offline, etc.) and pipeline records (optional). Pipeline records include basic information (operation type, operation time, operation result, etc.) of the currently running operation (delivery, test, deployment, monitoring, feedback) and optional auxiliary information. The interaction context of the communication partner may be obtained from the operator or newly generated by the supplier. Here, the context identifier is used to uniquely identify a specific interaction context. During the software delivery phase, the operator sends a subscription notification message to the supplier, and this subscription notification message includes the context identifier. In other words, when the operator first subscribes to software from a particular telecommunications supplier, both parties agree to create a new, unique context identifier, and all subsequent information exchange between them involves this context identifier. Specifically, the operator can generate the context identifier using a digest algorithm, taking the current time, identifiers of both parties (publicly known identifiers from the operator's public key certificate and the supplier's public key certificate), and requirements specifications (e.g., a digest of the software function description) as input.

[0013] In embodiments of the present invention, the interaction context of the communication partner further includes one or more of the following (1) to (3): (1) Version Identifier: Used to identify the version information of the software to be released. Here, the version identifier is generated by the supplier and is used to identify the target version (required) and the test (or temporary) version (optional), thereby indicating whether the currently released software version is the delivery version for production deployment or a temporary version for verifying the fix of a specific defect (set). The operator references the version identifier of the current delivery version in the information feedback message and embeds it into the interaction context. (2) Defect Identifier: Used to identify defects encountered during the testing or maintenance process of the current version of the software scheduled for release. The operator embeds it in the interaction context in an information feedback message, representing a set of defect identifiers discovered during the testing / maintenance process of the current version. (3) Test Identifier: Used to identify test cases for verifying the presence or absence of defects in the current version of the software scheduled for release. The operator embeds it in the interaction context in an information feedback message, and the current version includes a set of verification test case identifiers corresponding to defects found during the testing / maintenance process. As mentioned above, the interaction context that the supplier sends to the operator can also include the above identifiers, the difference being that the defect identifier and test identifier are generated by the supplier. Their specific meaning can be found in the description of the above-mentioned embodiment. When generating defect identifiers, operators or suppliers can use either a random method or a known consensus reference method. For example, a random method can use the current time, a context identifier, or problem description text as input and generate defect identifiers using a digest algorithm. A known consensus reference method can generate defect identifiers by referencing mutually known identifiers, such as a known defect identifier and a known test case identifier. When generating test identifiers, operators or suppliers can use a random method or a known consensus reference method. For example, in a random method, the current time, context identifier, or problem description text can be used as input, and a digest algorithm can be used to generate test identifiers. In a known consensus reference method, test identifiers can be generated by directly referencing identifiers known to both parties, such as known test case identifiers or agreed-upon test case identifiers. For example, for known test cases, or test cases that both parties have discussed and agreed upon through message exchange in a previous interaction, the feedback / release process directly references identifiers known to both parties, such as known test case identifiers or agreed-upon test case identifiers. In addition to providing test identifiers, test case templates can also be provided as part of supplementary feedback information / software release information. In embodiments of the present invention, by introducing a version identifier, defect identifier, or test identifier into the interaction context, operators and suppliers can implement a defect tracking and test consultation mechanism, thereby enabling them to establish an optimization iteration that allows for multiple trial-and-error, repeated debugging adjustments, and flexible organization after discovering a problem based on the same interaction context. Optionally, in embodiments of the present invention, the interaction context of the communication partner may also be verified. For example, the validity of the communication partner's interaction context, whether it is the current interaction context between the supplier and the operator, etc., may be verified. If the verification is successful, the subsequent process can be executed; otherwise, the process can be terminated. In step 402, processing is performed based on the interaction context of the communication partner and the processing result is obtained, and the local interaction context is obtained based on the processing result. Since software testing is primarily performed by operators, the supplier mainly obtains a first defect identifier and / or a first test identifier in the interaction context of the communication partner and processes based on the first defect identifier and / or the first test identifier. For example, based on the first defect identifier and / or the first test identifier in the received interaction context, the supplier can locally reconstruct test defect scenarios, identify root causes, optimize code, and perform test verification. Subsequently, based on the processing results, the supplier can obtain a second defect identifier and / or a second test identifier, record the second defect identifier and / or the second test identifier in the local context, and obtain the local interaction context. Here, a second defect identifier may be recorded for a first defect identifier. For example, for a set of defect identifiers found during the testing / maintenance process in the current version represented by the first defect identifier, the second defect identifier can identify which of the above defects (set) the supplier has resolved. A second test identifier may be recorded for a first test identifier. For example, the second test identifier is used to identify which of the verification test cases (set) corresponding to defects found during the testing / maintenance process in the current version the supplier has optimized. Here, the supplier can identify problematic test cases or defects based on the first defect identifier and / or the first test identifier, and then update, correct, iterate on versions of them, etc. For example, during the iteration phase, the local interaction context further includes information about the current release subversion of the release-planned software, and an identifier for the test case corresponding to the subversion. The information about the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software, and defect identifiers of defects awaiting resolution in the current release subversion of the release-planned software. Specifically, after a supplier completes software update optimization based on operator feedback and then re-releases a targeted update, it includes the same context identifier as its public key certificate in the updated software package, updates the sub-version record item and recommended test case identifier in the interaction context, and includes the new version number and a list of defect identifiers expected to be resolved in this release (e.g., a subset of the problem list recorded in the corresponding context as feedback from the operator). Subsequently, the supplier privately signs the digest of the software package and optionally uses its private / symmetric key to protect the confidentiality of the software update message in the update notification in the artifact repository. In step 403, the local interaction context is sent to the communication partner, and the local interaction context includes the context identifier. In an embodiment of the present invention, the supplier can receive a subscription notification message sent from the operator, the subscription notification message includes the context identifier, and based on the subscription notification message, the supplier sends a software update message to the operator, the software update message includes the supplier's local interaction context. In an embodiment of the present invention, during the process of a supplier or operator communicating with its communication partner, interaction contexts corresponding to the same context identifier are exchanged with the other party, thereby enabling both parties to negotiate based on the same interaction context, allowing for multiple trial-and-error iterations, repeated debugging adjustments, and optimization iterations through flexible organization. Therefore, according to the solution in the embodiment of the present invention, the flexibility of managing the interaction process between the supplier and the operator can be improved. Optionally, in an embodiment of the present invention, a digest of the local interaction context may be obtained, the digest may be signed using a secret key, and the signed local interaction context may be sent to the communication partner. This method ensures the security of the communication. In an embodiment of the present invention, the operator and the supplier each apply for a public key certificate in a mutually approved dedicated or public PKI (Public Key Infrastructure) system and use it for integrated management of software research and development and operation. Optionally, the three functional components in the operator development environment (i.e., the DevOps server, general-purpose test system, and data processing system), as well as the network management system in the operator production environment, will each apply for public key certificates for detailed process traceability management. The following describes the processing process for each stage in combination with several processing stages of the operator.

[0014] 1. Delivery stage (including the following processes) 1. Subscription Renewal: The DevOps server subscribes to software release / update notifications. Here, the subscription notification message includes a context identifier. 2. Update Notification: The supplier notifies the DevOps server that there are software updates available. After receiving a software update message, the operator DevOps server obtains a context identifier (including a version identifier) ​​and the storage address of the updated software. It then searches for the context identifier locally, and after successful verification, it either retrieves an existing context or generates initial context information for the software (with a state of "new creation"). The operator DevOps server performs analysis and updates version and test information in the local context log as needed, which may include the following: First, the version identifier in the context identifier is parsed. If the version identifier indicates a temporary test version for a specific target version, the local context record for the target version is updated, and the context is further parsed to see if it contains a defect identifier provided by the supplier. If a defect identifier is present, the context is further parsed to see if it contains a test identifier provided by the supplier. If a test identifier is present, the test identifier provided by the supplier is embedded into the current context, and the test cases executed in the previous iteration for the target version are embedded into the current context. If the version identifier indicates a target version, processing in this step can be terminated, and subsequent processing can be continued as needed. If there is no defect identifier or test identifier, subsequent processing can be continued. Subsequently, the operator DevOps server requests the download of the updated software package from the supplier's artifact repository. 3. Software Acquisition: The DevOps server acquires the vendor's software. When a supplier's deliverable repository releases a new version of the corresponding software, it includes a context identifier (including version identifier, defect identifier, and test identifier) ​​in the software package and signs the software package digest and context identifier with a private key. 4. Internal operation: After verifying the software package, the DevOps server saves the software to the internal software repository. Specifically, the DevOps server uses the public key in the supplier's certificate to verify the authenticity of the software package's digest signature and the integrity of the software package's contents. If the verification is successful, it executes the subsequent processes; otherwise, it terminates the processes. The DevOps server checks for a match between the version identifier in the software package and the version identifier in the local context. If the verification is successful, it executes the subsequent process; otherwise, it terminates the process. The DevOps server invokes a generic testing framework to check the validity (e.g., whether it is valid, available, etc.) of test case templates referenced by test identifiers within the context of the software package. If the verification is successful, it executes subsequent processes; otherwise, it terminates the process. After passing verification, update the pipeline's context state to Delivered. 2. Formation Stage The DevOps server determines the iteration type of the current pipeline based on the context record. If the version is a target version for delivery, schedule a full testing, deployment, and feedback pipeline. If the version is a temporary version for debugging and verification to resolve a specific issue, schedule a testing and feedback pipeline. 3. Testing Phase The generic test framework checks the completeness of the test case set referenced by the test identifier within the context. If the completeness check passes, it invokes the test execution system to run the tests; otherwise, it reports errors to the DevOps server. If the test passes, the DevOps server updates the context state to Accept and executes the next step in the pipeline. This next step depends on the iteration type and could be notifying the network management system of a software upgrade deployment or directly entering the feedback phase. If the test fails, the DevOps server examines the cause of the error and adds the cause to the set of defect identifiers in the context. If a specific test run fails, it triggers data processing components to perform any necessary data processing processes, such as masking test data. IV. Deployment Phase The DevOps server notifies the network management system to perform a software upgrade deployment. After the network management system in the production environment successfully completes the upgrade operation, the DevOps server updates the pipeline context information (status: deployed) and notifies the data processing component to monitor for software operational anomaly data. If the software upgrade deployment fails, the DevOps server updates the pipeline context information (e.g., adds the deployment anomaly to the set of defect identifiers in the context) and triggers the data processing component to perform any necessary data processing processes, such as masking test data. 5. Operational Phase In the production environment, the network management system performs continuous monitoring, data collection, and anomaly analysis of deployed software based on subscription requests for maintenance metrics / analysis services for data processing components. 6. Feedback stage The DevOps server receives notification that data processing components have completed processing data (test data, production data), provides feedback messages to suppliers (optionally providing download addresses for additional data / analysis / record information), simultaneously sends its public key certificate and context (including version identifier, defect identifier, and test identifier), and optionally uses a private key / symmetric key to protect the confidentiality of subscription messages. After receiving a feedback message, the supplier first verifies the authenticity of the operator's identity using a PKI certificate. Upon successful verification, the supplier decrypts the feedback message and the additional information download address using the operator's public / symmetric key, confirming successful receipt of the feedback message. Subsequently, when obtaining additional information, the supplier includes its own public key certificate in the download request and optionally uses its private / symmetric key to protect the confidentiality of the download request message. After receiving a data download request, the operator first verifies the authenticity of the supplier's identity using a PKI certificate. Upon successful verification, the operator decrypts the download request message using the supplier's public / symmetric key to confirm successful receipt of the message. Subsequently, when transmitting data information, the operator optionally uses its private / symmetric key to encrypt the message body and / or a digest signature scheme to protect the confidentiality, integrity, and authenticity of the transmitted information. 7. Iteration Phase After completing software update optimization based on operator feedback, when a supplier re-releases a targeted update, it will include the same context identifier as its public key certificate in the updated software package, update and add sub-version record items for this release (including the new version number and a list of defect identifiers expected to be resolved in this release (which must be a subset of the list of issues in the corresponding context record provided by the operator)) and recommended test case identifiers to the context record, sign the digest of the software package with its private key, and optionally use the supplier's private key / symmetric key to protect the confidentiality of the software update message in the update notification in the artifact repository. At each of the above stages, in order to ensure traceability of pipeline management within the operator, a unique and tamper-proof pipeline execution record is established for each network software entering the pipeline. Each record consists of two parts: the body and the digest signature. The body contains the most recent execution record, and the digest signature is generated when the current executor signs a digest of the body's contents using their private key. This signature is used by third parties to verify the completeness of the body's contents and the authenticity of it being from the current executor. The executor at the current stage (test framework / network management system / data processing component), upon receiving a process task, first verifies the digest signature of the execution log before executing the corresponding task. It checks the completeness of the content and the authenticity of the source. If it finds any anomalies that do not match expectations (process anomalies, signature anomalies, etc.), it rejects execution at the current stage and reports the execution check error to the DevOps server. If no anomalies are found, it continues executing the corresponding task, appends the execution results to the end of the execution log, extracts the digest value again from the updated execution log, and signs it using its private key. As can be seen from the above, suppliers and operators can consult based on the same interaction context, which enables multiple trial-and-error iterations, repeated debugging and adjustments, and optimization iterations with flexible organization. Therefore, according to the solution in the embodiment of the present invention, the flexibility of managing the interaction process between suppliers and operators can be improved. Referring to Figure 5, Figure 5 is a configuration diagram of an interaction context management device according to an embodiment of the present invention, which is applied to an operator. As shown in Figure 5, the interaction context management device comprises an acquisition module 501, a processing module 502, and a transmission module 503. The acquisition module 501 is configured to acquire the interaction context of the communication partner, and the interaction context of the communication partner includes a context identifier. The processing module 502 is configured to perform processing based on the interaction context of the communication partner, obtain the processing result, and obtain the local interaction context based on the processing result. The transmitting module 503 is configured to transmit the local interaction context to the communication partner, and the local interaction context includes the context identifier. In this case, the operator's communication partner is the supplier. Optionally, a version identifier may be used to identify version information of the software to be released; a defect identifier may be used to identify defects expected to be resolved in the current version of the software to be released, or defects encountered during the testing or maintenance process of the current version of the software to be released; and a test identifier may be used to identify test cases for verifying whether defects in the current version of the software to be released have been resolved, or test cases for verifying the presence or absence of defects in the current version of the software to be released. Optionally, the interaction context management device further comprises a transmission module configured to send a subscription notification message to the supplier during the software delivery phase, the subscription notification message including the context identifier. Optionally, the processing module is further configured to receive a software update message sent from the supplier during the software delivery phase, the software update message includes the interaction context of the communication partner, verify the context identifier in the software update message, and after passing the verification of the context identifier, update the local context to obtain the local interaction context. Optionally, the processing module is configured to determine, based on the version identifier in the interaction context of the communication partner, that the current version is a test version of the target version of the software to be released, and if the interaction context of the communication partner includes a defect identifier and a test identifier, to record the test identifier in the local context, embed a test case corresponding to the target version, and obtain the local interaction context. Optionally, the processing module is configured to further acquire a software package sent from the supplier during the software delivery phase, the software package containing the interaction context of the communication partner, the interaction context of the communication partner containing the version identifier, the defect identifier, and the test identifier, verify the version identifier in the software package, determine the validity of the test case template corresponding to the test identifier after passing the verification of the version identifier, update the context state in the local context after passing the verification of the validity of the test case template, and acquire the local interaction context. Optionally, the interaction context management device further comprises a first decision module configured to determine the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. Optionally, the first decision module is further configured to determine that if the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, then the iteration type of the current pipeline is a test, deploy, and feedback pipeline, and if the version identifier in the interaction context of the communication partner indicates that the current version is the test version of the release software, then the iteration type of the current pipeline is a test and feedback pipeline. Optionally, the processing module is configured to further verify the integrity of a test case set corresponding to a test identifier based on the test identifier in the interaction context of the communication partner during the testing phase. If the verification of the integrity of the test case set corresponding to the test identifier is successful, the module executes a test on the test case set. If the test is successful, it updates the context state in the local context to accepted and obtains the local interaction context. If the test fails, it records a defect identifier in the local context and obtains the local interaction context. Optionally, the processing module may be configured to, during the deployment phase, update the context state in the local context to deployed and obtain the local interaction context if the software upgrade is successful, or, if the software upgrade is unsuccessful, add a defect identifier to the local context and obtain the local interaction context. Optionally, the transmission module may be configured to transmit the local interaction context to the supplier during the feedback phase, the local interaction context including a version identifier, a defect identifier, and a test identifier. Optionally, the interaction context of the communication partner further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and defect identifiers of defects awaiting resolution in the current release subversion of the release-planned software. Optionally, the interaction context management device further comprises a second decision module configured to determine a test case corresponding to a test identifier based on a test identifier in the local context, and an analysis module configured to analyze test topology information corresponding to the test case, wherein the test topology information is used by the operator and / or the supplier to perform root cause analysis of test anomalies. Optionally, the interaction context management device further comprises a verification module configured to verify the interaction context of the communication partner, and the acquisition module is further configured to, if the verification of the communication partner's interaction context is successful, perform processing based on the communication partner's interaction context and acquire the processing result, and acquire a local interaction context based on the processing result. Optionally, the interaction context management device further comprises a signing module configured to obtain a digest of the local interaction context and sign the digest using a secret key, and the transmission module further comprises a signing module configured to transmit the signed local interaction context to the communication partner. The apparatus provided in the embodiment of the present invention can perform the above-described method embodiment, and since its implementation principle and technical effects are similar, a detailed explanation is omitted in this embodiment. Referring to Figure 6, Figure 6 is a configuration diagram of another interaction context management device according to an embodiment of the present invention, which is applied to a supplier. As shown in Figure 6, the interaction context management device comprises an acquisition module 601, a processing module 602, and a transmission module 603. The acquisition module 601 is configured to acquire the interaction context of the communication partner, and the interaction context of the communication partner includes a context identifier. The processing module 602 is configured to perform processing based on the interaction context of the communication partner, obtain the processing result, and obtain the local interaction context based on the processing result. The transmitting module 603 is configured to transmit the local interaction context to the communication partner, and the local interaction context includes the context identifier. In this case, the supplier's communication partner is the operator. If the interaction context management device is optionally applied to the supplier, the device further comprises a receiving module configured to receive subscription notification messages sent from the operator during the software delivery phase, the subscription notification messages including the context identifier, and the transmitting module configured to send a software update message to the operator based on the subscription notification message, the software update message including the local interaction context. If the interaction context management device is optionally applied to the supplier, the processing module is further configured to obtain a first defect identifier and / or a first test identifier in the interaction context of the communication partner, perform processing based on the first defect identifier and / or the first test identifier, obtain a second defect identifier and / or a second test identifier based on the processing result, record the second defect identifier and / or the second test identifier in the local context, and obtain the local interaction context. If the interaction context management device is optionally applied to the supplier, the local interaction context further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and a defect identifier for a defect awaiting resolution in the current release subversion of the release-planned software. Optionally, the interaction context management device further comprises a verification module configured to verify the interaction context of the communication partner, and the acquisition module is further configured to, if the verification of the communication partner's interaction context is successful, perform processing based on the communication partner's interaction context and acquire the processing result, and acquire a local interaction context based on the processing result. Optionally, the interaction context management device further comprises a signing module configured to obtain a digest of the local interaction context and sign the digest using a secret key, and the transmission module further comprises a signing module configured to transmit the signed local interaction context to the communication partner. The apparatus provided in the embodiment of the present invention can perform the above-described method embodiment, and since its implementation principle and technical effects are similar, a detailed explanation is omitted in this embodiment. Referring to Figure 7, Figure 7 is a configuration diagram of an interaction context management device according to an embodiment of the present invention, which is applied to a supplier. As shown in Figure 7, the interaction context management device comprises a processor 701 and a transceiver 702. The processor 701 is configured to acquire the interaction context of the communication partner, the interaction context of the communication partner includes a context identifier, perform processing based on the interaction context of the communication partner and acquire the processing result, and acquire a local interaction context based on the processing result. The transceiver 702 is configured to transmit the local interaction context to the communication partner, the local interaction context includes the context identifier. The communication partner of the supplier is the operator. Optionally, the processor 701 is configured to receive a subscription notification message sent from the operator during the software delivery phase, the subscription notification message including the context identifier, and to send a software update message to the operator based on the subscription notification message, the software update message including the local interaction context. Optionally, the processor 701 is configured to further obtain a first defect identifier and / or a first test identifier in the interaction context of the communication partner, perform processing based on the first defect identifier and / or the first test identifier, obtain a second defect identifier and / or a second test identifier based on the processing result, record the second defect identifier and / or the second test identifier in the local context, and obtain the local interaction context. If the interaction context management device is optionally applied to the supplier, the local interaction context further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and a defect identifier for a defect awaiting resolution in the current release subversion of the release-planned software. Optionally, the processor 701 is further configured to determine a test case corresponding to a test identifier based on the test identifier in the local context, and to analyze test topology information corresponding to the test case, the test topology information being used by the operator and / or the supplier to perform root cause analysis of test anomalies. Optionally, the processor 701 is configured to further verify the interaction context of the communication partner, and if the verification of the interaction context of the communication partner is successful, to perform processing based on the interaction context of the communication partner and obtain the processing result, and to obtain a local interaction context based on the processing result. Optionally, the processor 701 is configured to further obtain a digest of the local interaction context, sign the digest using a secret key, and send the signed local interaction context to the communication partner. The apparatus provided in the embodiment of the present invention can perform the above-described method embodiment, and since its implementation principle and technical effects are similar, a detailed explanation is omitted in this embodiment. Referring to Figure 8, Figure 8 is a configuration diagram of another interaction context management device according to an embodiment of the present invention, which is applied to an operator. As shown in Figure 8, the interaction context management device comprises a processor 801 and a transceiver 802. The processor 801 is configured to acquire the interaction context of the communication partner, which includes a context identifier, to perform processing based on the interaction context of the communication partner and to acquire the processing result, and to acquire a local interaction context based on the processing result. The transceiver 802 is configured to transmit the local interaction context to the communication partner, and the local interaction context includes the context identifier. The supplier's communication partner is the operator, and the operator's communication partner is the supplier. Optionally, a version identifier may be used to identify version information of the software to be released; a defect identifier may be used to identify defects expected to be resolved in the current version of the software to be released, or defects encountered during the testing or maintenance process of the current version of the software to be released; and a test identifier may be used to identify test cases for verifying whether defects in the current version of the software to be released have been resolved, or test cases for verifying the presence or absence of defects in the current version of the software to be released. Optionally, the processor 801 may be configured to send a subscription notification message to the supplier during the software delivery phase, the subscription notification message including the context identifier. Optionally, the processor 801 is further configured to receive a software update message sent from the supplier during the software delivery stage, the software update message includes the interaction context of the communication partner, verify the context identifier in the software update message, and after passing the verification of the context identifier, update the local context to obtain the local interaction context. Optionally, the processor 801 is configured to determine, based on the version identifier in the interaction context of the communication partner, that the current version is a test version of the target version of the software to be released, and if the interaction context of the communication partner includes a defect identifier and a test identifier, to record the test identifier in the local context, embed a test case corresponding to the target version, and obtain the local interaction context. Optionally, the processor 801 is further configured to, during the software delivery stage, acquire a software package sent from the supplier, the software package includes the interaction context of the communication partner, the interaction context of the communication partner includes the version identifier, the defect identifier, and the test identifier, verify the version identifier in the software package, and after passing the verification of the version identifier, determine the validity of the test case template corresponding to the test identifier, and after passing the verification of the validity of the test case template, update the context state in the local context and acquire the local interaction context. Optionally, the processor 801 is further configured to determine the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. Optionally, the processor 801 is further configured to determine that if the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, the iteration type of the current pipeline is a test, deploy, and feedback pipeline, and if the version identifier in the interaction context of the communication partner indicates that the current version is the test version of the release software, the iteration type of the current pipeline is a test and feedback pipeline. Optionally, the processor 801 is configured to further verify the integrity of a test case set corresponding to a test identifier based on the test identifier in the interaction context of the communication partner during the test phase. If the verification of the integrity of the test case set corresponding to the test identifier is successful, the processor 801 executes a test on the test case set. If the test is successful, it updates the context state in the local context to accepted and obtains the local interaction context. If the test fails, it records a defect identifier in the local context and obtains the local interaction context. Optionally, the processor 801 is further configured to, during the deployment phase, update the context state in the local context to deployed and obtain the local interaction context if the software upgrade is successful, or, if the software upgrade is unsuccessful, add a defect identifier to the local context and obtain the local interaction context. Optionally, the processor 801 is further configured to send the local interaction context to the supplier during the feedback phase, the local interaction context including a version identifier, a defect identifier, and a test identifier. Optionally, the interaction context of the communication partner further includes information on the current release subversion of the release-planned software and an identifier for a test case corresponding to the subversion, wherein the information on the current release subversion of the release-planned software includes one or more of the version number of the current release subversion of the release-planned software and defect identifiers of defects awaiting resolution in the current release subversion of the release-planned software.

[0015] The apparatus provided in the embodiment of the present invention can perform the above-described method embodiment, and since its implementation principle and technical effects are similar, a detailed explanation is omitted in this embodiment. It should be noted that the unit division in the embodiments of the present invention is illustrative and merely a logical functional division; other division methods may be possible in actual implementation. Furthermore, each functional unit in each embodiment of the present invention may be integrated into a single processing unit, each unit may exist individually physically, or two or more units may be integrated into a single unit. The integrated unit may be implemented in hardware form or in the form of a software functional unit. If the integrated unit is implemented in the form of software functionality and sold or used as an independent product, the processor may be stored in a readable storage medium. Based on this understanding, an essential part of the technical solution of the present invention, i.e., a part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a computer software product, which is stored in a storage medium and contains several instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) or processor to perform all or part of the processing in each embodiment of the present invention. The aforementioned storage mediums include various media capable of storing program code, such as U disks, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. Embodiments of the present invention provide a communication device comprising a memory, a processor, and a program stored in the memory and executable by the processor, wherein the processor is configured to read the program in the memory and perform any of the steps of the interaction context management method described above. Embodiments of the present invention further provide a non-temporary computer-readable storage medium on which a program is stored, and when the program is executed by the processor, each process of the embodiment of the interaction context management method described above is realized and the same technical effects are achieved; therefore, to avoid duplication, a detailed explanation is omitted here. Here, the readable storage medium may be any available medium or data storage device accessible by the processor, and includes, but is not limited to, magnetic memory (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MOs), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)), etc. In this specification, “includes,” “incorporates,” or any other variation thereof, is intended to be non-exclusive inclusion, meaning that a process, method, article, or apparatus containing a set of elements includes not only those elements but also other elements not expressly enumerated, or elements specific to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the expression “includes” does not preclude the presence of another identical element in a process, method, article, or apparatus containing that element. As will be clearly understood by those skilled in the art from the above description of the embodiments, the methods of the above embodiments can be implemented by a combination of software and an essential general-purpose hardware platform, and of course by hardware alone, but in many cases the former is a more preferred embodiment. Based on this understanding, the essence of the technical solutions of the present invention, or the portion that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM / RAM, magnetic disk, optical disk) and includes several instructions for causing a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to perform the methods of each embodiment of the present invention. Although embodiments of the present invention have been described above with reference to the drawings, the present invention is not limited to the above-described specific embodiments, and the above-described specific embodiments are merely illustrative and not limiting. Those skilled in the art will know that many modifications are possible under the disclosure of the present invention without departing from the spirit and claims of the present invention, and all of them fall within the scope of protection of the present invention.

Claims

1. A method for managing interaction contexts, applicable to suppliers or operators, The interaction context of the communication partner is obtained, and the interaction context of the communication partner includes a context identifier. The process involves performing processing based on the interaction context of the communication partner and obtaining the processing result, and then obtaining the local interaction context based on the processing result. Sending the local interaction context to the communication partner, wherein the local interaction context includes the context identifier, A method for managing interaction contexts, wherein the communication partner of the supplier is the operator, and the communication partner of the operator is the supplier.

2. The interaction context of the aforementioned communication partner is: A version identifier used to identify the version information of software scheduled for release. Defect identifiers used to identify defects that are expected to be resolved in the current version of the software to be released, or defects encountered during the testing or maintenance process of the current version of the software to be released, and The test identifier further includes one or more of the following: a test identifier used to identify a test case for verifying whether a defect in the current version of the software to be released has been resolved, or a test identifier used to identify a test case for verifying whether a defect exists in the current version of the software to be released. The method according to claim 1.

3. When the interaction context management method is applied to the operator, the interaction context management method is: The software delivery phase further includes sending a subscription notification message to the supplier, the subscription notification message including the context identifier. The method according to claim 2.

4. Performing processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result, In the software delivery phase, the software update message is received from the supplier, and the software update message includes the interaction context of the communication partner. Verifying the context identifier in the software update message, This includes, after passing the validation of the aforementioned context identifier, updating the local context and obtaining the aforementioned local interaction context, The method according to claim 3.

5. Updating the local context and obtaining the local interaction context is: Based on the version identifier in the interaction context of the communication partner, it is determined that the current version is a test version of the target version of the software to be released, and if the interaction context of the communication partner includes a defect identifier and a test identifier, the test identifier is recorded in the local context, a test case corresponding to the target version is embedded, and the local interaction context is obtained. The method according to claim 4.

6. Performing processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result, In the software delivery stage, the software package is obtained from the supplier, wherein the software package includes the interaction context of the communication partner, and the interaction context of the communication partner includes the version identifier, the defect identifier, and the test identifier. To verify the version identifier in the aforementioned software package, After the version identifier has passed verification, the validity of the test case template corresponding to the test identifier is determined, After passing the validation of the test case template, the process includes updating the context state in the local context and obtaining the local interaction context, The method according to claim 3.

7. When the interaction context management method is applied to the operator, the interaction context management method is: The process further includes determining the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner. The method according to claim 2.

8. Determining the iteration type of the current pipeline based on the version identifier in the interaction context of the communication partner is: If the version identifier in the interaction context of the communication partner indicates that the current version is the target version for delivery of the release software, then the iteration type of the current pipeline is determined to be a test, deploy, and feedback pipeline. If the version identifier in the interaction context of the communication partner indicates that the current version is a test version of the software scheduled for release, then the iteration type of the current pipeline is determined to be a test, feedback pipeline. The method according to claim 7.

9. When the interaction context management method described above is applied to the operator, processing is performed based on the interaction context of the communication partner, the processing result is obtained, and the local interaction context is obtained based on the processing result. During the testing phase, the completeness of the test case set corresponding to the test identifier is verified based on the test identifier in the interaction context of the communication partner, If the integrity verification of the test case set corresponding to the aforementioned test identifier is successful, the tests will be executed against the test case set. If the test is passed, the context state in the local context is updated and the local interaction context is obtained. If the test fails, the defect identifier is recorded in the local context, and the local interaction context is obtained, including: The method according to claim 7.

10. When the interaction context management method described above is applied to the operator, processing is performed based on the interaction context of the communication partner, the processing result is obtained, and the local interaction context is obtained based on the processing result. During the deployment phase, if the software upgrade is successful, the context state in the local context is updated to deployed, and the local interaction context is obtained. If the software upgrade is unsuccessful, the following steps are taken: adding a defect identifier to the local context and obtaining the local interaction context. The method according to claim 7.

11. When the interaction context management method is applied to the operator, transmitting the local interaction context to the communication partner means that The feedback phase includes sending the local interaction context to the supplier, the local interaction context including a version identifier, a defect identifier, and a test identifier. The method according to claim 2.

12. When the interaction context management method described above is applied to the operator, the interaction context of the communication partner is: Information on the current release subversion of the aforementioned software scheduled for release, and It further includes the identifier of the test case corresponding to the aforementioned subversion, The information on the current release subversion of the software scheduled for release includes one or more of the version number of the current release subversion of the software scheduled for release and the defect identifiers of defects awaiting resolution in the current release subversion of the software scheduled for release. The method according to claim 2.

13. When the interaction context management method is applied to the operator, the interaction context management method is: Based on the test identifier in the local context, determine the test case corresponding to the said test identifier, The process further includes analyzing test topology information corresponding to the test case, wherein the test topology information is used by the operator and / or the supplier to perform root cause analysis of test anomalies. The method according to claim 2.

14. When the interaction context management method is applied to the supplier, the interaction context management method is: The software delivery phase further includes receiving a subscription notification message sent by the operator, the subscription notification message including the context identifier, Sending the local interaction context to the communication partner is, The process includes sending a software update message to the operator based on the subscription notification message, wherein the software update message includes the local interaction context. The method according to claim 2.

15. When the interaction context management method described above is applied to the supplier, processing is performed based on the interaction context of the communication partner, the processing result is obtained, and the local interaction context is obtained based on the processing result. Obtaining a first defect identifier and / or a first test identifier in the interaction context of the communication partner, and performing processing based on the first defect identifier and / or the first test identifier, This includes obtaining a second defect identifier and / or a second test identifier based on the processing result, recording the second defect identifier and / or the second test identifier in the local context, and obtaining the local interaction context. The method according to claim 14.

16. When the interaction context management method described above is applied to the supplier, the local interaction context is: Information on the current release subversion of the aforementioned software scheduled for release, and It further includes the identifier of the test case corresponding to the aforementioned subversion, The information on the current release subversion of the software scheduled for release includes one or more of the version number of the current release subversion of the software scheduled for release and the defect identifiers of defects awaiting resolution in the current release subversion of the software scheduled for release. The method according to claim 2.

17. The method for managing the interaction context is as follows: This further includes verifying the interaction context of the communication partner, Performing processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result, If the verification of the interaction context of the communication partner is successful, the process includes performing processing based on the interaction context of the communication partner and obtaining the processing result, and obtaining the local interaction context based on the processing result. The method according to claim 1.

18. The method for managing the interaction context is as follows: The process further includes obtaining a digest of the local interaction context and signing the digest using a private key. Sending the local interaction context to the communication partner is, This includes sending the signed local interaction context to the communication partner. The method according to claim 1.

19. An interaction context management system comprising a supplier and an operator, The supplier is configured to provide software to the operator, acquire the supplier's interaction context, send the supplier's interaction context to the operator, process based on feedback information sent from the operator, acquire the supplier's local interaction context, and send the supplier's local interaction context to the operator. An interaction context management system wherein the operator is configured to process the software based on the supplier's interaction context, obtain feedback information, and transmit the feedback information to the supplier, the feedback information including the local interaction context acquired by the operator.

20. An interaction context management device applicable to suppliers or operators, An acquisition module configured to acquire the interaction context of a communication partner, wherein the interaction context of the communication partner includes a context identifier, A processing module configured to perform processing based on the interaction context of the communication partner, obtain the processing result, and obtain the local interaction context based on the processing result, A transmitting module configured to transmit the local interaction context to the communication partner, wherein the local interaction context includes the context identifier, An interaction context management device in which the supplier's communication partner is the operator, and the operator's communication partner is the supplier.

21. An interaction context management device applicable to a supplier or operator, comprising a processor and a transceiver, The processor is configured to acquire the interaction context of the communication partner, the interaction context of the communication partner includes a context identifier, perform processing based on the interaction context of the communication partner and obtain the processing result, and acquire a local interaction context based on the processing result. The transceiver is configured to transmit the local interaction context to the communication partner, and the local interaction context includes the context identifier. An interaction context management device in which the supplier's communication partner is the operator, and the operator's communication partner is the supplier.

22. A communication device comprising: memory; a processor; and a program stored in the memory and executable by the processor, wherein the processor is configured to read and execute the program in the memory to perform the steps of the interaction context management method described in any one of claims 1 to 18.

23. A computer-readable storage medium having a program stored in it that causes a processor to perform the interaction context management method described in any one of claims 1 to 18.

24. A computer program product including instructions, wherein when the instructions are executed by a processor, the processor is instructed to execute the interaction context management method described in any one of claims 1 to 18.

Images