Interface protocol specification for bidding-oriented three-stage inspection and closed-loop correction method

Abstract

The application relates to a method for three-order inspection and closed-loop correction of an interface protocol specification for bidding, which comprises the following steps: obtaining technical description text related to a software interface in a bidding document; extracting interface specification elements by using an information extraction method based on natural language processing; obtaining a specification integrity level according to the number of extracted elements; determining a processing path by using a flow branch control mechanism according to the specification integrity level; and generating an interface compliance evaluation report according to the execution result of the processing path. By using the method, the type and degree of specification loss can be automatically identified and differentiated processing can be performed according to the level in the case that the bidding requirements are not complete, and the whole-link interface specification credible management from bidding self-inspection to bidding verification to contract baseline can be realized.

Description

Technical Field

[0001] This application relates to the field of intelligent review and interface protocol testing technology for bidding, and in particular to a method for third-order verification and closed-loop correction of interface protocol specifications for bidding. Background Technology

[0002] In software development project bidding, system integration capability is a key indicator for technical solution evaluation. Whether the interface protocols and data exchange formats described in the bid proposal are standardized and consistent with the bidding requirements directly affects the difficulty and cost of system integration in the later stages of the project. At the same time, the quality of the description of interface technical requirements in the bidding documents themselves directly determines whether the bidder can accurately understand the requirements and whether the review experts can objectively judge compliance.

[0003] In current bidding practices, the review of interface specifications relies entirely on manual reading. Reviewers need to compare the bidding documents and check the interface descriptions in the bid proposal item by item. This approach has three problems: First, it is inefficient, as a technical proposal for a large project may contain dozens of interface definitions; second, it is easy to overlook, as hidden problems such as missing interface specifications and mismatched data exchange formats are not easily detected; and third, it lacks consistency, as different reviewers may have different judgments on the same interface specification.

[0004] Existing electronic bidding and tendering technical specifications mainly stipulate the format compliance requirements for tender documents, but do not cover the technical compliance verification of interface protocols and data exchange formats in software technical solutions. In the field of API specification quality assessment, tools such as OASQuali evaluate the standardization of OpenAPI specification documents themselves, which falls under the document quality dimension. However, the input is always structured OpenAPI files, which cannot handle unstructured natural language text in bidding and tendering scenarios. Semantic analysis-based tender document compliance detection methods assume complete tender requirements and cannot handle situations where the tender requirements themselves are incomplete.

[0005] The search revealed that CN120893849B, which focuses on fair competition testing of tender documents, does not address the completeness of interface specifications; CN120874825A, which constructs a knowledge graph of tender requirements for text mapping, requires the pre-construction and maintenance of a large-scale domain knowledge graph, resulting in high deployment costs; and CN118863823B, which involves multimodal data fusion before tender review.

[0006] In addition, existing technologies have the following shortcomings: the strong correlation between the completeness of the five elements and the consistency of bid interpretation is not utilized, and the bidding party cannot control the quality of interface specifications from the source; external and internal interfaces have significantly different sensitivities to specification elements, but existing technologies use a uniform standard for all interfaces, and cannot distinguish the risk levels of different interface types; even if specification deficiencies are detected, existing technologies only output a binary conclusion of whether the specification is met or not, without providing a list of missing elements and risk levels, and cannot coordinate with subsequent modules such as contract deviation detection and asymmetric cross-validation. Summary of the Invention

[0007] Based on this, it is necessary to provide a method, system, computer equipment, and storage medium for three-order verification and closed-loop correction of interface protocol specifications for bidding, which can automatically detect specification deficiencies in bidding requirements, process them in stages according to the degree of deficiency, and dynamically adjust the verification strategy according to interface risks.

[0008] A method for third-order verification and closed-loop correction of interface protocol specifications for bidding and tendering, the method comprising: Obtain the technical description text related to the software interface from the tender documents; Based on the technical description text, an information extraction method based on natural language processing is used to extract interface specification elements. The interface specification elements include five elements: protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. Based on the number of extracted interface specification elements, a specification integrity level is obtained. The specification integrity level includes four levels: complete, basically complete, partially missing, and severely missing. Five elements complete corresponds to the complete level, four elements complete corresponds to the basically complete level, two to three elements correspond to the partially missing level, and zero to one element corresponds to the severely missing level. Based on the specification integrity level, the corresponding processing path is determined using a process branch control mechanism: when the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification is performed; when the specification integrity level is partially missing, the contract verification is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked, cross-interface consistency verification is performed, and risk warnings are output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. Based on the execution results of the processing path, an interface compliance assessment report is generated. The assessment report includes information on the completeness level of the specification, a list of missing elements, and suggested corrections.

[0009] In one embodiment, the method further includes: obtaining the caller type, trigger mode type, sensitivity level type, and deployment location type of the interface; Calculate the comprehensive risk coefficient based on the specification integrity level and the interface type:

[0010] Where R is the comprehensive risk coefficient; Based on the basic risk coefficient, when the completeness level of the specification is partially missing... Take the first base value when the specification integrity level is severely lacking. Take a second base value, which is greater than the first base value; As a caller type weighting factor, As a trigger mode type weight factor, For sensitivity level type weighting factors, Deployment location type weighting factor; The risk level is determined based on the comprehensive risk coefficient; wherein, when the caller type of the interface is an external call or the sensitivity level type is high sensitivity level, and the security authentication mechanism element is missing, the risk level is configured as high risk level.

