A unified session control method and system based on page execution capability constraint

Abstract

This application relates to the field of computer software technology, and in particular to a unified session control method and system based on page execution capability constraints, applicable to loosely coupled multi-service page decoupling systems. This method pre-binds page capability versions during the session suggestion generation phase to solidify the expected execution environment. After user confirmation, it further binds the execution environment using an execution token. During the execution phase, it performs dual verification of version consistency and page instance consistency based solely on the pre-fixed environment information. Only after successful verification can business operations be executed, transforming execution conditions from runtime dynamic judgment to structured constraints at generation time. This effectively solves the problem of inconsistent execution environments across pages, improving the security and stability of session control.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a unified session control method and system based on page execution capability constraints. Background Technology

[0002] In complex business systems such as government service transactions and enterprise services, business processes are typically broken down into multiple independent pages, each carrying different business capabilities. To improve the user experience, existing systems have introduced intelligent question-and-answer conversation modules. However, due to the decoupled architecture of multiple pages, existing conversation control technologies have significant shortcomings and cannot achieve collaborative control between conversations and business pages.

[0003] In existing technologies, such as the conversation control method disclosed in patent CN202110004394.8, the core focus is on the management of modules within the conversation system. The controlled object is the conversation state or collection state, without being associated with specific business operations. Therefore, it cannot solve the problems of conversation conclusions driving page behavior, the executability of cross-page operations, and the matching of conversation suggestions with page capabilities. The intelligent dialogue engine system based on a large language model disclosed in patent CN202410070274.1 only achieves the unification of the dialogue layer or language understanding layer, outputting natural language text. It does not model the executability in the business system, does not distinguish page capability differences, does not determine execution conditions, and cross-page operations can only be responded to with prompts, lacking confirmation, state management, and execution recovery mechanisms.

[0004] In summary, existing technologies have three core problems: First, the execution state cannot be maintained when switching between pages, and there is no explicit modeling and persistence during the execution phase of the session suggestion, making the process prone to interruption; second, the session suggestion cannot perceive the boundaries of page capabilities, and cannot guarantee execution consistency when capabilities change, which easily leads to execution mismatch and lacks a user confirmation mechanism; third, the same operation is easily confirmed repeatedly in multiple rounds of interaction, and there is a lack of isolation mechanism for concurrent session suggestions, making irreversible operations easy to be triggered repeatedly, causing business errors. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this application provides a unified session control and system based on page execution capability constraints, which can achieve accurate matching of session suggestions and page capabilities in a multi-service page decoupling system, thereby improving the security and stability of session control.

[0006] Firstly, this application provides a unified session control method based on page execution capability constraints, applied to a loosely coupled architecture multi-service page decoupled business system. The business system includes a session system and a business page system deployed independently. The session system has a built-in intelligent analysis module, a session control module, and maintains a page capability cache table. The business page system contains multiple independently maintained business pages. The method includes the following steps:

[0007] The session system initializes a unified session context independent of the business page state and maintains the page capability cache table.

[0008] Receive the page capability structure (PCS) reported by the business page in the business page system after it is ready. The PCS includes a page business type identifier, capability set, capability version number, execution permission identifier, and page instance unique identifier.

[0009] The intelligent analysis module identifies the business intent of user input to determine the target business operation and the target page business type.

[0010] The session control module generates in-page or cross-page suggestions based on the page capability set, and abstracts the session suggestions into execution control units (ECUs). During the suggestion generation stage, the ECUs are pre-bound to the capability version number of the target page to solidify the expected execution environment.

[0011] The session control module switches the ECU to the confirmed state according to the user's confirmation command and generates an execution token. The execution token is then combined with the pre-bound target capability version number, target capability identifier, and page instance unique identifier.

[0012] Once the target page is ready, the session control module performs a joint verification on the ECU. The joint verification uses the previously bound capability version number and execution token binding information as the unique verification benchmark. When the capability version of the current page is consistent with the previously bound version and the execution token matches the current page instance, the verification is deemed to have passed.

[0013] When the joint verification passes, the corresponding business operation is triggered through the session control module and the ECU is set to the execution completed state.

[0014] In one possible implementation, the capability version number is generated by the page frontend based on the current permission configuration and the state hash of the function set, and the unique identifier of the page instance is a unique identifier newly generated each time it is ready; the page capability cache table stores the capability set, capability version number, and execution permission identifier reported by each page when it was most recently ready;

[0015] The readiness conditions for a business page are defined according to the front-end architecture type. For multi-page application architectures, a page is considered ready when the document object model rendering is complete, the business data loading is complete, and the user permission verification is complete. For single-page application architectures, a page is considered ready when the route switching is complete, the target view component hook is executed, and the business initialization interface returns.

