Front-end peripheral drive and authority management method

Abstract

The invention provides a front-end peripheral driving and authority management method. Through automatic enumeration and drive template matching of the device descriptor, plug and play and cross-platform compatibility of the peripheral drive are realized, and the development complexity is reduced; in combination with a fine-grained equipment access strategy and a secure sandbox environment, authority control is refined to an operation level (such as a read-write command and a data range), unauthorized and high-risk operations are effectively intercepted, and the system security is improved; an original byte stream and structured data are bidirectionally converted through an asynchronous data interaction and protocol adaptation mechanism, and the data interaction performance is circularly optimized based on a browser event, so that a main thread is prevented from being blocked; meanwhile, a resource optimization management process (such as a data buffer pool and a connection pool) is combined with real-time monitoring and self-adaptive degradation, memory fragments and resource competition are reduced, and response efficiency under high load is guaranteed. Therefore, the problems of driver redundancy, extensive authority and performance bottleneck in the traditional scheme are solved.

Description

Technical Field

[0001] This application relates to the field of device management, and in particular to a method for front-end peripheral driver and permission management. Background Technology

[0002] With the development of the Internet of Things (IoT) and edge computing, front-end applications increasingly need to interact directly with physical peripherals, such as sensors, printers, payment terminals, and industrial controllers. Traditional peripheral drivers rely on operating systems or native applications, which limits the cross-platform deployment and real-time control capabilities of web applications.

[0003] To overcome this bottleneck, some implementations, such as the WebHID and WebUSB standards, allow web pages to directly access HID and USB devices via browser APIs without requiring additional drivers. However, these standards only provide low-level device communication interfaces and lack high-level driver management, access control, and security isolation mechanisms. In practical applications, peripherals are diverse and their protocols are heterogeneous. Developers need to manually parse device descriptors, implement packet encoding and decoding, handle asynchronous I / O streams, and address issues like hot-plugging and concurrent access from multiple applications. Furthermore, access control is often rudimentary; once a user authorizes an application, it can completely control the device, posing risks of data leakage and malicious operation. Existing solutions often focus on device communication, neglecting driver reuse, granular access control, and performance optimization, resulting in high development complexity, poor security, and insufficient cross-platform compatibility. Therefore, a front-end peripheral driver and access control method is urgently needed to achieve unified abstraction, secure isolation, and efficient management of peripheral drivers. Summary of the Invention