[0011] In one embodiment, the method further includes: when the specification integrity level is complete, performing full contract verification, requiring all five elements to be satisfied, otherwise it is determined to fail; When the specification integrity level is basically complete, partial contract verification is performed, only verifying the extracted elements, and marking missing elements with a missing warning without judging them as failing.

[0012] In one embodiment, the method further includes: when a bidding technical solution document exists, performing multimodal parsing on the bidding technical solution document to extract interface implementation information from at least one modality among natural language text, Swagger / OpenAPI format files, code snippets, configuration files, and architecture diagrams; When at least two modalities exist, a weighted voting method is used to fuse the interface information of different modalities. The fusion confidence level is determined as follows: If the descriptions of all modalities are determined to be consistent through semantic matching, then the fusion confidence score is calculated:

[0013] in, The fusion confidence level under the condition of no contradiction. The maximum value among the initial confidence weights for each modality. This represents the initial confidence weight for the i-th mode. Here, m is the indicator variable, and m is the number of modes. If at least two modal descriptions are determined to be inconsistent through semantic matching, the description value of the higher-priority modality is taken as the fused description value, and the fusion confidence is calculated as follows:

[0014] And mark cross-modal conflicts, where, The fusion confidence level is given when cross-modal contradictions exist. This describes a subset of modalities that are determined to be consistent through semantic matching. The initial confidence weights are used to determine the high-priority modalities. The high-priority modalities are determined from high to low based on their initial confidence weights. If the initial confidence weights are the same, they are determined according to the priority order of configuration files, code snippets, Swagger / OpenAPI format files, architecture diagrams, and natural language text.

[0015] In one embodiment, the method further includes: outputting the specification integrity level, the list of missing elements, and the integrity score corresponding to the specification integrity level in a preset data format as a collaborative signal for at least one of the tender document generation system, external review system, or contract management system to read; Specifically, when the integrity score is lower than a first preset threshold, a first collaborative field indicating the confidence decay coefficient is written into the collaborative signal; when the integrity score is lower than a second preset threshold, a second collaborative field indicating a warning of insufficient integrity of the bidding specifications is written into the collaborative signal; the first preset threshold is greater than the second preset threshold.

[0016] In one embodiment, the first preset threshold is determined based on the median of samples with a specification integrity level of complete or substantially complete, and the second preset threshold is determined based on the median of the lower boundary of the partial missing level and the upper boundary of the severe missing level; the first preset threshold and the second preset threshold can be dynamically adjusted according to the actual business scenario.

[0017] In one embodiment, the method further includes: generating the correction suggestion information by matching from a predefined template according to the type of missing element; wherein, when the specification integrity level is partially missing, an element completion template is generated as the correction suggestion information; and when the specification integrity level is severely missing, a structured problem diagnosis list is generated as the correction suggestion information. The steps for dynamically expanding the set of interface specification elements based on historical contract dispute data include: Extract elements that cause disputes due to unclear interface specifications from historical contract dispute cases, use named entity recognition and association rule mining algorithms to discover high-frequency missing elements, include the high-frequency missing elements in the detection range of the interface specification elements, and automatically update the corresponding element extraction rules. A third-order verification and closed-loop correction system for interface protocol specifications oriented towards bidding and tendering, the system comprising: The interface specification element extraction module is used to obtain the technical description text related to the software interface in the tender document; based on the technical description text, an information extraction method based on natural language processing is used to extract interface specification elements; the interface specification elements include protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. The specification integrity level determination module is used to obtain the specification integrity level based on the number of extracted interface specification elements; the specification integrity level includes complete, basically complete, partially missing and severely missing, wherein complete interface specification elements correspond to the complete level, four complete interface specification elements correspond to the basically complete level, two to three interface specification elements correspond to the partially missing level, and zero to one interface specification element corresponds to the severely missing level. The processing path determination module is used to determine the processing path based on the specification integrity level using a process branch control mechanism: When the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification is performed; when the specification integrity level is partially missing, the contract verification is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked, cross-interface consistency verification is performed, and a risk warning is output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. The assessment report output module is used to generate an interface compliance assessment report based on the execution results of the processing path. The assessment report includes the specification completeness level information, the missing element list information, and correction suggestion information.

[0018] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program performing the following steps: Obtain the technical description text related to the software interface from the tender documents; Based on the technical description text, an information extraction method based on natural language processing is used to extract interface specification elements; the interface specification elements include protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. The specification integrity level is obtained based on the number of extracted interface specification elements. The specification integrity level includes complete, basically complete, partially missing, and severely missing. The completeness level corresponds to having all interface specification elements, the basically complete level corresponds to having all four interface specification elements, the partially missing level corresponds to having two to three interface specification elements, and the severely missing level corresponds to having zero to one interface specification element. Based on the specification integrity level, a process branch control mechanism is used to determine the processing path: When the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification is performed; when the specification integrity level is partially missing, the contract verification is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked, cross-interface consistency verification is performed, and a risk warning is output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. Based on the execution results of the processing path, an interface compliance assessment report is generated. The assessment report includes the specification completeness level information, the missing element list information, and correction suggestion information.

[0019] A computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain the technical description text related to the software interface from the tender documents; Based on the technical description text, an information extraction method based on natural language processing is used to extract interface specification elements; the interface specification elements include protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. The specification integrity level is obtained based on the number of extracted interface specification elements. The specification integrity level includes complete, basically complete, partially missing, and severely missing. The completeness level corresponds to having all interface specification elements, the basically complete level corresponds to having all four interface specification elements, the partially missing level corresponds to having two to three interface specification elements, and the severely missing level corresponds to having zero to one interface specification element. Based on the specification integrity level, a process branch control mechanism is used to determine the processing path: When the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification is performed; when the specification integrity level is partially missing, the contract verification is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked, cross-interface consistency verification is performed, and a risk warning is output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. Based on the execution results of the processing path, an interface compliance assessment report is generated. The assessment report includes the specification completeness level information, the missing element list information, and correction suggestion information.