[0016] In one possible implementation, the session control module determines whether to generate an in-page suggestion or a cross-page suggestion based on the following criteria: if the target operation belongs to the current page's capability set and the execution permission identifier is in a valid state, an in-page suggestion is generated; otherwise, a cross-page suggestion is generated.

[0017] The pre-binding includes: if the target page's historical capability version number exists in the page capability cache table, then the historical capability version number is written into the ECU and locked; if the target page's record does not exist in the page capability cache table, then the target capability version number is marked as pending confirmation, and the binding and locking are completed after the target page is first reported to the PCS.

[0018] The ECU includes a globally unique ECU identifier, a target page service type identifier, a target service operation identifier, a target capability identifier, a target capability version number, an execution token, a current status, and a creation timestamp field.

[0019] In one possible implementation, the execution token is generated when the target capability version number of the ECU is a determined value;

[0020] Among them, the composite binding adopts a differentiated strategy; for cache hit scenarios, an execution token is generated when the user confirms and the initial binding with the target capability identifier and the target capability version number is completed, and the page instance unique identifier is atomically supplemented and bound after the target page is ready; for cache miss scenarios, the execution token is delayed until the target page is ready and the PCS is reported, and the full binding with the target capability identifier, the target capability version number, and the page instance unique identifier is completed in one go.

[0021] The execution token is in an inactive state before the page instance unique identifier is supplemented and bound; once the page instance unique identifier is atomically supplemented and bound, the execution token becomes active and triggers joint verification.

[0022] In one possible implementation, the joint verification includes version consistency verification and token validity verification;

[0023] The version consistency verification meets the following conditions: the target capability version number of the ECU is consistent with the capability version number in the PCS reported on the current page, the target page service type identifier of the ECU is consistent with the page service type identifier in the PCS, and the execution permission identifier carried by the PCS is in a valid state.

[0024] The token validity verification meets the following conditions: the execution token has been generated and has not been marked as invalid; the capability version number bound to the execution token is consistent with the target capability version number of the ECU; and the unique identifier of the page instance bound to the execution token is consistent with the unique identifier of the page instance reported by the current page.

[0025] The page switching is triggered by system commands and manual switching by the user. Both switching methods trigger the same execution and recovery process. During the execution of business operations, the session system pauses to respond to PCS change signals and resumes listening after the execution is completed.

[0026] In one possible implementation, if the joint verification fails, the execution token is marked as invalid and unreusable, the target capability version number of the ECU is reset to pending confirmation, the page instance unique identifier is unbound, and a failure reason prompt is displayed to the user; when the target page resubmits the PCS and the execution permission identifier is valid, the ECU is automatically restored to the recommended display state.

[0027] In one possible implementation, the method further includes the following steps:

[0028] When the session control module detects a multi-ECU parallel conflict, it executes a differentiated conflict handling strategy based on the number of conflicting ECUs and the reversibility of the operation.

[0029] The differentiated conflict handling strategy includes: when there are 2 conflicting ECUs, timestamp sorting is created, and the ECU that entered the confirmed state earliest is restored first. Reversible operations are automatically restored sequentially for subsequent ECUs, while irreversible operations require user confirmation before execution; when there are 3 or more conflicting ECUs, the automatic restoration process is paused, and the user selects the ECUs to be restored. The user decides whether to retain or cancel the ECUs that are not selected. Among them, the reversible operations include automatic form filling and information query, and the irreversible operations include form submission, payment deduction, and data upload confirmation.

[0030] Secondly, this application provides a unified session control system based on page execution capability constraints, including a loosely coupled architecture multi-service page decoupled business system. The business system includes a session system and a business page system deployed independently. The session system has a built-in intelligent analysis module and a session control module and maintains a page capability cache table. The business page system contains multiple business pages that independently maintain their own states. The session system and the business page system cooperate to execute the steps of any of the unified session control methods based on page execution capability constraints described in the first aspect.

[0031] Thirdly, this application provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the unified session control method based on page execution capability constraints as described in any of the first aspects are performed.

[0032] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the unified session control method based on page execution capability constraints as described in any of the first aspects.

[0033] This embodiment provides a unified session control method and system based on page execution capability constraints. Targeting loosely coupled architectures and multi-service page decoupling scenarios, it transforms execution conditions from dynamic runtime judgment to structured constraints of the generation environment by pre-binding the execution environment, further solidifying the token, and performing dual verification based on the solidified environment. This fundamentally solves problems such as inconsistent execution environments across pages and illegal execution, ensuring the stability and security of session execution. At the same time, it simplifies session control logic, avoids accidental triggering of irreversible operations, and improves system reliability. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 A flowchart of a unified session control method based on page execution capability constraints according to an embodiment of this application is shown;

