Zero-delay interaction system and method driven by cloud computing big data GUI intention prediction

By combining modules on the client and server sides and using deep learning models, user intent is predicted and data is prefetched, solving the problems of user operation latency and redundant computation in existing technologies. This achieves zero-latency interaction of cloud computing big data GUI, improving user experience and system efficiency.

CN121657907APending Publication Date: 2026-03-13武汉市海阔电子信息科技有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-08
Publication Date
2026-03-13

AI Technical Summary

Technical Problem

The existing big data analytics platform GUI interaction model lacks the ability to predict user intent, resulting in user operation delays and redundant calculations, which affects operational efficiency in complex scenarios.

Method used

By employing client-side and server-side module groups, and through interactive event capture and vectorization, predictive request generation and scheduling, proactive data caching and rendering engine, combined with deep learning models for user intent prediction and data prefetching, zero-latency interaction is achieved.

Benefits of technology

By decoupling the data acquisition process from the synchronous path, interaction latency is reduced to the sub-ten millisecond level, redundant computing and network transmission are reduced, user experience and big data platform throughput are improved, and users are supported in in-depth data analysis.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121657907A_ABST
    Figure CN121657907A_ABST
Patent Text Reader

Abstract

The invention belongs to the technical field of computer information and man-machine interaction, and particularly relates to a cloud computing big data GUI intention prediction driven zero-delay interaction system and method.The cloud computing big data GUI intention prediction driven zero-delay interaction system comprises a client module group and a server module group, and user interaction sequence vectors (UISV) are generated through interaction event capturing and vectorization; triggering multi-hypothesis intention prediction of a server side based on a deep learning model through a predictive request, and further pre-fetching a data result set corresponding to a high-confidence prediction state and actively pushing the data result set to a client side for caching; and after the user operation is stable, the client queries the local cache through the prediction state hash to realize instantaneous rendering. By adopting the technical scheme, the interaction delay can be reduced from hundreds of milliseconds to subten milliseconds, the redundancy calculation and network overhead are remarkably reduced, and the user analysis fluency and the system self-adaptive capability are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of computer information technology and human-computer interaction technology, specifically a zero-latency interactive system and method driven by cloud computing and big data GUI intent prediction. Background Technology

[0002] The evolution of information technology has propelled cloud computing and big data analytics platforms to become the core infrastructure for data-driven decision-making. Their distributed computing and storage capabilities enable in-depth processing and value mining of massive amounts of high-dimensional heterogeneous data. As a crucial bridge between humans and backend systems, the design quality and responsiveness of graphical user interfaces directly determine the end-user's operational efficiency and work experience. Especially in scenarios involving complex data filtering and multidimensional analysis, an intuitive, smooth, and low-latency interface is a fundamental prerequisite for ensuring users focus on business logic.

[0003] Existing big data analytics platform GUIs generally adopt a client-server architecture with a "request-response" interaction model: the front end, acting as the client, presents visual components and interactive controls, captures user actions, transforms them into structured query requests, and transmits them to the back end; the back end's big data processing engine performs calculations, filtering, and other operations, returns the result set to the front end, and the front end parses, renders, and updates the view. This model has clear logic and a decoupled architecture, supporting the widespread adoption of data applications at a specific stage and forming the technological cornerstone of mainstream GUI interaction systems.

[0004] As application scenarios expand and real-time requirements increase, traditional models reveal fundamental bottlenecks: they treat each user action as an independent command, triggering a complete backend data round trip. However, in modern data analysis, user actions are often continuous exploratory processes, with each fine-tuning step interpreted as a new request. This leads to the system frequently initiating expensive backend processing and transmission flows before the user expresses their full intent. This "reactive" model lacks intent prediction capabilities, generates a large amount of redundant computation, results in user latency exceeding the 200-millisecond smoothness threshold, fragments analytical thinking, wastes resources, and hinders operational efficiency in complex scenarios.

[0005] Therefore, the present invention provides a zero-latency interactive system and method driven by cloud computing and big data GUI intent prediction. Summary of the Invention

[0006] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0007] The technical solution adopted by the present invention to solve its technical problem is: a zero-latency interactive system driven by cloud computing big data GUI intent prediction, comprising a client module group and a server module group.

[0008] The client module group is deployed on the end-user device and configured to manage the capture of user interactions, the triggering of intent predictions, and the local rendering of data without relying on the traditional synchronous request-response model. The client module group includes: an interaction event capture and vectorization module, a predictive request generation and scheduling module, and a proactive data caching and rendering engine.

[0009] The core function of the interaction event capture and vectorization module is to structure, serialize, and quantify the raw, discrete stream of interaction events generated by the user on the GUI, in order to generate machine-readable input that can characterize the user's short-term behavioral patterns. The module is configured to continuously monitor all interaction events on the GUI, including but not limited to mouse clicks, mouse movements, scroll wheel movements, keyboard input, control focus acquisition and loss, and the start and end of drag operations. For each captured event, the module records its core attributes, including an event type identifier, a unique identifier of the GUI component from which the event originated, a precise timestamp (in milliseconds) of the event occurrence, and event-related payload data, such as the selected dropdown option value or the entered text content. Furthermore, the module sets a dynamic time window or an "interaction burst" detection mechanism based on interaction pause time (e.g., an interval exceeding 150 milliseconds between two consecutive interactions) to aggregate consecutive events into a context-meaning interaction sequence. Based on this, the module performs vectorization processing, converting each event in the sequence into a fixed-dimensional numerical vector. Specifically, the vector is composed of the following parts: one-hot encoding of the GUI component identifier, enumerated integer values ​​of the event type, a normalized timestamp relative to the sequence start time, and an embedding vector of the payload data. The embedding vector of the payload data is generated using a pre-trained, hash-based embedding function to map any text or classification value to a low-dimensional dense vector space. Finally, a complete interaction sequence is converted into a two-dimensional tensor with dimensions (sequence length, single-event vector dimension). This tensor is called the User Interaction Sequence Vector (UISV) and serves as the sole input to trigger backend intent prediction.

