OEM Information Customization Method and Apparatus

By obtaining the actual hardware component list of the laptop and filtering and executing hardware configuration packages based on metadata and decision logic, the problem of OEM information mismatch caused by changes in hardware components was solved, realizing automated and accurate OEM information customization, and improving production line efficiency and product quality.

CN120560729BActive Publication Date: 2026-03-06SHENZHEN HONGZEMAI TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-05-15
Publication Date
2026-03-06

AI Technical Summary

Technical Problem

Existing OEM information customization methods cannot adapt to the dynamic changes in hardware components during the notebook computer production process, resulting in system instability, functional failures, and compatibility issues. Furthermore, relying on manual judgment is inefficient and fails to meet the requirements of modern production lines.

Method used

By acquiring the actual hardware component list, and based on metadata and pre-defined decision logic, a subset of configuration packages for the final application is selected from multiple hardware configuration packages. Configuration instructions are then executed in a predetermined order to ensure that OEM information matches the actual hardware. This includes supplementing the hardware information acquisition process to handle issues related to non-standard interfaces or firmware limitations.

Benefits of technology

It achieves precise matching between OEM information and actual hardware, avoiding compatibility issues and performance degradation, improving production efficiency and configuration accuracy, reducing manual intervention, and adapting to the automated processing of complex hardware combinations.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120560729B_ABST
    Figure CN120560729B_ABST
Patent Text Reader

Abstract

This application provides an OEM information customization method and apparatus, relating to the field of computer technology. The key technical points are: obtaining an actual hardware component list of a laptop to be configured; selecting a set of candidate hardware configuration packages from a predefined plurality of hardware configuration packages; parsing the metadata of each hardware configuration package in the candidate hardware configuration packages, and determining a subset of hardware configuration packages for final application and the application order of each hardware configuration package in the subset; and executing the execution instructions embedded in the subset of hardware configuration packages for final application. The OEM information customization method and apparatus provided by this application have the advantages of adapting to changes in the actual hardware component list, selecting configuration packages based on the actual hardware component list, determining the application order of configuration packages according to rules, completing configuration matching the actual hardware component list, reducing configuration mismatches, supporting hardware combination processing, automating configuration selection and application, and providing a configuration management structure.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method and apparatus for customizing OEM information. Background Technology

[0002] In the laptop manufacturing process, OEM (Original Equipment Manufacturer) information customization is a crucial step before product delivery. Typically, after hardware assembly on the production line, the laptops to be configured move to the OEM information customization station. This station connects to a central OEM information management system via network and, based on the product model information provided by the Manufacturing Execution System (MES), retrieves a pre-set OEM information package from the central system and writes it into the laptop. These OEM information packages usually include the operating system image, pre-installed software, branding, firmware parameters, and drivers that match the standard configuration of the specific product model.

[0003] However, in actual production, due to supply chain fluctuations, temporary adjustments to material supply, or specific customer order requirements, the actual hardware components assembled in different production batches or even within the same batch of the same laptop model may differ from the standard configuration list for that model. For example, specific brand or model hardware components (such as solid-state drives, wireless network cards, displays, etc.) originally planned to be used may be replaced by functionally equivalent alternative components from different suppliers or with slightly different specifications. While these alternative components can meet basic functional requirements, their driver versions, firmware internal parameters, power management strategies, or compatibility with other components may differ from those of the standard components.

[0004] Existing customization methods that obtain standard OEM information packages based on product models cannot detect and adapt to real-time changes in hardware components. If OEM information packages generated for standard hardware configurations are directly applied to laptops equipped with alternative hardware, the drivers or firmware parameters contained therein may not be fully compatible with the actual hardware. This could lead to system instability, partial functional failure, performance degradation, or even compatibility issues, severely impacting the quality of the final product and the user experience.

[0005] To address these issues, while production traceability systems typically record the material codes of the hardware actually assembled, effectively bridging this real-time, specific hardware information into the OEM customization process and ensuring that the customization system can automatically select and apply the correct configuration based on the actual hardware list remains a challenge. Central OEM information management systems usually organize and manage configuration data based on product models, lacking the direct perception and processing capabilities for the real-time hardware details of individual devices. Even if the system stores configuration snippets or patches for different alternative hardware, intelligently identifying alternative hardware combinations for the current device and accurately and efficiently filtering out all necessary and compatible configuration items from a massive amount of configuration snippets for application is a complex problem.

[0006] Furthermore, hardware component replacement is rarely isolated; a change in one component may require coordinated adjustments to the configurations of multiple related components. For example, replacing a CPU or motherboard with a specific model may necessitate adjustments to power management or frequency settings in the BIOS; replacing a high-resolution display may require matching specific display drivers and color profiles. This complex configuration adjustment involving multiple hardware components and their interactions makes simply selecting a patch based on a single replacement hardware component impractical and error-prone. Relying on manual judgment and selection of these complex configuration differences is not only inefficient but also demands extremely high levels of technical skill from operators, making it difficult to meet the efficiency, precision, and consistency requirements of modern automated production lines.

[0007] Furthermore, when faced with multiple product models and various hardware alternatives for each model, the central OEM information management system needs to maintain a vast and complex database of configuration data and matching rules. Creating, validating, updating, and maintaining these rules is extremely labor-intensive and prone to errors. If the rule database is incomplete or contains errors, incorrect OEM information written into it will directly lead to problems in subsequent product testing, increasing rework rates and production costs.

[0008] Therefore, dynamic changes in hardware materials are the norm in the consumer electronics manufacturing industry. Existing OEM information customization methods, which rely on pulling fixed information packages based on fixed models, face severe challenges in adaptability and accuracy when dealing with such dynamic production environments. How to achieve an automated, high-precision, and efficient mechanism for dynamically adapting and writing OEM information to complex hardware combinations, ensuring that every laptop coming off the production line receives system drivers, firmware parameters, and related configurations that perfectly match its unique, real-time hardware combination, thereby fundamentally avoiding compatibility issues, functional abnormalities, or performance degradation caused by improper configuration, and ultimately improving final product quality and meeting the high demands of modern intelligent manufacturing for production efficiency and flexibility, is a pressing technical problem to be solved in this field.

[0009] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0010] The purpose of this application is to provide an OEM information customization method and apparatus, which adapts to changes in the actual hardware component list, selects configuration packages based on the actual hardware component list, determines the application order of configuration packages according to rules, completes the configuration matching the actual hardware component list, reduces configuration mismatch, supports processing hardware combinations, automates configuration selection and application, and provides a configuration management structure.

[0011] Firstly, this application provides a method for customizing OEM information, the technical solution of which is as follows:

[0012] Obtain the actual hardware component list of the laptop to be configured;

[0013] Based on the actual hardware component list, a set of candidate hardware configuration packages is selected from a predefined set of hardware configuration packages. Each hardware configuration package corresponds to one or more hardware components or a combination of hardware components and includes execution instructions for deploying its corresponding OEM information configuration and metadata. The metadata defines one or more target hardware identifiers that are compatible with the hardware configuration package and rule information that characterizes the interaction between the hardware configuration package and other hardware configuration packages. The rule information includes at least dependencies for determining the application order between hardware configuration packages and conflict relationships for identifying incompatible combinations of hardware configuration packages.

[0014] The metadata of each hardware configuration package in the candidate hardware configuration package is parsed, and based on the dependency relationship, conflict relationship and preset decision logic defined in the metadata, a subset of hardware configuration packages for final application and the application order of each hardware configuration package in the subset are determined from the candidate hardware configuration packages.

[0015] In accordance with the determined application order, the execution instructions embedded in each hardware configuration package in the final application's hardware configuration package subset are executed sequentially to complete the configuration of OEM information on the laptop that matches its actual hardware component list.

[0016] Furthermore, in this application, the step of parsing the metadata of each hardware configuration package in the candidate hardware configuration packages, and determining a subset of hardware configuration packages for final application and the application order of each hardware configuration package in the subset based on the dependencies, conflicts, and preset decision logic defined in the metadata, further includes:

[0017] Collect historical configuration data, which includes the subset of hardware configuration packages selected in the historical configuration, the application order, the actual hardware combination, and the configuration result.

[0018] Based on the historical configuration data, the execution efficiency of the preset decision logic under different configuration scenarios is analyzed;