[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the poor security and efficiency of peripheral driver management in the prior art.

[0005] Firstly, this application provides a front-end peripheral driver and permission management method, the method comprising:

[0006] Enumerate the target peripherals through the device interfaces of the target device and obtain the device descriptors of each target peripheral;

[0007] The device descriptor is matched with the pre-registered driver template to determine the target driver strategy for each target peripheral.

[0008] Determine the device access policy for each of the target peripherals;

[0009] According to the target driving strategy and the device access strategy, asynchronous data interaction between each target peripheral and the target device is performed.

[0010] Furthermore, during the data interaction process between each of the target peripherals and the target device, protocol adaptation is performed on each of the target peripherals.

[0011] As an optional implementation, the step of matching the device descriptor with the pre-registered driver template to determine the target driver strategy for each target peripheral includes:

[0012] Selectable templates are filtered from the pre-registered driver templates based on information related to device type and protocol type in the device descriptor;

[0013] The pre-registered driver template is used to indicate the device function set, data format, command set, and event mapping.

[0014] Based on the signature and compatibility list in the device descriptor, a first target driving strategy is determined from the optional template;

[0015] If the optional template or the target driver strategy fails to match, then the endpoint data, target report descriptor and driver configuration items are obtained according to the device descriptor to generate the driver skeleton;

[0016] Furthermore, the method also includes driver registration, specifically including:

[0017] Dynamically load the first target driving strategy or the second target driving strategy corresponding to the driving skeleton from the remote repository, instantiate the first target driving strategy or the second driving strategy, and inject the device handle and configuration parameters to execute the first target driving strategy or the second driving strategy.

[0018] As an optional implementation, the protocol adapter is used to convert the input data corresponding to each of the target peripherals into a first structured data object, or to convert the second structured data object into output data in a preset format, specifically including:

[0019] For the input data, the original byte stream corresponding to the input data is parsed according to the driver report descriptor in the target driving strategy, and field extraction, unit conversion, form verification and data validation are performed to convert it into a first structured data object;

[0020] For the output data, the second structured data object is encoded into the data format corresponding to the target peripheral, and the packet header, serial number and verification field are injected to convert it into output data in a preset format.

[0021] As an optional implementation, the method further includes:

[0022] During the data interaction between each of the target peripherals and the target device, a custom parsing process is registered to the extensible parsing pipeline to perform data parsing.

[0023] The scalable parsing pipeline is used to receive the custom parsing process and insert the custom parsing process into a preset processing stage of the pipeline. The preset processing stage of the data parsing includes data framing, decryption, decompression and semantic parsing.

[0024] Furthermore, during the data parsing process, parsing anomalies in any of the preset processing stages are handled through error detection and retry mechanisms.

[0025] As an optional implementation, determining the device access policy for each of the target peripherals includes:

[0026] Declare the device capability set during the driver registration process;

[0027] The device capability set includes readable data fields, writable commands, and controllable function identifiers;

[0028] During the authorization phase, a list of permission options is generated, and operation scope information is received;

[0029] Based on the device capability set and the operation range information, determine the device access policy corresponding to each of the target peripherals;

[0030] Furthermore, during the asynchronous data interaction process, the method further includes:

[0031] In a secure sandbox environment, for any operation of the target application corresponding to any of the aforementioned target peripherals, verify whether the operation type and data range comply with the device access policy;

[0032] When an unauthorized or high-risk operation is initiated, a secondary confirmation process is triggered.

[0033] As an optional implementation, the asynchronous data interaction is achieved through a browser event loop and an asynchronous operation chain, specifically including:

[0034] The event scheduling module determines the device event flow for each of the target peripherals.

[0035] The event scheduling module is used to schedule the specific execution process according to the priority of each device event stream and the deadline event.

[0036] Perform one or more of the following processing steps on the high-frequency data stream in the device event stream: configure buffer window, dynamically adjust sampling rate, or merge consecutive events;

[0037] When the data volume of the device event stream accumulates within a preset time period, data cleanup or data flow control is triggered based on the back pressure control mechanism.

[0038] As an optional implementation, the method further includes a resource optimization management process, specifically comprising:

[0039] Pre-allocated data buffer pool;

[0040] The data buffer pool reuses memory blocks through reference counting and pooling.

[0041] Management equipment connection pool;

[0042] The device connection pool is used to keep connections active for short-term access and remove invalid connections in real time.

[0043] Real-time monitoring of the resource usage indicators of each target peripheral device; when any of the resource usage indicators exceeds a preset threshold, trigger execution of one or more resource degradation processes.

[0044] The resource usage metrics include response latency, error rate, memory usage, and device load. The resource degradation process includes reducing the data sampling rate, disabling non-critical functions, switching data interaction to simulation mode, or releasing idle connections.

[0045] Secondly, this application provides a front-end peripheral driver and permission management device, the device comprising:

[0046] The acquisition module is used to enumerate target peripherals through the device interface of the target device and obtain the device descriptors of each target peripheral.

[0047] The processing module is used to perform driver matching between the device descriptor and the pre-registered driver template to determine the target driver strategy for each target peripheral.

[0048] The processing module is also used to determine the device access policy for each of the target peripherals;

[0049] The processing module is further configured to perform asynchronous data interaction between each target peripheral and the target device according to the target driving strategy and the device access strategy;

[0050] The processing module is further configured to perform protocol adaptation for each of the target peripherals during the data interaction process between each target peripheral and the target device.

[0051] Thirdly, this application provides a computer device including one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method described in the first aspect.

[0052] Fourthly, this application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method described in the first aspect.

[0053] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0054] Based on any of the above embodiments, this application first enumerates target peripherals and parses device descriptors through the device interface. Combined with a multi-level matching strategy of pre-registered driver templates (device type filtering → precise feature code positioning), it achieves automatic loading and instantiation of drivers, significantly reducing the cost for developers to manually parse protocols and adapt hardware. At the permission management level, fine-grained access policies are generated based on the declared device capability set (readable fields, writable commands), and the legality of operations is verified in a security sandbox. High-risk instructions are intercepted through a secondary confirmation mechanism, preventing data leakage and malicious control from the root. The data interaction link adopts an asynchronous architecture. The protocol adaptation module parses the original device data into structured objects (including field extraction, unit conversion, and verification). At the same time, the event scheduling module dynamically merges high-frequency events and alleviates backlog traffic through backpressure control, ensuring real-time performance. In addition, the pre-allocated memory pool and connection pool reuse resources through reference counting. Combined with real-time monitoring indicators (latency, error rate) to trigger degradation strategies (such as sampling rate adjustment and simulation mode switching), it effectively copes with hot-plugging of devices and concurrent scenarios of multiple applications, improving system robustness and resource utilization. In summary, it achieves unified abstraction, secure isolation, and efficient management of peripheral drivers. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application 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 only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 A flowchart illustrating a front-end peripheral driver and permission management method provided in one embodiment of this application;

[0057] Figure 2 This is an internal structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] With the development of the Internet of Things (IoT) and edge computing, front-end applications increasingly need to interact directly with physical peripherals, such as sensors, printers, payment terminals, and industrial controllers. Traditional peripheral drivers rely on operating systems or native applications, limiting the cross-platform deployment and real-time control capabilities of web applications. To overcome this bottleneck, the W3C introduced the WebHID and WebUSB standards, allowing web pages to directly access HID and USB devices via browser APIs without requiring additional drivers. However, these standards only provide low-level device communication interfaces, lacking high-level driver management, access control, and security isolation mechanisms. In practical applications, peripherals are diverse and their protocols are heterogeneous. Developers need to manually parse device descriptors, implement packet encoding and decoding, handle asynchronous I / O streams, and address issues such as hot-plugging and concurrent access by multiple applications. Furthermore, access control is often rudimentary; once a user authorizes an application, it can completely control the device, posing risks of data leakage and malicious operation. Existing solutions often focus on device communication, neglecting driver reuse, granular access control, and performance optimization, resulting in high development complexity, poor security, and insufficient cross-platform compatibility. Therefore, there is an urgent need for a front-end peripheral driver and permission management system based on WebHID and WebUSB to achieve unified abstraction, secure isolation and efficient management of peripheral drivers.

[0060] In some application scenarios, device driver and management solutions can include the following implementation methods:

[0061] Native WebHID and WebUSB APIs: Based on W3C standards, these provide basic functions such as device enumeration, connection, and data transmission and reception. This solution enables web pages to communicate directly with peripherals, but developers need to implement device driver logic themselves, including descriptor parsing, protocol adaptation, and error handling, resulting in redundant and error-prone code. The permission model only supports global device access authorization and cannot be refined to specific operations or data scopes, posing a high security risk.

[0062] Browser extension or plugin solution: This approach calls native APIs through browser extensions, encapsulates some driver logic, and provides richer access control. However, this solution relies on extension installation, breaking the deployment-free nature of web applications. Furthermore, communication between the extension and the webpage requires message passing, introducing performance overhead and complexity. Incompatibility between different browser extension APIs also makes cross-platform deployment difficult.