[0010] The predictive request generation and scheduling module is responsible for replacing traditional data query requests based on the user's final action, and instead sending predictive requests that carry user behavior patterns. Once the interaction event capture and vectorization module generates a complete UISV, the predictive request generation and scheduling module immediately encapsulates it into a dedicated predictive request message body. This message body uses a binary serialization format, such as Protocol Buffers, to ensure transmission efficiency. The module asynchronously sends this predictive request to the server through a persistent, low-latency, bidirectional communication channel established with the server, such as WebSocket or an HTTP / 2-based gRPC stream. The module is also responsible for managing the lifecycle of the predictive request, including assigning a unique transaction ID to each request and listening for asynchronous responses or data pushes from the server in response to this ID. Crucially, the module is triggered by the formation of an interaction sequence, rather than any single, final user action, thus decoupling the interaction logic from the data request logic.

[0011] The proactive data caching and rendering engine is the final execution unit for achieving a zero-latency experience on the client side. This engine maintains a key-value pair-based memory cache within the client, with a fixed memory limit (e.g., 256MB), referred to as the proactive data cache. The key of the cache is a deterministic hash value calculated from the final state combination of GUI controls, called the predicted state hash. The algorithm for generating the predicted state hash is as follows: obtain the current values ​​of all GUI controls related to data queries on the interface (e.g., filter A's value is 'X', time range selector B's value is ['start_date', 'end_date']), sort these key-value pairs lexicographically by key name, serialize them into a standard string, and then apply the SHA-256 hash algorithm to this string. The cached value is the complete data result set returned by the server for the predicted query corresponding to the predicted state hash. The proactive data caching and rendering engine passively receives data packets pushed by the server through the persistent communication channel; each data packet contains a predicted state hash and its corresponding data result set. Upon receiving the data, the engine immediately stores the key-value pair in the proactive data cache and performs cache replacement according to the Least Recently Used (LRU) strategy. When the user's actions on the GUI finally stabilize (i.e., after a period of silence with no new interactive events), the rendering engine calculates the final state hash of all relevant GUI controls and uses this hash as the key to query the proactive data cache. If the query is successful, the engine immediately reads the data from the cache and calls the underlying rendering library (such as React or Vue.js) to update the UI view. This process is entirely completed locally on the client side and typically takes less than 10 milliseconds. If the query fails, it indicates that the server-side prediction failed to cover the current user intent or that the data has not yet been returned. In this case, the rendering engine triggers a fallback mechanism, instructing the predictive request generation and scheduling module to generate and send a traditional, synchronous data query request based on the current final state of the GUI to ensure the system's functional completeness and data correctness.

[0012] The server-side module group, deployed in a cloud computing environment, constitutes the intelligent core of the entire system. It is responsible for receiving and parsing the client's behavioral sequences, inferring intent, and driving subsequent data prefetching and push processes. The server-side module group includes: an intent prediction service gateway, a user interaction sequence modeling and prediction engine, an active data query generation and execution module, and a result set push and cache synchronization module.

[0013] The intent prediction service gateway is the sole entry point for the client-server prediction service. It is responsible for receiving prediction requests containing UISVs from clients via the persistent communication channel. The gateway first verifies the validity of the request, authenticates the user's identity, and verifies permissions. Upon successful verification, it forwards the UISV and related metadata (such as user ID and session ID) in the request to the core prediction engine and manages the connection status with the client, ensuring smooth data push channels for subsequent transactions.