[0036] Figure 2 This paper illustrates a timing diagram of a token composite binding implementation according to an embodiment of this application.

[0037] Figure 3 This paper illustrates a flowchart of the session control response triggered by the PCS reporting after the target page is ready, according to an embodiment of this application.

[0038] Figure 4 A flowchart of a multi-ECU parallel conflict handling embodiment of this application is shown;

[0039] Figure 5 A structural block diagram of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0041] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0042] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0043] In view of the technical problems raised in the background, this application provides a unified session control method, system, electronic device and storage medium based on page execution capability constraints, which can realize the accurate matching of session suggestions and page capabilities in a multi-service page decoupling system, and improve the security and stability of session control.

[0044] See the instruction manual appendix Figure 1 This application provides a unified session control method based on page execution capability constraints, applied to a loosely coupled architecture multi-service page decoupled business system. The business system includes a session system and a business page system deployed independently. The session system has a built-in intelligent analysis module, a session control module, and maintains a page capability cache table. The business page system contains multiple independently maintained business pages. The method includes the following steps:

[0045] S1. Initialize a unified session context independent of the business page state through the session system, and maintain the page capability cache table;

[0046] S2. Receive the page capability structure (PCS) reported by the business page in the business page system after it is ready. The PCS includes a page business type identifier, capability set, capability version number, execution permission identifier, and page instance unique identifier.

[0047] S3. The intelligent analysis module identifies the business intent of the user input and determines the target business operation and the target page business type.

[0048] S4. The session control module determines whether to generate in-page or cross-page suggestions based on the page capability set, and abstracts the session suggestions into an execution control unit (ECU). During the suggestion generation stage, the ECU is pre-bound to the capability version number of the target page to solidify the expected execution environment.

[0049] S5. The session control module switches the ECU to the confirmed state according to the user's confirmation command and generates an execution token. The execution token is then combined with the pre-bound target capability version number, target capability identifier, and page instance unique identifier.

[0050] S6. After the target page is ready, the session control module performs a joint verification on the ECU. The joint verification uses the previously bound capability version number and execution token binding information as the unique verification benchmark. When the capability version of the current page is consistent with the previously bound version and the execution token matches the current page instance, the verification is deemed to be successful.

[0051] S7. When the joint verification passes, the corresponding business operation is triggered through the session control module and the ECU is set to the execution completed state.

[0052] Specifically, the session system is used to maintain a unified session context, independent of specific business pages, and persists across pages; the business page system is used to provide a set of pages with specific business functions, each page independently maintains its page state, and actively reports the page capability structure when ready; the session control module is responsible for generating session suggestions, structural binding, state transition, and execution token management; the intelligent analysis module is used to identify the business intent of user input, output the target business operation identifier and the target page type, and the specific implementation method is not limited.

[0053] Steps S1 and S2 form the foundational building phase of the entire session control process. They are used to establish the runtime environment for cross-page sessions and enable the session system to perceive the capabilities of business pages in real time.

[0054] First, the unified session context of the session system is initialized. This context is independent of the state of each business page and includes at least the user input history, the identified business intent, and the list of execution control units, thereby achieving unified management and persistent storage of cross-page states throughout the entire session cycle.

[0055] The Execution Control Unit (ECU) is the basic unit for standardized and object-oriented management of session proposals in this application. It carries full lifecycle data such as target operation, target page, version information, execution token, status information, and timestamps. The session system maintains a page capability cache table with the page business type identifier Page_Type as the key. The page business type identifier is used to uniquely identify the business type to which a business page belongs and is a key field for distinguishing different business pages and matching ECUs. After meeting the readiness conditions, each business page reports its own Page Capability Structure (PCS) to the session system. The page capability structure is structured data reported by the business page to the session system to describe its own business capabilities, and includes at least the page business type identifier Page_Type, capability set Capability_Set, capability version number Capability_Version, execution permission identifier Permission_Flag, and page instance unique identifier Page_Instance_ID. Among them, Capability_Set is the set of all executable business operations that the business page currently possesses; Capability_Version is generated by the front-end of the page based on the current permission configuration and the state hash of the function set, and is used to represent the iterative changes of the business page's capabilities; Permission_Flag is used to identify whether the current user has the permission to execute the capabilities carried by the business page; Page_Instance_ID is a unique identifier that is newly generated after each business page is ready, and is used to distinguish different loaded instances under the same page type.

[0056] The session system uses the Page_Type identifier as the key to overwrite the latest reported page capability structure (PCS) into the page capability cache table. The page capability cache table only stores the Capability_Set, Capability_Version, and Permission_Flag of the most recently reported capability set for each page, and does not store the unique identifier of the page instance (Page_Instance_ID), ensuring that the cache table always reflects the latest capability status of each page.

