Multi-terminal cooperative processing system for remote court hearing

Abstract

The invention, which belongs to the technical field of computer data processing, discloses a remote court trial-oriented multi-terminal cooperative processing system comprising a data acquisition module, a feature extraction module, a cooperative decision-making module, a feature analysis module, a steady state transmission module, a synchronization module and a monitoring evaluation module. By fusing the court trial process state, the multi-dimensional network state and the evidence data compliance, transmission resource allocation can be dynamically optimized, and the transmission rhythm of multiple types of data streams can be coordinated, so that the continuity, stability and program compliance of remote court trial are improved.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and in particular to a multi-terminal collaborative processing system for remote court hearings. Background Technology

[0002] Remote court hearings are an information-based court hearing model that utilizes computer network technology, data processing, and audio / video communication technology to connect judges, litigants, lawyers, and other participants in court hearings who are located in different physical spaces, enabling online trials. This model relies on a stable and reliable multi-terminal collaborative processing system, which is responsible for processing real-time audio and video data from multiple terminals, as well as various electronic data generated during the trial, ensuring that all parties can communicate and interact clearly and smoothly.

[0003] In existing technologies, remote court hearing systems are typically modified from general video conferencing systems. The core of data processing in these systems lies in ensuring the quality of audio and video transmission, primarily employing techniques such as adaptive bitrate adjustment and network congestion control. When poor network conditions are detected, the system will reduce video resolution or frame rate to adapt to the current bandwidth, sacrificing some image quality to maintain basic communication accessibility. The transmission of evidence and other documents is usually treated as a separate file-sharing function, manually triggered by the user when needed; its transmission process directly competes with the audio and video streams for network bandwidth.

[0004] However, existing technical solutions have significant drawbacks when applied to court proceedings. First, general network adaptive strategies lack awareness of court proceedings and fail to distinguish between primary and secondary roles and key stages, resulting in blind resource allocation. This may lead to sacrificing the speaker's audio clarity to preserve the video clarity of non-speaking parties during crucial debate phases. Second, the transmission of audio / video streams conflicts with evidence data streams. When parties upload large evidence files, they consume significant bandwidth, often causing severe stuttering or even interruptions in audio and video for all participants, disrupting the continuity of the trial. Finally, existing systems lack a global monitoring view of multi-terminal collaboration, making it difficult for technicians to grasp the overall operational status of each terminal in real time, resulting in delays in problem detection and localization. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a multi-terminal collaborative processing system for remote court hearings. By integrating the status of the court hearing process, multi-dimensional network status, and the compliance of evidence data, it can dynamically optimize the allocation of transmission resources and coordinate the transmission rhythm of multiple data streams, thereby improving the continuity, stability, and procedural compliance of remote court hearings.

[0006] The above objectives can be achieved through the following approach: A multi-terminal collaborative processing system for remote court hearings includes a data acquisition module for acquiring and processing real-time audio and video stream data, real-time network link performance indicators, and current hearing node information from multiple devices during a remote hearing to obtain network quality data and hearing process status data; a feature extraction module for extracting features from the network quality data to generate a network state feature vector characterizing the current multi-link transmission environment; a collaborative decision-making module for generating link scheduling instructions for dynamically allocating transmission paths and resources based on the network state feature vector and a preset session consistency identifier characterizing the hearing progress; and a feature analysis module for acquiring evidence submission requests containing evidence data and analyzing the evidence data. The system performs pre-compliance verification and generates evidence compliance tags that include comprehensive verification results and display timing information; a steady-state transmission module is used to integrate the link scheduling instructions, the evidence compliance tags, and the court proceedings status data to generate a rhythm control variable for coordinating the transmission rhythm of multiple data streams; a synchronization module is used to drive subsequent audio and video stream data and evidence data to be collaboratively transmitted to multiple devices based on the rhythm control variable, and synchronously update the multi-terminal collaborative status diagram reflecting the current collaborative status of all terminals; a monitoring and evaluation module is used to calculate and generate a court proceedings continuity score for evaluating the stability of a single court proceedings based on the multi-terminal collaborative status diagram and records of abnormal events during the court proceedings.

[0007] Optionally, the step of acquiring and processing real-time audio and video stream data from multiple devices in a remote trial, real-time performance indicators of network links, and current trial node information to obtain network quality data and trial process status data includes: acquiring real-time audio and video stream data from the terminals of each participating party in the remote trial, and extracting a first network quality parameter from the packet header information of the real-time audio and video stream data; acquiring real-time performance indicators of multiple heterogeneous network links connected to each participating party's terminal as a second network quality parameter; merging the first network quality parameter and the second network quality parameter to form network quality data; acquiring current trial node information and operation status information of each terminal, and fusing the trial node information and the operation status information to generate trial process status data.

[0008] Optionally, the step of extracting features from the network quality data to generate a network state feature vector characterizing the current multi-link transmission environment includes: performing time-domain and frequency-domain analysis on the network quality data to extract comprehensive features reflecting link delay, jitter, packet loss rate, and bandwidth utilization to form an initial feature set; and weighting and fusing the initial feature set based on the role attributes of each participating terminal and the current stage of the court proceedings to generate the network state feature vector.

[0009] Optionally, the step of generating link scheduling instructions for dynamically allocating transmission paths and resources based on the network state feature vector and a preset session consistency identifier representing the progress of the trial includes: generating a basic session template representing fixed process nodes according to the type of the current trial and a preset trial process template; dynamically mapping the basic session template in conjunction with the current trial node information in the trial process state data to generate a session consistency identifier; performing resource scheduling analysis based on the network state feature vector and the session consistency identifier, and outputting a link scheduling instruction that includes a primary / backup transmission path selection strategy, a redundant data packet strategy, and a dynamic bitrate adjustment strategy.

[0010] Optionally, the step of obtaining an evidence submission request containing evidence data, performing preliminary compliance verification on the evidence data, and generating an evidence compliance tag containing a comprehensive verification result and display timing information includes: obtaining an evidence submission request from any participating party's terminal, wherein the evidence submission request carries an evidence type identifier and evidence data; according to the evidence type identifier, calling a preset corresponding compliance verification rule base to verify the format, size, and digital signature of the evidence data, generating format verification results, size verification results, and signature verification results; according to the court hearing process status data, determining whether the current court hearing node is in the stage where evidence submission is allowed, obtaining a stage judgment result; predicting the expected display time window of the evidence data in subsequent court hearing processes, obtaining display timing information; aggregating the format verification result, the size verification result, the signature verification result, and the stage judgment result to generate a comprehensive verification result; and binding the comprehensive verification result with the display timing information to generate an evidence compliance tag.

[0011] Optionally, the step of integrating the link scheduling instruction, the evidence compliance label, and the trial process status data to generate a rhythm control variable for coordinating the transmission rhythm of multiple types of data streams includes: parsing the link scheduling instruction to extract the priority transmission level for audio and video stream data and the transmission triggering condition for evidence data; parsing the evidence compliance label to extract the expected display time window and the comprehensive verification result; if the verification passes, calculating the pre-loading time point of the evidence data based on the expected display time window; predicting the next trial node switching time by combining the current trial node information and process progress status in the trial process status data; and calculating and generating a rhythm control variable for coordinating the real-time transmission of audio and video stream data and the asynchronous transmission of evidence data based on the priority transmission level, the transmission triggering condition, the pre-loading time point, and the next trial node switching time, wherein the rhythm control variable includes a transmission timing schedule table and a buffer management instruction.