[0014] The user interaction sequence modeling and prediction engine is the core innovation of this invention, integrating a deep learning model trained on large-scale historical user interaction data. This engine consists of three closely cooperating units: a real-time feature extraction unit, a multi-hypothesis intent inference model unit, and a prediction confidence evaluation unit. Upon receiving the UISV forwarded by the gateway, the real-time feature extraction unit combines the user's historical behavior profiles (e.g., common query patterns, function preferences) stored in the server-side database with the current global user's hot interaction patterns to enhance the UISV's features, generating a richer context-aware sequence vector. The multi-hypothesis intent inference model unit is, at its core, a sequence-to-multi-sequence neural network model based on a gated recurrent unit (GRU) and integrates an attention mechanism. This model takes the enhanced context-aware sequence vector as input, and its output is not a single prediction result, but a probability distribution describing the N most likely final GUI states that the user's current interaction sequence will evolve into. Each predicted final GUI state is a complete set of key-value pairs, precisely defining the final value of all relevant GUI controls. The design of outputting multiple hypotheses is intended to handle the ambiguity of user intent and allow the system to simultaneously prefetch data for multiple high-probability scenarios. The prediction confidence evaluation unit calculates a confidence score for each hypothetical final GUI state output by the model. This score integrates the model's output probability, its match with the user's historical behavior, and the global popularity of the intent. Only final GUI states with a confidence score exceeding a preset dynamic threshold (e.g., an initial value of 0.85, adaptively adjusted based on the system's overall prediction hit rate) are considered valid predicted intents and passed to downstream modules.

[0015] The proactive data query generation and execution module transforms abstract, predictive GUI states into concrete query instructions that can be executed by the backend big data platform. This module receives one or more high-confidence final GUI states from the prediction engine. For each state, it invokes a built-in query language generator, which precisely translates the key-value pair set of the GUI state into the corresponding backend query language, such as Structured Query Language (SQL), Multidimensional Expressions (MDX), or Domain-Specific Query Language (DSL), based on predefined rule templates. After generating the queries, the module submits these proactive queries to the backend big data processing engine (e.g., a distributed SQL query engine like Presto or ClickHouse, or an OLAP engine like Apache Kylin). Simultaneously, the module manages the lifecycle of these executing predictive queries. If subsequent user behavior explicitly negates a prediction (e.g., the user clears all filter conditions), the module immediately sends a cancellation command to the big data processing engine to avoid unnecessary computational resource consumption.

[0016] The result set push and cache synchronization module is responsible for closing the entire prediction-execution-feedback loop. This module continuously monitors the execution status of queries submitted by the proactive data query generation and execution module. Once a query is successfully completed, the module obtains its complete data result set. Subsequently, it recalculates the prediction state hash of the final GUI state associated with that query. Finally, it constructs a data push packet containing this prediction state hash and the serialized data result set, and proactively pushes this packet to the specific client that initiated the prediction request through the persistent communication channel maintained by the intent prediction service gateway. This push behavior is independent of any subsequent requests from the client, ensuring that the data is ready before the user needs it.

[0017] This invention also provides a zero-latency interaction method driven by intent prediction in a cloud computing big data GUI based on the above-mentioned system. The method includes the following steps:

[0018] Step S1: On the client side, the interaction event capture and vectorization module captures the user's continuous interaction events on the GUI in real time, aggregates these events into an interaction sequence, and then converts the interaction sequence into a User Interaction Sequence Vector (UISV) containing timing and context information.

[0019] Step S2: The client's predictive request generation and scheduling module asynchronously sends the generated UISV to the server's intent prediction service gateway through a persistent communication channel, thereby triggering an intent prediction process.

[0020] Step S3: The server-side user interaction sequence modeling and prediction engine receives the UISV, uses its internal deep learning model to make inferences, and generates one or more predictions with confidence scores of the user's final operation intention. Each prediction is specifically represented as a complete final GUI state.

[0021] Step S4: The server filters out the final GUI state predictions with a confidence level higher than a preset threshold, and the proactive data query generation and execution module translates these predicted states into specific big data query instructions. The proactive data query is submitted to the backend big data processing engine for execution. This process is carried out in parallel with the user operation on the client side.

[0022] Step S5: After the query is completed, the server-side result set push and cache synchronization module binds the query result with the corresponding prediction state hash and actively pushes it back to the client through the persistent channel.

[0023] Step S6: The client's proactive data caching and rendering engine receives and stores this pushed data, using the predicted state hash as the key.

[0024] Step S7: When the user's continuous interaction finally stops, the client calculates the final state hash of the current GUI and searches for it in the local active data cache. If a matching data is found (cache hit), the data is read directly from the cache and the GUI interface is updated instantly, completing a zero-latency interaction; if no data is found (cache miss), the backup mechanism is activated and a traditional synchronous data request is sent to obtain the data.

[0025] Compared with the prior art, the beneficial effects of the present invention are reflected in:

[0026] First, this invention predicts user intent and prefetches data, separating the data acquisition process from the synchronous path of user operations, making it a parallel background task. The user-perceived interaction latency is no longer the sum of "network round-trip time + backend processing time," but is reduced to the access time of the client's local memory, decreasing from hundreds or even thousands of milliseconds to sub-tens of milliseconds, providing users with an unprecedentedly smooth and instantaneous response experience.

[0027] Secondly, this invention transforms passive response into proactive prediction. By gaining a holistic understanding of the user's continuous behavior, it effectively avoids executing expensive backend queries for every intermediate step in the user's exploration process. It integrates a series of possible operations into one or a few high-probability final queries, greatly reducing redundant computation and unnecessary network data transmission, thereby lowering server load and operating costs, and improving the throughput of the entire big data platform.

[0028] Third, in the traditional model, frequent "operation-wait" cycles constantly interrupt the user's analytical train of thought, increasing cognitive burden. The seamless interactive environment created by this invention allows users to focus on data exploration and business logic itself, without their thought process being interrupted by technical bottlenecks. This enables more efficient and in-depth data analysis, improving decision-making quality.

[0029] Fourth, the predictive model embedded in this invention can continuously improve its predictive accuracy by learning from the interaction data of all users. The system can automatically adapt to individual user habits, team collaboration patterns, and new analytical paradigms brought about by business evolution, forming a positive feedback loop that makes the interactive experience increasingly intelligent and efficient over time. Attached Figure Description

[0030] The invention will now be further described with reference to the accompanying drawings.

[0031] Figure 1 This is a schematic diagram of the system architecture of the cloud computing big data GUI intent prediction-driven zero-latency interactive system described in this invention.

[0032] Figure 2 This is a structural block diagram of the client module group in the system described in this invention;

[0033] Figure 3 This is a structural block diagram of the server-side module group in the system described in this invention;

[0034] Figure 4 This is a flowchart illustrating the zero-latency interaction method driven by cloud computing and big data GUI intent prediction as described in this invention.

[0035] Figure 5 This is a schematic diagram of the interactive event capture and vectorization process described in this invention;

[0036] Figure 6 This is a schematic diagram illustrating the working principle of the multi-hypothesis intent inference model unit described in this invention;

[0037] Figure 7 This is a schematic diagram of the user interaction sequence modeling and prediction engine in the system described in this invention.

[0038] In the diagram: 100, Client-side module group; 110, Interaction event capture and vectorization module; 120, Predictive request generation and scheduling module; 130, Proactive data caching and rendering engine; 200, Server-side module group; 210, Intent prediction service gateway; 220, User interaction sequence modeling and prediction engine; 221, Real-time feature extraction unit; 222, Multi-hypothesis intent inference model unit; 223, Prediction confidence evaluation unit; 230, Proactive data query generation and execution module; 240, Result set push and cache synchronization module. Detailed Implementation

[0039] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0040] Please see Figures 1 to 7 This invention provides a zero-latency interactive system and method driven by intent prediction for cloud computing and big data GUIs. (See also...) Figure 1 The system is logically divided into a client module group 100 deployed on end-user devices and a server module group 200 deployed in a cloud computing environment. The two exchange data through a persistent, low-latency, bidirectional communication channel, such as WebSocket or gRPC streams based on HTTP / 2, forming a complete closed loop from user behavior capture to proactive data push. The core idea of ​​this system is to transform the traditional passive data acquisition model of "request-response" into a proactive "prediction-prefetching" model. By deeply understanding the user's continuous interactive behavior sequence, it predicts the user's final query opinion and performs data processing in advance, so that the data is ready on the client side when the user completes the operation, thus achieving zero-latency interaction.

[0041] Reference Figure 2 The client module group 100 is responsible for directly perceiving user interactions, structurally representing behavioral sequences, triggering prediction processes, and ultimately achieving a zero-latency experience in the overall system. Specifically, the client module group 100 includes an interaction event capture and vectorization module 110, a predictive request generation and scheduling module 120, and an active data caching and rendering engine 130.