[0057] The readiness conditions for a business page are uniformly defined based on the front-end architecture type: For multi-page application architectures, the page is considered ready after the document object model rendering, business data loading, and user permission verification are all completed; for single-page application architectures, the page is considered ready after the route switching, the execution of the hook for the target view component, and the return of the business initialization interface are all completed; in partial refresh scenarios, if the target being switched carries a new set of business capabilities, it is considered as one page ready and triggers the reporting of the page capability structure.

[0058] Steps S3 and S4 are the user intent parsing and execution object construction stages, realizing the transformation from natural language requests to standardized execution units.

[0059] See the instruction manual appendix Figure 2 The intelligent analysis module in the conversation system identifies the business intent of the user input and outputs the corresponding target business operation identifier and the target page business type identifier Page_Type. Based on the identification results and the current page's capability structure (PCS), the conversation control module determines whether to generate an in-page suggestion or a cross-page suggestion: if the target operation belongs to the current page's capability set (Capability_Set) and the execution permission identifier (Permission_Flag) is valid, then an in-page suggestion is generated; if the target operation does not belong to the current page's capability set or the execution permission is invalid, then a cross-page suggestion is generated.

[0060] Subsequently, the session control module abstracts each session suggestion into an independent ECU. Each ECU contains at least the globally unique identifier ECU_ID, the target page service type identifier Target_Page_Type, the target service operation identifier Target_Action_ID, the target capability identifier Target_Capability_ID, the target capability version number Target_Capability_Version, the execution token Execution_Token, the current state Current_State, and the creation timestamp Created_Timestamp. The target capability version number Target_Capability_Version is the expected execution environment version number bound in the ECU, used for consistency comparison with the current page capability version number.

[0061] Simultaneously, a version pre-binding operation is performed on the target capability version number of the ECU: if the page capability cache table matches the target page business type identifier, the historical capability version number is read and written to the ECU as the pre-bound version number; if it does not match, the target capability version number of the ECU is marked as "pending confirmation," and the pre-bound version number cannot be modified once written, thus solidifying the page capability version at the time of suggestion generation as the baseline version, providing a version basis for subsequent consistency verification of the execution environment. If the intelligent analysis module identifies the user request as an inquiry-type business intent, the conversation system directly returns the response result in natural language, without generating an ECU or entering the subsequent execution process, thus achieving the classification and processing of operation-type intents and inquiry-type intents.

[0062] Step S5 is the execution permission control and security credential generation stage, which uses a state machine mechanism to achieve strict isolation between suggestion display and business execution.

[0063] See the instruction manual appendix Figure 3 After creation, the ECU enters the Initial state. Once suggestions are generated, it transitions to the Suggestion state, where only suggestions are presented to the user without triggering any business operations. Based on user commands, the ECU performs state transitions: when the user confirms the suggestion, it transitions from the Suggestion state to the Commit state and locks the execution path; when the user cancels the suggestion, it transitions directly from the Suggestion state to the Cancelled state, terminating the process.

[0064] For an ECU in a confirmed state, the session control module generates an execution token (Execution_Token). The execution token is a valid execution credential generated for the confirmed ECU and is compositely bound to the target capability identifier, capability version number, and page instance unique identifier. It is the core credential ensuring the legality, uniqueness, and non-reusability of execution. The session control module completes the composite binding of the execution token with the target capability identifier, target capability version, and page instance unique identifier. This composite binding employs a differentiated strategy: In cache-hit scenarios, the execution token is generated upon user confirmation and initially bound to the target capability identifier and target capability version number; the page instance unique identifier is atomically bound after the target page is ready. In cache-miss scenarios, the execution token is delayed until the target page is ready and reported to the PCS, and a full binding with the target capability identifier, target capability version number, and page instance unique identifier is completed in one go.

[0065] The execution token is in an inactive state and does not trigger joint verification until the page instance unique identifier is atomically bound. Only after the page instance unique identifier is atomically bound is the execution token activated and joint verification is immediately triggered, thus ensuring that the execution token has execution effect only in a legal and complete binding state.

[0066] Step S6 is the cross-page continuity guarantee and legality verification execution phase, ensuring that session suggestions are executed only in a consistent and legal environment.

[0067] When a cross-page suggestion triggers a page switch, and the target page is ready and reports to the PCS, the execution recovery process is automatically triggered. The page switch can be triggered by system commands or by user manual switching. Both triggering methods trigger the same execution recovery process, and the session system does not need to distinguish the source of the switch.

[0068] The session control module performs a joint verification (Joint_Verify) on the confirmed ECU. The joint verification consists of a version consistency verification (Version_Match) and a token validity verification (Token_Valid), and is the only condition for unlocking business execution.