[0063] Third-party JavaScript driver libraries, such as node-hid or usb libraries, are wrappers within the Node.js environment, providing high-level driver interfaces. However, these libraries cannot be directly used in browser environments and typically lack access control. Some libraries attempt to be ported via WebAssembly, but are limited by browser sandboxes, have incomplete device access capabilities, and suffer from complex memory management.

[0064] Cloud-driven or gateway proxy solutions: These solutions deploy peripheral drivers in the cloud or on a local gateway, with the front-end communicating with the proxy via WebSocket or HTTP. While this isolates the front-end from the device, it introduces network latency and single points of failure, making it unsuitable for real-time control scenarios. Furthermore, the proxy itself needs to maintain device status and sessions, resulting in high system complexity.

[0065] Therefore, these feasible implementation methods have the following limitations:

[0066] The development complexity of the driver is high: developers need to have a deep understanding of device protocols and hardware specifications, manually implement data parsing, state machines and error recovery, and the code is repetitive and the maintenance cost is high.

[0067] Lax access control and security vulnerabilities: Existing permission models only support device-level authorization. Once authorized, applications can perform arbitrary operations, and cannot restrict specific functions or data scope, which can easily lead to unauthorized access and malicious attacks.

[0068] Lack of device management and resource contention: When multiple applications or tabs access the same device simultaneously, the lack of locking mechanisms and scheduling strategies leads to data conflicts and chaotic device states. Inadequate hot-swapping handling results in the inability to automatically recover after a session interruption.

[0069] Performance bottlenecks and resource leaks: High-frequency data transmission and reception may block the main thread, and unoptimized buffer management and event listening may lead to memory leaks and response delays, affecting user experience.

[0070] Therefore, this application aims to construct a unified peripheral driver abstraction layer, encapsulating the underlying operations of WebHID and WebUSB through automatic device descriptor resolution and a protocol template library, providing a declarative driver interface to reduce development complexity. It implements fine-grained permission management, introducing a capability-based security model that decomposes device access permissions into read, write, and control operation levels, and supports data range restrictions to improve system security. Furthermore, it provides a device session and resource scheduling mechanism, resolving multi-application resource contention issues through device locks, request queues, and state synchronization, and achieving hot-plug adaptive recovery to ensure reliable interaction. Simultaneously, it optimizes performance and resource utilization by employing asynchronous non-blocking I / O, memory pools, and event filtering technologies to reduce main thread blocking and memory fragmentation, ensuring system response efficiency under high load.

[0071] In summary, the technical concept of this application is as follows: First, it enumerates target peripherals and parses device descriptors through device interfaces. Combined with a multi-level matching strategy of pre-registered driver templates (device type filtering → precise feature code positioning), it achieves automatic loading and instantiation of drivers, significantly reducing the cost for developers to manually parse protocols and adapt hardware. At the permission management level, it generates fine-grained access policies based on the declared device capability set (readable fields, writable commands) and verifies the legality of operations in a security sandbox. High-risk commands are intercepted through a secondary confirmation mechanism, preventing data leakage and malicious control from the root. The data interaction process adopts an asynchronous architecture. The protocol adaptation module parses the raw device data into structured objects (including field extraction, unit conversion, and verification). At the same time, the event scheduling module dynamically merges high-frequency events and alleviates backlog traffic through backpressure control, ensuring real-time performance. In addition, the pre-allocated memory pool and connection pool reuse resources through reference counting. Combined with real-time monitoring indicators (latency, error rate) to trigger degradation strategies (such as sampling rate adjustment and simulation mode switching), it effectively copes with hot-plugging of devices and concurrent scenarios of multiple applications, improving system robustness and resource utilization. In summary, it achieves unified abstraction, secure isolation, and efficient management of peripheral drivers.

[0072] The methods provided in this application will be described in detail below based on the corresponding implementation methods in some practical application scenarios.

[0073] Figure 1 This is a flowchart illustrating a front-end peripheral driver and permission management method provided in one embodiment of this application, as shown below. Figure 1 As shown, this application provides a front-end peripheral driver and permission management method, the method comprising:

[0074] S101. Enumerate the target peripherals through the device interface of the target device and obtain the device descriptor of each target peripheral;

[0075] In this application, the device descriptor is used to indicate the device identity and related information of each target peripheral, which may include vendor ID, product ID, interface type, device type, device signature, device compatibility list, etc.

[0076] S102. Perform driver matching between the device descriptor and the pre-registered driver template to determine the target driver strategy for each target peripheral.

[0077] As an optional implementation, the step of matching the device descriptor with the pre-registered driver template to determine the target driver strategy for each target peripheral includes:

[0078] Selectable templates are filtered from the pre-registered driver templates based on information related to device type and protocol type in the device descriptor;

[0079] The pre-registered driver template is used to indicate the device function set, data format, command set, and event mapping.

[0080] Based on the signature and compatibility list in the device descriptor, a first target driving strategy is determined from the optional template;

[0081] If the optional template or the target driver strategy fails to match, then the endpoint data, target report descriptor and driver configuration items are obtained according to the device descriptor to generate the driver skeleton;

[0082] Furthermore, the method also includes driver registration, specifically including:

[0083] Dynamically load the first target driving strategy or the second target driving strategy corresponding to the driving skeleton from the remote repository, instantiate the first target driving strategy or the second driving strategy, and inject the device handle and configuration parameters to execute the first target driving strategy or the second driving strategy.