[0020] The aforementioned three-tiered verification and closed-loop correction method for interface protocol specifications in bidding and tendering processes extracts five types of interface specification elements from the tender documents, determines four specification integrity levels based on the number of elements, and uses a process branch control mechanism to determine differentiated processing paths according to the level. Contract verification is performed when the specification is complete or nearly complete; cross-interface consistency verification is performed when it is partially missing; and manual confirmation is mandatory when it is severely missing. Finally, a compliance assessment report containing level information, a missing item list, and correction suggestions is generated. This method adds a specification integrity detection pre-step before contract verification, fundamentally solving the technical problem that existing technologies cannot handle incomplete tender requirements in bidding and tendering scenarios due to the assumption of complete input. It achieves end-to-end trusted governance of interface specifications, from tender self-inspection to bid verification and then to the contract baseline. Attached Figure Description

[0021] Figure 1 This is a diagram illustrating an application scenario of a third-order verification and closed-loop correction method for an interface protocol specification oriented towards bidding in one embodiment. Figure 2 This is a flowchart illustrating a third-order verification and closed-loop correction method for an interface protocol specification oriented towards bidding in one embodiment. Figure 3 This is a structural block diagram of a third-order verification and closed-loop correction device for an interface protocol specification oriented towards bidding in one embodiment. Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] The third-order verification and closed-loop correction method for interface protocol specifications for bidding provided in this application can be applied to, for example... Figure 1 In the application environment shown, the bidding party terminal 1021 communicates with the inspection server 104 via the network. The inspection server 104 obtains the technical description text related to the software interface from the bidding documents, extracts five types of interface specification elements, determines the specification integrity level, and uses a process branch control mechanism to determine the processing path based on the level, generating an interface compliance assessment report. The bidding party terminal 1022 communicates with the inspection server 104 via the network. The inspection server 104 performs multimodal parsing on the bidding technical solution documents and performs contract verification or cross-interface consistency verification, generating an assessment report containing collaborative signals. The bidding party terminal 1021 and the bidding party terminal 1022 can be, but are not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The inspection server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0024] In one embodiment, such as Figure 2 As shown, a third-order verification and closed-loop correction method for interface protocol specifications oriented towards bidding is provided, and this method is applied to... Figure 1 Taking the verification server in the example, the following steps are included: Step 202: Obtain the technical description text related to the software interface from the tender documents.

[0025] The tender documents are documents containing technical requirements released during the bidding stage of software development projects. The technical description text consists of natural language paragraphs or sentences from the tender documents describing the technical requirements related to software interfaces. The acquisition process includes segmenting the tender documents into sentences and performing part-of-speech tagging, using a BERT-based sequence labeling model to identify sentence boundaries related to interfaces. The keyword library includes terms such as interface, data exchange, integration, compatibility, call, integration, communication protocol, data exchange format, REST, gRPC, SOAP, and message queue.

[0026] In one specific implementation, the BERT-based sequence labeling model was fine-tuned on a dataset of 2,500 labeled tender statements. This labeled dataset was independently labeled by three experts in the field of software engineering, with a Kappa coefficient of 0.87 for label consistency. The model training parameters were BERT-base, batch size was 16, learning rate was 2e-5, and 5-fold cross-validation was used.

[0027] Step 204: Based on the technical description text, extract the interface specification elements using a natural language processing-based information extraction method.

[0028] The interface specification elements include five elements: protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints.

[0029] These five elements are five core dimensions determined based on industry practices and necessity analysis in the field of interface technology specifications. They correspond to the protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints in the interface definition. These five dimensions are independent of each other and together constitute the complete semantic closure of the interface technology specification. For each identified interface-related sentence, a rule-based information extraction method is used to extract the five types of specification elements. The protocol type is extracted by matching keywords such as RESTful, REST, gRPC, SOAP, MQTT, WebSocket, and HTTP, along with their regular expressions, outputting a structured result containing the protocol type and confidence level. The data exchange format is extracted by matching keywords such as JSON, XML, Protobuf, Proto, and binary, along with their regular expressions, outputting a structured result containing the data exchange format and confidence level. The security authentication mechanism is extracted by matching keywords such as OAuth, JWT, API Key, Token, and certificate, along with their regular expressions, outputting a structured result containing the security authentication mechanism and confidence level. The exception handling specification extracts relevant information by matching keywords such as error codes, exception codes, and status codes. After regular expression extraction, post-processing rules are added to further check whether the exception handling specification includes error code encoding rules, error type classifications, HTTP status code mappings, and error description fields. If the extraction result contains an error code value but not a classification or description, it is marked as partially complete with a confidence level not exceeding 0.6. If it contains a value, a complete classification, and a complete description, it is marked as complete with a confidence level greater than 0.6. Performance constraints are extracted by matching numbers followed by keywords with units such as ms, seconds, QPS, TPS, and concurrency, and using regular expressions. The output is a structured result containing the indicator type, value, and unit. In a specific test, the average F1 score of the five-factor extraction was 0.83.

[0030] Step 206: Obtain the specification integrity level based on the number of extracted interface specification elements.

[0031] The completeness level of the specification includes four levels: complete, basically complete, partially missing, and severely missing. Among them, all five elements are complete, which corresponds to the complete level; all four elements are complete, which corresponds to the basically complete level; two to three elements correspond to the partially missing level; and zero to one element corresponds to the severely missing level.