[0019] Based on the analysis of the execution performance, suggestions for adjusting the decision logic are generated.

[0020] Based on the proposed adjustment of the decision logic, the preset decision logic is updated to adjust its behavior when handling new hardware combinations, rare configuration scenarios, or changing production objectives.

[0021] Furthermore, in this application, the step of obtaining the actual hardware component list of the laptop computer to be configured further includes:

[0022] When a hardware component connected via a non-standard interface is detected in the laptop, or when information about some of the hardware components cannot be fully obtained through standard scanning methods due to firmware limitations, a supplementary hardware information acquisition process is activated.

[0023] The supplementary hardware information acquisition process includes: using a preset dedicated communication protocol or driver for non-standard interfaces to interact with the hardware components connected to the non-standard interfaces to obtain their identification information; and / or, querying a knowledge base containing known firmware limitations and their corresponding information acquisition strategies, and using alternative detection methods or indirect information sources based on the query results to obtain information about the firmware-restricted hardware components.

[0024] The hardware information obtained through standard scanning and the hardware information obtained through the supplementary hardware information acquisition process are merged and verified to form the actual hardware component list, thereby ensuring its completeness and accuracy.

[0025] Furthermore, in this application, the step of parsing the metadata of each hardware configuration package in the candidate hardware configuration packages, and determining a subset of hardware configuration packages for final application and the application order of each hardware configuration package in the subset based on the dependencies, conflicts, and preset decision logic defined in the metadata, includes:

[0026] When multiple hardware configuration packages are found to have conflicting metadata claims and the preset decision logic cannot determine a unique choice based on a single priority value, or when the conflict resolution needs to be based on the specific goal of the current production task, external production target parameters associated with the current production task are obtained.

[0027] Obtain the preset multi-dimensional priority information from the metadata of each conflicting hardware configuration package;

[0028] Based on the external production target parameters and the multi-dimensional priority information, and combined with predefined conflict resolution rules, a comprehensive evaluation value is calculated for each conflicting hardware configuration package.

[0029] Based on the comprehensive evaluation value, a hardware configuration package is selected from the conflicting hardware configuration packages and included in the hardware configuration package subset of the final application. The hardware configuration package subset of the final application and the application order of each hardware configuration package in the subset are then determined according to the dependency relationship defined in the metadata and the preset decision logic.

[0030] Furthermore, in this application, the step of selecting one hardware configuration package from the conflicting hardware configuration packages based on the comprehensive evaluation value to include in the final application's hardware configuration package subset, and further determining the final application's hardware configuration package subset and the application order of each hardware configuration package in the subset according to the dependencies defined in the metadata and the preset decision logic, includes:

[0031] After selecting a hardware configuration package from the conflicting hardware configuration packages based on the comprehensive evaluation value and including it in the subset of hardware configuration packages of the final application, and before the final application order is determined, a dependency re-evaluation is performed on the subset of hardware configuration packages of the final application containing the selected hardware configuration package and the remaining candidate hardware configuration packages to identify new dependencies or potential secondary conflicts introduced by the selected hardware configuration package.

[0032] If a newly added dependency is identified as not being satisfied or a secondary conflict exists, and the preset decision logic cannot resolve the newly added dependency or the secondary conflict, a preset adjustment strategy is triggered. The adjustment strategy includes modifying the selection of other hardware configuration packages in the hardware configuration package subset of the final application, or adjusting the selection priority of subsequent candidate hardware configuration packages, in order to resolve the problem of the newly added dependency not being satisfied or the secondary conflict.

[0033] If the adjustment strategy cannot resolve the issue of unmet new dependencies or secondary conflicts, the current configuration will be marked as a high-risk configuration, and a preset risk avoidance operation will be executed. The risk avoidance operation includes rolling back to the suboptimal hardware configuration package in the hardware configuration package that caused the conflict, or prompting for manual intervention.

[0034] After the new dependencies are satisfied and the secondary conflicts are resolved, or after the risk avoidance operation has been performed, the application order of each hardware configuration package in the subset is finally determined based on the dependencies defined in the updated hardware configuration package subset of the final application and its metadata, as well as the preset decision logic.

[0035] Furthermore, in this application, the step of selecting a set of candidate hardware configuration packages from a predefined plurality of hardware configuration packages based on the actual hardware component list includes:

[0036] Obtain context parameters associated with the laptop computer to be configured, the context parameters including at least one of product series information, target market area information, or customer order specific requirements information;

[0037] Based on the actual hardware component list, preliminary candidate hardware configuration packages are selected from the predefined multiple hardware configuration packages, whose target hardware identifiers defined in their metadata match the hardware component identifiers in the actual hardware component list.

[0038] For each hardware configuration package in the preliminary candidate hardware configuration packages, based on the obtained context parameters and the context applicability rules defined in the metadata of the hardware configuration package or a predefined context policy library, it is determined whether the hardware configuration package is applicable to the current configuration context.

[0039] The appropriate hardware configuration packages are selected to form the set of candidate hardware configuration packages.

[0040] Furthermore, in this application, the step of calculating a comprehensive evaluation value for each conflicting hardware configuration package based on the external production target parameters and the multi-dimensional priority information, combined with predefined conflict resolution rules, includes:

[0041] For each of the conflicting hardware configuration packages, the multi-dimensional priority information is extracted from its metadata. The multi-dimensional priority information includes the indicator values ​​or level classifications of the hardware configuration package on multiple preset evaluation dimensions.

[0042] Based on the external production target parameters, a weight set or scoring rules corresponding to the external production target parameters are selected or generated from the predefined conflict resolution rules. The weight set or scoring rules define the importance of each evaluation dimension.

[0043] For each of the conflicting hardware configuration packages, the comprehensive evaluation value of the hardware configuration package under the external production target parameters is calculated by combining the weight set or scoring rules with its corresponding multi-dimensional priority information.

[0044] Furthermore, in this application, the OEM information includes at least one or more of the following combinations:

[0045] Preset desktop wallpaper, manufacturer support contact information displayed in system properties, and a set of pre-configured application shortcuts for specific regions.

[0046] Furthermore, in this application, the external production target parameters include preset regional compliance requirements or cost control levels associated with the current laptop production batch.

[0047] Secondly, this application also proposes an OEM information customization device, which includes:

[0048] The acquisition module is used to obtain a list of the actual hardware components of the laptop to be configured.

[0049] The filtering module is used to filter a set of candidate hardware configuration packages from a predefined set of multiple hardware configuration packages based on the actual hardware component list. Each hardware configuration package corresponds to one or more hardware components or a combination of hardware components and contains execution instructions for deploying its corresponding OEM information configuration and metadata. The metadata defines one or more target hardware identifiers that are compatible with the hardware configuration package and rule information characterizing the interaction between the hardware configuration package and other hardware configuration packages. The rule information includes at least dependencies for determining the application order between hardware configuration packages and conflict relationships for identifying incompatible hardware configuration package combinations.

[0050] The decision module is used to parse the metadata of each hardware configuration package in the candidate hardware configuration package, and determine a subset of hardware configuration packages to be finally applied and the application order of each hardware configuration package in the subset based on the dependency relationship, conflict relationship and preset decision logic defined in the metadata.

[0051] An execution module is configured to sequentially execute the execution instructions embedded in each hardware configuration package of the final application's hardware configuration package subset, according to the determined application order, to complete the configuration of OEM information matching its actual hardware component list on the laptop computer.

[0052] As can be seen from the above, the OEM information customization method and apparatus provided in this application obtains an actual hardware component list, filters candidate configuration packages based on the list, parses metadata and determines the final configuration package subset and application order according to rules and logic, and then executes configuration instructions. It has the functions of adapting to changes in the actual hardware component list, selecting configuration packages based on the actual hardware component list, determining the application order of configuration packages according to rules, completing the configuration that matches the actual hardware component list, reducing configuration mismatch, supporting the processing of hardware combinations, automating configuration selection and application, and providing a configuration management structure. Attached Figure Description

[0053] Figure 1 This is a flowchart illustrating an OEM information customization method provided in this application.

[0054] Figure 2 This is a structural schematic diagram of an OEM information customization device provided in this application.

[0055] In the diagram: 210, Acquisition Module; 220, Filtering Module; 230, Decision Module; 240, Execution Module. Detailed Implementation