[0042] In one specific embodiment, the interaction event capture and vectorization module 110 is implemented as JavaScript logic embedded in the root component of a front-end application framework (such as React or Vue.js). This module captures all user interaction events non-intrusively by registering global event listeners on the root node of the Document Object Model (DOM). The listened-to event types cover a full range of user actions, specifically including mousedown, mouseup, mousemove, wheel, keydown, keyup, focusin, focusout, dragstart, and dragend. For each captured event, the module immediately instantiates an event description object, which precisely records the core properties of the event. Its data structure can be defined as: { eventType: string; componentId: string; timestamp: number; payload: any;}. Here, `eventType` is a string identifier for the event type, such as 'click'; `componentId` is a unique identifier for the GUI component from which the event originated. This identifier is obtained by traversing the DOM tree and searching upwards for elements with a specific `data-id` attribute to ensure stability; `timestamp` is a high-precision timestamp obtained through `performance.now()`, in milliseconds; and `payload` carries contextual data related to the event. For example, for a `keyup` event of an input field, the payload is the current value of the input field.

[0043] Furthermore, to aggregate discrete event streams into a sequence with analytical value, module 110 internally implements an "interaction burst" detection mechanism based on interaction pause time. This mechanism maintains a timer; when a new event is captured, if the time interval since the previous event is less than a preset threshold (e.g., 150 milliseconds), the current event is appended to the interaction sequence being constructed, and the timer is reset. If the time interval exceeds the threshold, a continuous "interaction burst" is considered to have ended, the currently constructed interaction sequence is treated as a complete input unit, and subsequent vectorization processing is triggered. (Refer to...) Figure 5Vectorization is the process of converting this sequence of event description objects into a two-dimensional numerical tensor, namely the User Interaction Sequence Vector (UISV), whose dimensions are (sequence length, single event vector dimension). Specifically, each event object in the sequence is converted into a numerical vector of a fixed dimension. In a preferred embodiment, the vector is composed of four parts: First, the independent encoding of the GUI component identifier. Assuming there is a predefined dictionary containing 1024 interactive components in the system, this part is a 1024-dimensional vector, where the position corresponding to the component ID index is 1 and the rest are 0; Second, the enumerated integer values ​​of the event type, for example, clicking is mapped to 1, mousemove is mapped to 2, and so on, occupying 1 dimension; Third, the normalized timestamp relative to the sequence start time, calculated by the formula (current_event_timestamp - sequence_start_timestamp) / 5000, where 5000 milliseconds is defined as the maximum duration of an interaction burst, thus scaling the time information to the [0, 1] interval, occupying 1 dimension; Finally, the embedding vector of the payload data. For text or categorical value type payloads, the system uses a pre-trained FastText word embedding model to map it to a 128-dimensional dense vector space. For numerical or coordinate type payloads, normalization is performed directly. In summary, the dimension of a single event vector is 1024 + 1 + 1 + 128 = 1154. An interaction sequence containing 20 events is ultimately transformed into a tensor of shape [20, 1154], which serves as the sole input to trigger backend intent prediction.

[0044] The predictive request generation and scheduling module 120 efficiently and reliably sends the UISV generated by the interaction event capture and vectorization module 110 to the server. Once a complete UISV is generated, module 120 immediately serializes it using Protocol Buffers to minimize data transmission volume. The serialized data is encapsulated in a predictive request message body, which also contains a unique transaction ID in UUID v4 format used to track the entire transaction lifecycle. Subsequently, the module asynchronously sends this predictive request message through a long-lived WebSocket connection established and maintained with the server at application startup. Internally, the module includes a complete connection management logic, including a heartbeat mechanism (e.g., sending a ping frame every 30 seconds) to maintain connection activity, and an automatic exponential backoff reconnection strategy in case of network interruption or server restart. Crucially, the module's triggering is entirely driven by the formation of the interaction sequence, rather than a terminal user action (such as clicking the "Query" button), fundamentally decoupling and parallelizing the user interaction exploration process from the backend data request process.

[0045] The proactive data caching and rendering engine 130 is the final execution unit for achieving a zero-latency experience on the client side. This engine maintains a proactive data cache in key-value pairs in the client's memory. In a specific implementation, this cache is a JavaScript object whose key is the predicted state hash and whose value is the complete data result set pushed from the server. To prevent unlimited memory growth, the cache uses a Least Recently Used (LRU) policy for eviction and has a memory limit of 256MB. The cache key, the predicted state hash, is a deterministic identifier of the final state of the GUI. The generation algorithm is as follows: First, identify and obtain the current values ​​of all GUI controls related to data query on the interface (e.g., marked by specific CSS class names or data-query-source properties), forming a key-value pair array, such as [{key: 'region', value: 'APAC'}, {key: 'product_line', value: 'Electronics'}]; then, sort the array by the lexicographical order of the keys; next, serialize the sorted array into a standard JSON string, such as '{"product_line":"Electronics","region":"APAC"}'; finally, apply the SHA-256 hash algorithm to this string to generate a 64-bit hexadecimal string as the final hash key.

[0046] The engine 130 passively listens for data pushes from the server via a WebSocket connection. Each pushed data packet contains a predicted state hash and a corresponding data result set serialized in Apache Arrow format. Upon receiving the data packet, the engine immediately stores this key-value pair in the active data cache and updates the LRU record. When the user's interaction finally stabilizes (i.e., after the 150-millisecond silence period of interaction burst detection), the rendering engine immediately executes the above algorithm to calculate the final state hash of all relevant GUI controls. Subsequently, it uses this hash as the key to query the active data cache. If the query is successful, it indicates that the server's prediction is accurate and the data has arrived in advance. The engine immediately reads the Arrow format data from the cache and directly converts it into a data structure usable by the front-end rendering library using a zero-copy reader. Then, it calls the API of the underlying rendering library (such as React's setState or Vue's ref.value= ...) to update the UI view. The entire process is completed locally on the client, and the perceived latency from the end of the user operation to the UI update is typically controlled within 10 milliseconds. If the query fails (Cache Miss), it indicates that the prediction failed or the data is still in transit. In this case, to ensure the system's functionality, the engine will activate the fallback mechanism, instructing the predictive request generation and scheduling module 120 to generate and send a traditional, synchronous RESTful API data query request based on the current final state of the GUI, while displaying a temporary loading indicator on the interface until a response is received and rendering is completed.