[0069] Among them, the version consistency verification must simultaneously meet the following conditions: the target capability version number of the ECU is consistent with the capability version number in the page capability structure reported by the current page, the target page business type identifier of the ECU is consistent with the page business type identifier in the page capability structure, and the execution permission identifier carried by the page capability structure is in a valid state.

[0070] Token validity verification requires the following conditions to be met simultaneously: the Execution_Token has been generated and not marked as invalid; the capability version number bound to the Execution_Token is consistent with the target capability version number of the ECU; and the unique identifier of the page instance bound to the Execution_Token is consistent with the unique identifier of the page instance reported by the current page. Passing the joint verification means that both the version consistency verification and token validity verification conditions are met simultaneously. Only when all joint verifications pass will the session control module trigger the corresponding business operation on the target page and migrate the ECU to the final execution state. During the execution of the business operation, the session system pauses response to page capability structure change signals and resumes listening after execution, ensuring the atomicity and stability of business execution.

[0071] Step S7 is the final execution stage of the closed-loop execution environment constraints in this application. Only when the joint verification passes will the session control module trigger the business operation and set the execution control unit to the execution completed state, ensuring that the business execution strictly follows the pre-fixed execution environment constraints. Furthermore, this application further improves the session control logic for multi-ECU parallel conflict scenarios to enhance the overall adaptability and robustness of the system.

[0072] See the instruction manual appendix Figure 4When the joint verification fails, the session control module migrates the ECU to the capability failure state, marks the execution token as invalid and unreusable, resets the target capability version number of the ECU to "pending confirmation", removes the page instance unique identifier binding and displays a failure reason prompt to the user; if the target page corresponding to the ECU in the capability failure state re-reports the PCS, and the capability set of the new page capability structure contains the target capability identifier of the ECU and the execution permission identifier is in a valid state, the ECU automatically reverts from the capability failure state to the suggested display state, and after the user reconfirms, steps S5 to S7 are repeated.

[0073] Meanwhile, the session control module monitors multiple ECUs in parallel for conflict in real time. Conflict detection conditions are: multiple ECUs are simultaneously in the confirmed state, the target page business type identifier is the same, and the target capability identifier is the same. For conflict scenarios, differentiated conflict handling strategies are implemented based on the number of conflicting ECUs and the reversibility of the business operations: for two conflicting ECUs, sorted by creation timestamp, the ECU that entered the confirmed state earliest is restored first; reversible operations are automatically restored sequentially for subsequent ECUs; irreversible operations require user confirmation before execution; for three or more conflicting ECUs, the automatic recovery process is paused, and the user selects the ECU to be executed; the user decides whether to retain or cancel the unselected ECUs.

[0074] Reversible operations include repeatable operations with no business risk, such as automatic form filling and information query; irreversible operations include critical business operations that cannot be rolled back after execution, such as form submission, payment deduction, and data upload confirmation.

[0075] When the session ends, the session control module migrates all ECUs that have not reached the final state to the canceled final state and completes the relevant data cleanup to ensure that all ECUs enter a stable final state, achieving a closed loop throughout the entire life cycle and avoiding residual states from affecting system stability.

[0076] The following explanation will be based on specific application scenarios.

[0077] Example 1: Policy applicability inquiry scenario.

[0078] This application can be used in the policy implementation system to assist in the application process. The user is currently on the attachment upload page (page_type: attachment_page) of the policy implementation application system and enters two requests through the embedded AI assistant: the first is "Help me fill in the basic information of the enterprise into the application form" (operation request), and the second is "Which category of attachments do these materials belong to?" (inquiry request).

[0079] For the first request, the intelligent analysis module identifies the target operation as `auto_fill` and the target page type as `form_page`. The session control module queries the current page's PCS; `attachment_page`'s `Capability_Set` does not contain `auto_fill`, generating a cross-page suggestion ECU_1. The system queries the page capability cache table; `form_page` has a historical record with a `Capability_Version` of v2.1. The system writes v2.1 into the `Target_Capability_Version` field of ECU_1 to complete the pre-binding. ECU_1 enters the Suggestion state, and a dialog box displays the list of fields to be filled in a structured format, without triggering any business operations.

[0080] Regarding the second request, the intelligent analysis module identifies it as an inquiry-type intent, requiring no specific business operation to be triggered. The system directly returns an attachment category description in natural language, without generating an ECU or entering any execution flow. The two requests are processed in parallel at the session layer without interfering with each other.