[0056] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0057] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0058] In the traditional OEM information customization process of existing laptop production lines, how can we achieve an automated, high-precision, and efficient mechanism for dynamically adapting and writing OEM information to handle complex hardware combinations when the actual assembled hardware components of the same model are inconsistent with the standard configuration list? This would ensure that every laptop coming off the production line receives system drivers, firmware parameters, and related configurations that are perfectly matched to its unique, real-time hardware combination, thereby avoiding compatibility issues, functional abnormalities, or performance degradation caused by improper configuration.

[0059] In this regard, refer to Figure 1 This application proposes a method for customizing OEM information, the method comprising:

[0060] S110. Obtain the actual hardware component list of the laptop to be configured;

[0061] S120. Based on the actual hardware component list, select a set of candidate hardware configuration packages from a predefined set of multiple hardware configuration packages. Each hardware configuration package corresponds to one or more hardware components or a combination of hardware components and contains execution instructions for deploying its corresponding OEM information configuration and metadata. The metadata defines one or more target hardware identifiers that are compatible with the hardware configuration package and rule information that characterizes the interaction between the hardware configuration package and other hardware configuration packages. The rule information includes at least the dependency relationship for determining the application order between hardware configuration packages and the conflict relationship for identifying incompatible hardware configuration package combinations.

[0062] S130. Parse the metadata of each hardware configuration package in the candidate hardware configuration package, and determine a subset of hardware configuration packages for final application and the application order of each hardware configuration package in the subset based on the dependency relationship, conflict relationship and preset decision logic defined in the metadata.

[0063] S140. Following the determined application order, execute the execution instructions embedded in each hardware configuration package in the final application's hardware configuration package subset in sequence to complete the configuration of OEM information on the laptop that matches its actual hardware component list.

[0064] The actual hardware component list refers to the list of hardware that is currently installed in the laptop to be configured. It can be obtained by scanning or querying and its purpose is to provide information on the actual hardware configuration of the device.

[0065] Among them, the predefined multiple hardware configuration packages refer to a library containing multiple hardware configuration schemes, which can be stored using data structures, and their function is to provide selectable configuration units.

[0066] The metadata of a hardware configuration package refers to the additional information in the hardware configuration package that describes its own attributes and interrelationships. Specifically, it can be stored in a structured data format. Its function is to define the hardware to which the configuration package is applicable and the rules for its interaction with other configuration packages.

[0067] The target hardware identifier refers to one or more hardware identification information that are compatible with the hardware configuration package as defined in the metadata. Specifically, it can be represented by hardware ID or material code. Its function is to filter candidate configuration packages that match the actual hardware.

[0068] Among them, rule information refers to the information in the metadata that represents the interaction between hardware configuration packages. Specifically, it can be represented by dependency relationships and conflict relationships, and its role is to guide the selection and ordering of configuration packages.

[0069] Among them, dependency relationship refers to the information in the rule information used to determine the application order between hardware configuration packages. Specifically, it can be represented by a pointing relationship. Its function is to ensure that the dependent configuration package is applied before the dependent configuration package.

[0070] Among them, conflict relationship refers to the information in the rule information used to identify incompatible hardware configuration package combinations. Specifically, it can be represented by mutual exclusion relationship, and its function is to avoid selecting incompatible configuration packages at the same time.

[0071] The preset decision logic refers to the rules or algorithms used to parse metadata and determine the final configuration scheme. Specifically, it can be implemented using algorithms or rule sets. Its function is to intelligently select a subset from the candidate package and determine the application order.

[0072] The final application hardware configuration package subset refers to a set of configuration packages selected from the candidate hardware configuration packages that will ultimately be executed on the device. Specifically, it can be represented as a list, and its function is to determine the configuration scheme that matches the actual hardware.

[0073] The application order of each hardware configuration package in the subset refers to the execution order of each configuration package in the final application hardware configuration package subset. Specifically, it can be represented by an ordered list, the purpose of which is to ensure that the dependencies are satisfied.

[0074] The execution instructions refer to the executable code or scripts contained in the hardware configuration package used to deploy OEM information configurations. Specifically, they can be implemented using scripts or programs, and their function is to actually complete the configuration operation on the device.

[0075] The core innovation of this application lies in obtaining the actual hardware list of the device, and based on the hardware configuration package containing interaction rules, automatically selecting a subset of configuration packages that match the actual hardware and determining their application order according to metadata and preset decision logic, and finally executing the configuration in sequence, thereby realizing dynamic adaptation of OEM information.

[0076] The working process and principle of this application are as follows: First, obtain a list of the actual hardware components of the laptop to be configured. This list contains identification information of the various hardware components currently installed in the device. Thus, the system obtains the basic data for precise configuration, no longer relying solely on preset product model information.

[0077] Furthermore, based on the acquired list of actual hardware components, a set of candidate hardware configuration packages is selected from a predefined pool of hardware configuration packages. Each hardware configuration package is designed to configure one or more specific hardware components or combinations thereof. These configuration packages contain execution instructions for actually deploying OEM information configurations, as well as key metadata. The metadata defines the target hardware identifiers that the configuration package is adapted to, ensuring that the selected candidate packages are associated with actual hardware. In addition, the metadata also contains rule information characterizing the interactions between configuration packages, such as dependencies for determining application order and conflict relationships for identifying incompatible combinations.

[0078] Next, the metadata of each configuration package in the candidate hardware configuration packages is parsed. Based on the dependencies, conflicts, and preset decision logic defined in the metadata, the system determines a subset of hardware configuration packages for final application from the candidate hardware configuration packages and determines the application order of each configuration package in this subset. This step is the core of achieving automation and high-precision customization. By parsing the metadata, the system can identify the mutual constraints between configuration packages. Combined with the preset decision logic, the system can intelligently select an optimal combination of configuration packages and plan their correct application order, thereby handling complex hardware combinations and interactions.

[0079] Finally, following the defined application order, the execution instructions embedded in each hardware configuration package within the final application's hardware configuration package subset are executed sequentially. These instructions configure the OEM information on the laptop to match its actual hardware component list. Strict adherence to the defined order ensures that dependencies are satisfied and avoids configuration problems caused by incorrect execution order. Ultimately, the OEM information configuration on the device precisely matches its actual hardware.

[0080] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0081] A laptop to be configured is connected to the custom system. The system first scans the laptop to obtain a list of its current hardware components. For example, the list shows that the device is equipped with a specific CPU model, a specific vendor's SSD, and a non-standard wireless network card.

[0082] Based on this actual hardware component list, the system filters through a predefined hardware configuration package library. The library contains configuration packages for different CPUs, SSDs, wireless network cards, etc. The filtering process identifies a set of candidate configuration packages that match the hardware identifiers in the list. For example, it filters out a performance optimization package for the CPU, a firmware configuration package for the SSD, and a driver and firmware configuration package for the wireless network card. Each selected configuration package contains an execution script and metadata. For example, the metadata of the wireless network card driver package declares that it depends on the wireless network card firmware package, and that the SSD firmware package conflicts with another general SSD optimization package.

[0083] The system parses the metadata of these candidate configuration packages. Based on the dependencies (driver depends on firmware), conflict relationships (two SSD packages conflict) defined in the metadata, and preset decision logic (e.g., prioritizing SSD firmware packages from specific vendors over general optimization packages), the system determines the subset of configuration packages to be applied. For example, the subset may include a CPU performance package, a specific SSD firmware package, a wireless network card firmware package, and a wireless network card driver package. Simultaneously, the application order of these packages is determined; for example, the CPU package is applied first, followed by the SSD firmware package, then the wireless network card firmware package, and finally the wireless network card driver package.

[0084] Finally, the system executes the instructions embedded in each configuration package within the subset in a predetermined application order. For example, it first executes the CPU performance optimization script, then the SSD firmware update or configuration script, followed by the wireless network card firmware writing instruction, and finally the wireless network card driver installation or configuration instruction. This completes the OEM information configuration on the laptop, precisely matching its actual hardware component list.

[0085] This application addresses the mismatch between OEM information and actual hardware during the OEM information customization stage of a laptop production line, where discrepancies between the actual assembled hardware components and the standard configuration list are common. By obtaining the actual hardware component list of the device and intelligently filtering, deciding, and executing based on hardware configuration packages containing interaction rules, dynamic adaptation and writing of OEM information are achieved. This ensures that every laptop coming off the production line receives system drivers, firmware parameters, and related configurations that perfectly match its unique, real-time hardware combination. This avoids compatibility issues, functional failures, or performance degradation caused by improper configuration, improving the accuracy and reliability of configuration. This solution automates the handling of complex hardware combination changes and dependency conflicts between configuration packages, improving production efficiency and reducing reliance on manual intervention.