[0012] Optionally, the step of driving subsequent audio and video stream data and evidence data to be collaboratively transmitted to multiple devices based on the rhythm control variable, and synchronously updating the multi-terminal collaborative state diagram reflecting the current collaborative state of all terminals, includes: according to the transmission timing schedule table, before the pre-loading time point arrives, initiating background block transmission and terminal-side caching of the verified evidence data to obtain the cache state; during the court hearing process, adjusting the encoding bitrate and transmission path of the audio and video stream data of each terminal according to the priority transmission level and the network state feature vector to obtain the playback smoothness and network link status; real-time monitoring of the cache state, playback smoothness, and network link status of each terminal to generate terminal status monitoring data; and merging and rendering the terminal status monitoring data with the court hearing process status data to generate visual primitives, and synchronously updating the multi-terminal collaborative state diagram reflecting the current collaborative state of all terminals.

[0013] Optionally, the real-time monitoring of the cache status, playback smoothness, and network link status of each terminal to generate terminal status monitoring data includes: periodically sending status query instructions to each participating terminal and receiving the cache status, playback smoothness, and network link status fed back by each terminal; generating evidence cache completion based on the cache status, extracting the audio / video frame decoding delay from the playback smoothness, and extracting the signal strength of the current access link from the network link status; calculating the end-to-end delay and consecutive packet loss count of each audio / video stream data on the local server based on the signal strength; generating an abnormal status marker when it is detected that the evidence cache completion of any terminal is lower than a preset completion threshold, or the audio / video frame decoding delay exceeds a preset first tolerance threshold, or the consecutive packet loss count exceeds a preset second tolerance threshold; and summarizing the cache status, playback smoothness, network link status, end-to-end delay, consecutive packet loss count, and abnormal status marker fed back by all terminals to form structured terminal status monitoring data.

[0014] Optionally, the step of calculating and generating a trial continuity score for evaluating the stability of a single trial process based on the multi-terminal collaborative state diagram and the abnormal event records during the trial includes: extracting the duration and type of collaborative anomalies for each terminal from the multi-terminal collaborative state diagram; obtaining the number of process interruptions and the duration of interruptions caused by network or data problems during the trial from the system log to form an abnormal event record; calculating a network collaborative stability sub-score and a process continuity sub-score respectively based on the collaborative anomaly duration, the anomaly type, and the number and duration of interruptions in the abnormal event record; and performing weighted normalization processing on the network collaborative stability sub-score and the process continuity sub-score based on the total duration of this trial to generate a trial continuity score.

[0015] Based on the same inventive concept, this invention also provides a multi-terminal collaborative processing method for remote court hearings. The method includes: acquiring and processing real-time audio and video stream data from multiple devices in a remote court hearing, real-time performance indicators of network links, and current court hearing node information to obtain network quality data and court hearing process status data; extracting features from the network quality data to generate a network status feature vector characterizing the current multi-link transmission environment; generating a link scheduling instruction for dynamically allocating transmission paths and resources based on the network status feature vector and a preset session consistency identifier characterizing the court hearing progress; and acquiring an evidence submission request containing evidence data. The evidence data undergoes preliminary compliance verification, generating an evidence compliance tag that includes comprehensive verification results and display timing information. The link scheduling instructions, the evidence compliance tags, and the trial process status data are integrated to generate a rhythm control variable for coordinating the transmission pace of multiple data streams. Based on the rhythm control variable, subsequent audio and video stream data and the evidence data are driven to be collaboratively transmitted to multiple devices, and a multi-terminal collaborative status diagram reflecting the current collaborative status of all terminals is updated synchronously. Based on the multi-terminal collaborative status diagram and records of abnormal events during the trial, a trial continuity score is calculated to evaluate the stability of a single trial process.

[0016] Compared with the prior art, the present invention has the following advantages: This invention can perceive the current trial process and the role attributes of each participant in real time. Combined with the assessment of multi-link network quality, it prioritizes the allocation of limited network resources to the most important audio and video data streams. This avoids the stuttering or distortion that occurs at critical moments due to the indiscriminate processing of traditional systems, and improves the stability and smoothness of the core interactive process of the trial.

[0017] This invention ensures the validity of evidence and the seriousness of court proceedings by verifying the compliance of its format, size, signature, and submission timing before its formal presentation. It can predict the presentation sequence of evidence and transmit and cache it in blocks in advance in the background, minimizing the impact of large file transmission on real-time audio and video streams. This invention solves the technical defect in the prior art that the submission of evidence can easily lead to the interruption of the court proceedings, and ensures the continuity and uninterruptedness of the court proceedings.

[0018] This invention constructs and updates a multi-terminal collaborative status diagram in real time, visualizing complex collaborative information such as network status, playback smoothness, and evidence caching progress of all terminals, providing a global situational awareness capability for the technical support of court hearings. The final generated court hearing continuity score quantifies the overall technical stability of a single hearing, providing objective and quantifiable data for the performance evaluation, fault tracing, and continuous optimization of remote court hearing systems. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the structure of a multi-terminal collaborative processing system for remote court hearings according to an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram of the transmission timing schedule table according to an embodiment of the present invention.

[0022] Figure 3 This is a schematic diagram of the multi-terminal collaborative state diagram according to an embodiment of the present invention.

[0023] Figure 4 This is a flowchart illustrating a multi-terminal collaborative processing method for remote court hearings according to an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Reference Figure 1 One embodiment of the present invention proposes a multi-terminal collaborative processing system for remote court hearings. By integrating the status of the court hearing process, the status of multi-dimensional network, and the compliance of evidence data, it can dynamically optimize the allocation of transmission resources and coordinate the transmission rhythm of multiple types of data streams, thereby improving the continuity, stability, and procedural compliance of remote court hearings.

[0026] The system described in this embodiment specifically includes: The data acquisition module is used to acquire real-time audio and video stream data from multiple devices in remote court hearings, real-time performance indicators of network links, and current court hearing node information for processing, in order to obtain network quality data and court hearing process status data. The feature extraction module is used to extract features from the network quality data and generate a network state feature vector that characterizes the current multi-link transmission environment. The collaborative decision-making module is used to generate link scheduling instructions for dynamically allocating transmission paths and resources based on the network state feature vector and a preset session consistency identifier representing the progress of the court hearing. The feature analysis module is used to obtain evidence submission requests containing evidence data, perform preliminary compliance verification on the evidence data, and generate evidence compliance tags containing comprehensive verification results and display time sequence information. A steady-state transmission module is used to integrate the link scheduling instructions, the evidence compliance tags, and the court hearing process status data to generate a rhythm control variable for coordinating the transmission rhythm of multiple data streams. The synchronization module is used to drive the subsequent audio and video stream data and the evidence data to be transmitted collaboratively to multiple devices according to the rhythm control variable, and to synchronously update the multi-terminal collaborative status diagram reflecting the current collaborative status of all terminals. The monitoring and evaluation module is used to calculate and generate a trial continuity score to evaluate the stability of a single trial process based on the multi-terminal collaborative status diagram and the abnormal event records during the trial.

[0027] Optionally, the process of acquiring and processing real-time audio and video stream data from multiple devices in a remote court hearing, real-time performance indicators of the network link, and current hearing node information to obtain network quality data and court hearing process status data includes: Acquire real-time audio and video stream data from the terminals of each participating party in a remote court hearing, and extract the first network quality parameter from the packet header information of the real-time audio and video stream data; The real-time performance metrics of multiple heterogeneous network links connected to the terminals of each participating party are obtained as a second network quality parameter. The first network quality parameter and the second network quality parameter are combined to form network quality data; The system acquires current trial node information and operation status information of each terminal, and integrates the trial node information and operation status information to generate trial process status data.