[0081] After the user confirms the feedback suggestion for ECU_1, ECU_1 migrates to Commit, and the system generates an Execution_Token (initially bound to Target_Capability_ID: auto_fill and Target_Capability_Version: v2.1; Page_Instance_ID is supplemented and bound after the target page is ready). The session system sends a switching command to the front end, and the front end routes to the application page. After the application page is ready, the PCS is reported, with Capability_Version as v2.1 and Page_Instance_ID as inst_012. The system performs atomic supplementary binding of Page_Instance_ID, the Token becomes active, and then performs joint verification: Version_Match passes (v2.1 == v2.1, permissions are valid); Token_Valid passes (Token is valid, Page_Instance_ID is bound to inst_012). Joint_Verify=True, the system resumes execution, the form is automatically filled in, and ECU_1 migrates to Completed.

[0082] The above process demonstrates two capabilities of this application: First, the session system can perceive the capability range of the target page and generate cross-page suggestions when the user is on any business page, without requiring the user to manually switch and then initiate a request; Second, query-type intents and operation-type intents are processed in parallel in the same session. Query-type requests do not enter the ECU process, while operation-type requests are fully controlled through the state machine to manage the execution lifecycle, with strict separation of responsibilities between the two.

[0083] Example 2: Handling scenario where user modification of page content leads to inconsistency between session state and page state.

[0084] When a user fills out a form on the application page (page_type: form_page) of the cashback application system, they can input "Please check if my application materials are complete" through the AI ​​assistant. The intelligent analysis module identifies the target operation as form_validate, which belongs to the Capability_Set of form_page and has Permission_Flag set to True, generating a suggested ECU_2 on the page. The Target_Capability_Version of ECU_2 is directly read from the current PCS and recorded as v2.1, and the Page_Instance_ID is inst_021. After the user confirms, ECU_2 is migrated to Commit, and the system completes the full token binding in one go (binding Target_Capability_ID: form_validate, Target_Capability_Version: v2.1, Page_Instance_ID: inst_021), and then performs joint verification.

[0085] However, during the process from ECU_2's Commit phase to the joint verification execution, the user realized that some of the submitted materials were incorrect. They directly modified the table fields and attachments on the submission page, triggering the system's permission re-verification process. After the permission verification was completed, the submission page frontend detected a substantial change in the functional set (the addition of attachment verification capability), recalculated the status hash, generated a new version number v2.2, and reported the new PCS (Capability_Version: v2.2, Page_Instance_ID: inst_022).

[0086] After receiving the new PCS, the session control module checks if the ECU_2 currently in the Commit state matches the Page_Type of the new PCS. If so, a joint verification is immediately performed: the Version_Match sub-condition fails (ECU_2.Target_Capability_Version v2.1 ≠ PCS.Capability_Version v2.2); Joint_Verify = False. ECU_2 is then migrated to Invalid, the token is immediately marked as invalid, and the system displays a message to the user: "The declaration page function has been updated, and the recommended execution environment has changed. Please reconfirm whether to continue the verification."

[0087] After the user confirms the re-execution, the system regenerates the token based on the current PCS v2.2, completes the full binding with Target_Capability_Version: v2.2 and Page_Instance_ID: inst_022, the joint verification passes, form_validate is executed in the new capability environment, covering the newly added attachment verification capability, the verification result fully reflects the latest page status after the user's modification, and ECU_2 is migrated to Completed.

[0088] The above process embodies the core value of this application: if a user's active operation on the page (modifying a table, uploading an attachment) triggers a page capability version update, the session system can passively detect the change through the PCS ready event without any active polling, and automatically block execution requests based on the old capability environment by comparing the version number, ensuring that the execution result of the session suggestion is strictly consistent with the user's current real page state.

[0089] As can be seen, the unified session control method based on page execution capability constraints provided in this application binds the capability version number (Capability_Version) to the suggested structure when the ECU is generated (rather than dynamically obtained during execution) and introduces a joint verification mechanism (Version_Match verifies whether the execution environment is consistent, and Token_Valid verifies the validity of the token bound to the page instance). This elevates the unlocking condition of the execution path from flow control to structural constraint. The only condition for Commit to Complete is Joint_Verify=True, and both sub-conditions are indispensable. In an environment where page capabilities change dynamically, the system can automatically block inconsistent execution behaviors through version comparison without actively polling or additional runtime detection. At the same time, it structurally eliminates the possibility of old tokens being reused after capability changes, triggering erroneous execution, and solves the execution mismatch problem caused by permission changes, user modifications to page content, or version upgrades.