[0086] Specifically, the OEM information in this application includes at least one or more of the following combinations: a preset desktop wallpaper, manufacturer support contact information displayed in system properties, or a set of pre-configured application shortcuts for a specific region.

[0087] The OEM information defined in this application, such as preset desktop wallpapers, manufacturer support contact information integrated in system properties, and application shortcuts pre-configured for specific regions, aims to provide end users with an instantly visible branded experience, convenient after-sales support, and optimized accessibility of regional applications. This allows users to experience personalization and convenience from the first time they use the device, effectively improving overall user satisfaction.

[0088] In some of the solutions described above in this application, a method is proposed to determine the subset of hardware configuration packages to be finally applied and their application order from candidate hardware configuration packages based on a preset decision logic. However, this preset decision logic is relatively fixed. When faced with constantly changing hardware combinations in actual production, rare configuration scenarios that may occur, or the need to adjust configuration strategies according to changing production goals (such as efficiency, cost, quality, etc.), the fixed decision logic may not be able to make the optimal or most reliable decision. This may result in the determined configuration scheme not being able to fully match the actual hardware, or performing poorly in some complex conflict scenarios, thereby affecting the accuracy of OEM information configuration and the quality of the final product.

[0089] To this end, this application further proposes a step of parsing the metadata of each hardware configuration package in the candidate hardware configuration packages, and determining a subset of hardware configuration packages for final application and the application order of each hardware configuration package in the subset based on the dependencies, conflict relationships, and preset decision logic defined in the metadata. The step also includes:

[0090] Collect historical configuration data, which includes the subset of hardware configuration packages selected in the historical configuration, the application order, the actual hardware combination, and the configuration results.

[0091] Based on historical configuration data analysis, the execution efficiency of pre-set decision logic under different configuration scenarios is evaluated.

[0092] Based on the analysis of execution effectiveness, suggestions for adjusting decision-making logic are generated.

[0093] Based on the decision logic adjustment suggestions, update the preset decision logic to adjust its behavior when dealing with new hardware combinations, rare configuration scenarios, or changing production goals.

[0094] This approach involves introducing a mechanism based on historical data feedback to dynamically optimize the pre-defined decision-making logic used to determine the final hardware configuration package subset and application order. First, historical configuration data is collected. This data includes the hardware configuration package subsets used in past configuration processes, the application order of these packages, the actual hardware combination of the devices to be configured at that time, and the final configuration result. This historical data provides an empirical basis for evaluating and improving the decision-making logic. For example, the inputs (actual hardware combination, candidate packages), decision-making process (selected subset, order), and outputs (configuration success / failure, error code, time consumed, etc.) of each configuration attempt can be recorded. This data can be stored in a database or log files.

[0095] Furthermore, based on this collected historical configuration data, the performance of the currently preset decision-making logic under different configuration scenarios is analyzed. This analysis process can identify the performance of the decision-making logic in handling specific hardware combinations, resolving conflicts, or determining the order, thereby discovering in which aspects it performs well and in which aspects it is deficient or can be improved. For example, the analysis can identify that in scenarios involving specific alternative hardware combinations, the subset of configuration packages selected by the decision-making logic leads to a high failure rate, or that when handling certain dependency conflicts, the determined application order always causes subsequent steps to fail. The analysis can employ statistical methods or pattern recognition techniques.

[0096] Based on the analysis of execution performance, suggestions for adjusting the decision-making logic are generated. These suggestions are derived from practical experience and aim to optimize the behavior of the decision-making logic so that it can make better decisions in the future. For example, if the analysis finds that a conflict resolution rule performs poorly in a specific scenario, the suggestions might include modifying the priority weight of that rule or adding a new, more refined rule for that specific scenario. Suggestions can be generated automatically by the analysis system or provided by human experts based on the analysis report.

[0097] Finally, based on these generated decision logic adjustment suggestions, the preset decision logic is updated. In this way, the decision logic is no longer static but can learn and evolve based on historical experience. This dynamically updated decision logic, combined with steps such as obtaining the actual hardware component list, screening candidate hardware configuration packages, and parsing metadata, enables the entire OEM information customization method to more accurately identify the hardware characteristics of the current device and, based on continuously optimized decision logic, select the most matching subset from the candidate packages and determine the optimal application order. This combination allows the method to better adapt to new hardware combinations, handle rare configuration scenarios, and flexibly adjust its decision-making behavior according to changing production goals, improving the intelligence level and adaptability and reliability of the entire OEM information customization method in complex and ever-changing environments.

[0098] In some of the solutions described above in this application, a list of the actual hardware components of the laptop to be configured is proposed as the basis for subsequent screening of hardware configuration packages and determination of application order. However, in actual production environments, some hardware components may be connected through non-standard interfaces, or their information may not be fully obtained through standard scanning methods due to firmware limitations, resulting in the inability to obtain a complete and accurate list of actual hardware components, which in turn affects the accuracy of subsequent OEM information configuration and may lead to the problem of mismatch between configuration and actual hardware.

[0099] In this regard, this application further proposes that the steps for obtaining an actual hardware component list of the laptop to be configured include:

[0100] When a hardware component connected via a non-standard interface is detected in the laptop, or when information about some hardware components cannot be fully obtained through standard scanning methods due to firmware limitations, a supplementary hardware information acquisition process is activated.

[0101] The supplementary hardware information acquisition process includes: using a pre-defined dedicated communication protocol or driver for non-standard interfaces to interact with hardware components connected to non-standard interfaces to obtain their identification information; and / or, querying a knowledge base containing known firmware limitations and their corresponding information acquisition strategies, and using alternative probing methods or indirect information sources based on the query results to obtain information about firmware-limited hardware components.

[0102] The hardware information obtained through standard scanning and the hardware information obtained through supplementary hardware information acquisition process are merged and verified to form an actual hardware component list, thereby ensuring its completeness and accuracy.

[0103] This solution specifically refines and enhances the step of obtaining the actual hardware component list of the laptop to be configured. Its purpose is to address the issue that standard scanning methods cannot obtain complete and accurate information when faced with hardware connected through non-standard interfaces or hardware whose information is limited by firmware.

[0104] By introducing a supplementary hardware information acquisition process and activating it when necessary, a complete and accurate list of actual hardware components is ensured even in complex hardware environments. This provides a reliable foundation for subsequent hardware configuration package selection, application sequence determination, and final OEM information customization based on this list.

[0105] Specifically, when the system attempts to obtain hardware component information of a laptop using standard hardware scanning methods (such as the Device Manager interface provided by the operating system, PCI scanning, USB enumeration, etc.), it may encounter situations where some hardware components cannot be identified, or the identification information is incomplete or inaccurate. This may be because these hardware components use non-standard physical interfaces or communication protocols, or their firmware design limits the exposure of complete identification or configuration information through standard methods.

[0106] When the system identifies hardware components connected via non-standard interfaces, or when information about some hardware components cannot be fully obtained through standard scanning methods—for example, when information about a specific model of embedded controller or custom sensor cannot be obtained using standard methods—the system will trigger and activate a supplementary hardware information acquisition process. Identification can be achieved by checking the results of standard scans, such as checking for the presence of unknown devices, empty device information fields, or the inclusion of generic identifiers, or by using a pre-established hardware feature library to identify specific hardware types known to present acquisition problems.

[0107] This supplementary hardware information acquisition process provides a targeted solution. For hardware connected via non-standard interfaces, such as sensors, controllers, or security chips connected via I2C, SPI, or other custom buses, the system utilizes pre-defined dedicated communication protocols or drivers for these non-standard interfaces. These dedicated protocols or drivers can interact at a low level with hardware components connected via non-standard interfaces, sending specific query commands or reading registers to obtain identification information about the hardware, such as vendor ID, device ID, model, serial number, or firmware version. For example, for a custom touchpad controller connected via an I2C bus, a specific I2C driver can be loaded, through which commands can be sent to read the controller's device ID and firmware version.