[0028] Specifically, the data acquisition module captures and parses real-time audio and video streams generated by the terminals of various participants in a remote court hearing, such as the judge, plaintiff, defendant, and lawyer. These data streams typically follow the Real-Time Transport Protocol (RTP). In this embodiment, the first network quality parameter specifically refers to an indicator that directly reflects the audio and video transmission quality at the service layer. By parsing the field information of the RTP packet header and RTCP control packet, packet loss rate, network jitter, and round-trip time are extracted as the first network quality parameter. The proportion of lost data packets is statistically analyzed based on the sequence number continuity in the RTP packet header as the packet loss rate; the rate of change in transmission delay is calculated based on the difference in the timestamps of data packet arrival as the network jitter; and the end-to-end communication delay is calculated by parsing the timestamp information of the RTCP sender's report (SR) and receiver's report (RR) as the round-trip time. Thus, the system directly quantifies the transmission status related to the user's audiovisual experience through the first network quality parameter.

[0029] Simultaneously, the data acquisition module actively or passively monitors multiple heterogeneous network links connected to the terminals of each participating party, including 5G, Wi-Fi, and wired Ethernet. In this embodiment, the second network quality parameter specifically refers to an indicator reflecting the health of the underlying physical network infrastructure. The module extracts link physical latency and connectivity, signal strength, and current available bandwidth as the second network quality parameter by network probing and calling the terminal's underlying API interface. Link physical latency and connectivity are obtained by sending ICMP probe packets to the gateway or designated node; the received power of the wireless link is obtained by calling the terminal operating system's underlying API, specifically the Reference Received Power (RSRP) for 5G / 4G networks and the Received Signal Strength Indication (RSSI), i.e., signal strength, for Wi-Fi networks; and the current maximum throughput capacity of the link is estimated using an instantaneous bandwidth testing tool as the current available bandwidth.

[0030] The data acquisition module merges the first and second network quality parameters. Since the two sets of parameters have different units and physical meanings—for example, latency is measured in milliseconds, packet loss rate is a percentage, and signal strength is measured in dBm—direct numerical calculations are not possible. Therefore, the system uses a normalized weighted fusion algorithm to generate a comprehensive network quality score, i.e., network quality data. It should be noted that the network quality data calculated here is not the final decision score, but rather a basic operator after addressing the parameter heterogeneity problem, used to provide standardized time-series input data for the subsequent feature extraction module. Its calculation process can be represented as follows: , in, The final generated network quality data is a comprehensive score or vector. This represents a vector composed of the first network quality parameters. This represents a vector composed of the second network quality parameters. and It is a normalization function, which maps parameters with different dimensions to a unified interval of 0 to 1 to solve the problem of inconsistent dimensions. and These are preset or dynamically adjusted weighting coefficients, and add A value of 1 is used to adjust the relative importance of application layer experience and physical link status in the final evaluation. When the signal strength in the second network quality parameter, such as Wi-Fi RSSI or 5G RSRP, exceeds a preset safety threshold, for example, -80dBm, the system determines that the physical link is reliable. At this point, to ensure a good audiovisual experience during the trial, the focus is on application layer performance. The system sets the weight to... , When the signal is strong, occasional stuttering is usually caused by software coding or server congestion. Therefore, assigning higher weight to the first network quality parameter, i.e., the application layer stream data, can more accurately reflect the current conference quality. When the signal strength is below a preset safety threshold, such as -80dBm, but the connection is still maintained, the system determines that the physical link is on the verge of collapse. At this time, in order to trigger link switching or error correction mechanisms in advance, it must be extremely sensitive to fluctuations in the underlying signal. The system dynamically inverts the weights to... , At this point, application-layer data such as packet loss rate may not have deteriorated yet (due to caching mechanisms), but a decline in physical-layer signal strength indicates an impending connection loss. Improving... The weighting can make the overall score The rapid decline prompts the system to generate a link switching instruction in the collaborative decision-making module as early as possible, thus avoiding interruption of the trial.

[0031] The data acquisition module obtains current trial node information from the court control center or judge's terminal application, such as the current macro-process node of "court investigation," "court debate," or "evidence examination." On the other hand, the module acquires micro-level operational status information by monitoring user interface events of various terminal applications, such as "Lawyer A is requesting to speak," "Defendant B is uploading evidence documents," or "Court clerk is revising the court transcript." The data acquisition module logically integrates the macro-level trial node information and the micro-level operational status information to generate structured trial process status data. This data not only indicates the progress of the trial proceedings but also includes the real-time interactive intentions of all parties, providing contextual basis for subsequent modules to judge the compliance and timeliness of actions.

[0032] Optionally, the step of extracting features from the network quality data to generate a network state feature vector characterizing the current multi-link transmission environment includes: The network quality data is analyzed in the time and frequency domains to extract comprehensive features reflecting link latency, jitter, packet loss rate, and bandwidth utilization, forming an initial feature set. Based on the role attributes of each participating terminal and the current stage of the court proceedings, the initial feature set is weighted and fused to generate the network state feature vector.

[0033] Specifically, the feature extraction module sets a sliding time window (e.g., 30 seconds) for the received sequence of continuously generated, normalized network quality data. Within this window, it performs time-domain and frequency-domain analysis on time-series data such as latency, jitter, packet loss rate, and bandwidth utilization. This step aims to extract the fluctuation patterns of data over time from simple numerical values. In the time-domain analysis, the module calculates statistics for each indicator, such as mean, variance, and peak value, to capture its central trend, stability, and extreme fluctuations. For example, calculating the variance of latency can quantify the severity of jitter, reflecting transmission stability far better than instantaneous jitter values. In the frequency-domain analysis, the module can apply algorithms such as Fast Fourier Transform (FFT) to analyze the frequency components of network jitter or packet loss events to identify the presence of periodic network congestion or interference. Through this analysis, the system extracts a series of comprehensive features, such as "average uplink packet loss rate over the past 30 seconds," "standard deviation of downlink jitter over the past 10 seconds," and "bandwidth utilization fluctuation coefficient." These features together constitute the initial feature set, which provides a multi-dimensional performance snapshot for each network link.

[0034] The feature extraction module acquires the role attributes of each participating terminal, such as "Judge," "Presiding Speaker," and "Ordinary Participant," as well as the current courtroom process stage obtained from the trial process status data, such as "Presentation and Examination of Evidence" or "Court Debate." The system pre-defines a weighting strategy matrix, which defines the sensitivity of different roles to various network features at different trial stages. For example, during the "Court Debate" stage, the "Audio Uplink Latency" and "Audio Uplink Packet Loss Rate" features of the Presiding Speaker terminal have significantly higher weights than other terminals; during the "Presentation and Examination of Evidence" stage, the "Downlink Bandwidth" feature weight of all terminals is increased to ensure rapid synchronization of evidence documents. The weighted fusion process can be represented by the following formula: , in, It is the final network state feature vector generated for participant terminal j. This is the initial feature set vector belonging to terminal j, obtained from the first stage. R represents the role attribute of terminal j, and S represents the current stage of the trial process. It is a weight vector found from the weighted policy matrix based on the role R and stage S. (Symbol) This represents the Hadamard product, which is the element-wise multiplication of vectors. This operation multiplies each feature in the initial feature set by its corresponding weight, generating a weighted feature value. This process adjusts the relative importance of each feature component using dimensionless weight coefficients. The final generated network state feature vector... It represents the current network environment's ability to support specific users in specific court proceedings.

[0035] Optionally, the step of generating link scheduling instructions for dynamically allocating transmission paths and resources based on the network state feature vector and a preset session consistency identifier representing the progress of the court hearing includes: Based on the type of this court hearing and the pre-set court hearing process template, generate a basic conversation template that represents fixed process nodes; By combining the current trial node information in the trial process status data, the basic session template is dynamically mapped to generate a session consistency identifier; Based on the network state feature vector and the session consistency identifier, resource scheduling analysis is performed, and link scheduling instructions including primary / backup transmission path selection strategy, redundant data packet strategy and dynamic bit rate adjustment strategy are output.