[0084] Driver matching and registration can be achieved through automatic device descriptor parsing and the driver loader. This module, as the first layer of peripheral connection processing, is responsible for device enumeration and automatic driver matching. The system scans available devices via WebHID and WebUSB APIs to obtain device descriptors (vendor ID, product ID, interface class). The driver loader has a built-in device knowledge base and matches the descriptors with pre-registered driver templates. The matching process uses a multi-level indexing strategy: first, a coarse screening is performed based on device class and protocol type, and then the optimal driver template is precisely located through feature codes and compatibility lists. For unknown devices, the system provides a descriptor parser that automatically extracts endpoints, report descriptors, and configuration items, and generates a basic driver skeleton. The driver template uses a JSON-style declaration structure, defining the device function set, data format, command set, and event mapping. The loader instantiates the driver object based on the template and injects the device handle and configuration parameters to achieve plug-and-play functionality. The system supports dynamic driver updates, pulling the latest drivers from a remote repository through version numbers and dependency management to ensure device compatibility.

[0085] This implementation filters driver templates based on type and protocol information in the device descriptor, narrowing the matching range and improving driver retrieval efficiency. It accurately locates the first target driver strategy from the available templates using feature codes and a compatibility list, ensuring driver compatibility with device hardware. When a match fails, a driver skeleton is dynamically generated based on endpoint data and report descriptors, expanding support for unknown devices. During the driver registration phase, driver strategies are dynamically loaded and instantiated from a remote repository, injecting real-time device handles and configuration parameters to achieve plug-and-play functionality and remote update and maintenance. This process significantly reduces the complexity of driver deployment and enhances the system's flexibility and scalability.

[0086] S103. Determine the device access policy for each of the target peripherals;

[0087] As an optional implementation, determining the device access policy for each of the target peripherals includes:

[0088] Declare the device capability set during the driver registration process;

[0089] The device capability set includes readable data fields, writable commands, and controllable function identifiers;

[0090] During the authorization phase, a list of permission options is generated, and operation scope information is received;

[0091] Based on the device capability set and the operation range information, determine the device access policy corresponding to each of the target peripherals;

[0092] Specifically, fine-grained access control can be achieved through capability declarations and dynamic permission granters, defining device access policies based on a capability security model. The system declares a set of device capabilities (readable data fields, writable commands, and controllable functions) during driver registration. When granting user authorization, the permission granter no longer simply grants global access rights but presents a list of capabilities for the user to choose from (allowing only reading sensor data but not writing configuration files). Dynamic permission granting supports runtime permission escalation: when an application attempts to perform an unauthorized operation, the system triggers secondary confirmation from the user and intelligently recommends the minimum permission set based on the context (application origin, device sensitivity). Permission states are persisted through browser storage and an indexed database, and cross-session recovery is supported.

[0093] Furthermore, during the asynchronous data interaction process, the method further includes:

[0094] In a secure sandbox environment, for any operation of the target application corresponding to any of the aforementioned target peripherals, verify whether the operation type and data range comply with the device access policy;

[0095] When an unauthorized or high-risk operation is initiated, a secondary confirmation process is triggered.

[0096] This application also provides a secure sandbox and operation validator to build an isolated execution environment, restricting direct application operations on devices. All device access requests are first verified by the sandbox, checking the legitimacy of the permission token and operation. The validator, based on a rule engine, matches the operation type (read, write, control) with the authorization capability and verifies the data scope (e.g., only allowing access to fields with specific report IDs). For high-risk operations (firmware updates, factory resets), the system mandates real-time user confirmation or two-factor authentication. The sandbox also integrates input filtering and output sanitization to prevent malicious data packets from causing device malfunctions. Operation logs record all device interactions for auditing and anomaly detection.

[0097] This implementation declares the device capability set (such as readable fields and writable commands) during driver registration, clearly defining the security boundaries of the peripheral device. During the authorization phase, a list of permission options is generated for users to select the scope of operations, achieving fine-grained permission allocation. During asynchronous interaction, the operation type and data scope are verified within a security sandbox to ensure compliance with access policies, intercepting unauthorized behavior. For unauthorized or high-risk operations (such as firmware writing), secondary confirmation is triggered, strengthening the security audit of critical operations. This mechanism refines traditional device-level authorization to the operation level, effectively preventing malicious control and data abuse.

[0098] S104. According to the target driving strategy and the device access strategy, perform asynchronous data interaction between each target peripheral and the target device;

[0099] As an optional implementation, the asynchronous data interaction is achieved through a browser event loop and an asynchronous operation chain, specifically including:

[0100] The event scheduling module determines the device event flow for each of the target peripherals.

[0101] The event scheduling module is used to schedule the specific execution process according to the priority of each device event stream and the deadline event.

[0102] Perform one or more of the following processing steps on the high-frequency data stream in the device event stream: configure buffer window, dynamically adjust sampling rate, or merge consecutive events;

[0103] When the data volume of the device event stream accumulates within a preset time period, data cleanup or data flow control is triggered based on the back pressure control mechanism.

[0104] In specific application scenarios, device data transmission and reception performance is optimized through asynchronous non-blocking I / O and an event scheduler, employing a fully asynchronous architecture. The system handles all I / O operations via the browser event loop and Promise chain, avoiding blocking the main thread. The event scheduler manages multiple device event streams, scheduling callback execution based on priority and deadline. For high-frequency data streams (such as sensor sampling), the system provides configurable sampling rates and buffer windows, merging consecutive events to reduce processing overhead. The scheduler also supports backpressure control, automatically discarding expired data or triggering flow control when the consumption rate is lower than the production rate to prevent memory overflow.

[0105] This implementation optimizes the execution order of asynchronous tasks by scheduling device event streams according to priority and deadline using an event scheduling module; it configures buffer windows or dynamically adjusts the sampling rate for high-frequency data streams to reduce redundant event processing overhead; and it triggers a backpressure control mechanism (such as cleaning up expired data or rate limiting) when data backlog occurs to prevent memory overflow. This process utilizes the non-blocking characteristics of the browser event loop to ensure system response speed and stability under high concurrency data.

[0106] Furthermore, during the data interaction process between each of the target peripherals and the target device, protocol adaptation is performed on each of the target peripherals.

