A method for instant recognition trigger of desktop chat

Abstract

The application relates to the field of Internet interaction technology and provides a desktop chat instant identification triggering method, which comprises the following steps: periodically sensing a desktop foreground window, judging whether a target chat window exists or not, and controlling the display or hiding of a floating entry according to the judgment; in response to the clicking operation of a user on the floating entry, creating a floating identification triggering session, recording current window binding information, filling in a non-sending mark only, and inhibiting repeated triggering; performing screenshot, chat content identification and reply generation according to the chat window bound by the triggering session, obtaining generated reply text; and filling in the generated reply text into an input box of the chat window only, without performing an automatic sending operation. The application can effectively avoid the risks of mis-triggering and mis-sending while reducing the switching cost of the intelligent reply operation of the desktop chat.

Description

Technical Field

[0001] This invention relates to the field of Internet interaction technology, and in particular to a method for real-time recognition and triggering of desktop chat. Background Technology

[0002] In desktop office scenarios, instant messaging tools have become a core channel for enterprise communication. Users need to handle a large number of chat messages every day, and the frequent writing of replies significantly affects work efficiency. To address this, intelligent desktop chat reply systems have emerged. These systems help users respond to messages quickly by taking screenshots of chat windows, recognizing chat content using OCR, searching knowledge bases, and combining them with large models.

[0003] In the typical workflow of existing desktop chat intelligent reply systems, the user first reads the message in the target chat window, then switches to the main window of the intelligent reply tool, clicks the recognition button, waits for the system to complete screenshotting, recognition, knowledge retrieval, and reply generation, and finally switches back to the chat window to send the reply. While this workflow reduces the cost of writing replies to some extent, it still has the following shortcomings in high-frequency communication scenarios:

[0004] First, the trigger entry point is separated from the chat context. Smart reply tools usually exist in an independent main window, requiring users to repeatedly switch between the chat window and the tool window. This operation path is long, disrupts the continuity of the chat scene, and reduces usage efficiency.

[0005] Second, a persistent floating entry can easily interfere with desktop operations. Some solutions attempt to shorten the operation path by using a persistent floating button, but this floating entry is always visible on the desktop, which can obscure the interface content of non-chat applications, and users may accidentally trigger the recognition in the wrong window, resulting in the recognition target not matching the expectation.

[0006] Third, ordinary floating buttons lack the ability to bind to a target window. When a floating entry is clicked, if the system has not recorded the handle of the current foreground chat window, it may use the previously bound old window for screenshotting and recognition, resulting in the reply content being inconsistent with the conversation the user is currently processing.

[0007] Fourth, repeated clicks can easily lead to concurrent recognition. Screenshotting, OCR, knowledge retrieval, and large model generation are usually time-consuming. If a user clicks the floating entry point continuously during the recognition process, multiple concurrent recognition tasks may be launched simultaneously, causing system state chaos, wasted resources, and even overlapping of response content.

[0008] Fifth, automatic sending carries the risk of accidental sending. Some solutions automatically send replies after they are generated, and floating entry points are usually placed next to the chat window. If a click is accidentally made or the recognition result does not match the current conversation, an incorrect reply may be sent directly to the other party, causing a communication accident.

[0009] Sixth, there is a lack of traceable entry points for failure states. When a model is not configured, a session is blocked by a policy, generation fails, or the response is empty, users cannot find out the specific reason for the failure from the floating entry point, nor do they have a convenient way to return to the main window to view logs, configurations, or hit details, which affects problem localization and system availability.

[0010] Chinese patent CN120935132A discloses a conversation processing method. This method extracts chat content and generates response suggestions non-intrusively by automatically taking screenshots, performing object detection, and using OCR recognition on the customer service chat window. Its core focus is on solving the problem of automatically acquiring chat content in the absence of an interface, rather than user-triggered instant recognition and secure data entry control. However, it lacks a floating interactive entry point, cannot be triggered by users on demand, lacks window binding and anti-repeated triggering mechanisms, and does not include a security control that only allows data entry without sending. Furthermore, the automatic screenshot strategy suffers from resource waste and a conflict between timeliness and efficiency.

[0011] In summary, existing technologies urgently need a desktop chat real-time recognition triggering method that can combine floating entry with foreground window awareness, target window binding, trigger session state management, repeated trigger suppression, and secure input control, so as to effectively avoid the risks of accidental triggering and accidental sending while reducing operation switching costs. Summary of the Invention

[0012] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a method for real-time identification and triggering of desktop chat.

[0013] This invention provides a method for real-time recognition and triggering in desktop chat, the method comprising:

[0014] Step S1: By periodically sensing the desktop foreground windows, determine whether a target chat window exists, and control the display or hiding of the floating entry accordingly;

[0015] Step S2: In response to the user's click on the floating entry, create a floating recognition trigger session, record the current window binding information and the "fill in but do not send" flag, and suppress repeated triggering;

[0016] Step S3: Based on the chat window that triggered the session, perform screenshotting, chat content recognition, and reply generation to obtain the generated reply text;

[0017] Step S4: Simply fill the generated reply text into the input box of the chat window without performing the automatic send operation.

[0018] Optionally, in the desktop chat instant recognition triggering method of the present invention, step S1 controls the display or hiding of the floating entry in the following manner:

[0019] When the desktop foreground window is the floating entry itself, keep the floating entry displayed in the corresponding position of the previously bound target chat window;

[0020] When the desktop foreground window matches the target chat application, a floating entry is displayed and bound to that window;

[0021] When the desktop foreground window does not match the target chat application, scan all candidate chat windows and select the target window according to priority. If there are no candidate windows, hide the floating entry.

[0022] Optionally, in the desktop chat instant recognition triggering method of the present invention, the floating entry in step S2 is a top-mounted transparent window control that supports user dragging and moving. After dragging, the position is saved to the configuration file. Each time it is displayed, the saved position is read and screen boundary clamping is performed to ensure that the floating entry is fully displayed in the visible area of ​​the screen.

[0023] Optionally, in the desktop chat instant recognition triggering method of the present invention, the floating entry in step S2 maintains a state object, which includes at least an idle state, a recognition in progress state, a success state, a warning state, and a failure state; in the idle state, it responds to click operations; in the recognition in progress state, it rejects new clicks and displays a recognition in progress prompt; in the success, warning, or failure states, it allows opening the main window to view details.

[0024] Optionally, in the desktop chat instant recognition triggering method of the present invention, in step S2, the current window binding information is recorded in the following manner: it is determined whether the window handle passed when clicking matches the target chat application; if it matches, the window is bound; if it does not match, the already bound window is used or the manual binding process is triggered; after successful binding, the chat window is activated, and it is checked whether the current session is blocked by a blacklist or policy; if it is blocked, the session is ended and updated to the blocked state.

[0025] Optionally, in the desktop chat instant recognition triggering method of the present invention, in step S2, repeated triggering is suppressed in the following manner: when creating a floating recognition triggering session, if an existing triggering session that has not yet been terminated is detected, the current click will not create a new session or start a new recognition process, but only update the floating entry to a recognition prompt; the stages of the triggering session include the binding stage, screenshot stage, generation stage, filling stage, completion stage, interception stage and failure stage, wherein completion, interception and failure are termination states.

[0026] Optionally, in the desktop chat instant recognition triggering method of the present invention, in step S3, the floating entry calls the main workflow interface with a floating path identifier, so that the main workflow does not automatically send the reply after generating it; when any operation of screenshot, chat content recognition and reply generation fails, the failure stage is recorded and the floating entry is updated to the corresponding failure or warning status.

[0027] Optionally, in the desktop chat instant recognition triggering method of the present invention, step S4, the method of only filling in text without automatically sending is implemented as follows: the generated reply text is written to the clipboard; the bound chat window is activated and the input box is positioned; the paste shortcut key is sent to complete the text filling; the Enter key signal or the newline key signal is forcibly not sent; the only filling in text is recorded as true in the event data; after successful filling in, the floating entry displays the success status and switches back to the idle status, and the user decides whether to send the text after manual confirmation.

[0028] Optionally, in the desktop chat instant recognition triggering method of the present invention, the floating entry is displayed in the following manner:

[0029] When the generated reply text is empty, the floating entry will display a no reply status;

[0030] When the policy rules determine that sending is not allowed, the status will be displayed as blocked;

[0031] When a model configuration is missing, a configuration requirement will be displayed and a click will open the settings page.

[0032] When a screenshot, generation, or input operation fails, a failure status is displayed, and the main window is opened to view at least one of the following information: the trigger session record, execution log, identification result, hit knowledge document, and error details.

[0033] Optionally, in the desktop chat instant recognition triggering method of the present invention, the floating entry runs in an independent thread, isolated from the recognition workflow thread of the main window, and the triggering, status update and filling operations of the floating entry do not block other functions of the main window.

[0034] The desktop chat instant recognition triggering method of the present invention has the following beneficial technical effects:

[0035] I. Reduce operation switching costs