[0036] Specifically, the collaborative decision-making module loads the corresponding basic session template from a pre-set trial process template library based on the type of the trial. This template is a structured data object that defines all the necessary fixed process nodes for this type of trial in the form of a finite state machine, such as "pre-trial preparation," "court investigation," "court debate," and "final statement," and predefines the communication mode and resource priority for each node. For example, the "court debate" node will preset a "single speaker, multiple audience" communication mode and stipulate that the speaker's audio and video uplink quality assurance level is the highest.

[0037] Secondly, the collaborative decision-making module continuously receives trial process status data from the data acquisition module and extracts current trial node information, such as "Currently in the court investigation stage, the plaintiff's lawyer is presenting evidence." The module dynamically maps this real-time node information to the basic session template, activating the preset strategies for the corresponding nodes in the template, thereby generating a session consistency identifier. This identifier is a set of QoS parameters required by all participating terminals in the current business scenario. For example, it explicitly indicates that the uplink audio stream latency of the current speaker must be less than 150 milliseconds, while the downlink video streams of other listeners can tolerate latency greater than 250 milliseconds. The session consistency identifier serves as a bridge connecting legal procedures and network engineering, transforming trial rules into quantifiable network transmission targets.

[0038] The collaborative decision-making module executes a resource scheduling analysis algorithm. The core inputs to this algorithm are network state feature vectors from the feature extraction module, describing the actual availability of links for each terminal, and session consistency identifiers generated in the previous step, defining the ideal transmission target. The algorithm aims to solve an optimization problem: maximizing the overall communication quality of the court proceedings while satisfying the constraints defined by the session consistency identifiers. Its decision-making process can be represented as follows: , in, V represents the final output set of link scheduling instructions. V is a network state feature vector containing the performance metrics of each link for all terminals. I is the session consistency identifier for the current stage. This is the scheduling optimization function, which determines the optimal transmission strategy for each data flow by comparing the actual capabilities of each link in V with the quality requirements defined in I. Scheduling optimization function It is a multi-stage constraint programming solution process. The function first parses the hard constraint indicators defined in the session consistency identifier I, such as "maximum allowable delay". "and minimum bandwidth requirements" "Traverse all candidate physical links contained in the network state feature vector V. If the measured delay of a certain link is greater than..." Or bandwidth less than If a link is not found to be available, it is marked as unavailable and removed from the candidate set. For the remaining links in the candidate set, a weighted utility function is constructed for scoring. The scoring formula is set as follows: ,in For actual delay, For packet loss rate, This is the normalized value of available bandwidth. , , The weighting coefficients are based on the current stage of the trial, such as the delay weighting during the court debate stage. Increase; during the evidentiary phase, bandwidth weighting Increase. Based on the calculated scores, the link with the highest score is selected as the primary transmission path, and the link with the second highest score, independent of the primary path, is selected as the backup transmission path. Simultaneously, a dynamic bitrate cap is calculated based on the bandwidth margin of the optimal link; combined with packet loss rate characteristics, if... If it exceeds a preset threshold, such as 2%, then... The instruction to activate the Redundant Packet Policy (FEC) is used.

[0039] The output link scheduling command is a composite command set, specifically including a primary / backup transmission path selection strategy, such as instructing terminal A to set the 5G link as primary and the Wi-Fi link as backup; a redundant data packet strategy, such as enabling 15% forward error correction (FEC) for the main speaker's audio stream or sending critical data packets simultaneously on the primary and backup links; and a dynamic bitrate adjustment strategy, such as instructing non-speaking terminals to adaptively reduce their video encoding bitrate to 700kbps to save network resources and ensure the stable transmission of core services.

[0040] Optionally, the step of obtaining an evidence submission request containing evidence data, performing preliminary compliance verification on the evidence data, and generating an evidence compliance label containing comprehensive verification results and display time sequence information includes: Obtain an evidence submission request from any participating party's terminal, wherein the evidence submission request carries an evidence type identifier and evidence data; Based on the evidence type identifier, the corresponding preset compliance verification rule base is invoked to verify the format, size, and digital signature of the evidence data, generating format verification results, size verification results, and signature verification results; Based on the court hearing process status data, determine whether the current hearing node is in the stage where evidence can be submitted, and obtain the stage determination result; Predict the expected presentation time window of the evidence data in subsequent court proceedings to obtain presentation timing information; The format verification result, the size verification result, the signature verification result, and the stage judgment result are aggregated to generate a comprehensive verification result; The comprehensive verification result is bound to the display time sequence information to generate an evidence compliance label.

[0041] Specifically, the feature analysis module listens for evidence submission requests initiated from any participating party's terminal, such as a lawyer's or a client's terminal. This request is a standardized data packet that explicitly carries an evidence type identifier, such as "PDF document," "MP4 video," or "WAV audio recording," as well as the evidence data itself or a pointer to its storage location. The module unpacks the request and extracts these two core pieces of information.

[0042] The feature analysis module, based on the extracted evidence type identifier, calls the corresponding rule set from a pre-configured compliance verification rule base. This rule base is pre-configured by the system according to legal document standards. For example, for a "PDF document," the rule set checks whether the file header conforms to PDF specifications, whether the file size is within the 200MB limit, and whether the file includes a valid digital signature issued by a third-party CA. The module performs these checks item by item, generating independent format verification results, size verification results, and signature verification results, all of which are Boolean values.

[0043] The feature analysis module acquires real-time trial process status data generated by the data acquisition module and parses it to determine the current macro-level trial stage, such as "Court Investigation - Evidence Presentation Stage." The module compares this stage information with preset trial procedure rules to determine whether the submission of that type of evidence is permitted at the current moment. For example, the rules might stipulate that new evidence can only be submitted during the "Evidence Presentation and Examination" stage, but is prohibited during the "Court Debate" stage. This determination produces a Boolean-type stage judgment result.

[0044] Subsequently, the feature analysis module, based on more granular information from the court proceedings status data, such as the current evidence number being examined and the number of evidence awaiting examination in the queue, combined with an average presentation time model for each type of evidence, predicts the expected presentation time window for the currently submitted evidence data in subsequent court proceedings. This time window includes a start time and an end time, for example, "expected to begin presentation in 15 minutes, presentation duration approximately 5 minutes." This set of time data constitutes the presentation sequence information.

[0045] The feature analysis module aggregates the format verification results, size verification results, signature verification results, and stage judgment results generated in the preceding steps. The aggregation logic is typically a logical AND operation; that is, the overall verification result is "passed" only when all verification items are "passed". This aggregation process can be represented as: , in, This represents the comprehensive verification result. , , , These represent Boolean verification results for format, size, digital signature, and stage judgment, respectively. (Symbols) It represents the logical AND operation.

[0046] Finally, the feature analysis module encapsulates the comprehensive verification result generated in the previous step with the display timing information generated in the fourth step, forming a data object, namely the evidence compliance label. This label not only informs the system whether the evidence is "qualified," but also indicates "when" it should be used, providing crucial decision-making basis for the subsequent asynchronous preloading and precise scheduling by the steady-state transmission module.