[0032] It should be noted that elements with a confidence level below the preset threshold are treated as missing, but a prompt message is output for manual review. This confidence level threshold can be adjusted by the system administrator based on the actual data distribution. For example, when the confidence level threshold is set to 0.6, if an element has a confidence level of 0.5, then that element is considered missing.

[0033] Step 208: Determine the corresponding processing path based on the specification integrity level using the process branch control mechanism.

[0034] Specifically, when the specification integrity level is complete or substantially complete, the interface specification elements are converted into formal contracts, which are then compared item by item with the bidding interface solutions, and contract verification processing is performed. The formal contract refers to organizing the interface specification elements extracted in step 204 according to a preset data structure. This data structure includes fields such as contract number, contract type, constraints, and verification methods. For example, for protocol type elements, the constraint field in the contract records the required protocol name, and the verification method field records the keyword matching method. When this method is applied to a bidding self-inspection scenario (i.e., when there is no bidding solution input), the contract verification processing involves checking the self-consistency of the descriptions of the same interface in different chapters of the bidding documents to ensure internal consistency of the bidding requirements. When applied to a bidding verification scenario (i.e., when there is bidding solution input), the contract verification processing involves converting the bidding interface requirements into a formal contract and comparing it item by item with the bidding interface solutions, outputting a compliance assessment result.

[0035] When the specification integrity level is partially missing, the contract verification process is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked. Cross-interface consistency verification is performed, and a risk warning is output. Before performing cross-interface consistency verification, a compatibility dependency prediction mechanism is also included: pre-evaluating whether the missing elements of each interface will affect the completeness of the compatibility detection, defining the dependent element set as data exchange format and protocol type, and the non-dependent element set as performance constraints, exception handling specifications, and security authentication mechanisms.

[0036] The above division is based on the following: data exchange format and protocol type are hard dependencies for direct communication between interfaces; their absence makes it impossible to determine compatibility. Performance constraints, exception handling specifications, and security authentication mechanisms are non-dependent elements, and their absence does not affect the basic logic of compatibility testing. If the intersection of the set of missing elements and the set of dependent elements is not empty, the missing element is marked as unverifiable, all downstream related interfaces of that interface are locked, a prompt suggesting correction of the missing element followed by re-verification is output, the current compatibility check path is terminated, and the process is transferred to manual confirmation. If the missing element belongs only to the set of non-dependent elements, only a corresponding missing warning is marked, and compatibility testing continues.

[0037] When the integrity level of the specification is severely lacking, the automated verification process is terminated and manual confirmation is mandatory.

[0038] Step 210: Generate an interface compliance assessment report based on the execution results of the processing path.

[0039] The assessment report includes information on the level of completeness of the specifications, a list of missing elements, and recommendations for correction.

[0040] The aforementioned three-level verification and closed-loop correction method for interface protocol specifications for bidding and tendering involves obtaining the technical description text from the tender documents and extracting five types of interface specification elements using a natural language processing-based information extraction method. The completeness level of the specification is determined based on the number of elements, and then a differentiated processing path is determined using a process branch control mechanism based on the level. Finally, a compliance assessment report containing level information, a missing item list, and correction suggestions is generated. This method adds a pre-step for specification completeness detection before contract verification, enabling the system to automatically identify the type and degree of missing information even when the tender requirements themselves are incomplete. Differentiated processing—full contract verification, partial contract verification, cross-interface consistency verification, and mandatory manual confirmation—is performed according to four levels: complete, basically complete, partially missing, and severely missing. This avoids misleading results from performing invalid verification on incomplete inputs and outputs the detection results to the tender generation system, external review system, and contract management system through three-level collaborative signals, achieving a closed-loop governance across the entire chain from tender self-inspection to bid verification and then to the contract baseline.

[0041] In one embodiment, after extracting interface specification elements, the method also includes related processing for interface type identification and dynamic risk coefficient calculation.

[0042] Specifically, the caller type, trigger mode type, sensitivity level type, and deployment location type of the interface are obtained. The caller type is determined by identifying keywords such as "third party," "open," and "external" in the text to classify it as external, and keywords such as "inter-module," "internal," and "service call" to classify it as internal. The trigger mode type is determined by identifying keywords such as "synchronous" and "blocking" to classify it as synchronous, keywords such as "asynchronous" and "callback" to classify it as asynchronous, and keywords such as "batch" and "offline" to classify it as batch. The sensitivity level type is determined by identifying keywords such as "funds," "payment," and "personal privacy" to classify it as high, keywords such as "business data" to classify it as medium, and keywords such as "logs" and "monitoring" to classify it as low. The deployment location type is determined by identifying keywords such as "cross-domain" and "public network" to classify it as cross-network, keywords such as "government extranet" to classify it as same-domain, and keywords such as "localhost" to classify it as local. The interface type classification uses TF-IDF to extract features and trains a logistic regression classifier. When the classification confidence is below 0.7, it is marked as unspecified and processed according to the strictest rules: external, synchronous, high, and cross-network.

[0043] Based on the specification integrity level and the interface type, a comprehensive risk coefficient is calculated. The formula for calculating the comprehensive risk coefficient is as follows:

[0044] Where R is the comprehensive risk coefficient; Based on the basic risk coefficient, when the specification integrity level is partially missing... Take the first base value when the specification integrity level is severely lacking. Take the second base value, which is greater than the first base value; As a caller type weighting factor, As a trigger mode type weight factor, For sensitivity level type weighting factors, This is a weighting factor for the deployment location type.