[0108] Furthermore, for hardware whose information cannot be fully obtained through standard scanning methods due to firmware limitations—for example, the firmware of certain network adapters or storage devices may restrict the acquisition of detailed model or feature information via standard APIs—the system queries a knowledge base containing known firmware limitations and corresponding information acquisition strategies. This knowledge base pre-stores known information acquisition limitations for specific hardware models, firmware versions, and provides corresponding alternative probing methods or indirect information sources. Based on the query results, the system employs the strategies specified in the knowledge base to acquire the information. Alternative probing methods may include using vendor-provided tools, reading specific memory regions, or querying other system components associated with the hardware (e.g., BIOS or management engine) to obtain indirect information. Indirect information sources include consulting manufacturing data associated with the hardware, serial number databases, or querying known information over the network. For example, the knowledge base may record that complete model information for a specific solid-state drive cannot be obtained through the standard interface, but can be obtained by reading its specific SMART attributes or using vendor-provided command-line tools.

[0109] Finally, the basic hardware information obtained through standard scanning methods is merged with the specific hardware information obtained through a supplementary hardware information acquisition process. The merged information forms a more comprehensive and accurate list of actual hardware components. The merged list is then validated, for example, by checking for duplicate entries, information consistency, and the completeness of key component information, to further ensure the completeness and accuracy of the list. This supplemented and validated list of actual hardware components contains accurate information on all identifiable key hardware components in the laptop, including those that are difficult to obtain through standard methods. This accurate list forms the basis for subsequent steps, such as filtering candidate packages from predefined hardware configuration packages that match the actual hardware, and determining the final application subset and order based on the metadata of these packages. By providing a complete and accurate hardware list, this solution enables the subsequent configuration process to accurately match the actual hardware combination of the device, thereby avoiding configuration errors caused by incomplete or inaccurate hardware information, improving the success rate of OEM information customization, and the quality of the final product.

[0110] In some of the solutions described above in this application, a method is proposed to parse the metadata of candidate hardware configuration packages and determine a subset of hardware configuration packages to be used in the final application and the application order of each hardware configuration package in the subset based on the dependencies, conflict relationships, and preset decision logic defined in the metadata. However, in this process, when the metadata declarations of multiple hardware configuration packages conflict with each other, if the preset decision logic only relies on a single priority value, it may not be able to determine a choice. Or, in some production scenarios, the resolution of conflicts needs to consider the specific goals of the current production task or external factors, and the existing preset decision logic lacks the ability to adjust and optimize according to the external context, resulting in a deviation between the configuration selection in complex or specific scenarios and the production goals.

[0111] To address this, this application further proposes a method for parsing the metadata of each hardware configuration package in a candidate hardware configuration package, and determining a subset of hardware configuration packages for final application and the application order of each hardware configuration package within the subset based on the dependencies, conflict relationships, and preset decision logic defined in the metadata. This method includes: when multiple hardware configuration packages are identified as having conflicting metadata declarations and the preset decision logic cannot determine a choice based on a single priority value, or when conflict resolution requires consideration of the specific objectives of the current production task, obtaining external production target parameters associated with the current production task; obtaining preset multi-dimensional priority information from the metadata of each conflicting hardware configuration package; calculating a comprehensive evaluation value for each conflicting hardware configuration package based on the external production target parameters and multi-dimensional priority information, combined with predefined conflict resolution rules; and, based on the comprehensive evaluation value, selecting one hardware configuration package from the conflicting hardware configuration packages to include in the subset of hardware configuration packages for final application, and continuing to determine the subset of hardware configuration packages for final application and the application order of each hardware configuration package within the subset based on the dependencies defined in the metadata and the preset decision logic.

[0112] Specifically, a higher-level decision-making process is triggered when a specific conflict scenario is identified. This occurs when the metadata declarations of multiple hardware configuration packages conflict, and the preset decision logic relies solely on a single priority value and cannot determine a choice, or when resolving the conflict requires consideration of the specific objectives of the current production task. For example, on a production line, if two hardware configuration packages are found to be suitable for a certain hardware component, but they have the same single priority value, or if the current production task requires prioritizing cost over performance, this process will be initiated.

[0113] Furthermore, the process retrieves external production target parameters associated with the current production task. These parameters can come from the Manufacturing Execution System (MES) or order information; for example, the production target for the current batch may be cost minimization, performance maximization, maximizing the activation rate of specific functions, or prioritizing the use of specific supplier components. For instance, an external production target parameter could be a flag indicating "cost priority" or a list indicating "specific functional modules must be enabled."

[0114] Simultaneously, this process retrieves pre-defined multi-dimensional priority information from the metadata of each conflicting hardware configuration package. Unlike single-dimensional priority, multi-dimensional priority information provides a more detailed evaluation basis. For example, the metadata of a hardware configuration package may contain its priority values ​​or levels (such as high, medium, and low) across multiple dimensions such as "performance," "cost," "compatibility," and "stability." For instance, a configuration package might have a priority of 90 in the performance dimension, 30 in the cost dimension, and 95 in the compatibility dimension.

[0115] Based on the acquired external production target parameters and multi-dimensional priority information, and combined with predefined conflict resolution rules, a comprehensive evaluation value is calculated for each conflicting hardware configuration package. This calculation process combines external targets with multi-dimensional priority information. For example, if the external production target is "prioritize cost," then the cost dimension will be given a higher weight when calculating the comprehensive evaluation value; if the external target is "maximize performance," then the performance dimension's priority weight will increase. The predefined conflict resolution rules can be a set of weight coefficients, a scoring function, or a decision matrix. For example, the comprehensive evaluation value can be calculated as: `Comprehensive Evaluation Value = Weight_Performance * Priority_Performance + Weight_Cost * Priority_Cost + ...`, where the weight values ​​are determined based on the external production target parameters.

[0116] Based on the calculated overall evaluation value, the hardware configuration package with the highest overall evaluation value is selected from the conflicting hardware configuration packages and included in the final application's hardware configuration package subset. For example, if the calculation results show that the overall evaluation value of configuration package A is 85 and the overall evaluation value of configuration package B is 70, then configuration package A is selected.

[0117] After selecting a hardware configuration package, this solution continues to determine the subset of hardware configuration packages to be used in the final application and the application order of each hardware configuration package within the subset, based on the dependencies defined in the metadata and pre-defined decision logic. This part of the process is similar to the basic solution, but more refined decision criteria are introduced in the conflict resolution stage. In this way, building upon the candidate package selection and conflict identification of the basic solution, this solution provides a mechanism for handling complex conflicts, enabling choices that better meet actual needs when a single priority is insufficient for decision-making or when external factors need to be considered. This decision-making process, which combines external context and multi-dimensional information, enhances the adaptability of configuration selection and solves the bias problem of configuration selection in complex or specific scenarios in the basic solution.

[0118] In some of the solutions described above in this application, hardware configuration package conflicts are resolved based on external production target parameters and multi-dimensional priority information, and a hardware configuration package is selected to be included in the final application's hardware configuration package subset. The final application's hardware configuration package subset and the application order of each hardware configuration package within the subset are then determined based on dependencies defined in the metadata and pre-defined decision logic. However, after selecting a hardware configuration package from the conflicting hardware configuration packages based on a comprehensive evaluation value, this selected package may introduce new dependencies or potentially create secondary conflicts with remaining candidate hardware configuration packages or other selected hardware configuration packages. The original pre-defined decision logic may fail to fully consider or effectively resolve these new dependencies or secondary conflicts that only emerge after conflict resolution, resulting in an incomplete final hardware configuration package subset, unmet dependencies, or unresolved conflicts, thereby affecting the correctness and stability of OEM information configuration.

[0119] To address this, this application further proposes that after selecting a hardware configuration package from the conflicting hardware configuration packages based on a comprehensive evaluation value and incorporating it into the final application's hardware configuration package subset, and before finalizing the application order, a dependency re-evaluation is performed on the hardware configuration package subset of the final application containing the selected hardware configuration package and the remaining candidate hardware configuration packages. This re-evaluation aims to identify new dependencies or potential secondary conflicts introduced by the selected hardware configuration package. If a new dependency is identified as unmet or a secondary conflict exists, and the preset decision logic cannot resolve the new dependency or secondary conflict, a preset adjustment strategy is triggered. This adjustment strategy includes modifying other hardware configuration packages in the final application's hardware configuration package subset. The selection process involves choosing or adjusting the selection priority of subsequent candidate hardware configuration packages to resolve issues such as unmet new dependencies or secondary conflicts. If adjusting the strategy fails to resolve these issues, the current configuration is marked as a high-risk configuration, and a preset risk avoidance operation is executed. This risk avoidance operation includes reverting to the suboptimal hardware configuration package among the conflicting hardware configuration packages or prompting for manual intervention. After the new dependencies are satisfied and the secondary conflicts are resolved, or after the risk avoidance operation has been executed, the application order of each hardware configuration package in the subset is finally determined based on the updated final application hardware configuration package subset, the dependencies defined in its metadata, and the preset decision logic.