[0047] Optionally, the step of integrating the link scheduling instruction, the evidence compliance label, and the trial process status data to generate a rhythm control variable for coordinating the transmission rhythm of multiple data streams includes: The link scheduling instructions are analyzed to extract the priority transmission levels for audio and video stream data and the transmission triggering conditions for evidence data; The evidence compliance label is parsed, the expected display time window and the comprehensive verification result are extracted, and if the verification is passed, the pre-loading time point of the evidence data is calculated based on the expected display time window. Based on the current trial node information and the progress status in the trial process status data, predict the switching time of the next trial node; Based on the priority transmission level, the transmission triggering condition, the preloading time point, and the switching time of the next court hearing node, a rhythm control variable for coordinating the real-time transmission of audio and video stream data and the asynchronous transmission of evidence data is calculated and generated. The rhythm control variable includes a transmission timing schedule table and buffer management instructions.

[0048] Specifically, the steady-state transmission module receives and parses link scheduling instructions. From these instructions, the module extracts the priority transmission levels for audio and video streams from different participants. For example, the main speaker's audio stream is prioritized as "highest," the video stream as "high," and the audio and video streams of other participants as "normal." Simultaneously, the module also extracts the transmission triggering conditions for evidence data, such as "initiate transmission only when network bandwidth margin is greater than 2Mbps" or "initiate transmission only when the current main speaker's bitrate is less than 1Mbps." These parameters concretize the macro-level network resource allocation strategy into executable transmission priorities and preconditions.

[0049] The steady-state transmission module receives and parses the evidence compliance tags generated by the feature analysis module. The module extracts the comprehensive verification result. If the verification result is "failed," the transmission task for that evidence is discarded. If the verification passes, the module extracts the expected display time window. Based on the start time of this time window, the module subtracts a preset transmission and loading lead time, calculated based on the evidence size and the estimated average transmission rate, typically set to 3-5 minutes. Through this calculation, the module determines the pre-loading time point for the evidence data, i.e., the optimal time to start background transmission.

[0050] The steady-state transmission module continuously acquires the latest trial process status data, especially the current trial node information and process progress status, such as "Evidence examination stage, currently presenting evidence number 2, out of a total of 5 evidences." Based on a preset model of the average time consumption of each trial node and the current progress, the module predicts the switching time of the next trial node, for example, predicting that the "court debate" stage will begin in approximately 10 minutes. This time point provides an important time anchor for adjusting the audio and video streaming transmission strategy.

[0051] Finally, the steady-state transmission module performs a comprehensive calculation and decision based on the priority transmission level and transmission triggering conditions obtained in the first step, the preloading time point calculated in the second step, and the predicted switching time of the next court hearing node in the third step. This calculation aims to dynamically balance the stable transmission of real-time streams with the preloading of asynchronous streams. For example, when the system detects good network conditions and is close to the evidence preloading time point, even if the audio and video streams have a high priority, bandwidth will be appropriately allocated to evidence transmission provided the triggering conditions are met. This decision-making process generates a composite rhythm control variable, which specifically includes two parts: a transmission timing schedule table, such as... Figure 2As shown, it is a dynamically updated timeline that precisely marks the exact time when each evidence data block begins transmission; the other is a buffer management instruction, which instructs each terminal on how much buffer space to reserve and how to store and manage the received data blocks to ensure that they can be retrieved instantly and without delay when displayed.

[0052] Optionally, the step of driving subsequent audio and video stream data and evidence data to be collaboratively transmitted to multiple devices based on the rhythm control variable, and synchronously updating the multi-terminal collaborative state diagram reflecting the current collaborative state of all terminals, includes: According to the transmission timing schedule table, before the preloading time point arrives, the background block transmission and terminal-side caching of the verified evidence data are initiated to obtain the cache status; During the court proceedings, the encoding bitrate and transmission path of the audio and video stream data of each terminal are adjusted according to the priority transmission level and the network status feature vector to obtain the playback smoothness and network link status. Real-time monitoring of the cache status, playback smoothness, and network link status of each terminal generates terminal status monitoring data; The terminal status monitoring data and the court hearing process status data are merged and rendered to generate visual primitives, and a multi-terminal collaborative status diagram reflecting the current collaborative status of all terminals is updated synchronously.

[0053] Specifically, the synchronization module continuously monitors the system time based on the transmission timing schedule table in the rhythm control variable. When the time reaches the pre-loading time point of a certain verified evidence data, the module automatically triggers the background transmission task. The evidence data is divided into appropriately sized data blocks, for example, each data block is 1MB, and then sent to all relevant terminals through an independent, low-priority transmission channel. After receiving the data blocks, the terminals cache them locally. The synchronization module continuously tracks the reception progress of each terminal to obtain a real-time updated cache status, which quantifies the percentage of cache completion for each terminal on that evidence.

[0054] During the court proceedings, the synchronization module dynamically adjusts the audio and video encoding parameters and transmission paths of each terminal based on the priority transmission levels assigned to each audio and video stream in the rhythm control variables and the network status feature vectors updated in real time by the feature extraction module. For example, when a decline in the uplink quality of the main speaker is detected, the module will, according to the link scheduling instructions, instruct the terminal to switch to a backup network link and may appropriately reduce the video encoding bitrate to ensure absolute audio smoothness. The synchronization module obtains playback smoothness indicators reflecting user experience, such as video stuttering rate and audio latency, as well as the current network link status used by each terminal, by monitoring the decoding and rendering statistics fed back by the players of each terminal.

[0055] The synchronization module monitors the cache status, playback smoothness, and network link status of all terminals in real time. This monitoring data comes from various sources, including heartbeat packets actively reported by the terminals, proactive probing by the server, and parsing of transmission protocol control messages. The module cleans and aggregates this raw data to generate structured terminal status monitoring data. This data structure includes a series of key performance indicators for each terminal, such as evidence preloading progress, whether audio and video playback is choppy, which network is currently connected, and the signal quality of that network.

[0056] Finally, as Figure 3 As shown, the synchronization module merges and renders the terminal status monitoring data generated in the previous step with the court proceedings status data provided by the data acquisition module. For example, a topology map displays all participating terminals; the color of the terminal icon changes according to its network quality, a progress bar next to the icon indicates the evidence caching status, and the timeline representing the court proceedings marks the current node. These elements constitute the visual primitives. The synchronization module updates the status and position of these primitives at a high frequency, such as 2-5 times per second, thereby dynamically and synchronously updating a multi-terminal collaborative status map reflecting the current collaborative status of all terminals. This status map provides judges, technical support personnel, and others with global situational awareness, enabling them to identify and intervene in potential collaborative problems immediately.

[0057] Optionally, the real-time monitoring of the cache status, playback smoothness, and network link status of each terminal to generate terminal status monitoring data includes: Periodically send status query commands to each participating terminal, and receive feedback from each terminal on the cache status, playback smoothness, and network link status; Based on the cache status, evidence cache completion is generated; audio and video frame decoding latency is extracted from the playback smoothness; and signal strength of the current access link is extracted from the network link status. Based on the signal strength, the end-to-end delay and number of consecutive packet losses for each audio and video stream are calculated on the local server. An abnormal status flag is generated when it is detected that the evidence cache completion of any terminal is lower than the preset completion threshold, or the audio / video frame decoding delay exceeds the preset first tolerance threshold, or the number of consecutive packet losses exceeds the preset second tolerance threshold. The cache status, playback smoothness, network link status, end-to-end latency, number of consecutive packet losses, and abnormal status markers reported by all terminals are aggregated to form structured terminal status monitoring data.

[0058] Specifically, the synchronization module sends a status query command to all online participating terminals at a fixed interval, such as every 2 seconds. This command is a lightweight signaling mechanism. Upon receiving the command, each terminal application immediately queries its local operating status and encapsulates information such as the cached status (i.e., the proportion of received evidence data blocks to the total data blocks), playback smoothness (e.g., the video frame rendering interval in the most recent statistical period), and network link status (i.e., the network type and signal strength of the currently active connection) into a response message and sends it back to the server.