[0107] As an optional implementation, the protocol adapter is used to convert the input data corresponding to each of the target peripherals into a first structured data object, or to convert the second structured data object into output data in a preset format, specifically including:

[0108] For the input data, the original byte stream corresponding to the input data is parsed according to the driver report descriptor in the target driving strategy, and field extraction, unit conversion, form verification and data validation are performed to convert it into a first structured data object;

[0109] For the output data, the second structured data object is encoded into the data format corresponding to the target peripheral, and the packet header, serial number and verification field are injected to convert it into output data in a preset format.

[0110] This section is implemented through protocol adaptation and data converters, with components specifically responsible for converting between device protocols and front-end data models. The system includes built-in interpreters for common protocols such as HID reporting protocols, USB control transfers, and bulk transfers. For input data, the adapter parses the raw byte stream into structured objects based on the report descriptor in the driver template, including field extraction, unit conversion, and checksum verification. For output data, the adapter encodes JavaScript objects into the binary format required by the device and automatically fills in the packet header, serial number, and CRC fields. For complex protocols (custom industrial protocols), the system provides an extensible parsing pipeline, allowing developers to register custom parsers and conversion rules. The parsing pipeline adopts a pipelined architecture, sequentially performing data framing, decryption, decompression, and semantic parsing, and handling transmission anomalies through error detection and retry mechanisms. The data converter supports multiple output formats, such as JSON, ArrayBuffer, or Stream, adapting to different application scenarios.

[0111] In this implementation, during protocol adaptation, for input data, the raw byte stream is parsed based on the driver report descriptor. A structured object is generated through field extraction, unit conversion, and data validation, improving data readability and accuracy. For output data, the structured object is encoded into a binary format supported by the target device, and a header, serial number, and verification field are automatically injected to ensure data transmission integrity and device compatibility. This bidirectional conversion mechanism solves the data standardization problem of heterogeneous protocols and reduces the development burden of application layer processing device data.

[0112] As an optional implementation, the method further includes:

[0113] During the data interaction between each of the target peripherals and the target device, a custom parsing process is registered to the extensible parsing pipeline to perform data parsing.

[0114] The scalable parsing pipeline is used to receive the custom parsing process and insert the custom parsing process into a preset processing stage of the pipeline. The preset processing stage of the data parsing includes data framing, decryption, decompression and semantic parsing.

[0115] Furthermore, during the data parsing process, parsing anomalies in any of the preset processing stages are handled through error detection and retry mechanisms.

[0116] This implementation registers a custom parsing process to an extensible parsing pipeline during data interaction, allowing developers to extend processing stages such as data framing, decryption, or semantic parsing as needed, enhancing the flexibility of protocol adaptation. It executes each parsing stage in an orderly manner through a pipelined architecture, and handles parsing anomalies with error detection and retry mechanisms, ensuring the robustness of data processing. This design can cover complex scenarios such as custom protocols in industrial equipment, improving the system's adaptability and fault tolerance.

[0117] This application enumerates peripherals and obtains device descriptors through the target device's interface, providing a precise device identification foundation for subsequent driver matching. It matches the descriptors with pre-registered driver templates to determine the target driver strategy, achieving automated driver adaptation and loading, avoiding developers manually writing underlying protocol parsing code. Based on the device capability set, it generates fine-grained device access policies, restricting application access to specific functions or data, reducing the risk of unauthorized access. During asynchronous data interaction, it combines the protocol rules of the target driver strategy with the security constraints of the access policy to ensure efficient and compliant data transmission. Simultaneously, it performs real-time protocol adaptation during data interaction, converting raw peripheral data into structured objects or reverse encoding, resolving heterogeneous device protocol compatibility issues. Therefore, it lowers the development threshold for front-end peripheral integration, strengthens security control, and improves the reliability of cross-device communication.

[0118] As an optional implementation, the method further includes a resource optimization management process, specifically comprising:

[0119] Pre-allocated data buffer pool;

[0120] The data buffer pool reuses memory blocks through reference counting and pooling.

[0121] Management equipment connection pool;

[0122] The device connection pool is used to keep connections active for short-term access and remove invalid connections in real time.

[0123] Real-time monitoring of the resource usage indicators of each target peripheral device; when any of the resource usage indicators exceeds a preset threshold, trigger execution of one or more resource degradation processes.

[0124] The resource usage metrics include response latency, error rate, memory usage, and device load. The resource degradation process includes reducing the data sampling rate, disabling non-critical functions, switching data interaction to simulation mode, or releasing idle connections.

[0125] This implementation improves resource utilization and reduces dynamic allocation overhead through a memory pool and connection pool manager. The system pre-allocates a fixed-size memory pool for data buffering, reusing memory blocks through reference counting and pooling techniques to reduce garbage collection pressure. The connection pool manager maintains active device connections, supporting connection reuse and lazy establishment. For short-term access, the pool manager keeps connections active for a period of time to avoid latency caused by frequent device opening and closing. The manager performs connection health checks and automatic rebuilding, handling device unresponsiveness or abnormal disconnections.

[0126] Furthermore, the system collects real-time system metrics, including response latency, error rate, memory usage, and device load, through monitoring and adaptive degradation mechanisms. The monitor sets threshold alarms and triggers adaptive degradation strategies when resources are strained. Degradation strategies include reducing the data sampling rate, disabling non-critical functions, switching to simulation mode, or releasing idle connections. The system provides a performance analysis interface, outputting detailed metric reports to help developers optimize driver logic and resource configuration.

[0127] This implementation pre-allocates a data buffer pool and reuses memory blocks using reference counting, reducing dynamic allocation overhead; it manages a device connection pool to maintain connection activity for short-term access, avoiding latency from frequent start-stop cycles; and it monitors resource metrics (such as latency and memory usage) in real time, triggering degradation strategies (such as disabling non-critical functions or switching to simulation mode) when thresholds are exceeded, dynamically releasing resources. This process significantly reduces garbage collection pressure and improves system resilience in resource-scarce scenarios.