[0045] In one specific embodiment, the example values ​​for each parameter are: The external value is 1.5, and the internal value is 0.8. Synchronous takes 1.2, asynchronous takes 0.9, and batch takes 0.6. The high value is 1.5, the middle value is 1.0, and the low value is 0.7. Cross-network uses 1.3, same-domain uses 1.0, local uses 0.8.

[0046] The risk level is determined based on the calculated comprehensive risk coefficient. When the caller type of the interface is an external call or the sensitivity level is high sensitivity, and the security authentication mechanism is missing, the risk level is configured as high risk. For example, for external interfaces lacking a security authentication mechanism, the comprehensive risk coefficient can be set to 0.9 or higher.

[0047] Through the above processing, this embodiment has made fine-grained quantitative distinctions between the risks of different types of interfaces under the same integrity level, so that the lack of specifications for external interfaces and highly sensitive interfaces can be identified in a timely manner and upgraded to high risk, effectively avoiding the problem of false alarms for external interfaces under the traditional unified standard.

[0048] In one embodiment, the step of converting interface specification elements into a formal contract and comparing them item by item with the tendered interface scheme to perform contract verification processing is further refined.

[0049] When the specification integrity level is complete, full contract verification is performed, requiring all five elements to be satisfied; otherwise, it is deemed unsuccessful. During full contract verification, the system generates corresponding contract entries based on the five elements extracted in step 204. Each contract entry includes constraints, verification methods, and verification parameters. The verification engine performs a search and matching within the structured representation of the bidding interface based on the verification method, outputting verification results that indicate complete satisfaction, partial satisfaction, non-satisfaction, or indeterminability.

[0050] When the specification integrity level is basically complete, partial contract verification is performed. Only the extracted elements are verified, and missing elements are marked with a warning but not considered as failing. This means that at the basically complete level, for example, if the system only extracts four elements—protocol type, data exchange format, security authentication mechanism, and exception handling specifications—and lacks performance constraints, the system will only generate and verify contracts for the first four elements. The performance constraints will be marked with a warning, and this warning information will be recorded in the evaluation report as structured fields for reviewers' reference.

[0051] It should be noted that when this method performs full contract verification at the full level, as an optional extension method, the system can also simultaneously detect whether there are any extended capability commitments or specification elements in the bidding interface scheme beyond the five elements of bidding, including but not limited to rate limiting strategies, circuit breaking mechanisms, and logging specifications. If extended elements exist, they are output as extended compliance items and appended to the review report in a list; if they do not exist, the non-five-element interface characteristics are marked as unclear. This extension method is a non-essential feature and does not affect the pass determination of the five-element contract verification.

[0052] In one embodiment, the step of extracting interface specification elements further includes processing the tender technical solution document for multimodal parsing.

[0053] When a technical proposal document exists for a bid, it undergoes multimodal parsing to extract interface implementation information from at least one modality: natural language text, Swagger or OpenAPI format files, code snippets, configuration files, and architecture diagrams. The specific parsing methods for each modality are as follows: For Swagger or OpenAPI format files, identification is performed by detecting file extensions of .yaml or .json, or by detecting the presence of the keywords "openapi" or "swagger" in the file content. The OpenAPI parser then traverses the `paths` node to extract the interface path and HTTP method, traverses the `components` node to extract request parameters and the request body schema, traverses the `schemas` node to extract the response format, and extracts security definition information from the `securitySchemes` node. For code snippets, after identifying the code language type, the corresponding AST parser is called for extraction. For example, Java code uses `JavaParser` to parse annotations such as `RequestMapping` and `GetMapping`, Python code uses the `ast` module to parse the `app.get` decorator of FastAPI, and Go code uses `go / parser` to parse the `router.GET` call of the Gin framework. The extracted content includes the path, HTTP method, parameter type, return value type, and authentication annotations. For configuration files, regular expressions and YAML or Properties parsers are used to extract information such as service ports, data source configurations, and cache configurations. For architecture diagrams, YOLOv8 is used to detect component types such as module frames, database icons, interface icons, and API gateways; OCR is used to recognize component annotation text; and Hough transform is used to detect connections and arrow directions to obtain the call relationships between interfaces. When the tender documents do not contain an architecture diagram or cannot parse an architecture diagram, the system can extract and fuse information based solely on other modalities without affecting the core integrity detection and process branch control functions.

[0054] When at least two modalities exist, a weighted voting method is used to fuse the interface information of different modalities. The fusion confidence level is determined as follows: If the descriptions of all modalities are determined to be consistent through semantic matching, then the fusion confidence score is calculated:

[0055] in, The fusion confidence level under the condition of no contradiction. The maximum value among the initial confidence weights for each modality. This represents the initial confidence weight for the i-th mode. Here, m is the indicator variable, and m is the number of modes.

[0056] If at least two modal descriptions are determined to be inconsistent through semantic matching, the description value of the higher-priority modality is taken as the fused description value, and the fusion confidence is calculated as follows:

[0057] And mark cross-modal conflicts, where, The fusion confidence level is given when cross-modal contradictions exist. This describes a subset of modalities that are determined to be consistent through semantic matching. The initial confidence weights are used to determine the high-priority modalities. The high-priority modalities are determined from high to low based on their initial confidence weights. If the initial confidence weights are the same, they are determined according to the priority order of configuration files, code snippets, Swagger / OpenAPI format files, architecture diagrams, and natural language text.

[0058] If only a single modality exists, the information extracted from that modality is directly output without fusion processing.