[0059] The synchronization module parses the received response message. Based on the feedback cache status, the system directly calculates the evidence cache completion rate, a percentage value from 0 to 100. From the playback smoothness metric, the module extracts the key audio and video frame decoding latency, which refers to the time difference from receiving a data packet to completing decoding and preparing for rendering, in milliseconds. From the network link status, the module extracts the signal strength of the current access link, such as 5G RSRP or Wi-Fi RSSI.

[0060] The synchronization module not only relies on terminal reports but also performs calculations from a global perspective on the local server. Based on signal strength information fed back from the terminal, as well as the data packet sending timestamps recorded by the server and the acknowledgment information fed back by the receiver, the system can calculate the end-to-end latency of each audio and video stream. Simultaneously, by continuously monitoring the sequence numbers of RTP packets, the server can accurately count the number of consecutive packet losses, an indicator that reflects sudden network deterioration more effectively than the average packet loss rate.

[0061] Then, the synchronization module incorporates a multi-dimensional set of anomaly detection rules. When it detects that the evidence cache completion rate of any terminal remains below a preset completion threshold (e.g., 95%) before the pre-loading deadline, or that the audio / video frame decoding latency consistently exceeds a preset first tolerance threshold (e.g., 200 milliseconds), or that the number of consecutive packet losses exceeds a preset second tolerance threshold within a short time window (e.g., more than three consecutively lost data packets), the system generates an anomaly status flag for that terminal. This flag includes the anomaly type, the time of occurrence, and the associated indicator value.

[0062] Finally, the synchronization module summarizes and organizes the raw cache status, playback smoothness, and network link status reported by all terminals, combined with the end-to-end latency, number of consecutive packet losses, and any abnormal status markers that may be generated during the anomaly detection step. This information is encapsulated into a structured terminal status monitoring data object. Using the terminal ID as the primary key, this object clearly lists the complete performance profile of each terminal at the current moment, from the application layer to the network layer, providing data input for rendering the multi-terminal collaborative state diagram and subsequent quality assessment.

[0063] Optionally, the step of calculating and generating a trial continuity score for evaluating the stability of a single trial process based on the multi-terminal collaborative state diagram and the abnormal event records during the trial includes: Extract the duration and type of each terminal's collaborative anomaly from the multi-terminal collaborative state diagram; The system logs are used to obtain the number of times and duration of process interruptions caused by network or data problems during the court hearing, forming an abnormal event record. Based on the duration of the collaborative anomaly, the anomaly type, and the number and duration of interruptions in the anomaly event record, the network collaborative stability sub-score and the process continuity sub-score are calculated respectively. Based on the total duration of this court hearing, the network collaborative stability sub-score and the process continuity sub-score are weighted and normalized to generate a court hearing continuity score.

[0064] Specifically, the monitoring and evaluation module traces and analyzes the complete evolution record of the multi-terminal collaborative state graph during this court hearing. By analyzing the changes in the graph element states, the module can accurately extract the total duration and specific type of collaborative anomaly for each terminal during the hearing. For example, the system will record that "the defendant's terminal experienced a cumulative video stuttering duration of 180 seconds due to network jitter" or "the plaintiff's terminal experienced a 30-second display delay due to evidence preloading failure." These data constitute a measure of the micro-network collaborative quality.

[0065] The monitoring and evaluation module scans and analyzes system operation logs, especially error and warning entries. The module filters out events that directly disrupt the trial proceedings due to network or data issues, recording the number of interruptions and their duration. For example, the log might record "Trial suspended for 5 minutes due to complete network outage of the lead speaker" or "Procedure interrupted for 2 minutes due to corrupted evidence documents." These event records constitute a measure of overall process continuity.

[0066] The monitoring and evaluation module calculates a network coordination stability sub-score and a process continuity sub-score based on a pre-set scoring model. The network coordination stability sub-score reflects technical performance during the trial and uses a deduction system, with an initial maximum score of 100 points. The calculation formula is as follows: , Among them, 100 is the basic full score; This refers to the cumulative duration of collaborative anomalies extracted from the collaborative state diagram. This is the total duration of the court hearing; To address the severity impact factors for different types of anomalies, for example, in cases of minor video stuttering, this factor can be set between 20 and 50 to adjust the deduction after normalization; video anomalies involving key figures, such as stuttering of judges or speaking lawyers, affect the seriousness of the court proceedings and identity verification, and are classified as moderate severity, with a factor set between 50 and 80; audio anomalies, such as intermittent sound, missing words, and echoes caused by high latency, severely impact the generation of court transcripts and the judge's rulings, and are classified as high severity, with a factor set between 80 and 100. This formula ensures that the longer the anomaly lasts, the more points are deducted, and by dividing by the total duration, it eliminates scoring biases caused by varying trial lengths.

[0067] The procedural continuity sub-score reflects the coherence of the court proceedings. It also uses a deduction system, with an initial maximum score of 100 points. The calculation formula is as follows: , in, The number of interruptions that result in a substantial suspension of the trial proceedings; A fixed penalty score is imposed for each interruption (e.g., 5 points are deducted each time). The total duration of the interruption (in minutes); A dynamic penalty score is applied based on duration (e.g., 2 points are deducted for every minute of pause). This logic reflects the principle that "the more frequent the interruptions and the longer the pauses, the heavier the penalty on the score." Finally, the monitoring and evaluation module obtains the total duration of the trial and uses this as a benchmark to perform weighted normalization on the network collaboration stability sub-score and the process continuity sub-score. Normalization aims to eliminate the impact of different trial durations on the score, making trials of different durations comparable. The weighting reflects the system designers' emphasis on network collaboration quality and process assurance. This process can be expressed by the following formula: , in, It is the final score for the continuity of the trial. and These are the network collaborative stability sub-score and the process continuity sub-score, respectively. and These are preset weighting coefficients, and add Equal to 1, weighting coefficient and The settings were configured according to the business principle of "prioritizing procedural legality over audiovisual experience" in remote court hearings. Due to process interruption ( The reflection) may lead to the need to reschedule the trial or even procedural violations, while network fluctuations ( (Reflection) usually only affects efficiency, therefore setting In this embodiment, it can be set that... , . This is the total duration of this court hearing. This serves as a reference benchmark duration, such as 60 minutes. By dividing by the total duration for normalization, the impact of occasional minor issues during long trials can be adjusted, preventing an unreasonable decrease in the score due to increased trial duration. This calculation method, which combines multi-dimensionality, normalization, and weighted processing, ensures the objectivity and fairness of the trial continuity score.

[0068] Based on the same inventive concept, such as Figure 4 As shown, the present invention also provides a multi-terminal collaborative processing method for remote court hearings, the method comprising: The system acquires and processes real-time audio and video stream data from multiple devices during remote court hearings, real-time performance indicators of network links, and current hearing node information to obtain network quality data and hearing process status data. Feature extraction is performed on the network quality data to generate a network state feature vector characterizing the current multi-link transmission environment; Based on the network state feature vector and the preset session consistency identifier representing the progress of the court hearing, a link scheduling instruction for dynamically allocating transmission paths and resources is generated. Obtain an evidence submission request containing evidence data, perform preliminary compliance verification on the evidence data, and generate an evidence compliance label containing comprehensive verification results and display time sequence information; By integrating the link scheduling instructions, the evidence compliance tags, and the court hearing process status data, a rhythm control variable is generated to coordinate the transmission rhythm of multiple types of data streams. Based on the rhythm control variables, the subsequent audio and video stream data and the evidence data are driven to be transmitted collaboratively to multiple devices, and the multi-terminal collaborative state diagram reflecting the current collaborative state of all terminals is updated synchronously. Based on the multi-terminal collaborative state diagram and the records of abnormal events during the trial, a trial continuity score is calculated and generated to evaluate the stability of a single trial process.