[0128] As an optional implementation, device session management may include: assigning an independent session context to each peripheral device, recording device status and active command queues; responding to device hot-plug events and automatically resuming sessions through a heartbeat detection mechanism; scheduling concurrent requests from multiple applications through a priority queue and setting timeout policies to release resource locks.

[0129] In this application, a device state machine and a session manager are used to maintain the complete lifecycle state of peripherals in real time, including disconnected, ready, busy, error, and sleep states. The state machine is based on an event-driven model, responding to device events (connection, disconnection, data arrival) and application commands (open, close, send). The session manager assigns an independent session context to each device, recording the current state, active command queue, buffered data, and error history. In hot-plugging scenarios, the manager automatically resumes the session or triggers reinitialization through heartbeat detection (a mechanism to determine whether a remote device or connection is still active and available) and state persistence. For devices shared by multiple applications, the session manager implements a soft-lock mechanism: scheduling access requests through priority queues and timeout policies to avoid resource contention; and supporting session inheritance and transfer to maintain device state consistency during application switching.

[0130] In addition, in cross-platform, multi-application scenarios, scheduling concurrent requests from multiple applications includes: allocating virtual device views to each application and exposing only the data interfaces corresponding to authorized capabilities; arbitrating access conflicts according to configurable strategies: the first strategy is for high-priority applications to preempt resources, and the second strategy is to allocate bandwidth based on time-slice round-robin.

[0131] Specifically, in cross-platform, multi-application scenarios, multi-tenant isolation and a resource arbitrator are used to ensure the fair allocation and isolation of device resources. The system assigns a virtual device view to each application, exposing only its authorized capabilities and data. The resource arbitrator handles concurrent access requests through time-slice round-robin and priority scheduling. Arbitration strategies are configurable; for example, a high-priority application (payment) can preempt a low-priority application (log reading), or bandwidth can be allocated based on fair sharing. The arbitrator also implements device simulation and redirection for testing and simulation, allowing the development of driver logic without physical devices.

[0132] Therefore, the main focus of this application lies in the device driver abstraction layer based on WebHID and WebUSB, which provides a declarative driver interface through automatic descriptor resolution and protocol adaptation, simplifying peripheral device development. It also includes fine-grained permission management and a security sandbox mechanism, implementing operation-level access control based on a capability model to enhance system security. Furthermore, it incorporates asynchronous non-blocking I / O and resource pooling optimizations to reduce performance overhead and memory fragmentation, ensuring efficient system operation. This application significantly reduces the complexity of peripheral device development and improves code reusability and maintainability through driver abstraction and protocol adaptation. Simultaneously, fine-grained permission control and the security sandbox effectively prevent unauthorized access and malicious operations, enhancing system security.

[0133] This application also provides a front-end peripheral driver and permission management device, the device comprising:

[0134] The acquisition module is used to enumerate target peripherals through the device interface of the target device and obtain the device descriptors of each target peripheral.

[0135] The processing module is used to perform driver matching between the device descriptor and the pre-registered driver template to determine the target driver strategy for each target peripheral.

[0136] The processing module is also used to determine the device access policy for each of the target peripherals;

[0137] The processing module is further configured to perform asynchronous data interaction between each target peripheral and the target device according to the target driving strategy and the device access strategy;

[0138] The processing module is further configured to perform protocol adaptation for each of the target peripherals during the data interaction process between each target peripheral and the target device.

[0139] This implementation enumerates peripherals and obtains device descriptors through the target device's interface, providing a precise device identification foundation for subsequent driver matching. The descriptors are matched with pre-registered driver templates to determine the target driver strategy, achieving automated driver adaptation and loading, avoiding developers manually writing underlying protocol parsing code. Fine-grained device access policies are generated based on the device capability set, restricting application access to specific functions or data, reducing the risk of unauthorized access. During asynchronous data interaction, the protocol rules of the target driver strategy and the security constraints of the access policy are combined to ensure efficient and compliant data transmission. Simultaneously, protocol adaptation is performed in real-time during data interaction, converting raw peripheral data into structured objects or reverse encoding, resolving heterogeneous device protocol compatibility issues. Therefore, the development threshold for front-end peripheral integration is lowered, security control is strengthened, and the reliability of cross-device communication is improved.

[0140] As an optional implementation, the processing module performs driver matching between the device descriptor and the pre-registered driver template to determine the specific method of the target driver strategy for each target peripheral, including:

[0141] Selectable templates are filtered from the pre-registered driver templates based on information related to device type and protocol type in the device descriptor;

[0142] The pre-registered driver template is used to indicate the device function set, data format, command set, and event mapping.

[0143] Based on the signature and compatibility list in the device descriptor, a first target driving strategy is determined from the optional template;

[0144] If the optional template or the target driver strategy fails to match, then the endpoint data, target report descriptor and driver configuration items are obtained according to the device descriptor to generate the driver skeleton;

[0145] Furthermore, the processing module is also used to drive registration, specifically including:

[0146] Dynamically load the first target driving strategy or the second target driving strategy corresponding to the driving skeleton from the remote repository, instantiate the first target driving strategy or the second driving strategy, and inject the device handle and configuration parameters to execute the first target driving strategy or the second driving strategy.

[0147] This implementation filters driver templates based on type and protocol information in the device descriptor, narrowing the matching range and improving driver retrieval efficiency. It accurately locates the first target driver strategy from the available templates using feature codes and a compatibility list, ensuring driver compatibility with device hardware. When a match fails, a driver skeleton is dynamically generated based on endpoint data and report descriptors, expanding support for unknown devices. During the driver registration phase, driver strategies are dynamically loaded and instantiated from a remote repository, injecting real-time device handles and configuration parameters to achieve plug-and-play functionality and remote update and maintenance. This process significantly reduces the complexity of driver deployment and enhances the system's flexibility and scalability.