[0059] The aforementioned multimodal parsing and fusion processing can comprehensively extract interface implementation information from different presentation forms of bidding proposals, and identify cross-modal inconsistencies through weighted voting and contradiction detection mechanisms, such as when the bidding text describes OAuth2.0 authentication but the configuration file does not contain the relevant implementation configuration, thereby avoiding misjudgments caused by relying on only a single modality.

[0060] In one embodiment, the method further includes the generation and output processing of a third-order verification coordination signal before generating the interface compliance assessment report.

[0061] The completeness level of the specifications, the list of missing elements, and the completeness score corresponding to the completeness level are output in a preset data format as collaborative signals for at least one of the tender document generation system, external review system, or contract management system. Specifically, the first-order signal serves as a correction input for the tender document generation system, triggering the automatic completion function of the interface description; the second-order signal serves as a calibration signal for the completeness of the tender requirements for the external review system. When the completeness score is lower than a first preset threshold, a first collaborative field indicating the confidence decay coefficient is written into the collaborative signal, allowing the receiving end to automatically adjust the decay parameters of its internal inference model accordingly; the third-order signal serves as a contract baseline completeness score for the contract management system. When the completeness score is lower than a second preset threshold, a second collaborative field indicating a warning of insufficient completeness of the tender specifications is written into the collaborative signal, allowing the receiving end to automatically generate a contract deviation warning. The first preset threshold is greater than the second preset threshold, for example, the first preset threshold is 0.7 and the second preset threshold is 0.5. The collaborative signals are organized in a preset JSON data format, including a stage identifier, requirement number, completeness level, list of missing elements, risk level, and a calibration signal field containing a suggested value for the confidence decay coefficient and a warning level. In standalone deployment scenarios lacking associated application modules, the second-order and third-order signals can be used as independent bidding review report data outputs, which can be read into by third-party review systems or contract management platforms through standard JSON APIs, without relying on specific downstream modules.

[0062] In one embodiment, the method for determining the first preset threshold and the second preset threshold in the above-mentioned coordinated signal is further explained.

[0063] The first preset threshold is determined based on the median of samples with a complete or nearly complete specification integrity level; for example, it might be 0.7 in a specific implementation. The second preset threshold is determined based on the median of the lower boundary of the partial missing level and the upper boundary of the severe missing level; for example, it might be 0.5 in a specific implementation. Both the first and second preset thresholds can be dynamically adjusted according to actual business scenarios. The above values ​​are based on statistical analysis of 132 interface requirements samples from 80 real tender documents. The first preset threshold is determined based on the median of samples with a complete or nearly complete specification integrity level, and the second preset threshold is determined based on the median of the lower boundary of the partial missing level and the upper boundary of the severe missing level. Furthermore, these values ​​can be dynamically learned and optimized based on actual data after system deployment.

[0064] In one embodiment, before generating the interface compliance assessment report, the method further includes processing for generating correction suggestion information and dynamically expanding the set of interface specification elements.

[0065] Based on the type of missing element, corrective suggestions are generated from predefined templates. The correspondence between predefined templates and missing elements is as follows: When a protocol type is missing, the corrective suggestion is to recommend that the tendering party supplement the required interface protocol type, including but not limited to at least one of RESTful, gRPC, SOAP, and WebSocket, and specify the version number; when a data exchange format is missing, the corrective suggestion is to supplement the data exchange format of the request or response, including but not limited to at least one of JSON, XML, and Protobuf, and provide a schema definition or example; when a security authentication mechanism is missing, the corrective suggestion is to supplement at least one of OAuth2.0, JWT, and API Key for external interfaces or highly sensitive data scenarios, and specify the token transmission method; when an exception handling specification is missing, the corrective suggestion is to supplement the standard error code definition format, including error classification, error description, and HTTP status code mapping; when performance constraints are missing, the corrective suggestion is to supplement quantified performance constraints, including the average and 95th percentile of response time, QPS or TPS of throughput, and the number of concurrent users.

[0066] When the specification integrity level is partially missing, a template for completing each element is generated as a correction suggestion, that is, the corresponding template is matched according to the five types of missing elements mentioned above. When the specification integrity level is severely missing, a structured problem diagnosis list is generated as a correction suggestion. The output format is a structured problem diagnosis list rather than a template for completing each element, because there are too many missing elements under the severe missing level, and automatic completion may introduce inaccurate specification definitions. Therefore, a specification reconstruction guidance mode is adopted, requiring the bidding party to redefine the interface specification as a whole.

[0067] The set of interface specification elements can be dynamically expanded based on historical contract dispute data. The dynamic expansion is triggered either at a preset cycle or when the number of newly added contract dispute cases in the historical dispute database exceeds a preset threshold. The specific steps are as follows: The system has a built-in dispute database synchronization interface that extracts dispute description text from project acceptance audit reports and contract legal judgments. A BERT-BiLSTM-CRF joint model is used to perform named entity recognition on the dispute text, identifying the boundaries and categories of target elements in the dispute text to form a candidate element set. An association rule mining algorithm is used to filter high-frequency missing elements from the identified elements. System administrators can review new elements based on actual business needs and select them for inclusion in the specification element set. After inclusion, the semantic vector of the new element is calculated using Word2Vec pre-trained word vectors. Keywords with a similarity of at least 0.7 are extracted based on vector clustering, and the corresponding regular expressions and confidence levels are automatically generated, achieving automatic updates to the element extraction rules. This dynamic expansion capability allows the detection dimensions of this invention to continuously evolve with industry practice and the accumulation of dispute cases, constantly discovering new key specification elements.