[0069] To verify the feasibility and advancement of this invention in practice, it was applied to a simulated remote civil contract dispute trial. This trial involved three key participants: the judge, the plaintiff's lawyer, and the defendant's lawyer, all deployed in different geographical locations and accessing the system via the internet. The judge used the court's dedicated network, the plaintiff's lawyer used office Wi-Fi, and the defendant's lawyer used a 5G mobile network to simulate a real heterogeneous network environment.

[0070] This embodiment aims to verify the system's ability to perform multi-terminal collaborative processing and ensure the continuity of court proceedings in the face of network fluctuations and dynamic changes in the trial process. The test process covers the entire process from data collection, feature extraction, collaborative decision-making, evidence analysis, steady-state transmission, synchronous presentation to final evaluation.

[0071] First, during the "court debate" phase of the trial, the system's data acquisition module continuously collected network quality data from each terminal. At time T0, i.e., 10:15:00, the system detected a deterioration in the network quality of the plaintiff's lawyer, who was serving as the main speaker. The specific values ​​of the first and second network quality parameters acquired by the data acquisition module are as follows: the uplink packet loss rate of the audio and video stream RTP packet header parsing was 5%, and the jitter reached 80ms; the terminal API reported that its Wi-Fi signal strength RSSI dropped to -78dBm.

[0072] Subsequently, the feature extraction module analyzes the network quality data from time window T0-30s to T0. Since the current stage is the "court debate" phase and the plaintiff's lawyer is the main speaker, the system performs weighted fusion of the initial feature set according to a preset weight strategy matrix. For the main speaker role, the weight coefficients for audio uplink packet loss rate and audio uplink latency are increased to 0.4, while the weights of other features total 0.6. After weighted calculation, the components related to audio transmission stability in the generated network state feature vector are significantly lower than the warning threshold, indicating a high risk to the speaker's speaking quality.

[0073] Table 1. Extraction and Analysis of Network State Features During Court Debate Stage

[0074] Based on the low network state feature vector, the collaborative decision-making module initiates intervention. The session consistency identifier generated by the module requires the main speaker's audio end-to-end latency to be less than 150ms. The current latency of 180ms no longer meets the requirement. Therefore, the system performs resource scheduling analysis and generates a link scheduling instruction at T0+1s, i.e., 10:15:01. The instruction includes: 1) instructing the plaintiff's lawyer to switch the primary audio transmission path from Wi-Fi to its backup 5G link; 2) enabling a 15% forward error correction (FEC) redundancy strategy for audio data packets on this 5G link.

[0075] During the trial proceedings at the "Evidence Presentation and Examination" stage, the defendant's lawyer submitted a 350MB video evidence at time T1 (10:30:00). Upon receiving this request, the feature analysis module immediately invoked the compliance verification rule base. The verification results were as follows: format verification (MP4) passed; size verification failed due to exceeding the system's preset 200MB limit; digital signature verification passed; stage judgment (evidence submission is allowed during the evidence presentation and examination stage) passed. Because the size verification failed, the overall verification result was "failed." The system generated an evidence compliance tag containing this result and returned a "Evidence file too large, submission failed" message to the defendant's lawyer, preventing the large file from entering the transmission process and avoiding network congestion.

[0076] Subsequently, at time T2 (10:35:00), the plaintiff's lawyer submitted a 25MB PDF evidence file with a valid digital signature. After verification by the feature analysis module, all items passed, and the overall verification result was "Pass". Simultaneously, based on the current court hearing queue, the module predicted the expected presentation window for this evidence to be T2+10 minutes, i.e., 10:45:00. Based on this, an evidence compliance label containing "Pass" and "Presentation Time 10:45:00" was generated.

[0077] After receiving the compliance tag, the steady-state transmission module calculates the pre-loading time point for the evidence. Based on a size of 25MB and an estimated average transmission rate, with a 3-minute lead time, the calculated pre-loading time point is T2+5 minutes, or 10:40:00. The module then generates a rhythm control variable, in which the transmission timing schedule explicitly indicates that background chunked transmission of the PDF file should begin at 10:40:00.

[0078] The synchronization module executes operations according to this rhythm control variable. At 10:40:00, the system initiates background transmission of evidence files to all terminals. On the multi-terminal collaboration status diagram, an evidence preloading progress bar appears next to the icon of each participating party. By 10:42:30, the cache status of all terminals reaches 100%, and the progress bar shows the completion status. When the judge announces the presentation of the evidence at 10:45:15, all terminals can load and synchronously present the evidence from their local cache within milliseconds, without any network latency.

[0079] The entire court hearing concluded at 11:30:00, lasting a total of 90 minutes. The monitoring and evaluation module conducted a post-mortem evaluation of the entire process.

[0080] After the trial concluded, the monitoring and evaluation module calculated the trial continuity score based on the process log. System logs showed a brief interruption of 10 seconds in the trial proceedings due to a brief network switchover, during which the judge requested the speaker to repeat themselves. The multi-terminal collaboration status graph historical records showed that the defendant's lawyer's video feed experienced a cumulative 45 seconds of slight lag (collaboration anomaly) due to occasional network fluctuations. This is assumed to be based on a standard trial duration of 90 minutes.

[0081] Table 2. Court Hearing Continuity Assessment Data and Scores

[0082] In summary, Table 1 illustrates how the system weights network characteristics based on roles and trial stages to identify key network issues affecting the core trial process. The system's complete closed loop from decision-making to execution, including dynamic path optimization of real-time audio and video streams and pre-verification and asynchronous preloading of evidence data, ensures the smooth conduct of the trial. Table 2's final score of 96.716 quantifies the effectiveness of this invention in ensuring the continuity and stability of trials. Compared to traditional video conferencing systems that rely solely on passive network adaptation, this invention improves the reliability and procedural safeguards of remote trials through proactive, collaborative, and business process-oriented control.

[0083] It should be noted that the above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the invention. That is, any equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Those skilled in the art will readily conceive of other embodiments of the invention upon considering the disclosure of the specification and practical truths. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A multi-terminal collaborative processing system for remote court hearings, characterized in that, The system includes: The data acquisition module is used to acquire real-time audio and video stream data from multiple devices in remote court hearings, real-time performance indicators of network links, and current court hearing node information for processing, in order to obtain network quality data and court hearing process status data. The feature extraction module is used to extract features from the network quality data and generate a network state feature vector that characterizes the current multi-link transmission environment. The collaborative decision-making module is used to generate link scheduling instructions for dynamically allocating transmission paths and resources based on the network state feature vector and a preset session consistency identifier representing the progress of the court hearing. The feature analysis module is used to obtain evidence submission requests containing evidence data, perform preliminary compliance verification on the evidence data, and generate evidence compliance tags containing comprehensive verification results and display time sequence information. A steady-state transmission module is used to integrate the link scheduling instructions, the evidence compliance tags, and the court hearing process status data to generate a rhythm control variable for coordinating the transmission rhythm of multiple data streams. The synchronization module is used to drive the subsequent audio and video stream data and the evidence data to be transmitted collaboratively to multiple devices according to the rhythm control variable, and to synchronously update the multi-terminal collaborative status diagram reflecting the current collaborative status of all terminals. The monitoring and evaluation module is used to calculate and generate a trial continuity score to evaluate the stability of a single trial process based on the multi-terminal collaborative status diagram and the abnormal event records during the trial.