[0120] The process involves selecting one package from conflicting hardware configuration packages based on a comprehensive evaluation and initially incorporating it into the final application subset. Before determining the final application order of these packages, the solution performs a comprehensive dependency re-evaluation of the currently determined subset and the candidate packages that have not yet been selected. The purpose of this dependency re-evaluation is to proactively identify any new dependencies or potential secondary conflicts that may arise from the addition of the newly selected hardware configuration package. New dependencies refer to packages that require support from other packages, which may not yet be selected or whose dependencies have not been considered. Potential secondary conflicts refer to new incompatibilities between the package and other packages within the subset or the remaining candidate packages. By performing this re-evaluation before finalizing the application order, global or subsequent problems that may arise from local conflict resolution decisions can be identified in a timely manner. For example, selected package A may depend on package X, which is not yet in the subset, or package A may have a version conflict with the selected package B. The re-evaluation process can traverse the packages and their metadata within the subset, check whether their dependencies are in the subset or candidate sets, and examine conflict declarations between packages within the subset and between subset packages and candidate packages.

[0121] Furthermore, if during the re-evaluation process, new unmet dependencies or secondary conflicts are identified, and the existing preset decision logic is insufficient to automatically handle these emerging issues, the system will trigger a preset adjustment strategy. This adjustment strategy is triggered because standard logic cannot cope with such complex situations, requiring a more flexible or specific approach. The adjustment strategy includes modifying the selection of other hardware configuration packages within the initially selected subset; for example, selecting a package to satisfy a new dependency, or replacing or removing a package to avoid secondary conflicts. The adjustment strategy can also adjust the selection priority of remaining candidate hardware configuration packages; for example, increasing the priority of packages that satisfy new dependencies, or decreasing the priority of packages that conflict with already selected packages. These adjustments are intended to attempt to fix problems arising from the initial selection within the automation framework, ensuring the validity and compatibility of the final subset. For example, if selected package A depends on package X, the adjustment strategy might attempt to add package X to the subset; or if package A conflicts with package B, the adjustment strategy might attempt to remove package B or replace it with a compatible package C.

[0122] Furthermore, if the aforementioned adjustment strategies still fail to resolve issues such as unmet dependencies or secondary conflicts, it indicates a complex situation or deep incompatibility, and automated processing may not find an effective solution. In this case, the system will mark the current configuration as high-risk and execute pre-defined risk avoidance operations. Marking it as high-risk serves as a warning of potential problems. Risk avoidance operations aim to prevent deploying a known problematic or uncertain configuration to the laptop. These operations include rolling back to the suboptimal hardware configuration package chosen when resolving the initial conflict—trying another conflict resolution method to see if subsequent problems can be avoided. Risk avoidance operations may also prompt for manual intervention, submitting the problem to technical personnel for manual analysis and decision-making, leveraging human experience to resolve complex or unusual situations. These risk avoidance measures ensure a safe and reliable exit or intervention mechanism in case of automation failure, preventing misconfigurations. For example, if the adjustment strategy cannot find a subset that satisfies package A's dependency without introducing new conflicts, the system can choose to roll back to the suboptimal package D chosen at the time of the initial conflict and restart the subset determination process, or simply pause and prompt the operator to check.

[0123] Finally, only when new dependencies are satisfied and secondary conflicts are resolved, successfully handled through strategy adjustments, or risk mitigation operations have been performed, indicating that the problem has been resolved through rollback or manual intervention, will the system ultimately determine the application order of the hardware configuration packages within the updated final application subset and the dependencies defined in its metadata, along with pre-defined decision logic. Determining the order based on the updated subset and metadata is necessary because the subset may have changed during the adjustment process, and the correct application sequence needs to be constructed based on the currently valid set of packages. This step ensures that the final configuration application order is based on a validated set of hardware configuration packages where dependencies are satisfied and conflicts have been resolved or mitigated.

[0124] In some of the solutions described above in this application, candidate hardware configuration packages are screened based on an actual hardware component list to initially narrow down the range of configuration packages. However, screening based solely on hardware matching fails to consider the specific production context of the laptop to be configured (such as product series, target market, customer order requirements, etc.). This may result in a large number of hardware matching configuration packages in the selected candidate hardware configuration package set that are not actually suitable for the current production task, increasing the processing burden of subsequent parsing and decision-making, and reducing the matching degree and processing speed of the screening.

[0125] In response, this application further proposes a step for selecting a set of candidate hardware configuration packages from a predefined pool of hardware configuration packages based on an actual hardware component list, including:

[0126] Obtain context parameters associated with the laptop to be configured. The context parameters include at least one of product family information, target market area information, or customer order-specific requirements information.

[0127] Based on the actual hardware component list, preliminary candidate hardware configuration packages are selected from multiple predefined hardware configuration packages, whose target hardware identifiers defined in their metadata match the hardware component identifiers in the actual hardware component list.

[0128] For each hardware configuration package in the initial candidate hardware configuration packages, based on the obtained context parameters and the context applicability rules defined in the metadata of the hardware configuration package or a predefined context policy library, it is determined whether the hardware configuration package is applicable to the current configuration context.

[0129] The appropriate hardware configuration packages are selected to form a set of candidate hardware configuration packages.

[0130] This solution is a further refinement and improvement of the step of screening candidate hardware configuration packages based on the actual hardware component list. Its basis lies in introducing production context information as an additional basis for screening, so as to improve the matching degree and processing speed of the screening.

[0131] This approach first captures the specific requirements of the current production task for OEM information by obtaining contextual parameters associated with the laptop to be configured, such as product family, target market region, or customer order-specific requirements. These contextual parameters are non-hardware factors that affect the applicability of the configuration package. For example, product family information can be a string identifier, such as "Latitude 7000 series"; target market region information can be a region code, such as "EMEA"; and customer order-specific requirements information can be a boolean flag or a specific configuration code. These parameters can be obtained from the Manufacturing Execution System (MES) or the associated production database.

[0132] Furthermore, based on the actual hardware component list, a preliminary screening is performed from multiple predefined hardware configuration packages. Hardware configuration packages whose target hardware identifiers defined in their metadata match the hardware component identifiers in the actual hardware component list are selected, forming a preliminary set of candidate hardware configuration packages. This step ensures that the initially selected configuration packages are hardware-level compatible and reflects the basic screening logic. For example, if the actual hardware list contains a specific wireless network card module identifier, the preliminary screening will identify all hardware configuration packages whose metadata contains that wireless network card module identifier.

[0133] Then, for each hardware configuration package in the initial candidate hardware configuration packages, based on the previously obtained context parameters and the context applicability rules defined in the hardware configuration package's metadata or a predefined context policy library, it is determined whether the configuration package is actually suitable for the current configuration context. Context applicability rules can be embedded in the metadata of each configuration package, for example, a simple conditional expression. As a preferred implementation, a predefined context policy library can be used, which centrally manages more complex applicability logic, such as a set of rules based on multiple combinations of context parameters. The determination process matches the context parameters with the rules or policy library to determine whether the configuration package is allowed to be applied in the current production environment. For example, a configuration package may be hardware-compatible, but its rules may state "not applicable to the EMEA market" or "only applicable to specific customer orders."

[0134] Therefore, hardware configuration packages deemed suitable based on contextual applicability are selected, forming a final set of candidate hardware configuration packages. This step further narrows down the initially screened set of hardware-compatible configuration packages, removing those that, although hardware-matched, should not be applied due to incompatibility with the production context. By introducing context filtering immediately after the initial screening, this approach ensures that subsequent parsing and decision-making processes only need to handle a small set of configuration packages highly relevant to the current production task. Compared to simply performing hardware matching screening, this reduces the number of configuration packages entering subsequent complex processing stages, lowers the processing burden, and improves the processing speed and matching accuracy of the entire OEM information customization process.