[0036] By displaying a floating entry point in the context of the foreground chat window, users can trigger the recognition operation without leaving the chat window, avoiding repeated switching between the chat window and the main window of the smart reply tool, significantly shortening the operation path and improving the efficiency of use in high-frequency communication scenarios.

[0037] II. Reduce desktop distractions

[0038] The display of the floating entry is controlled by the foreground window perception mechanism. It only appears when the target chat window is in the foreground or when there is a recognizable candidate window. It is automatically hidden in non-chat application scenarios to avoid the persistent floating button from obscuring and interfering with other applications on the desktop.

[0039] III. Improve the consistency of the target window

[0040] When a user clicks the floating entry, a trigger session is established, and the handle of the current foreground chat window is recorded and bound in real time. This ensures that the screenshot and recognition operations are always targeted at the session window that the user is currently processing, avoiding the problem of inconsistent recognition objects with expectations due to the use of old bound windows.

[0041] IV. Avoid repeated triggering

[0042] By using the state object of the floating entry and the active state judgment mechanism of the triggered session, when the floating entry is clicked again during the recognition process, a new recognition task will not be started and a recognition prompt will be displayed, which effectively prevents concurrent recognition, state confusion and resource waste caused by continuous clicks.

[0043] V. Reduce the risk of false positives

[0044] The system enforces a "fill-in only, no automatic sending" security control mode, which only pastes the generated reply text into the chat input box and does not automatically send it by pressing the Enter key or line break key. This retains the user's manual confirmation step and effectively avoids the risk of incorrect replies being sent directly due to recognition errors, session mismatches, or accidental touches.

[0045] VI. Clear status feedback

[0046] The floating entry has a built-in status object that can intuitively display various statuses such as idle, recognizing, successful, filled, blocked, no reply, configuration required, and failed. Users can know the current recognition and filling results without opening the main window, improving the system's understandability and ease of use.

[0047] VII. Facilitates problem tracing

[0048] The session triggers a complete record of window binding information, execution stages, and failure details during the recognition process. In case of abnormal situations such as interception, failure, or missing configuration, users can directly open the main window through the floating entry to view logs, recognition results, hit knowledge documents, and error details, which facilitates quick location and resolution of problems.

[0049] 8. Reuse existing identification links

[0050] The floating entry is only responsible for window perception, trigger control, and secure data entry. It does not reimplement algorithms such as screenshot recognition, OCR, chat context parsing, knowledge retrieval, and reply generation. It fully reuses the existing workflow of the desktop chat intelligent reply system, ensuring the consistency of recognition results and reducing the complexity and maintenance cost of system implementation. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating the desktop chat instant recognition triggering method according to an exemplary embodiment 1 of the present invention;

[0053] Figure 2 This is a flowchart illustrating the process of controlling the display or hiding of a floating entry point in a desktop chat instant recognition triggering method according to an exemplary embodiment 1 of the present invention.

[0054] Figure 3 This is a flowchart illustrating the process of dragging and controlling the floating entry point in the desktop chat instant recognition triggering method according to Exemplary Embodiment 1 of the present invention.

[0055] Figure 4 A flowchart illustrating the process of maintaining state objects for the desktop chat real-time identification triggering method according to Exemplary Embodiment 1 of the present invention;

[0056] Figure 5 This is a flowchart illustrating the desktop chat real-time identification triggering method for recording current window binding information according to Exemplary Embodiment 1 of the present invention;

[0057] Figure 6 This is a flowchart illustrating the method for suppressing repeated triggering in real-time desktop chat recognition according to an exemplary embodiment 1 of the present invention. Detailed Implementation

[0058] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0059] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0060] It should be noted that various aspects of the embodiments described below are within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0061] Example 1

[0062] Exemplary embodiment 1 of the present invention provides a method for real-time recognition and triggering of desktop chat. Figure 1 This is a flowchart illustrating the desktop chat real-time identification triggering method according to Exemplary Embodiment 1 of the present invention, as follows: Figure 1 As shown, in this embodiment, the method of the present invention is implemented in the following manner.

[0063] Step S1: By periodically sensing the desktop foreground windows, determine whether a target chat window exists, and control the display or hiding of the floating entry accordingly.

[0064] Figure 2 This is a flowchart illustrating the process of controlling the display or hiding of a floating entry point in a desktop chat real-time recognition triggering method according to an exemplary embodiment 1 of the present invention. Figure 2 As shown, in this embodiment, the display or hiding of the floating entrance is controlled in the following manner:

[0065] When the desktop foreground window is the floating entry itself, keep the floating entry displayed in the position corresponding to the previously bound target chat window; when the desktop foreground window matches the target chat application, display the floating entry and bind it to the window; when the desktop foreground window does not match the target chat application, scan all candidate chat windows and select the target window according to priority, and hide the floating entry if there are no candidate windows.

[0066] Step S2: In response to the user's click on the floating entry, create a floating recognition trigger session, record the current window binding information and the "fill in but do not send" flag, and suppress repeated triggering.

[0067] Figure 3 This is a flowchart illustrating the process of dragging and controlling a floating entry point in the desktop chat real-time recognition triggering method according to Exemplary Embodiment 1 of the present invention. Figure 3As shown, in this embodiment, the floating entrance is a top-mounted transparent window control that supports user dragging and moving. After dragging, the position is saved to the configuration file. Each time it is displayed, the saved position is read and screen boundary clamping is performed to ensure that the floating entrance is fully displayed in the visible area of ​​the screen.

[0068] In this embodiment, the floating inlet maintains a state object. Figure 4 A flowchart illustrating the process of maintaining a state object in the desktop chat real-time identification triggering method according to Exemplary Embodiment 1 of the present invention is shown below. Figure 4 As shown, the status object includes at least the idle state, the recognition state, the success state, the warning state, and the failure state; in the idle state, it responds to click operations; in the recognition state, it rejects new clicks and displays a recognition prompt; in the success, warning, or failure states, it allows opening the main window to view details.

[0069] Figure 5 This is a flowchart illustrating the process of recording current window binding information in the desktop chat real-time recognition triggering method according to Exemplary Embodiment 1 of the present invention, as follows: Figure 5 As shown, in this embodiment, the current window binding information is recorded in the following way: it is determined whether the window handle passed when clicking matches the target chat application. If it matches, the window is bound; if it does not match, the already bound window is used or the manual binding process is triggered; after successful binding, the chat window is activated, and it is checked whether the current session is blocked by a blacklist or policy. If it is blocked, the session is ended and updated to the blocked state.

[0070] Figure 6 This is a flowchart illustrating the method for suppressing repeated triggering in real-time desktop chat recognition according to Exemplary Embodiment 1 of the present invention, as follows: Figure 6 As shown, in this embodiment, repeated triggering is suppressed in the following way: when creating a floating recognition trigger session, if an existing trigger session that has not yet been terminated is detected, the current click will not create a new session or start a new recognition process, but will only update the floating entry to a recognition prompt; the stages of the trigger session include the binding stage, screenshot stage, generation stage, filling stage, completion stage, interception stage and failure stage, where completion, interception and failure are the termination states.

[0071] Step S3: Based on the chat window that triggered the session, perform screenshot, chat content recognition and reply generation to obtain the generated reply text.

[0072] In this embodiment, the floating entry calls the main workflow interface with a floating path identifier, so that the main workflow does not automatically send the reply after it generates it; when any operation of screenshot, chat content recognition and reply generation fails, the failure stage is recorded and the floating entry is updated to the corresponding failure or warning status.

[0073] Step S4: Simply fill the generated reply text into the input box of the chat window without performing the automatic send operation.

[0074] In this embodiment, the method of only filling in text without automatic sending is implemented as follows: the generated reply text is written to the clipboard; the bound chat window is activated and the input box is positioned; the paste shortcut key is sent to complete the text filling; the Enter key signal or line break key signal is forcibly not sent; the only filling in text is recorded as true in the event data; after successful filling in, the floating entry displays the success status and switches back to the idle status, and the user decides whether to send it after manual confirmation.

[0075] It should be noted that in this embodiment, the floating entrance is displayed in the following manner:

[0076] When the generated reply text is empty, the floating entry will display a no reply status;

[0077] When the policy rules determine that sending is not allowed, the status will be displayed as blocked;

[0078] When a model configuration is missing, a configuration requirement will be displayed and a click will open the settings page.

[0079] When a screenshot, generation, or input operation fails, a failure status is displayed, and the main window is opened to view at least one of the following information: the trigger session record, execution log, identification result, hit knowledge document, and error details.

[0080] In this embodiment, the floating entry runs in an independent thread, isolated from the recognition workflow thread of the main window. The triggering, status updating and filling operations of the floating entry do not block other functions of the main window.

[0081] In a specific engineering implementation, the method of this embodiment is supported by the following code structure:

[0082] 1. src / ddtalk / floating_ball.py

[0083] default_ball_position(): Calculates the default floating entry position;

[0084] clamp_ball_position(): Performs a boundary clamp on the dragged position;