2. The multi-terminal collaborative processing system for remote court hearings according to claim 1, characterized in that, The process of acquiring and processing real-time audio and video stream data from multiple devices during remote court hearings, real-time performance indicators of network links, and current hearing node information to obtain network quality data and court hearing process status data includes: Acquire real-time audio and video stream data from the terminals of each participating party in a remote court hearing, and extract the first network quality parameter from the packet header information of the real-time audio and video stream data; The real-time performance metrics of multiple heterogeneous network links connected to the terminals of each participating party are obtained as a second network quality parameter. The first network quality parameter and the second network quality parameter are combined to form network quality data; The system acquires information about the current trial node and the operation status of each terminal, and integrates the trial node information and the operation status information to generate trial process status data.

3. A multi-terminal collaborative processing system for remote court hearings according to claim 2, characterized in that, The step of extracting features from the network quality data to generate a network state feature vector characterizing the current multi-link transmission environment includes: The network quality data is analyzed in the time and frequency domains to extract comprehensive features reflecting link latency, jitter, packet loss rate, and bandwidth utilization, forming an initial feature set. Based on the role attributes of each participating terminal and the current stage of the court proceedings, the initial feature set is weighted and fused to generate the network state feature vector.

4. A multi-terminal collaborative processing system for remote court hearings according to claim 3, characterized in that, The step of generating link scheduling instructions for dynamically allocating transmission paths and resources based on the network state feature vector and a preset session consistency identifier representing the progress of the court hearing includes: Based on the type of this court hearing and the pre-set court hearing process template, generate a basic conversation template that represents fixed process nodes; By combining the current trial node information in the trial process status data, the basic session template is dynamically mapped to generate a session consistency identifier; Based on the network state feature vector and the session consistency identifier, resource scheduling analysis is performed, and link scheduling instructions including primary / backup transmission path selection strategy, redundant data packet strategy and dynamic bit rate adjustment strategy are output.

5. A multi-terminal collaborative processing system for remote court hearings according to claim 4, characterized in that, The process of obtaining an evidence submission request containing evidence data, performing preliminary compliance verification on the evidence data, and generating an evidence compliance label containing comprehensive verification results and display time sequence information includes: Obtain an evidence submission request from any participating party's terminal, wherein the evidence submission request carries an evidence type identifier and evidence data; Based on the evidence type identifier, the corresponding preset compliance verification rule base is invoked to verify the format, size, and digital signature of the evidence data, generating format verification results, size verification results, and signature verification results; Based on the court hearing process status data, determine whether the current hearing node is in the stage where evidence can be submitted, and obtain the stage determination result; Predict the expected presentation time window of the evidence data in subsequent court proceedings to obtain presentation timing information; The format verification result, the size verification result, the signature verification result, and the stage judgment result are aggregated to generate a comprehensive verification result; The comprehensive verification result is bound to the display time sequence information to generate an evidence compliance label.

6. A multi-terminal collaborative processing system for remote court hearings according to claim 5, characterized in that, The process of integrating the link scheduling instructions, the evidence compliance tags, and the court proceedings status data to generate rhythm control variables for coordinating the transmission rhythm of multiple data streams includes: The link scheduling instructions are analyzed to extract the priority transmission levels for audio and video stream data and the transmission triggering conditions for evidence data; The evidence compliance label is parsed, the expected display time window and the comprehensive verification result are extracted, and if the verification is passed, the pre-loading time point of the evidence data is calculated based on the expected display time window. Based on the current trial node information and the progress status in the trial process status data, predict the switching time of the next trial node; Based on the priority transmission level, the transmission triggering condition, the preloading time point, and the switching time of the next court hearing node, a rhythm control variable for coordinating the real-time transmission of audio and video stream data and the asynchronous transmission of evidence data is calculated and generated. The rhythm control variable includes a transmission timing schedule table and buffer management instructions.

7. A multi-terminal collaborative processing system for remote court hearings according to claim 6, characterized in that, The step of driving subsequent audio and video stream data and evidence data to be collaboratively transmitted to multiple devices based on the rhythm control variable, and synchronously updating the multi-terminal collaborative state diagram reflecting the current collaborative state of all terminals, includes: According to the transmission timing schedule table, before the preloading time point arrives, the background block transmission and terminal-side caching of the verified evidence data are initiated to obtain the cache status; During the court proceedings, the encoding bitrate and transmission path of the audio and video stream data of each terminal are adjusted according to the priority transmission level and the network status feature vector to obtain the playback smoothness and network link status. Real-time monitoring of the cache status, playback smoothness, and network link status of each terminal generates terminal status monitoring data; The terminal status monitoring data and the court hearing process status data are merged and rendered to generate visual primitives, and a multi-terminal collaborative status diagram reflecting the current collaborative status of all terminals is updated synchronously.

8. A multi-terminal collaborative processing system for remote court hearings according to claim 7, characterized in that, The real-time monitoring of the cache status, playback smoothness, and network link status of each terminal, generating terminal status monitoring data includes: Periodically send status query commands to each participating terminal, and receive feedback from each terminal on the cache status, playback smoothness, and network link status; Based on the cache status, evidence cache completion is generated; audio and video frame decoding latency is extracted from the playback smoothness; and signal strength of the current access link is extracted from the network link status. Based on the signal strength, the end-to-end delay and number of consecutive packet losses for each audio and video stream are calculated on the local server. An abnormal status flag is generated when it is detected that the evidence cache completion of any terminal is lower than the preset completion threshold, or the audio / video frame decoding delay exceeds the preset first tolerance threshold, or the number of consecutive packet losses exceeds the preset second tolerance threshold. The cache status, playback smoothness, network link status, end-to-end latency, number of consecutive packet losses, and abnormal status markers reported by all terminals are aggregated to form structured terminal status monitoring data.

9. A multi-terminal collaborative processing system for remote court hearings according to claim 7, characterized in that, The court hearing continuity score, calculated based on the multi-terminal collaborative state diagram and records of abnormal events during the court hearing, for evaluating the stability of a single court hearing process, includes: Extract the duration and type of each terminal's collaborative anomaly from the multi-terminal collaborative state diagram; The system logs are used to obtain the number of times and duration of process interruptions caused by network or data problems during the court hearing, forming an abnormal event record. Based on the duration of the collaborative anomaly, the anomaly type, and the number and duration of interruptions in the anomaly event record, the network collaborative stability sub-score and the process continuity sub-score are calculated respectively. Based on the total duration of this court hearing, the network collaborative stability sub-score and the process continuity sub-score are weighted and normalized to generate a court hearing continuity score.

10. A multi-terminal collaborative processing method for remote court hearings, characterized in that, The method includes: The system acquires and processes real-time audio and video stream data from multiple devices during remote court hearings, real-time performance indicators of network links, and current hearing node information to obtain network quality data and hearing process status data. Feature extraction is performed on the network quality data to generate a network state feature vector characterizing the current multi-link transmission environment; Based on the network state feature vector and the preset session consistency identifier representing the progress of the court hearing, a link scheduling instruction for dynamically allocating transmission paths and resources is generated. Obtain an evidence submission request containing evidence data, perform preliminary compliance verification on the evidence data, and generate an evidence compliance label containing comprehensive verification results and display time sequence information; By integrating the link scheduling instructions, the evidence compliance tags, and the court hearing process status data, a rhythm control variable is generated to coordinate the transmission rhythm of multiple types of data streams. Based on the rhythm control variables, the subsequent audio and video stream data and the evidence data are driven to be transmitted collaboratively to multiple devices, and the multi-terminal collaborative state diagram reflecting the current collaborative state of all terminals is updated synchronously. Based on the multi-terminal collaborative state diagram and the abnormal event records during the court hearing, a court hearing continuity score is calculated and generated to evaluate the stability of a single court hearing process.

Images