[0047] Reference Figure 3 The server-side module group 200 constitutes the intelligent decision-making core of the entire system, responsible for learning and inferring user intent from massive amounts of user behavior data, and driving the entire proactive data prefetching process. Specifically, the server-side module group 200 includes an intent prediction service gateway 210, a user interaction sequence modeling and prediction engine 220, a proactive data query generation and execution module 230, and a result set push and cache synchronization module 240.

[0048] The Intent Prediction Service Gateway 210 is the sole communication entry point between the client and the server-side prediction service. In a microservices-based implementation, this gateway is a standalone, high-concurrency Node.js or Go service. It manages tens of thousands of concurrent WebSocket connections, authenticating users and establishing sessions for each newly established connection by parsing the JWT (JSON Web Token) in the initial handshake request. Upon receiving a prediction request containing a UISV from a client, the gateway first performs deserialization and basic validation. Then, it publishes the UISV, along with metadata such as the user ID and tenant ID extracted from the session, to a specific topic in a high-throughput message queue (e.g., Apache Kafka). This asynchronous processing decouples the gateway from the complex backend prediction model, ensuring high availability and scalability. Simultaneously, the gateway maintains a mapping from transaction IDs to client WebSocket connection identifiers (typically stored in a distributed cache like Redis) to ensure that processing results are accurately pushed back to the correct client.

[0049] The user interaction sequence modeling and prediction engine 220 is the core technological innovation of this invention, such as... Figure 7 As shown, it is essentially a large-scale deployed machine learning inference service. The engine consists of three closely cooperating units: a real-time feature extraction unit 221, a multi-hypothesis intent inference model unit 222, and a prediction confidence evaluation unit 223. The real-time feature extraction unit 221, as part of a data preprocessing pipeline, consumes prediction requests from Kafka. For each UISV in the request, it performs feature augmentation. Specifically, based on the user ID in the request, it queries a user profile database (e.g., HBase or Cassandra) for the user's historical behavioral profile, such as the user's most frequently used filter combinations and preferred chart types; these profiles are themselves encoded as feature vectors. Simultaneously, it retrieves the current global user group or the user's team's hotspot interaction patterns from a real-time stream processing system (e.g., Apache Flink), such as the data dimension most frequently queried in the past hour. These additional user-level and group-level feature vectors are concatenated with the original UISV tensor or fused through an attention mechanism to generate a more context-rich augmented sequence vector, which serves as input to subsequent models.

[0050] Reference Figure 6The core of the multi-hypothesis intent inference model unit 222 is a deep neural network model. In a preferred embodiment of the invention, this model employs a sequence-to-multi-sequence architecture integrating a self-attention mechanism. Its encoder consists of a three-layer stacked bidirectional gated recurrent unit (Bi-GRU) network, each layer containing 512 hidden units, responsible for encoding the input augmented sequence vector into a context vector containing rich temporal dependencies. The decoder is an autoregressive Transformer decoder that iteratively generates the components of the final GUI state (i.e., the final value of each relevant control) using the encoder's output and the generated partial predicted states as input. To handle the inherent ambiguity of user intent, the decoder does not employ a greedy strategy in each generation step, but instead uses a beam search algorithm, while retaining N (e.g., N=5) candidate output sequences with the highest probability. Finally, the model outputs a list containing N hypothetical final GUI states, along with the conditional probability corresponding to each hypothetical state. Each final GUI state is a complete set of key-value pairs, precisely defining the predicted final value of all related GUI controls, for example: { "prediction": {"region": "EMEA", "time_range":["2023-01-01", "2023-03-31"]}, "probability": 0.92}. The model is trained using supervised learning on terabytes of historical anonymized user interaction logs, where the input is the first K event sequences of user interactions, and the label is the user's final stable GUI state.

[0051] The prediction confidence evaluation unit 223 is responsible for filtering multiple hypotheses from the model output to determine which predictions are worth investing expensive backend computing resources in. For each hypothetical final GUI state output by the model, this unit calculates a comprehensive confidence score. This score is a weighted average, calculated as: Score = w1 * P_model + w2 * S_history + w3 * T_global. Here, P_model is the probability of the model output; S_history is the similarity score between the predicted state and the user's historical query patterns, obtained by calculating the cosine similarity between the predicted state vector and the historical query template vector stored in the user profile; T_global is the global popularity score of the predicted pattern, reflecting the popularity of the query within the current time window. The weights w1, w2, and w3 (e.g., 0.6, 0.3, and 0.1 respectively) are hyperparameters tuned based on offline evaluation experiments. After calculating the comprehensive confidence score, this unit compares it to a dynamically adjusted threshold. The initial threshold value may be set to 0.85 and adaptively adjusted based on the overall prediction hit rate of the system: if the recent hit rate is higher than the target value (e.g., 90%), the threshold is appropriately lowered to pursue higher coverage; conversely, the threshold is increased to ensure prediction accuracy and reduce resource waste. Only the final GUI state with a confidence score exceeding the current threshold is considered a valid prediction intent and is passed to downstream modules.

[0052] The proactive data query generation and execution module 230 functions as a bridge between the predictive intent and the backend data system. It receives one or more high-confidence final GUI states from the predictive engine. For each state, it invokes a built-in, rule-based query language generator. This generator internally maintains a series of parameterized query templates that map to the IDs of GUI controls and the schemas of backend data tables. For example, a GUI state {"region": "EMEA", "status": ["New", "Processing"]} would be precisely translated into a specific SQL query using the template SELECT ... FROM sales_table WHERE region = ? AND status IN (?): SELECT ... FROM sales_table WHERE region = 'EMEA' AND status IN ('New','Processing'). After generating the queries, this module asynchronously submits these proactive queries to the backend big data processing engine cluster (e.g., a distributed SQL query engine consisting of Presto or ClickHouse) via a database connection pool. Upon submitting a query, this module associates the unique query ID returned by the query engine with the client transaction ID that triggered the query, and stores this association in Redis with a reasonable expiration time (e.g., 5 minutes). This module also has query lifecycle management capabilities. If a new UISV is subsequently received from the same user's session, indicating a change in user intent, the prediction engine may issue a "prediction failure" signal. In this case, the module will locate the previously submitted, incomplete predictive query ID based on the transaction ID and send a cancellation command to the big data processing engine, thereby proactively reclaiming computing resources.