[0148] As an optional implementation, the processing module is used to process the protocol adaptation, which is used to convert the input data corresponding to each of the target peripherals into a first structured data object, or to convert the second structured data object into output data in a preset format, specifically including:

[0149] For the input data, the original byte stream corresponding to the input data is parsed according to the driver report descriptor in the target driving strategy, and field extraction, unit conversion, form verification and data validation are performed to convert it into a first structured data object;

[0150] For the output data, the second structured data object is encoded into the data format corresponding to the target peripheral, and the packet header, serial number and verification field are injected to convert it into output data in a preset format.

[0151] In this implementation, during protocol adaptation, for input data, the raw byte stream is parsed based on the driver report descriptor. A structured object is generated through field extraction, unit conversion, and data validation, improving data readability and accuracy. For output data, the structured object is encoded into a binary format supported by the target device, and a header, serial number, and verification field are automatically injected to ensure data transmission integrity and device compatibility. This bidirectional conversion mechanism solves the data standardization problem of heterogeneous protocols and reduces the development burden of application layer processing device data.

[0152] As an optional implementation, the processing module is further configured to:

[0153] During the data interaction between each of the target peripherals and the target device, a custom parsing process is registered to the extensible parsing pipeline to perform data parsing.

[0154] The scalable parsing pipeline is used to receive the custom parsing process and insert the custom parsing process into a preset processing stage of the pipeline. The preset processing stage of the data parsing includes data framing, decryption, decompression and semantic parsing.

[0155] Furthermore, during the data parsing process, parsing anomalies in any of the preset processing stages are handled through error detection and retry mechanisms.

[0156] This implementation registers a custom parsing process to an extensible parsing pipeline during data interaction, allowing developers to extend processing stages such as data framing, decryption, or semantic parsing as needed, enhancing the flexibility of protocol adaptation. It executes each parsing stage in an orderly manner through a pipelined architecture, and handles parsing anomalies with error detection and retry mechanisms, ensuring the robustness of data processing. This design can cover complex scenarios such as custom protocols in industrial equipment, improving the system's adaptability and fault tolerance.

[0157] As an optional implementation, the processing module determines the specific method of the device access policy for each of the target peripherals, including:

[0158] Declare the device capability set during the driver registration process;

[0159] The device capability set includes readable data fields, writable commands, and controllable function identifiers;

[0160] During the authorization phase, a list of permission options is generated, and operation scope information is received;

[0161] Based on the device capability set and the operation range information, determine the device access policy corresponding to each of the target peripherals;

[0162] Furthermore, the processing module is also configured to perform the following during the asynchronous data interaction:

[0163] In a secure sandbox environment, for any operation of the target application corresponding to any of the aforementioned target peripherals, verify whether the operation type and data range comply with the device access policy;

[0164] When an unauthorized or high-risk operation is initiated, a secondary confirmation process is triggered.

[0165] This implementation declares the device capability set (such as readable fields and writable commands) during driver registration, clearly defining the security boundaries of the peripheral device. During the authorization phase, a list of permission options is generated for users to select the scope of operations, achieving fine-grained permission allocation. During asynchronous interaction, the operation type and data scope are verified within a security sandbox to ensure compliance with access policies, intercepting unauthorized behavior. For unauthorized or high-risk operations (such as firmware writing), secondary confirmation is triggered, strengthening the security audit of critical operations. This mechanism refines traditional device-level authorization to the operation level, effectively preventing malicious control and data abuse.

[0166] As an optional implementation, the processing module is used to execute the asynchronous data interaction through the browser event loop and asynchronous operation chain, specifically including:

[0167] The event scheduling module determines the device event flow for each of the target peripherals.

[0168] The event scheduling module is used to schedule the specific execution process according to the priority of each device event stream and the deadline event.

[0169] Perform one or more of the following processing steps on the high-frequency data stream in the device event stream: configure buffer window, dynamically adjust sampling rate, or merge consecutive events;

[0170] When the data volume of the device event stream accumulates within a preset time period, data cleanup or data flow control is triggered based on the back pressure control mechanism.

[0171] This implementation optimizes the execution order of asynchronous tasks by scheduling device event streams according to priority and deadline using an event scheduling module; it configures buffer windows or dynamically adjusts the sampling rate for high-frequency data streams to reduce redundant event processing overhead; and it triggers a backpressure control mechanism (such as cleaning up expired data or rate limiting) when data backlog occurs to prevent memory overflow. This process utilizes the non-blocking characteristics of the browser event loop to ensure system response speed and stability under high concurrency data.

[0172] As an optional implementation, the processing module is also used to execute a resource optimization management process, specifically including:

[0173] Pre-allocated data buffer pool;

[0174] The data buffer pool reuses memory blocks through reference counting and pooling.

[0175] Management equipment connection pool;

[0176] The device connection pool is used to keep connections active for short-term access and remove invalid connections in real time.

[0177] Real-time monitoring of the resource usage indicators of each target peripheral device; when any of the resource usage indicators exceeds a preset threshold, trigger execution of one or more resource degradation processes.

[0178] The resource usage metrics include response latency, error rate, memory usage, and device load. The resource degradation process includes reducing the data sampling rate, disabling non-critical functions, switching data interaction to simulation mode, or releasing idle connections.

[0179] This implementation pre-allocates a data buffer pool and reuses memory blocks using reference counting, reducing dynamic allocation overhead; it manages a device connection pool to maintain connection activity for short-term access, avoiding latency from frequent start-stop cycles; and it monitors resource metrics (such as latency and memory usage) in real time, triggering degradation strategies (such as disabling non-critical functions or switching to simulation mode) when thresholds are exceeded, dynamically releasing resources. This process significantly reduces garbage collection pressure and improves system resilience in resource-scarce scenarios.