[0085] FloatingBallState: Describes states such as idle, processing, success, warning, and error;

[0086] FloatingRecognitionSession: Records the trigger window, foreground window, bound target, only fill in the tag, stage and details;

[0087] FloatingRecognitionBall: Creates a small transparent window that stays on top, supporting display, hiding, dragging, state rendering, and click triggering.

[0088] 2.src / ddtalk / ui.py

[0089] _poll_floating_ball_visibility(): Periodically detects the foreground window and controls the display and hiding of the floating entry;

[0090] _select_floating_lanxin_window(): Selects the current target chat window from the candidate windows;

[0091] _start_floating_session(), _update_floating_session(), _finish_floating_session(): Maintain the floating-triggered session;

[0092] _generate_and_paste_from_floating_ball(): After clicking the floating entry point, bind the window, take a screenshot, and execute the generated link;

[0093] _start_floating_reply_paste(): Generates a reply by filling in only the input field if the sender is marked as no by pressing Enter;

[0094] The floating_workflow_success, floating_workflow_error, floating_paste_success, and floating_paste_error functions in _pump_events() update the session phase and floating state based on the results.

[0095] 3.src / ddtalk / sender.py

[0096] send_text(): Supports pasting text into a specified window, and controls whether to send it by pressing Enter to send the text;

[0097] When calling this method via a floating path, the send flag is always set to "No".

[0098] 4. Test Cases

[0099] tests / test_floating_ball.py overrides the default position, boundary grabbing, state object, and triggering session phase;

[0100] The tests / test_ui.py file covers foreground window display / hide, candidate window selection, hover trigger generation, anti-duplicate session, policy interception, and input-only without automatic sending.

[0101] Example 2

[0102] Exemplary embodiment 2 of the present invention provides a real-time identification triggering method for desktop chat. In this embodiment, instead of displaying a button on the desktop, a floating entry is deeply integrated with foreground window identification, target window binding, trigger session state, repeated triggering suppression, screenshot identification link and security control mechanism of filling in but not sending, to form a set of real-time identification triggering methods suitable for desktop chat scenarios.

[0103] Specifically, the method of the present invention is implemented in this embodiment as follows:

[0104] Step 1: Periodic Sensing of the Foreground Window

[0105] The background periodically retrieves the handle of the current foreground root window; determines whether the window matches the target chat application; if the current foreground window belongs to the floating entry itself, it keeps the floating entry bound to the previous target chat window; if the foreground window is not the target chat window, it scans desktop chat candidate windows and selects the already bound window, the window with the matching title, or the candidate window with the largest area; if no available chat window is found, the floating entry is hidden.

[0106] Step 2: Floating entrance display and position control

[0107] When the target chat window is in the foreground or can be identified as a candidate window, a transparent floating entry is displayed at the top;

[0108] The floating entry point supports dragging. After dragging, the position is saved to the configuration. It will be displayed at the saved position on the next startup and will be clamped to the screen boundary to prevent the entry point from going off-screen.

[0109] Step 3: State the Suspended Inlet

[0110] The floating entry maintains a status object, including at least the following states: Idle, Recognizing, Success, Warning, Failure, and Details that can be opened. The Idle state allows clicks to trigger; the Recognizing state prevents repeated triggering; the Success, Warning, and Failure states provide feedback on the execution result through text, color, or badges; the Warning or Failure state allows opening the main window to view details or configuration.

[0111] Step 4: Trigger the creation of the session object

[0112] When a user clicks the floating entry, a floating recognition trigger session is established. The trigger session records the trigger window handle, the current foreground window handle, the bound target, whether to fill in without sending, the current stage, the selected window handle, and the stage description. The current stage includes at least binding, screenshot, generation, filling, completion, interception, and failure. If there is already an activity trigger session, the new click will only show that recognition is in progress and will not start a new recognition task.

[0113] Step 5: Bind the current chat window

[0114] If the window handle passed in when clicking matches the target chat application, the window information is obtained based on the handle and bound to the current chat window; if the foreground window cannot be confirmed, the currently bound window is used or the user is prompted to bind it manually; the chat window is activated after successful binding; before performing recognition, it is checked whether the current session is in the blacklist or policy blocking range.

[0115] Step Six: Reuse Identification and Link Generation

[0116] Take a screenshot of the bound chat window; invoke the existing screenshot recognition, chat context parsing, knowledge retrieval and reply generation chain; use the generated but not automatically sent mode for the floating path; when the generation process fails, record the failure stage and update the floating entry status.