[0053] The result set push and cache synchronization module 240 is responsible for closing the entire prediction-execution-feedback loop. This module continuously monitors the execution status of queries submitted by the proactive data query generation and execution module 230 by polling or subscribing to the query status interface of the big data processing engine. Once a predictive query is detected as successfully completed, the module retrieves its complete data result set from the result storage (e.g., S3). Then, based on the predicted final GUI state associated with the query, it re-invokes the SHA-256 hash algorithm, identical to that used by the client, to calculate the prediction state hash. Next, it efficiently serializes the data result set using Apache Arrow's IPC stream format. Finally, it constructs a data push packet containing the prediction state hash and the serialized data result set. Based on the transaction ID associated with the query, the module retrieves the corresponding client WebSocket connection identifier from Redis and proactively pushes this data packet to the target client via a long-lived connection maintained by the intent prediction service gateway 210. The entire push process is initiated proactively by the server, completely independent of any subsequent client requests, ensuring that the data is ready in the client's cache before the user needs it.

[0054] This invention also provides a zero-latency interaction method based on cloud computing big data GUI intent prediction driven by the above system, referring to... Figure 4The method includes the following steps: Step S1: On the client side, the interaction event capture and vectorization module 110 continuously listens for and captures all user interaction events on the GUI, and aggregates continuous events into an interaction sequence through an interaction burst detection mechanism based on a 150-millisecond silence time, and then converts the interaction sequence into a 1154-dimensional user interaction sequence vector (UISV) containing temporal and contextual information. Step S2: The client-side predictive request generation and scheduling module 120 encapsulates the generated UISV in a Protocol Buffers message body containing a unique transaction ID, and asynchronously sends it to the intent prediction service gateway 210 on the server side through a persistent WebSocket channel, thereby triggering an intent prediction process. Step S3: After receiving the UISV, the server-side user interaction sequence modeling and prediction engine 220 performs feature enhancement by the real-time feature extraction unit 221, and then uses its internal multi-hypothesis intent inference model unit 222 based on Bi-GRU and Transformer to infer and generate a prediction containing N (e.g., N=5) conditional probabilities for the user's final operation intent, each prediction specifically representing a complete final GUI state. Step S4: The prediction confidence assessment unit 223 calculates the comprehensive confidence score of each prediction hypothesis and filters out the final GUI state predictions with scores higher than a dynamically preset threshold (e.g., 0.85), which are then passed downstream. The server-side proactive data query generation and execution module 230 translates these high-confidence prediction states into specific big data query instructions (e.g., SQL) through a built-in query template engine. The proactive data query is asynchronously submitted to the backend big data processing engine (e.g., Presto) for execution. This process is completely parallel to subsequent user operations on the client side. Step S5: After the query is executed, the server-side result set push and cache synchronization module 240 obtains the result set, calculates its corresponding prediction state hash, and packages the hash with the Arrow format serialized result set. It then proactively pushes the result set back to the requesting client via the WebSocket channel. Step S6: The client-side proactive data caching and rendering engine 130 receives and stores this pushed data, using the prediction state hash as the key, and stores it in the local LRU cache. Step S7: When the user's continuous interaction finally stops (silence period exceeds 150 milliseconds), the client calculates the final state hash of the current GUI and searches for it in the local active data cache. If a matching data is found (cache hit), the data is read directly from the cache and the GUI interface is updated instantaneously (less than 10 milliseconds), completing a zero-latency interaction; if no data is found (cache miss), a backup mechanism is activated, and a traditional synchronous data request is sent to obtain the data, ensuring eventual consistency of the function.

[0055] Example

[0056] This embodiment uses a typical business intelligence (BI) analytics platform as an example, where users analyze sales data. The platform's user interface includes three core filtering controls: a drop-down menu for selecting "sales region" (ID: filter_region), a checkbox group for selecting "product line" (ID: filter_prod_line), and a date range selector for specifying "order date" (ID: filter_date_range).

[0057] A user initiates an analysis task. First, the user clicks the "Sales Region" dropdown menu, which expands. The user's mouse hovers over the "North America" ​​option for 120 milliseconds before selecting it. This series of interaction events (mousedown, mousemove, mouseup) is captured by the client's interaction event capture and vectorization module 110, aggregated into an interaction sequence, and quickly converted into a UISV. At this point, the predictive request generation and scheduling module 120 immediately sends this UISV to the server.

[0058] The server-side user interaction sequence modeling and prediction engine 220 receives the UISV. The real-time feature extraction unit 221 queries the user profile and finds that, historically, after selecting the "North America" ​​region, the user has an 85% probability of continuing to analyze the "Consumer Electronics" product line. At the same time, global hotspot data shows that the recent data for "Q4 2023" is the analysis hotspot. Combining this information, the multi-hypothesis intent inference model unit 222 outputs a prediction with a confidence level of 0.95: the final GUI state is { "filter_region": "North America", "filter_prod_line": ["Consumer Electronics"], "filter_date_range": ["2023-10-01", "2023-12-31"]}.

[0059] The prediction passed the confidence assessment. The proactive data query generation and execution module 230 received this status and generated the SQL query: SELECT category, SUM(sales) FROM sales_records WHERE region = 'North America' AND product_line = 'Consumer Electronics' AND order_date BETWEEN '2023-10-01' AND '2023-12-31' GROUP BY category;. This query was submitted to the backend ClickHouse cluster for execution, taking 650 milliseconds.

[0060] While the server executes the query, the client user continues their actions. They move the mouse to the "Product Lines" checkbox group and select "Consumer Electronics." Then, they open the date range selector and choose the fourth quarter of 2023. At the moment they complete their date selection—the final stable state of user interaction—the server-side query has already finished, and the result set (approximately 2.1MB) has been pushed to the client via the result set push and cache synchronization module 240 and stored in the proactive data cache.

[0061] The client-side proactive data caching and rendering engine 130 calculates the final state hash of the current GUI after detecting a pause in user interaction. This hash value exactly matches the key of the data just stored in the cache (cache hit). The engine immediately reads the data from memory and completes the re-rendering of the chart within 8 milliseconds. For the user, the entire process from selecting a date range to seeing the final data chart is instantaneous, without any perceptible waiting.