[0090] Furthermore, this application achieves consistency assurance in two directions by maintaining a unified session context across pages, combined with a passive recovery triggering mechanism based on PCS ready events and isolation of the suggestion state using a state machine: First, user-initiated operation suggestions on any page remain locked after confirmation and automatically resume execution when the target page is ready. Regardless of whether the switch is triggered by the system or manually operated by the user, the execution continuity is uninterrupted, avoiding repeated user input. Second, all suggestions (including intra-page and cross-page suggestions) are uniformly displayed through the suggestion state and must be explicitly confirmed by the user before entering the execution path. AI suggestions do not directly trigger business operations, eliminating the risk of misoperation caused by the lack of a user confirmation mechanism in existing technologies.

[0091] Furthermore, this application employs a multi-ECU parallel conflict isolation mechanism. When the system detects multiple ECUs in the Commit state pointing to the same page and performing the same operation, it automatically switches processing strategies based on whether the operation is reversible: reversible operations are automatically executed sequentially according to timestamp order; irreversible operations are paused after the preceding ECU completes and the user is prompted for confirmation; three or more conflicting ECUs are uniformly assigned to the user for active selection. This mechanism ensures that each business execution corresponds to a unique user confirmation, fundamentally preventing the risk of irreversible operations such as form submissions and payment deductions being repeatedly triggered in scenarios involving multiple rounds of interaction or accidental operations.

[0092] Based on the same inventive concept, this application also provides a unified session control system based on page execution capability constraints, including a loosely coupled architecture multi-service page decoupled business system. The business system includes a session system and a business page system deployed independently. The session system has a built-in intelligent analysis module and a session control module and maintains a page capability cache table. The business page system contains multiple business pages that independently maintain their own states. The session system and the business page system cooperate to execute the steps of any of the above-described unified session control methods based on page execution capability constraints.

[0093] Since the principle of the system in this application embodiment is similar to the unified session control method based on page execution capability constraints described above in this application embodiment, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be described again.

[0094] Based on the same concept of the present invention, the specification is attached. Figure 5 As shown in the embodiment of this application, an electronic device 500 is provided. The electronic device 500 includes: at least one processor 501, at least one network interface 504 or other user interface 503, a memory 505, and at least one communication bus 502. The communication bus 502 is used to enable communication between these components. The electronic device 500 may optionally include a user interface 503, including a display (e.g., touchscreen, LCD, CRT, holographic imaging, or projector), a keyboard, or a clicking device (e.g., mouse, trackball, touchpad, or touchscreen).

[0095] Memory 505 may include read-only memory and random access memory, and provides instructions and data to processor 501. A portion of memory 505 may also include non-volatile random access memory (NVRAM).

[0096] In some implementations, memory 505 stores executable modules or data structures, or subsets or extensions thereof:

[0097] The 5051 operating system contains various system programs used to implement various basic business functions and handle hardware-based tasks.

[0098] Application module 5052 contains various applications, such as launchers, media players, and browsers, to implement various application functions.

[0099] In this embodiment, by calling the program or instructions stored in the memory 505, the processor 501 executes steps such as in a unified session control method based on page execution capability constraints, which can achieve accurate matching of session suggestions and page capabilities in a multi-service page decoupling system, thereby improving the security and stability of session control.

[0100] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs steps such as those in a unified session control method based on page execution capability constraints.

[0101] Specifically, the storage medium can be a general-purpose storage medium, such as a removable disk or hard disk. When the computer program on the storage medium is run, it can execute the aforementioned unified session control method based on page execution capability constraints.

[0102] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0103] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0104] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0105] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] Finally, it should be noted that the above embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A unified session control method based on page execution capability constraints, characterized in that, A method for decoupling multiple service pages in a loosely coupled architecture is provided. The service system includes an independently deployed session system and a service page system. The session system has a built-in intelligent analysis module, a session control module, and maintains a page capability cache table. The service page system contains multiple independently maintained service pages. The method includes the following steps: The session system initializes a unified session context independent of the business page state and maintains the page capability cache table. The system receives a Page Capability Structure (PCS) reported by a business page in the business page system after it becomes ready. The PCS includes a page business type identifier, capability set, capability version number, execution permission identifier, and a unique page instance identifier. The capability version number is generated by the page frontend based on the current permission configuration and the state hash of the function set. The unique page instance identifier is a newly generated identifier for each ready page. The page capability cache table stores the capability set, capability version number, and execution permission identifier reported by each page at its most recent ready state. The ready conditions for a business page are defined according to the frontend architecture type. For multi-page application architectures, a page is considered ready after the document object model rendering is completed, business data loading is completed, and user permission verification is completed. For single-page application architectures, a page is considered ready after route switching is completed, the target view component hook is executed, and the business initialization interface returns. The intelligent analysis module identifies the business intent of user input to determine the target business operation and the target page business type. The session control module determines whether to generate in-page or cross-page suggestions based on the page capability set, and abstracts the session suggestions into execution control units (ECUs). During the suggestion generation phase, the ECU is pre-bound to the capability version number of the target page to solidify the expected execution environment. The session control module determines whether to generate in-page or cross-page suggestions based on the following criteria: if the target operation belongs to the current page capability set and the execution permission identifier is valid, an in-page suggestion is generated; otherwise, a cross-page suggestion is generated. The pre-binding includes: if the target page's historical capability version number exists in the page capability cache table, the historical capability version number is written into the ECU and locked; if the target page record does not exist in the page capability cache table, the target capability version number is marked as pending confirmation, and the binding and locking are completed after the target page is first reported to the PCS. The ECU includes a globally unique ECU identifier, a target page business type identifier, a target business operation identifier, a target capability identifier, a target capability version number, an execution token, a current status, and a creation timestamp field. The session control module switches the ECU to the confirmed state according to the user's confirmation command and generates an execution token. The execution token is then combined with the pre-bound target capability version number, target capability identifier, and page instance unique identifier. Once the target page is ready, the session control module performs a joint verification on the ECU. The joint verification uses the previously bound capability version number and execution token binding information as the unique verification benchmark. When the capability version of the current page is consistent with the previously bound version and the execution token matches the current page instance, the verification is deemed to have passed. When the joint verification passes, the corresponding business operation is triggered through the session control module and the ECU is set to the execution completed state.