[0117] Step 7: Fill in the security control information (but do not send it automatically)

[0118] When the generated result is allowed by the policy and the reply is not empty, the filling stage begins; the text sending module is called to paste the reply text into the bound chat window; when pasting, it is forced to not press Enter to send; the event data is explicitly recorded to only fill in the mark as true; after the generated reply is filled into the input box, the user manually confirms whether to send it.

[0119] Step 8: Control of Result Status and Details Entry

[0120] If a reply has been entered, the floating entry will display a success status and automatically return to idle; if the policy does not allow sending, it will display an intercepted status; if the reply is empty, it will display a no reply status; if the model configuration is missing, it will display a configuration required status and open the settings page; if the screenshot, generation, or entry fails, it will display a failure status and allow the user to open the main window to view the logs.

[0121] Through the above steps, this embodiment enables desktop chat users to trigger instant recognition without leaving the chat window. At the same time, it reduces the risk of false triggering and false sending through window awareness, stateful anti-re-entry, and a fill-in-only-not-send mechanism.

[0122] Example 3

[0123] Exemplary embodiment 3 of the present invention provides a method for real-time identification and triggering of desktop chat. This embodiment further describes the method of the present invention in a specific scenario.

[0124] In this embodiment, the target chat application is BlueMessage. The system corresponding to the method in this embodiment runs on a Windows desktop environment and maintains the binding status of the main window, floating entry, and chat window in the background.

[0125] In this embodiment, the method of the present invention is implemented according to the following steps:

[0126] Step 1: Initialize the floating entrance

[0127] The system reads the floating entry's enabled status and last saved position from the configuration. If the floating entry is enabled, a small, transparent window is created at the top as the floating entry. If a position already exists in the configuration, that position is used; otherwise, the entry is placed near the center right side of the screen. To prevent the entry from being dragged off-screen, the system uses boundary clamping based on the screen's width and height and the entry's dimensions when calculating its position. After dragging, the system saves the new coordinates to the configuration.

[0128] Step 2: Polling the front-end window

[0129] The system performs a polling of the foreground window at a fixed period. During each polling:

[0130] Obtain the handle of the current foreground root window; determine if the foreground window is the floating entry itself; if it is the floating entry itself and there is already an active target window, continue to display the floating entry for that target window; if the foreground window matches the target chat application, record that window as the active target window and display the floating entry; if the foreground window does not match, scan all target chat candidate windows; when selecting candidates, prioritize the currently active window, the bound window, and the window whose title contains the target application name; if there are still multiple candidates, select the main window with the largest area; if there are no candidates, hide the floating entry. This step ensures that the floating entry mainly appears near the chat context, rather than persistently interfering with other desktop applications.

[0131] Step 3: State Object Drives Floating Entry

[0132] In this embodiment, the floating entry point is displayed using a state object. The state object includes:

[0133] Display text: The entry center displays text;

[0134] Type: Status type, such as idle, processing, success, warning, error;

[0135] Processing status: Whether identification is currently being performed;

[0136] Click the "Open Details" marker: Click or right-click to open the details.

[0137] The idle state displays "Recognizing" and allows clicking; the busy state displays "Recognizing" and prevents repeated triggering; the action state, such as "Configuration Required", "Blocked", and "Failed", allows you to open the main window to view details.

[0138] Step 4: Trigger the session object

[0139] When a user clicks the floating entry, the system creates a floating recognition trigger session. The trigger session records the following:

[0140] Trigger window handle: The handle of the target window to which the floating entry is bound when clicked;

[0141] Foreground window handle: The handle of the foreground window read by the system when clicked;

[0142] Target binding: Target chat application;

[0143] Enter only the tag: Whether to enter only the tag and not send automatically;

[0144] Selected window handle: The chat window handle ultimately used for screenshotting and input;

[0145] Stage: Current stage;

[0146] Phase Description: Phase Description;

[0147] Trigger time: Trigger time.

[0148] The stages of triggering a session include: created, bound, screenshotted, generated, filled in, completed, intercepted, and failed. Completed, intercepted, and failed are terminated states. If a non-terminated triggering session is detected, the system will not restart the recognition task, but will update the floating entry to a "Recognizing" prompt.

[0149] Step 5: Click Trigger and Window Binding

[0150] When a user clicks the floating entry, the system first checks if there is already an active session or the main workflow is being executed. If a task is already running, it will not be started again.

[0151] If startup is allowed, the system enters the binding phase. The binding logic is as follows:

[0152] The floating path target is fixed to BlueMessage; if the passed window handle matches BlueMessage, information such as the window title and process are obtained based on the handle; this window is applied as the currently bound chat window; if the passed window cannot be confirmed, the currently bound window is used or the manual binding process is triggered; the chat window is activated after successful binding; the current session is checked to see if it is blocked by a blacklist or policy. If binding fails, activation fails, or the session is blocked, the system updates the triggered session to show as failed or blocked, and updates the floating entry status.

[0153] Step Six: Screenshot Recognition and Response Generation

[0154] After successful binding, the system enters the screenshot stage, taking a screenshot of the currently bound chat window and recording the screenshot path. It then enters the generation stage, calling existing workflows to process the screenshot, including OCR, chat context parsing, knowledge retrieval, response generation, and strategy determination.

[0155] Instead of implementing a new recognition algorithm for the floating path, the existing link in the desktop intelligent reply system is reused. This ensures that the recognition results of the floating entry are consistent with those of the main window, while avoiding mixing with other modules such as screenshot validity, latest message recognition, and knowledge retrieval.

[0156] Step 7: Processing the generated results

[0157] Once the workflow is generated and returns results, the system processes them according to the strategy results:

[0158] If the policy does not allow sending, record "Reply policy does not allow sending", and the floating entry will show that it has been blocked; if the generated reply is empty, record "Generated reply is empty", and the floating entry will show that there is no reply; if the generated reply is not empty and the policy allows it, then proceed to the filling stage.

[0159] Regardless of the outcome, the system triggers a session log to record the current stage, facilitating subsequent log analysis and explanation of patent implementation examples.

[0160] Step 8: Fill in the information but do not send automatically.

[0161] Once the text input phase begins, the system invokes the text sending module to write the reply text to the bound chat window. Unlike normal automatic sending, the floating path forces a text-only mode:

[0162] Write the reply text to the system clipboard; activate the bound chat window and position the input box; send the paste shortcut; set the Enter key to send to no, so that Enter is not sent; record only the field marked as true in the event data; display the "filled in" success status in the floating entry.

[0163] The floating entry will not send the reply directly to the other party. Instead, it will put the generated content into the input box, which the user can read and confirm before sending it.

[0164] Step Nine: Details Entry Control

[0165] When the floating entry is in a state such as "Requires Configuration," "Failed," or "Blocked," the user can open the main window. The system will then navigate to different pages based on the state.

[0166] You need to configure the status by entering the settings page;

[0167] Enter the workspace page upon failure, block, or other status;

[0168] The main window displays logs, OCR results, hit documents, response previews, or error details.

[0169] This mechanism keeps the floating inlet lightweight while retaining full problem localization capabilities.

[0170] The desktop chat instant recognition triggering method of this invention has the following beneficial technical effects:

[0171] I. Reduce operation switching costs

[0172] By displaying a floating entry point in the context of the foreground chat window, users can trigger the recognition operation without leaving the chat window, avoiding repeated switching between the chat window and the main window of the smart reply tool, significantly shortening the operation path and improving the efficiency of use in high-frequency communication scenarios.

[0173] II. Reduce desktop distractions

[0174] The display of the floating entry is controlled by the foreground window perception mechanism. It only appears when the target chat window is in the foreground or when there is a recognizable candidate window. It is automatically hidden in non-chat application scenarios to avoid the persistent floating button from obscuring and interfering with other applications on the desktop.

[0175] III. Improve the consistency of the target window

[0176] When a user clicks the floating entry, a trigger session is established, and the handle of the current foreground chat window is recorded and bound in real time. This ensures that the screenshot and recognition operations are always targeted at the session window that the user is currently processing, avoiding the problem of inconsistent recognition objects with expectations due to the use of old bound windows.

[0177] IV. Avoid repeated triggering

[0178] By using the state object of the floating entry and the active state judgment mechanism of the triggered session, when the floating entry is clicked again during the recognition process, a new recognition task will not be started and a recognition prompt will be displayed, which effectively prevents concurrent recognition, state confusion and resource waste caused by continuous clicks.

[0179] V. Reduce the risk of false positives

[0180] The system enforces a "fill-in only, no automatic sending" security control mode, which only pastes the generated reply text into the chat input box and does not automatically send it by pressing the Enter key or line break key. This retains the user's manual confirmation step and effectively avoids the risk of incorrect replies being sent directly due to recognition errors, session mismatches, or accidental touches.

[0181] VI. Clear status feedback

[0182] The floating entry has a built-in status object that can intuitively display various statuses such as idle, recognizing, successful, filled, blocked, no reply, configuration required, and failed. Users can know the current recognition and filling results without opening the main window, improving the system's understandability and ease of use.