[0180] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, a processing module can be a separate processing element, or it can be integrated into a chip within the device. Alternatively, it can be stored as program code in the device's memory, and its functions can be called and executed by a processing element. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0181] Indicatively, such as Figure 2 As shown, Figure 2 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 2 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the methods of any of the embodiments described above.

[0182] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

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

[0184] This application provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method provided in any embodiment.

[0185] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0186] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0187] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A front-end peripheral driver and permission management method, characterized in that, The method includes: Enumerate the target peripherals through the device interfaces of the target device and obtain the device descriptors of each target peripheral; The device descriptor is matched with the pre-registered driver template to determine the target driver strategy for each target peripheral. Determine the device access policy for each of the target peripherals; According to the target driving strategy and the device access strategy, asynchronous data interaction between each target peripheral and the target device is performed. Furthermore, during the data interaction process between each of the target peripherals and the target device, protocol adaptation is performed on each of the target peripherals.

2. The method according to claim 1, characterized in that, The step of matching the device descriptor with the pre-registered driver template to determine the target driver strategy for each target peripheral includes: Selectable templates are filtered from the pre-registered driver templates based on information related to device type and protocol type in the device descriptor; The pre-registered driver template is used to indicate the device function set, data format, command set, and event mapping. Based on the signature and compatibility list in the device descriptor, a first target driving strategy is determined from the optional template; If the optional template or the target driver strategy fails to match, then the endpoint data, target report descriptor and driver configuration items are obtained according to the device descriptor to generate the driver skeleton; Furthermore, the method also includes driver registration, specifically including: Dynamically load the first target driving strategy or the second target driving strategy corresponding to the driving skeleton from the remote repository, instantiate the first target driving strategy or the second driving strategy, and inject the device handle and configuration parameters to execute the first target driving strategy or the second driving strategy.

3. The method according to claim 1, characterized in that, The protocol adapter is used to convert the input data corresponding to each of the target peripherals into a first structured data object, or to convert the second structured data object into output data in a preset format, specifically including: For the input data, the original byte stream corresponding to the input data is parsed according to the driver report descriptor in the target driving strategy, and field extraction, unit conversion, form verification and data validation are performed to convert it into a first structured data object; For the output data, the second structured data object is encoded into the data format corresponding to the target peripheral, and the packet header, serial number and verification field are injected to convert it into output data in a preset format.

4. The method according to claim 3, characterized in that, The method further includes: During the data interaction between each of the target peripherals and the target device, a custom parsing process is registered to the extensible parsing pipeline to perform data parsing. The scalable parsing pipeline is used to receive the custom parsing process and insert the custom parsing process into a preset processing stage of the pipeline. The preset processing stage of the data parsing includes data framing, decryption, decompression and semantic parsing. Furthermore, during the data parsing process, parsing anomalies in any of the preset processing stages are handled through error detection and retry mechanisms.

5. The method according to claim 2, characterized in that, The determination of the device access policy for each of the target peripherals includes: Declare the device capability set during the driver registration process; The device capability set includes readable data fields, writable commands, and controllable function identifiers; During the authorization phase, a list of permission options is generated, and operation scope information is received; Based on the device capability set and the operation range information, determine the device access policy corresponding to each of the target peripherals; Furthermore, during the asynchronous data interaction process, the method further includes: In a secure sandbox environment, for any operation of the target application corresponding to any of the aforementioned target peripherals, verify whether the operation type and data range comply with the device access policy; When an unauthorized or high-risk operation is initiated, a secondary confirmation process is triggered.

6. The method according to any one of claims 1-5, characterized in that, The asynchronous data interaction is implemented through the browser event loop and asynchronous operation chain, specifically including: The event scheduling module determines the device event flow for each of the target peripherals. The event scheduling module is used to schedule the specific execution process according to the priority of each device event stream and the deadline event. Perform one or more of the following processing steps on the high-frequency data stream in the device event stream: configure buffer window, dynamically adjust sampling rate, or merge consecutive events; When the data volume of the device event stream accumulates within a preset time period, data cleanup or data flow control is triggered based on the back pressure control mechanism.

7. The method according to any one of claims 1-5, characterized in that, The method also includes a resource optimization management process, specifically comprising: Pre-allocated data buffer pool; The data buffer pool reuses memory blocks through reference counting and pooling. Management equipment connection pool; The device connection pool is used to keep connections active for short-term access and remove invalid connections in real time. Real-time monitoring of the resource usage indicators of each target peripheral device; when any of the resource usage indicators exceeds a preset threshold, trigger execution of one or more resource degradation processes. The resource usage metrics include response latency, error rate, memory usage, and device load. The resource degradation process includes reducing the data sampling rate, disabling non-critical functions, switching data interaction to simulation mode, or releasing idle connections.

8. A front-end peripheral driver and permission management device, characterized in that, The device includes: The acquisition module is used to enumerate target peripherals through the device interface of the target device and obtain the device descriptors of each target peripheral. The processing module is used to perform driver matching between the device descriptor and the pre-registered driver template to determine the target driver strategy for each target peripheral. The processing module is also used to determine the device access policy for each of the target peripherals; The processing module is further configured to perform asynchronous data interaction between each target peripheral and the target device according to the target driving strategy and the device access strategy; The processing module is further configured to perform protocol adaptation for each of the target peripherals during the data interaction process between each target peripheral and the target device.

9. A computer device, characterized in that, The method includes one or more processors and a memory storing computer-readable instructions that, when executed by the one or more processors, perform the steps of the method as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the method as described in any one of claims 1-7.

Images