[0062] Comparative Example

[0063] This is a traditional request-response BI platform using existing technology. The interface and filtering controls are exactly the same as in the previous example, but an "Apply Filter" button has been added.

[0064] The user performed the exact same operations as in the example: selecting "North America" ​​as the "Sales Region," checking "Consumer Electronics" as the "Product Line," and selecting the "Order Date" as the fourth quarter of 2023. After each step, the interface remained unchanged, and the system remained in a waiting state.

[0065] After all filter criteria are set, the user clicks the "Apply Filters" button. At this point, the client collects the current values ​​of all filter controls, constructs a JSON payload, and sends it to the server's ` / api / query` endpoint via an HTTP POST request. The network round-trip time (RTT) is 90 milliseconds.

[0066] After receiving the request, the server parses the JSON payload and generates the exact same SQL query as in the example. The query is then submitted to the ClickHouse cluster for execution, which also takes 650 milliseconds.

[0067] After the query is completed, the server serializes the 2.1MB result set into JSON format and returns it to the client via an HTTP response. Upon receiving the response, the client parses the JSON string and then calls the rendering function to update the chart. From the user clicking the "Apply Filter" button to finally seeing the updated chart, the total time taken is: 90 milliseconds (network request and response) + 650 milliseconds (server query execution) + 55 milliseconds (server JSON serialization and client JSON parsing) = 795 milliseconds. During this time, the user sees a loading indicator, significantly interrupting their analytical flow.

[0068] Data Comparison

[0069] To more intuitively demonstrate the beneficial effects of the technical solution of the present invention, the key performance indicators of the above embodiments and comparative examples are quantitatively compared, and the results are shown in the table below:

[0070] Performance indicators Example (Solution of the Invention) Comparative example (traditional technical solution) Performance improvement rate The user's perceived latency (from the completion of the final operation to the rendering of the interface) 8 milliseconds (local cache read and rendering time) 795 milliseconds (network RTT + server processing + client parsing) 98.99% Server resource utilization rate (prediction hit rate) 95% not applicable - Backup mechanism (synchronous request) trigger rate 5% 100% (System Design) - Total time taken for a single analysis task (from the first interaction to the final result presentation) Approximately equal to the total user operation time Total user operation time + 795 milliseconds Significantly reduced Total network traffic (completing a full analysis) ~2.1MB (a small amount of UISV signaling + one Arrow data push) ~2.1MB (one HTTP request / response) Equal or slightly better Number of interruptions in user cognition 0 times 1 time (waiting after clicking "Apply Filter") 100% Elimination

[0071] As can be seen from the above embodiments, comparative examples, and data comparisons, the cloud computing big data GUI intent prediction-driven zero-latency interactive system and method described in this invention, through its innovative prediction-prefetching mechanism, successfully removes the data acquisition delay from the user's perception path, achieving sub-millisecond instantaneous interactive response, greatly improving user experience and data analysis efficiency. At the same time, by avoiding invalid queries for intermediate exploration steps, it also improves the utilization efficiency of backend computing resources.

[0072] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A zero-latency interactive system driven by cloud computing and big data GUI intent prediction, characterized in that, include: A client module group (100) deployed on end-user devices, and a server module group (200) deployed in a cloud computing environment. The client module group (100) includes: The interaction event capture and vectorization module (110) is configured to capture continuous interaction events of the user on the graphical user interface (GUI) in real time, aggregate the continuous interaction events into an interaction sequence with contextual meaning, and convert the interaction sequence into a user interaction sequence vector representing the user's short-term behavior pattern. The predictive request generation and scheduling module (120) is configured to asynchronously send the user interaction sequence vector to the server module group (200) through a persistent communication channel after the interaction sequence is formed, so as to trigger an intent prediction process. The active data cache and rendering engine (130) is configured to maintain an active data cache for storing a set of data results actively pushed by the server-side module group (200) and corresponding to a predicted state hash; and when the user interaction finally stops, the final state hash of the current GUI is calculated, and the final state hash is used to look up the corresponding set of data results in the active data cache to complete the interface rendering. The server-side module group (200) includes: The intent prediction service gateway (210) is configured to receive a prediction request containing the user interaction sequence vector from the client module group (100) via the persistent communication channel. The user interaction sequence modeling and prediction engine (220) is configured to receive the user interaction sequence vector and make inferences based on a deep learning model to generate one or more predictions of the user's final operation intention, wherein each prediction represents a complete final GUI state. The proactive data query generation and execution module (230) is configured to translate the high-confidence final GUI state generated by the user interaction sequence modeling and prediction engine (220) into a specific query instruction that can be executed by the backend big data platform, and submit it for execution; The result set push and cache synchronization module (240) is configured to obtain the data result set after the specific query instruction is executed, calculate the predicted state hash associated with the final GUI state, bind the data result set with the predicted state hash, and actively push it to the client module group (100) through the persistent communication channel.

2. The zero-latency interactive system driven by cloud computing and big data GUI intent prediction according to claim 1, characterized in that, The interactive event capture and vectorization module (110) is specifically configured to continuously listen to interactive events on the GUI, including mouse clicks, mouse movements, scroll wheel scrolling, keyboard input, control focus acquisition and loss, and the start and end of drag operations; Record the core attributes of each captured event, including the event type identifier, the unique identifier of the event source GUI component, the precise timestamp when the event occurred, and the payload data associated with the event; Furthermore, an interaction burst detection mechanism based on the interaction pause time is set up. When the interval between two consecutive interaction events exceeds a preset time threshold, it is determined that an interaction burst has ended, thereby aggregating the consecutive events captured within this time threshold into the interaction sequence.

3. The zero-latency interactive system driven by intent prediction in a cloud computing big data GUI according to claim 2, characterized in that, When the interaction event capture and vectorization module (110) converts the interaction sequence into a user interaction sequence vector, it is specifically used for: Each event in the interaction sequence is converted into a fixed-dimensional numerical vector. The numerical vector is composed of an independent encoding of the unique identifier of the event source graphical user interface component, an enumerated integer value of the event type identifier, a normalized timestamp relative to the start time of the interaction sequence, and an embedding vector of the payload data. The embedding vector is generated by a pre-trained hash-based embedding function or word embedding model. Stack the numerical vectors corresponding to all events in the interaction sequence to form a two-dimensional tensor with the sequence length and the dimension of the single event vector as the dimensions, which serves as the user interaction sequence vector.