[0135] Furthermore, this application proposes a step for calculating a comprehensive evaluation value for each conflicting hardware configuration package based on external production target parameters and multi-dimensional priority information, combined with predefined conflict resolution rules. This step includes: for each conflicting hardware configuration package, extracting multi-dimensional priority information from its metadata, whereby the multi-dimensional priority information includes the indicator values ​​or level classifications of the hardware configuration package on multiple preset evaluation dimensions; selecting or generating a weight set or scoring details corresponding to the external production target parameters from the predefined conflict resolution rules, whereby the weight set or scoring details define the importance level of each evaluation dimension; and for each conflicting hardware configuration package, calculating the comprehensive evaluation value of the hardware configuration package under the external production target parameters by combining the weight set or scoring details with its corresponding multi-dimensional priority information.

[0136] For each conflicting hardware configuration package, multi-dimensional priority information is extracted from its metadata. This information includes the hardware configuration package's metric values ​​or grading across multiple preset evaluation dimensions. This process ensures that when evaluating a hardware configuration package, its characteristic data in several key aspects, such as cost, performance, compatibility, and deployment complexity, can be obtained. This multi-dimensional information can be stored in the hardware configuration package's metadata in numerical form (e.g., performance score, cost amount) or in graded form (e.g., compatibility level: high, medium, low). Extracting this information forms the basis for a comprehensive evaluation, providing data input for a complete measure of the hardware package's suitability.

[0137] Furthermore, based on external production target parameters, weight sets or scoring rules corresponding to these parameters are selected or generated from predefined conflict resolution rules. External production target parameters reflect current production task requirements, such as pursuing lowest cost, optimal performance, or rapid deployment. The predefined conflict resolution rule library stores the relative importance of each evaluation dimension under different production targets. For example, when the external target is "cost optimization," the rules may specify a higher weight for the cost dimension; when the target is "performance priority," the weight for the performance dimension increases. The weight set can be a set of values ​​representing the contribution ratio of each dimension in the overall evaluation. Scoring rules can define scores corresponding to different levels (such as compatibility levels). The process of selecting or generating weight sets or scoring rules allows the evaluation criteria to dynamically adapt to current production targets, ensuring that the final evaluation results are closely related to actual needs.

[0138] Therefore, for each conflicting hardware configuration package, a comprehensive evaluation value for that package under external production target parameters is calculated by combining the weight set or scoring details with its corresponding multi-dimensional priority information. The calculation method can be to multiply the indicator values ​​(or convert the levels into scores) of each dimension with their corresponding weights, and then sum the weighted scores of all dimensions to obtain the total evaluation value. For example, if a hardware package has quantified values ​​of V_c, V_p, and V_comp in the three dimensions of cost, performance, and compatibility, respectively, and the weights under the current production target are W_c, W_p, and W_comp, then the comprehensive evaluation value can be calculated as V_c*W_c + V_p*W_p + V_comp*W_comp. This calculation method combines the characteristics of the hardware package itself with the importance preferences of the external production target, and the resulting comprehensive evaluation value quantifies the merits of the hardware package in the current specific scenario.

[0139] This step of calculating the comprehensive evaluation value is combined with a holistic approach that identifies conflicts and determines the application subset and order based on decision logic. This calculation step is triggered when multiple hardware configuration package conflicts are identified, and the pre-defined decision logic, based on a single priority, cannot determine a unique choice, or when a decision needs to be made based on the specific objectives of the current production task. By calculating the comprehensive evaluation value of each conflicting package, the system can compare these quantified results to select the optimal hardware configuration package for inclusion in the final application subset under the current external production objectives. This combination enables the entire OEM information customization method to make more flexible and realistic decisions when dealing with complex conflicts and dynamic production needs, improving the accuracy and efficiency of configuration.

[0140] Specifically, the external production target parameters of this application include preset regional compliance requirements or cost control levels associated with the current notebook computer production batch.

[0141] In the OEM information customization method of this application, external production target parameters provide key production and business-level guidance for automated configuration decisions (especially when resolving configuration conflicts), ensuring that the final configuration accurately aligns with current production tasks. Specifically, these parameters may include specific regional compliance requirements closely associated with a particular laptop production batch, such as configuration standards that must be followed to meet the laws and regulations of the target sales region (e.g., specific software pre-installation specifications, environmental certification standards), thereby ensuring market access and mitigating potential risks. Simultaneously, they may also cover the specific cost control level of the production batch, such as setting it as "economical," "balanced," or "high-value experience," to guide the system in effectively balancing cost input and expected benefits when selecting or combining OEM information configurations (e.g., selecting pre-installed software versions, including certain value-added services), thereby meeting profit targets and competitive strategies under different market positioning. These external parameters associated with specific production batches enable this customization method to flexibly adapt to changing regulatory environments, market demands, and business objectives.

[0142] Secondly, referring to Figure 2 This application also proposes an OEM information customization device, which includes:

[0143] Module 210 is used to obtain a list of the actual hardware components of the laptop to be configured.

[0144] The filtering module 220 is used to filter a set of candidate hardware configuration packages from a predefined plurality of hardware configuration packages based on the actual hardware component list. Each hardware configuration package corresponds to one or more hardware components or a combination of hardware components and contains execution instructions for deploying its corresponding OEM information configuration and metadata. The metadata defines one or more target hardware identifiers that are adapted to the hardware configuration package and rule information characterizing the interaction between the hardware configuration package and other hardware configuration packages. The rule information includes at least a dependency relationship for determining the application order between hardware configuration packages and a conflict relationship for identifying incompatible hardware configuration package combinations.

[0145] The decision module 230 is used to parse the metadata of each hardware configuration package in the candidate hardware configuration package, and determine a subset of hardware configuration packages to be finally applied and the application order of each hardware configuration package in the subset based on the dependency relationship, conflict relationship and preset decision logic defined in the metadata.

[0146] The execution module 240 is configured to execute the execution instructions embedded in each hardware configuration package of the final application in a determined application order, so as to complete the configuration of OEM information matching its actual hardware component list on the laptop computer.

[0147] By obtaining the actual hardware component list, filtering candidate configuration packages based on the list, parsing metadata, and determining the final configuration package subset and application order according to rules and logic, and then executing configuration instructions, it can adapt to changes in the actual hardware component list, select configuration packages based on the actual hardware component list, determine the application order of configuration packages according to rules, complete the configuration that matches the actual hardware component list, reduce configuration mismatches, support the handling of hardware combinations, automate configuration selection and application, and provide a configuration management structure.

[0148] Furthermore, in some preferred embodiments, the OEM information customization device proposed in this application can perform any one of the steps in the above methods.

[0149] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An OEM information customization method, characterized by, The method comprises: obtaining an actual hardware component list of a notebook computer to be configured; based on the actual hardware component list, screening a set of candidate hardware configuration packages from a plurality of predefined hardware configuration packages, wherein each hardware configuration package corresponds to one or more hardware components or combinations of hardware components, and contains execution instructions for deploying its corresponding OEM information configuration and metadata, the metadata defining one or more target hardware identifiers to which the hardware configuration package is adapted, and rule information characterizing the interaction between the hardware configuration package and other hardware configuration packages, the rule information at least including dependency relationships for determining the application order between hardware configuration packages and conflict relationships for identifying incompatible hardware configuration package combinations; parsing the metadata of each hardware configuration package in the candidate hardware configuration packages, and determining a final applied hardware configuration package subset and the application order of each hardware configuration package in the subset from the candidate hardware configuration packages according to the dependency relationships, the conflict relationships and the preset decision logic in the metadata; executing the execution instructions embedded in each hardware configuration package in the final applied hardware configuration package subset in the determined application order, to complete the configuration of the OEM information matching the actual hardware component list on the notebook computer; the step of parsing the metadata of each hardware configuration package in the candidate hardware configuration packages, and determining a final applied hardware configuration package subset and the application order of each hardware configuration package in the subset from the candidate hardware configuration packages according to the dependency relationships, the conflict relationships and the preset decision logic in the metadata further comprises: collecting historical configuration data, including the hardware configuration package subset, the application order, the actual hardware combination and the configuration result used in historical configuration; analyzing the execution performance of the preset decision logic under different configuration scenarios based on the historical configuration data; generating decision logic adjustment suggestions according to the analysis of the execution performance; updating the preset decision logic according to the decision logic adjustment suggestions to adjust the behavior of the preset decision logic in handling new hardware combinations, rare configuration scenarios or changing production targets.