[0183] VII. Facilitates problem tracing

[0184] The session triggers a complete record of window binding information, execution stages, and failure details during the recognition process. In case of abnormal situations such as interception, failure, or missing configuration, users can directly open the main window through the floating entry to view logs, recognition results, hit knowledge documents, and error details, which facilitates quick location and resolution of problems.

[0185] 8. Reuse existing identification links

[0186] The floating entry is only responsible for window perception, trigger control, and secure data entry. It does not reimplement algorithms such as screenshot recognition, OCR, chat context parsing, knowledge retrieval, and reply generation. It fully reuses the existing workflow of the desktop chat intelligent reply system, ensuring the consistency of recognition results and reducing the complexity and maintenance cost of system implementation.

[0187] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0188] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for real-time recognition and triggering in desktop chat, characterized in that, The method includes: Step S1: By periodically sensing the desktop foreground windows, determine whether a target chat window exists, and control the display or hiding of the floating entry accordingly; Step S2: In response to the user's click on the floating entry, create a floating recognition trigger session, record the current window binding information and the "fill in but do not send" flag, and suppress repeated triggering; Step S3: Based on the chat window that triggered the session, perform screenshotting, chat content recognition, and reply generation to obtain the generated reply text; Step S4: Simply fill the generated reply text into the input box of the chat window without performing the automatic send operation.

2. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, In step S1, the display or hiding of the floating entrance is controlled as follows: When the desktop foreground window is the floating entry itself, keep the floating entry displayed in the corresponding position of the previously bound target chat window; When the desktop foreground window matches the target chat application, a floating entry is displayed and bound to that window; When the desktop foreground window does not match the target chat application, scan all candidate chat windows and select the target window according to priority. If there are no candidate windows, hide the floating entry.

3. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, The floating entry in step S2 is a top-mounted transparent window control that allows users to drag and move it. After dragging, the position is saved to the configuration file. Each time it is displayed, the saved position is read and screen boundary clamping is performed to ensure that the floating entry is fully displayed in the visible area of ​​the screen.

4. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, The floating entry in step S2 maintains a state object, which includes at least an idle state, a recognition state, a success state, a warning state, and a failure state. In the idle state, it responds to click operations; in the recognition state, it rejects new clicks and displays a recognition prompt; in the success, warning, or failure states, it allows opening the main window to view details.

5. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, In step S2, the current window binding information is recorded as follows: it is determined whether the window handle passed when clicking matches the target chat application. If it matches, the window is bound; if it does not match, the already bound window is used or the manual binding process is triggered. After successful binding, the chat window will be activated, and the current session will be checked to see if it is blocked by a blacklist or policy. If it is blocked, the session will be ended and the status will be updated to blocked.

6. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, In step S2, repeated triggering is suppressed as follows: when creating a floating recognition trigger session, if an existing trigger session that has not yet been terminated is detected, the current click will not create a new session or start a new recognition process, but will only update the floating entry to the recognition prompt; The stages that trigger a session include the binding stage, screenshot stage, generation stage, filling stage, completion stage, interception stage, and failure stage, among which completion, interception, and failure are termination states.

7. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, In step S3, the floating entry calls the main workflow interface with a floating path identifier, so that the main workflow does not automatically send the reply after it generates it; when any operation of screenshot, chat content recognition and reply generation fails, the failure stage is recorded and the floating entry is updated to the corresponding failure or warning status.

8. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, In step S4, the "fill in but do not send automatically" method is implemented as follows: write the generated reply text to the clipboard; activate the bound chat window and position the input box; send the paste shortcut key to complete the text filling; force the Enter key signal or Line Feed key signal not to be sent; record the "fill in only" flag as true in the event data; after successful filling, the floating entry displays the success status and switches back to the idle status, allowing the user to manually confirm and decide whether to send.

9. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, The floating entrance is displayed as follows: When the generated reply text is empty, the floating entry will display a no reply status; When the policy rules determine that sending is not allowed, the status will be displayed as blocked; When a model configuration is missing, a configuration status will be displayed and a click will open the settings page; When a screenshot, generation, or input operation fails, a failure status is displayed, and the main window is opened to view at least one of the following information: the trigger session record, execution log, identification result, hit knowledge document, and error details.

10. The desktop chat real-time recognition triggering method according to claim 1, characterized in that, The floating entry runs in an independent thread, isolated from the recognition workflow thread of the main window. The triggering, status updating and filling operations of the floating entry do not block other functions of the main window.

Images