4. The zero-latency interactive system driven by intent prediction in a cloud computing big data GUI according to claim 1, characterized in that, The active data caching and rendering engine (130) is specifically used for: The active data cache follows a least recently used strategy for cache replacement and has a fixed memory limit. The predicted state hash and the final state hash are generated by a deterministic hash generation algorithm, which includes the following steps: obtaining the current values ​​of all graphical user interface controls related to data query on the interface, sorting the key-value pairs of these controls in lexicographical order by key name, serializing the sorted key-value pairs into a standard string, and applying the SHA-256 hash algorithm to the string; When a query using the final state hash fails in the active data cache, a backup mechanism is activated. The backup mechanism instructs the predictive request generation and scheduling module (120) to generate and send a traditional synchronous data query request based on the current graphical user interface final state.

5. A zero-latency interactive system driven by intent prediction in a cloud computing and big data GUI according to claim 1, characterized in that, The user interaction sequence modeling and prediction engine (220) include: The real-time feature extraction unit (221) is used to enhance the features of the user interaction sequence vector after receiving the user interaction sequence vector, and generate a context-aware sequence vector by combining the user's historical behavior profile stored in the server-side database and the current global user hotspot interaction mode. The multi-hypothesis intent inference model unit (222) is used to take the context-aware sequence vector as input and output the probability distribution of N final graphical user interface states that the interaction sequence is most likely to evolve into, where each final graphical user interface state is a complete set of key-value pairs that define the final values ​​of all relevant graphical user interface controls. The prediction confidence assessment unit (223) is used to calculate the confidence score for each hypothetical final graphical user interface state output by the multi-hypothesis intention inference model unit (222) and filter out the final graphical user interface states whose confidence scores exceed a preset dynamic threshold.

6. A zero-latency interactive system driven by intent prediction in a cloud computing big data GUI according to claim 5, characterized in that, The core of the multi-hypothesis intention inference model unit (222) is a deep neural network model, which adopts a sequence-to-multi-sequence architecture; The encoder part of the model consists of a multi-layered stacked bidirectional gated recurrent unit network, used to encode the context-aware sequence vector into a context vector; The decoder part of the model is an autoregressive Transformer decoder. During the decoding process, a beam search algorithm is used to retain N highest probability candidate output sequences in each generation step to generate the N final graphical user interface states.

7. A zero-latency interactive system driven by intent prediction for a cloud computing big data GUI according to claim 5, characterized in that, The confidence score calculated by the prediction confidence assessment unit (223) is a comprehensive score, obtained by weighted averaging of the following three items: The multi-hypothesis intention inference model unit (222) outputs the model probability corresponding to the hypothetical final graphical user interface state; The similarity score between the hypothetical final graphical user interface state and the historical query patterns stored in the user's historical behavior profile; The global popularity score of the query pattern represented by the hypothetical final graphical user interface state; The preset dynamic threshold is adaptively adjusted based on the overall prediction hit rate of the system.

8. A zero-latency interactive system driven by intent prediction for cloud computing and big data GUI according to claim 1, characterized in that, The active data query generation and execution module (230) is specifically used for: A built-in query language generator translates the key-value pair set of the final graphical user interface state into a structured query language, a multidimensional expression, or a domain-specific query language based on a predefined graphical user interface control identifier and backend data table schema mapping rule template. Predictive queries submitted to the backend big data platform are subject to lifecycle management. When a new user interaction sequence vector indicating a change in user intent is received, a cancellation command is sent to the backend big data platform to terminate the execution of unfinished queries related to previous predictions in order to avoid unnecessary consumption of computing resources.

9. A zero-latency interactive system driven by intent prediction for a cloud computing big data GUI according to claim 1, characterized in that, The persistent communication channel is a persistent, low-latency, bidirectional communication channel established between the client and the server. The predictive request generation and scheduling module (120) asynchronously sends the user interaction sequence vector to the server through the bidirectional communication channel; The result set push and cache synchronization module (240) uniquely identifies the client that passively receives the push data through the bidirectional communication channel, and actively pushes the data result set and prediction state hash to the client. The bidirectional communication channel is a WebSocket or a gRPC stream based on HTTP / 2.

10. A zero-latency interaction method driven by intent prediction for a cloud computing big data GUI, applicable to the zero-latency interaction system driven by intent prediction for a cloud computing big data GUI as described in any one of claims 1-9, characterized in that, Includes the following steps: Step S1: On the client side, the interaction event capture and vectorization module (110) captures the user's continuous interaction events on the GUI in real time, aggregates the events into an interaction sequence, and converts the interaction sequence into a user interaction sequence vector; Step S2: The predictive request generation and scheduling module (120) of the client asynchronously sends the user interaction sequence vector to the intent prediction service gateway (210) on the server side through a persistent communication channel to trigger an intent prediction process; Step S3: On the server side, the user interaction sequence modeling and prediction engine (220) receives the user interaction sequence vector, uses its internal deep learning model to make inferences, and generates one or more predictions of the user's final operation intention with confidence scores, wherein each prediction specifically represents a complete final GUI state. Step S4: The server filters out the final GUI state predictions with a confidence level higher than a preset threshold, and the active data query generation and execution module (230) translates the predicted state into specific big data query instructions and submits them to the backend big data processing engine for parallel execution; Step S5: After the query is completed, the result set push and cache synchronization module (240) on the server side binds the query result with the corresponding predicted state hash and actively pushes it back to the client through the persistent channel; Step S6: On the client side, the active data cache and rendering engine (130) receives and stores the pushed data in an active data cache using the predicted state hash as the key; Step S7: When the user's continuous interaction finally stops, the client calculates the final state hash of the current GUI and searches for it in the active data cache. If a matching data is found, the data is read directly from the cache and the GUI interface is updated instantly, completing a zero-latency interaction. If no matching data is found, the backup mechanism is activated and a traditional synchronous data request is sent to obtain the data.