2. The OEM information customization method of claim 1, wherein, The step of obtaining the actual hardware component list of the notebook computer to be configured further comprises: when it is identified that there is a hardware component connected through a non-standard interface in the notebook computer, or the information of part of the hardware components cannot be completely obtained through standard scanning methods due to firmware restrictions, activating a supplementary hardware information acquisition process; the supplementary hardware information acquisition process comprises: using a preset dedicated communication protocol or driver for non-standard interfaces to interact with the hardware component connected through the non-standard interface to obtain its identification information; and / or querying a knowledge base containing known firmware restrictions and their corresponding information acquisition strategies, and using alternative detection methods or indirect information sources to obtain the hardware component information restricted by firmware according to the query result; The hardware information acquired by the standard scanning mode is merged and checked with the hardware information acquired by the supplementary hardware information acquisition procedure to form the actual hardware component list, thereby ensuring the completeness and accuracy thereof.

3. The OEM information customization method of claim 1, wherein, The step of analyzing the metadata of each hardware configuration package in the candidate hardware configuration package and determining a final applied hardware configuration package subset and the application sequence of each hardware configuration package in the subset according to the dependency relationship, the conflict relationship defined in the metadata and the preset decision logic comprises: When it is identified that the metadata of multiple hardware configuration packages declare conflicts with each other and the preset decision logic cannot determine a unique selection based on a single priority value, or when the conflict resolution needs to be based on specific goals of the current production task, external production goal parameters associated with the current production task are acquired; Multi-dimensional priority information preset in the metadata of each hardware configuration package in conflict is acquired; According to the external production goal parameters and the multi-dimensional priority information, a comprehensive evaluation value is calculated for each hardware configuration package in conflict by combining a predefined conflict resolution rule; Based on the comprehensive evaluation value, a hardware configuration package is selected from the hardware configuration packages in conflict to be included in the final applied hardware configuration package subset, and the final applied hardware configuration package subset and the application sequence of each hardware configuration package in the subset are determined according to the dependency relationship and the preset decision logic defined in the metadata.

4. The OEM information customization method of claim 3, wherein, The step of selecting a hardware configuration package from the hardware configuration packages in conflict based on the comprehensive evaluation value to be included in the final applied hardware configuration package subset and continuing to determine the final applied hardware configuration package subset and the application sequence of each hardware configuration package in the subset according to the dependency relationship and the preset decision logic defined in the metadata comprises: After the hardware configuration package is selected from the hardware configuration packages in conflict based on the comprehensive evaluation value to be included in the final applied hardware configuration package subset, and before the application sequence is finally determined, the dependency relationship is re-evaluated for the final applied hardware configuration package subset containing the selected hardware configuration package and the remaining candidate hardware configuration packages, to identify newly added dependency relationships or potential secondary conflicts introduced by the selected hardware configuration package; If the newly added dependency relationship is not satisfied or there is a secondary conflict, and the preset decision logic cannot resolve the newly added dependency relationship or the secondary conflict, a preset adjustment strategy is triggered, which includes modifying the selection of other hardware configuration packages in the final applied hardware configuration package subset or adjusting the selection priority of subsequent candidate hardware configuration packages to solve the problem that the newly added dependency relationship is not satisfied or the secondary conflict; If the adjustment strategy cannot solve the problem that the newly added dependency relationship is not satisfied or the secondary conflict, the current configuration is marked as a high-risk configuration, and a preset risk avoidance operation is performed, which includes reverting to selecting a suboptimal hardware configuration package in the hardware configuration packages in conflict or prompting manual intervention. After the new dependency relationship is satisfied and the secondary conflict is resolved, or after the risk avoidance operation is performed, the application order of each hardware configuration package in the subset is finally determined according to the dependency relationship and the preset decision logic defined in the updated hardware configuration package subset and the metadata thereof of the final application.

5. The OEM information customization method of claim 1, wherein, The step of screening a group of candidate hardware configuration packages from the plurality of predefined hardware configuration packages based on the actual hardware component list comprises: obtaining context parameters associated with the notebook computer to be configured, the context parameters comprising at least one of product series information, target market area information, or customer order specific demand information; screening, from the plurality of predefined hardware configuration packages, preliminary candidate hardware configuration packages whose target hardware identifiers defined in the metadata thereof match the hardware component identifiers in the actual hardware component list based on the actual hardware component list; for each hardware configuration package in the preliminary candidate hardware configuration packages, determining whether the hardware configuration package is applicable to the current configuration context according to the obtained context parameters and context applicability rules defined in the metadata of the hardware configuration package or a predefined context policy library; selecting the hardware configuration packages determined to be applicable to form the group of candidate hardware configuration packages.

6. The OEM information customization method of claim 3, wherein, The step of calculating a comprehensive evaluation value for each conflicting hardware configuration package according to the external production target parameter and the multi-dimensional priority information, in combination with predefined conflict resolution rules, comprises: for each of the conflicting hardware configuration packages, extracting the multi-dimensional priority information from the metadata thereof, the multi-dimensional priority information comprising index values or level divisions of the hardware configuration package in a plurality of preset evaluation dimensions; selecting or generating a weight set or scoring rules corresponding to the external production target parameter from the predefined conflict resolution rules according to the external production target parameter, the weight set or scoring rules defining the importance of each evaluation dimension; for each of the conflicting hardware configuration packages, combining the weight set or scoring rules with the multi-dimensional priority information corresponding thereto to calculate the comprehensive evaluation value of the hardware configuration package under the external production target parameter.

7. The OEM information customization method of claim 1, wherein, The OEM information at least comprises one or more combinations of the following: a preset desktop wallpaper, a manufacturer support contact displayed in system properties, a group of preconfigured application shortcuts for specific regions.

8. The OEM information customization method of claim 3, wherein, The external production target parameter comprises a preset specific region compliance requirement or cost control level associated with a current notebook computer production batch.

9. An apparatus for customizing OEM information, characterized by comprising: The apparatus comprises: an obtaining module configured to obtain an actual hardware component list of a notebook computer to be configured; a screening module configured to screen a set of candidate hardware configuration packages from a plurality of predefined hardware configuration packages based on the actual hardware component list, wherein each of the hardware configuration packages corresponds to one or more hardware components or combinations of hardware components, and contains execution instructions for deploying its corresponding OEM information configuration and metadata defining one or more target hardware identities to which the hardware configuration package is adapted, and rule information characterizing interactions between the hardware configuration package and other hardware configuration packages, the rule information including at least dependency relationships for determining application order between hardware configuration packages and conflict relationships for identifying incompatible combinations of hardware configuration packages; a decision module configured to analyze the metadata of each of the candidate hardware configuration packages, and determine a subset of finally applied hardware configuration packages and an application order of each of the hardware configuration packages in the subset from the candidate hardware configuration packages according to the dependency relationships, the conflict relationships and a preset decision logic defined in the metadata; an execution module configured to sequentially execute the execution instructions embedded in each of the hardware configuration packages in the subset of finally applied hardware configuration packages in the determined application order, to complete the configuration of OEM information matching the actual hardware component list on the notebook computer; the analysis of the metadata of each of the candidate hardware configuration packages, and the determination of the subset of finally applied hardware configuration packages and the application order of each of the hardware configuration packages in the subset from the candidate hardware configuration packages according to the dependency relationships, the conflict relationships and the preset decision logic further include: collecting historical configuration data including a subset of hardware configuration packages, an application order, an actual hardware combination and a configuration result of historical configuration; analyzing the execution performance of the preset decision logic under different configuration scenarios based on the historical configuration data; generating a decision logic adjustment suggestion according to the analyzed execution performance; updating the preset decision logic according to the decision logic adjustment suggestion to adjust the behavior of the preset decision logic in handling new hardware combinations, rare configuration scenarios or changing production targets.

Citation Information

Patent Citations

  • Hard disk priority setting method and device, computer equipment and storage medium

    CN119003006A

  • Preserving hardware status points in operating system environment for use in preboot diagnostics

    US20240134765A1