[0068] Experimental data description The following experimental data represents the verification results of this application on actual tender document samples, used to illustrate the technical effectiveness of this application. The experiment covered 80 actual tender documents from five industries, containing 132 interface requirements. These included 22 from the government sector, 18 from the financial sector, 15 from the healthcare sector, 13 from the education sector, and 12 from the manufacturing sector. The consensus rate of bid comprehension was determined by the percentage of five independent review experts who reached a consensus on the technical feasibility of the same interface requirement, with a Kappa coefficient of no less than 0.75.

[0069] The following table shows the sample statistics and bid comprehension consistency rates under different integrity levels:

[0070] The correlation coefficients between the bid comprehension consistency rate and the completeness of the five elements in the five industries are shown in the table below:

[0071] The Spearman correlation coefficient ρ between completeness and consistency rate is 0.89, with a p-value less than 0.01, indicating statistical significance. This demonstrates the effectiveness of the five elements as the core detection dimensions for interface specification completeness, and the model exhibits cross-industry stability.

[0072] The five-factor extraction model uses BERT-based sampling with a batch size of 16, a learning rate of 2e-5, and 5-fold cross-validation, resulting in an average F1 score of 0.83. Using Bootstrap resampling 1000 times to calculate 95% confidence intervals, the five-factor extraction accuracy confidence interval ranges from 88.5% to 93.9%, with a Kappa coefficient of 0.87 and a p-value less than 0.01 compared to manually labeled data. The five-factor integrity detection accuracy is 91.2%, with a false positive rate of 8.6%. After differentiating interface types, the false positive rate for external interfaces decreased from 23.5% to 8.9%. After three-stage loop closure, the integrity improvement rate of the tender document interface specifications is 67%.

[0073] For the value of the basic risk coefficient C_base in the comprehensive risk coefficient, based on the statistical analysis of the dispute rates of 29 partially missing interfaces and 12 severely missing interfaces in the historical sample database, the example value of the first basic value was set to 0.3, and the example value of the second basic value was set to 0.7. The difference in dispute rates between the two groups was tested by chi-square test, and the chi-square value was 6.32, with a p-value less than 0.05, indicating statistical significance. Experimental data also showed that under the partially missing level, when the C_base value was in the range of 0.2 to 0.4, there was no significant difference in the system's early warning accuracy, with a p-value greater than 0.05; under the severely missing level, when the C_base value was in the range of 0.6 to 0.8, the recall rate of the system's forced manual confirmation was higher than 96%.

[0074] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0075] In one embodiment, such as Figure 3 As shown, a third-order verification and closed-loop correction system for interface protocol specifications oriented towards bidding is provided. The system includes: The interface specification element extraction module 302 is used to obtain the technical description text related to the software interface in the tender document; based on the technical description text, it uses an information extraction method based on natural language processing to extract interface specification elements; the interface specification elements include protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. The specification integrity level determination module 304 is used to obtain the specification integrity level based on the number of extracted interface specification elements; the specification integrity level includes complete, basically complete, partially missing and severely missing, wherein the completeness level corresponds to the completeness level, the basic completeness level corresponds to the four elements being complete, the partially missing level corresponds to the two to three elements being complete, and the severely missing level corresponds to the zero to one element being complete. The processing path determination module 306 is used to determine the processing path based on the specification integrity level using a process branch control mechanism: When the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification processing is performed; when the specification integrity level is partially missing, the contract verification processing is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are detected, cross-interface consistency verification processing is performed, and a risk warning is output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. The assessment report output module 308 is used to generate an interface compliance assessment report based on the execution result of the processing path. The assessment report includes the specification completeness level information, the missing element list information, and the correction suggestion information.

[0076] Specific limitations regarding the third-order verification and closed-loop correction device for interface protocol specifications oriented towards bidding can be found in the limitations of the third-order verification and closed-loop correction method for interface protocol specifications oriented towards bidding mentioned above, and will not be repeated here. Each module in the aforementioned third-order verification and closed-loop correction device for interface protocol specifications oriented towards bidding can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in a computer device, or stored in software in the memory of a computer device, so that the processor can call and execute the corresponding operations of each module.

[0077] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides the environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores tender document data, bidding proposal data, interface specification element extraction results, and evaluation report data. The network interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a third-order verification and closed-loop correction method for interface protocol specifications oriented towards bidding.

[0078] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0079] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described above.

[0080] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0081] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0082] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0083] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A third-order verification and closed-loop correction method for interface protocol specifications oriented towards bidding, characterized in that, The method includes: Obtain the technical description text related to the software interface from the tender documents; Based on the technical description text, an information extraction method based on natural language processing is used to extract interface specification elements; the interface specification elements include protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. The specification integrity level is obtained based on the number of extracted interface specification elements. The specification integrity level includes complete, basically complete, partially missing, and severely missing. The completeness level corresponds to having all interface specification elements, the basically complete level corresponds to having all four interface specification elements, the partially missing level corresponds to having two to three interface specification elements, and the severely missing level corresponds to having zero to one interface specification element. Based on the specification integrity level, a process branch control mechanism is used to determine the processing path: When the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification is performed; when the specification integrity level is partially missing, the contract verification is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked, cross-interface consistency verification is performed, and a risk warning is output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. Based on the execution results of the processing path, an interface compliance assessment report is generated. The assessment report includes the specification completeness level information, the missing element list information, and correction suggestion information.