2. The unified session control method based on page execution capability constraints according to claim 1, characterized in that, The execution token is generated when the target capability version number of the ECU is a defined value; Among them, the composite binding adopts a differentiated strategy; for cache hit scenarios, an execution token is generated when the user confirms and the initial binding with the target capability identifier and the target capability version number is completed, and the page instance unique identifier is atomically supplemented and bound after the target page is ready; for cache miss scenarios, the execution token is delayed until the target page is ready and the PCS is reported, and the full binding with the target capability identifier, the target capability version number, and the page instance unique identifier is completed in one go. The execution token is in an inactive state before the page instance unique identifier is supplemented and bound; once the page instance unique identifier is atomically supplemented and bound, the execution token becomes active and triggers joint verification.

3. The unified session control method based on page execution capability constraints according to claim 2, characterized in that, The joint verification includes version consistency verification and token validity verification; The version consistency verification meets the following conditions: the target capability version number of the ECU is consistent with the capability version number in the PCS reported on the current page, the target page service type identifier of the ECU is consistent with the page service type identifier in the PCS, and the execution permission identifier carried by the PCS is in a valid state. The token validity verification meets the following conditions: the execution token has been generated and has not been marked as invalid; the capability version number bound to the execution token is consistent with the target capability version number of the ECU; and the unique identifier of the page instance bound to the execution token is consistent with the unique identifier of the page instance reported by the current page. The page switching is triggered by system commands and manual switching by the user. Both switching methods trigger the same execution and recovery process. During the execution of business operations, the session system pauses to respond to PCS change signals and resumes listening after the execution is completed.

4. The unified session control method based on page execution capability constraints according to claim 3, characterized in that, If the joint verification fails, the execution token will be marked as invalid and unreusable, the target capability version number of the ECU will be reset to pending confirmation, the unique identifier of the page instance will be unbound, and the user will be shown a prompt indicating the reason for the failure. When the target page resubmits the PCS and the PCS with valid execution permissions is executed, the ECU will be automatically restored to the recommended display state.

5. The unified session control method based on page execution capability constraints according to claim 4, characterized in that, The method further includes the following steps: When the session control module detects a multi-ECU parallel conflict, it executes a differentiated conflict handling strategy based on the number of conflicting ECUs and the reversibility of the operation. The differentiated conflict handling strategy includes: when there are 2 conflicting ECUs, timestamp sorting is created, and the ECU that entered the confirmed state earliest is restored first. Reversible operations are automatically restored sequentially for subsequent ECUs, while irreversible operations require user confirmation before execution; when there are 3 or more conflicting ECUs, the automatic restoration process is paused, and the user selects the ECUs to be restored. The user decides whether to retain or cancel the ECUs that are not selected. Among them, the reversible operations include automatic form filling and information query, and the irreversible operations include form submission, payment deduction, and data upload confirmation.

6. A unified session control system based on page execution capability constraints, characterized in that, The system includes a loosely coupled architecture and a multi-service page decoupled business system. The business system includes a session system and a business page system that are deployed independently. The session system has a built-in intelligent analysis module and a session control module and maintains a page capability cache table. The business page system contains multiple business pages that independently maintain their own states. The session system and the business page system cooperate to execute the steps of the unified session control method based on page execution capability constraints as described in any one of claims 1 to 5.

7. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the unified session control method based on page execution capability constraints as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the unified session control method based on page execution capability constraints as described in any one of claims 1 to 5.

Images