2. The method according to claim 1, characterized in that, After extracting the interface specification elements, it also includes: Obtain the caller type, trigger mode type, sensitivity level type, and deployment location type of the interface; Calculate the comprehensive risk coefficient based on the specification integrity level and the interface type: Where R is the comprehensive risk coefficient; Based on the basic risk coefficient, when the completeness level of the specification is partially missing... Take the first base value when the specification integrity level is severely lacking. Take a second base value, which is greater than the first base value; As a caller type weighting factor, As a trigger mode type weight factor, For sensitivity level type weighting factors, Deployment location type weighting factor; The risk level is determined based on the comprehensive risk coefficient; wherein, when the caller type of the interface is an external call or the sensitivity level type is high sensitivity level, and the security authentication mechanism element is missing, the risk level is configured as high risk level.

3. The method according to claim 1, characterized in that, The step of converting the interface specification elements into a formal contract, comparing it item by item with the bidding interface proposal, and performing contract verification processing specifically includes: When the specification integrity level is complete, full contract verification is performed, requiring all five elements to be satisfied; otherwise, it is deemed unsuccessful. When the specification integrity level is basically complete, partial contract verification is performed, only verifying the extracted elements, and marking missing elements with a missing warning without judging them as failing.

4. The method according to claim 1, characterized in that, Extracting interface specification elements also includes: When a bidding technical solution document exists, multimodal parsing is performed on the bidding technical solution document to extract interface implementation information from at least one modality among natural language text, Swagger / OpenAPI format files, code snippets, configuration files, and architecture diagrams; When at least two modalities exist, a weighted voting method is used to fuse the interface information of different modalities. The fusion confidence level is determined as follows: If the descriptions of all modalities are determined to be consistent through semantic matching, then the fusion confidence score is calculated: in, The fusion confidence level under the condition of no contradiction. The maximum value among the initial confidence weights for each modality. This represents the initial confidence weight for the i-th mode. Here, m is the indicator variable, and m is the number of modes. If at least two modal descriptions are determined to be inconsistent through semantic matching, the description value of the higher-priority modality is taken as the fused description value, and the fusion confidence is calculated as follows: And mark cross-modal conflicts, where, The fusion confidence level is given when cross-modal contradictions exist. This describes a subset of modalities that are determined to be consistent through semantic matching. The initial confidence weights are used to determine the high-priority modalities. The high-priority modalities are determined from high to low based on their initial confidence weights. If the initial confidence weights are the same, they are determined according to the priority order of configuration files, code snippets, Swagger / OpenAPI format files, architecture diagrams, and natural language text.

5. The method according to claim 1, characterized in that, Before generating the interface compliance assessment report, the following steps are also included: The specification integrity level, the list of missing elements, and the integrity score corresponding to the specification integrity level are output in a preset data format as a collaborative signal for at least one of the tender document generation system, external review system, or contract management system to read. Specifically, when the integrity score is lower than a first preset threshold, a first collaborative field indicating the confidence decay coefficient is written into the collaborative signal; when the integrity score is lower than a second preset threshold, a second collaborative field indicating a warning of insufficient integrity of the bidding specifications is written into the collaborative signal; the first preset threshold is greater than the second preset threshold.

6. The method according to claim 5, characterized in that, The first preset threshold is determined based on the median of samples with a complete or nearly complete specification integrity level, and the second preset threshold is determined based on the median of the lower boundary of the partial missing level and the upper boundary of the severe missing level; the first preset threshold and the second preset threshold can be dynamically adjusted according to the actual business scenario.

7. The method according to claim 1, characterized in that, Before generating the interface compliance assessment report, the following is also included: Based on the type of missing element, the correction suggestion information is generated by matching from a predefined template; wherein, when the specification integrity level is partially missing, an element completion template is generated as the correction suggestion information; when the specification integrity level is severely missing, a structured problem diagnosis list is generated as the correction suggestion information. The steps for dynamically expanding the set of interface specification elements based on historical contract dispute data include: Extract elements that cause disputes due to unclear interface specifications from historical contract dispute cases, use named entity recognition and association rule mining algorithms to discover high-frequency missing elements, include the high-frequency missing elements in the detection range of the interface specification elements, and automatically update the corresponding element extraction rules.

8. A third-order verification and closed-loop correction system for interface protocol specifications oriented towards bidding and tendering, characterized in that, The system includes: The interface specification element extraction module is used to obtain the technical description text related to the software interface in the tender document; based on the technical description text, an information extraction method based on natural language processing is used to extract interface specification elements; the interface specification elements include protocol type, data exchange format, security authentication mechanism, exception handling specifications, and performance constraints. The specification integrity level determination module is used to obtain the specification integrity level based on the number of extracted interface specification elements; the specification integrity level includes complete, basically complete, partially missing and severely missing, wherein complete interface specification elements correspond to the complete level, four complete interface specification elements correspond to the basically complete level, two to three interface specification elements correspond to the partially missing level, and zero to one interface specification element corresponds to the severely missing level. The processing path determination module is used to determine the processing path based on the specification integrity level using a process branch control mechanism: When the specification integrity level is complete or basically complete, the interface specification elements are converted into a formal contract, compared item by item with the bidding interface scheme, and contract verification is performed; when the specification integrity level is partially missing, the contract verification is skipped, and the data exchange format compatibility, protocol compatibility, and authentication transmission compatibility between multiple interfaces are checked, cross-interface consistency verification is performed, and a risk warning is output; when the specification integrity level is severely missing, the automated verification process is terminated, and manual confirmation is mandatory. The assessment report output module is used to generate an interface compliance assessment report based on the execution results of the processing path. The assessment report includes the specification completeness level information, the missing element list information, and correction suggestion information.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images