A computer device information processing method, device and system

Abstract

This application discloses a computer equipment information processing method, device, and system to solve the problems of low efficiency, inaccurate information, poor real-time performance, and cumbersome inventory management in computer equipment management. The method includes: in response to the access of an external device, a first computer obtains its unique hardware identifier and generates device binding data associated with that hardware identifier; the first computer collects its own hardware and software information, combines it with the binding data to generate device file data, and sends it to a second computer (server); the server establishes a device file associated with the first computer based on the file data. The system correspondingly includes modules for performing the above steps. This application achieves automated, accurate acquisition and centralized management of equipment information by automatically triggering information collection and binding through hardware devices, and supports rapid inventory management via mobile terminals using near-field communication technology, significantly improving the efficiency, accuracy, and real-time performance of equipment asset management.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a computer device information processing method, device, and system. Background Technology

[0002] In today's digital office era, various enterprises are widely equipped with a large number of computer devices, such as all-in-one computers and laptops, to meet the needs of daily business operations. Existing technologies employ a variety of methods for managing these devices.

[0003] In terms of obtaining device information, traditional methods mainly rely on manual operation. For example, to obtain the motherboard information of a device (corresponding to the hardware information in this application), the administrator needs to open the computer case and check the model, manufacturer, and other information marked on the motherboard, or obtain it by manually searching for relevant hardware information options in the operating system. For the device serial number (a type of hardware identifier), it usually needs to be found in a specific location on the device, such as a label on the bottom of a laptop. Obtaining the MAC address (a type of hardware identifier) ​​requires manual querying in the network settings of the operating system. When compiling statistics on software installations (corresponding to the software information in this application), the administrator often needs to open each device one by one, check the list of installed programs, or manually scan using specific software management tools.

[0004] In terms of equipment tracking and usage management, a common practice is to affix a numbered paper label to each device, and employees record the usage information on a paper registration form when they pick up the equipment. To understand the real-time usage status of the equipment, it usually relies on employees proactively reporting the equipment's usage, such as whether it is being used or whether there is a malfunction. Some companies may use network management software to monitor whether the equipment is online via IP address, but this method cannot accurately link to specific users and is difficult to obtain detailed hardware and software information about the equipment.

[0005] Traditionally, equipment inventory involves inventory personnel using a paper list to verify the equipment number, model, and other information for each device, recording the actual equipment status on the list, and then manually entering the paper records into a spreadsheet for aggregation. Some companies may utilize barcode or QR code technology, scanning the barcodes or QR codes affixed to the equipment for quick identification. However, this method still requires inventory personnel to scan each item on-site, offering limited efficiency improvements for a large number of devices distributed across different office areas.

[0006] Based on the above-mentioned existing technical solutions, many shortcomings have been exposed in practical applications.

[0007] Manually obtaining device information is extremely inefficient. For companies with hundreds or thousands of computers, manually checking hardware information, finding serial numbers, and compiling software installation statistics for each device requires a significant amount of time and manpower. Furthermore, manual operation is prone to data recording errors, such as misreading motherboard models or entering incorrect serial numbers, thus affecting the accuracy of device management data.

[0008] Existing equipment tracking and usage management methods struggle to achieve real-time, accurate monitoring. Paper labels and manual registration methods cannot provide timely feedback on the actual usage status of equipment. If employees fail to report equipment malfunctions or transfers in a timely manner, management cannot keep abreast of the situation. Network management software that relies solely on IP addresses cannot establish a close connection between equipment and specific users, nor can it obtain detailed usage information such as the equipment's geographical location and running software, thus failing to meet the needs of enterprises for refined management.

[0009] Traditional equipment inventory methods also have serious shortcomings. Manually checking paper lists is not only inefficient, but also prone to omissions or duplicates during the inventory process. While barcode or QR code scanning improves information reading speed to some extent, it still requires on-site operation by inventory personnel. For equipment distributed across different floors and areas in large enterprises, the inventory work is time-consuming and cannot be updated in real time, hindering the company from timely understanding the status of its equipment assets.

[0010] In summary, existing computer equipment management technologies suffer from low efficiency, poor accuracy, and insufficient real-time performance in information acquisition, equipment tracking, and inventory management. There is an urgent need for an innovative solution to improve the efficiency and accuracy of equipment management. Summary of the Invention

[0011] This application proposes a computer equipment information processing method, device, and system to solve the problems of existing computer equipment management, such as reliance on manual labor, low efficiency, inaccurate information, inability to track equipment status in real time, and cumbersome inventory work.

[0012] In a first aspect, embodiments of this application provide a computer device information processing method, comprising the following steps:

[0013] In response to the access of an external device, the first computer obtains a first hardware identifier; the first hardware identifier belongs to the external device and is unique;

[0014] A first computer generates device binding data; the device binding data includes association information between a first hardware identifier and a second hardware identifier; the second hardware identifier belongs to the first computer.

[0015] The first computer generates device profile data; the device profile data includes the device binding data and the hardware or software information of the first computer.

[0016] The first computer sends the device file data to the second computer;

[0017] The second computer creates a device file based on the device file data; the device file is associated with the first computer.

[0018] Preferably, the device binding data also includes user identity information;

[0019] The step of the second computer establishing a device file based on the device file data specifically includes: establishing a device file that is simultaneously associated with the first computer and the user identity information.

[0020] In one embodiment, the step of generating device binding data includes:

[0021] Obtain the first hardware identifier and the second hardware identifier, and associate the two to generate the association information.

[0022] In one embodiment, the step of creating the device profile includes:

[0023] Parse the device file data to obtain the second hardware identifier;

[0024] The device profile is created using the second hardware identifier as an index.

[0025] In one embodiment, the steps of the first computer obtaining the first hardware identifier and generating device binding data are executed by a client program automatically installed on the first computer and triggered by the external device.

[0026] The client program is configured to block or restrict the sending of device file data to the second computer when the external device is not connected to the first computer.

[0027] In one embodiment, the software information is a list of installed applications obtained by calling the software manifest interface provided by the operating system or by scanning predetermined system directories and registry entries.

[0028] In one embodiment, the step of:

[0029] In response to the update information received from the first computer, the second computer updates the established device file.

[0030] Secondly, embodiments of this application also provide a computer device information processing system for implementing the computer device information processing method described in any embodiment of the first aspect, comprising a first computer device and a second computer device. The first computer device includes:

[0031] A first receiving module is configured to, in response to the access of an external device, acquire a first hardware identifier; the first hardware identifier belongs to the external device and is unique. A first determining module is configured to generate device binding data and device profile data; the device binding data includes association information between the first hardware identifier and a second hardware identifier belonging to the first computer device; the device profile data includes the device binding data and hardware information or software information of the first computer device. A first sending module is configured to send the device profile data to the second computer device.

[0032] The second computer device includes:

[0033] The second receiving module is used to receive device file data from the first sending module. The second determining module is used to create a device file based on the device file data. The second sending module is used to associate the created device file with the first computer device.

[0034] Thirdly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any embodiment of the first aspect.

[0035] Fourthly, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any embodiment of the first aspect.

[0036] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0037] This application achieves automation and precision in information collection. By connecting an external device to an automatically triggered client program, which then calls the operating system interface to automatically collect motherboard hardware information and software installation lists, completely eliminating reliance on manual operation. This allows equipment information collection, which previously required significant manpower and time, to be completed automatically in a short time, greatly improving efficiency. Simultaneously, by reducing human intervention, errors due to negligence are effectively avoided, ensuring the accuracy of data collected from the equipment source. In terms of equipment tracking and management, unique binding and real-time monitoring are achieved. By generating and reporting equipment binding data containing the association information between external device hardware identifiers and computer hardware identifiers, equipment files are established on the server side and uniquely associated with specific computers. This allows enterprise management departments to grasp the identity, status, and installed software of each device in real time and accurately, solving the problems of chaotic equipment information, unclear status, and difficulty in associating with specific users or locations in existing technologies, greatly improving the precision of equipment asset management. In terms of equipment inventory and on-site management, it provides efficient and convenient innovative methods. By integrating near-field communication (NFC) functionality into external devices and using them in conjunction with mobile terminals, administrators can quickly read the identifier of an external device on the equipment and trigger interaction with the server simply by bringing the mobile terminal close to the device. This allows for operations such as information retrieval, status updates, and inventory registration. This method eliminates the need for powering on the device, manual verification of lists, or operation of barcode scanners, significantly improving the efficiency and accuracy of inventory work and enabling real-time synchronization of management information. The technical solution provided in this application effectively solves the core problems of low efficiency, poor accuracy, insufficient real-time performance, and cumbersome inventory management in existing computer equipment management technologies, providing enterprises with a complete, efficient, accurate, and automated solution for equipment asset management. Attached Figure Description

[0038] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0039] Figure 1 This is a flowchart of a computer device information processing method according to an embodiment of this application;

[0040] Figure 2 A schematic diagram of the physical architecture of a computer device information processing system provided in an embodiment of this application;

[0041] Figure 3 This is a structural diagram of a computer device information processing system according to an embodiment of this application;

[0042] Figure 4This is a schematic diagram of the hardware structure of the external device provided in the embodiments of this application. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0044] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0045] Figure 1 This is a flowchart of a computer device information processing method according to an embodiment of this application.

[0046] In a first aspect, embodiments of this application provide a computer device information processing method, including steps 110-160.

[0047] Step 110: In response to the access of an external device, the first computer obtains a first hardware identifier; the first hardware identifier belongs to the external device and is unique.

[0048] In this embodiment of the application, the first computer refers to any computing device in the enterprise that needs to be included in asset management.

[0049] For example, desktop computers, laptops, or all-in-one computers used by employees.

[0050] The external device is a physical hardware device independent of the first computer. It has a standardized electrical interface in the form of USB or Type-C for establishing a physical connection and data communication with the first computer. The device is compact in design and integrates an information transmission module and an NFC sensing chip, allowing it to be easily connected to computer devices such as PCs or laptops.

[0051] The first hardware identifier is a unique code that is embedded in the internal storage unit of the external device.

[0052] For example, the serial number of the chip fuse or read-only memory is written by the semiconductor manufacturer during the production testing phase.

[0053] In one embodiment, the identifier is bound to the physical entity of the device and cannot be tampered with or copied by conventional software instructions. This constitutes the device's "hardware root of trust" or "unique identity token." In a more preferred embodiment, the device's control and storage unit may integrate a Physically Unclonable Function (PUF) circuit, making the first hardware identifier embedded in its unique physical microstructure, possessing extremely high anti-counterfeiting and anti-copying properties.

[0054] When an external device is plugged into the corresponding port of the first computer through its interface, a physical event of "access" is constituted. In today's digital office era, enterprises are widely equipped with a large number of such computer devices. Traditional management methods mainly rely on manual operation for information acquisition, such as opening the computer case to check the motherboard information or manually querying in the operating system, which is inefficient and prone to errors.

[0055] The dedicated software (which may be referred to as the client program in this application) pre-deployed on the first computer or triggered to be installed by the external device will detect the access by listening to the hot-plug events of the hardware devices at the underlying operating system.

[0056] Subsequently, the client program sends a query command to the connected external device by calling the device access interface provided by the operating system kernel or hardware abstraction layer, and reads the first hardware identifier returned by the device, which represents its unique identity.

[0057] The entire process is completed automatically by the program, without the need for administrators or users to manually view, copy, or enter any numbering information.

[0058] Step 120: The first computer generates device binding data; the device binding data includes association information between a first hardware identifier and a second hardware identifier; the second hardware identifier belongs to the first computer.

[0059] In this embodiment of the application, the second hardware identifier is the unique hardware feature code of the first computer itself.

[0060] For example, the motherboard serial number, trusted platform module key, or system firmware UUID.

[0061] This identifier is also difficult to counterfeit with conventional software. Traditional methods of obtaining such information (such as device serial numbers) usually require searching for tags on the device, and manually scanning each device individually when tracking software installations, which is inefficient and inaccurate.

[0062] Generating device binding data refers to the process by which the client program on the first computer, after obtaining the first hardware identifier of the external device, acquires the second hardware identifier of the local machine and logically records these two as a pairing relationship. This represents a breakthrough from traditional manual methods.

[0063] This association information is the core data for all subsequent precise management operations. It essentially establishes a unique mapping relationship between a specific external physical device and a specific primary computer at the data level.

[0064] The client program can store this pair of identifiers in local non-volatile memory in the form of a specific data structure (such as a key-value pair, a digital signature token, or an encrypted string) to form a binding credential.

[0065] To better ensure the security and privacy of data transmission, in a preferred embodiment, the communication between the client program and the second computer (server) is end-to-end encrypted.

[0066] Specifically, the client program can use a key obtained from an external device or a first computer hardware security module (HSM) to encrypt the device binding data and subsequent device profile data, and then decrypt and verify the integrity of the data on a second computer (e.g., using a hash-based message authentication code HMAC) to ensure that the information is not stolen or tampered with during transmission.

[0067] Preferably, the device binding data also includes user identity information.

[0068] In this preferred embodiment, when generating binding data, the client program further requests or automatically obtains user-identifying information such as the current operating system's login username and employee ID, and includes this information along with the aforementioned two hardware identifiers in the binding data. This achieves a unique "device-apparatus-user" binding. This upgrades the binding relationship from a "thing-thing" association to a "person-thing-thing" association. That is, it establishes a triple binding relationship based on hardware identifiers (first and second hardware identifiers) and user credentials (user identity information), and generates an indivisible digital binding credential.

[0069] The step of the second computer establishing a device file based on the device file data specifically includes: establishing a device file that is simultaneously associated with the first computer and the user identity information.

[0070] In this embodiment, after receiving device profile data containing such binding data, the second computer (server) will not only create a profile based on the identifier of the first computer, but also record and associate user identity information in the profile.

[0071] For example, in database design, the equipment file table not only links to the equipment record representing the primary computer through fields, but may also link to the user information table through foreign keys. This allows the final equipment file generated on the server side to clearly answer both the management questions of "which device is this?" and "who is currently using / responsible for this device?". This enables fine-grained management and querying of equipment asset information at the database record level, greatly improving the precision of management. It facilitates timely resource allocation and handling of equipment failures, significantly enhancing the sophistication of equipment management.

[0072] In one embodiment, the step of generating device binding data includes:

[0073] Obtain the first hardware identifier and the second hardware identifier, and associate the two to generate the association information.

[0074] This embodiment describes in detail the internal actions for generating the association information. The client program obtains the first hardware identifier and the second hardware identifier through different system calls. Then, it can use methods such as string concatenation (e.g., "{first identifier}-{second identifier}"), hash value calculation (e.g., SHA-256({first identifier}+{second identifier})) or symmetric encryption using a preset key to transform the two independent identifiers into a single, indivisible data unit that reflects their association, i.e., the association information.

[0075] In one embodiment, the steps of the first computer obtaining the first hardware identifier and generating device binding data are executed by a client program automatically installed on the first computer and triggered by the external device.

[0076] The external device contains a pre-installed client installation program and its drivers. When it is first connected to the first computer, the operating system typically automatically recognizes and installs its basic drivers. Subsequently, the user can initiate the client installation process by double-clicking the installation program on the external device's virtual storage disk, either through an automatic prompt from the operating system or by directly accessing the virtual storage disk. The installation process is simple; the user only needs to confirm or follow the wizard prompts to complete it. After installation, the client program will automatically start and reside in the system background. The external device can be designed to simulate a storage device with an autorun function. When it is first connected to the first computer, the operating system's autoplay function or a specific driver installation wizard will be triggered, automatically running the pre-installed client installation program within the device. The user only needs to confirm or perform a few steps to complete the client installation. After installation, the client program immediately starts and automatically executes the operations described in steps 110 and 120. This completes the initialization process from "inserting the device" to "completing the binding."

[0077] The client program is configured to block or restrict the sending of device file data to the second computer when the external device is not connected to the first computer.

[0078] This embodiment describes a configuration strategy that enhances security and management enforcement. The device acts as the computer's "identity card," only communicating with the server after being continuously plugged in and completing authentication, ensuring the accuracy and privacy of the information obtained by the device. The client program continuously or periodically verifies whether the external device is still connected to the first computer during runtime. If the device is detected to have been unplugged, the client program enters a restricted state.

[0079] In this state, the program may completely stop sending any data updates to the second computer (blocking), or only allow sending specific alarm messages indicating "device removed," while prohibiting the sending of normal device profile data (restriction). This mechanism ensures the real-time and authenticity of the device management status; that is, the first computer can only "check in" and update the status normally when the external device, the "physical key," is in place, effectively preventing account misuse or false device status reporting.

[0080] Step 130: The first computer generates device file data; the device file data includes the device binding data and the hardware or software information of the first computer.

[0081] In this embodiment, generating device profile data refers to the process by which a client program on the first computer, after completing device binding data, actively and systematically collects detailed asset status information of the first computer and integrates this information with the generated device binding data into a structured data packet. After binding is completed, the device will read the motherboard hardware information and operating system software information.

[0082] The hardware information specifically refers to the detailed specifications and identification information of the core hardware of the first computer, especially the motherboard information, which may include the motherboard manufacturer, product model, version number, serial number, and BIOS supplier and version. This information is usually obtained by calling the low-level hardware management interface provided by the operating system (such as Windows' WMI, Linux's DMI / SMBIOS).

[0083] For example, by calling the operating system's low-level hardware interface functions, it can read motherboard information, including detailed parameters such as the motherboard chipset model, BIOS version, and manufacturer; obtain the device serial number from the device's BIOS settings; read the device's MAC address through the network driver interface; and obtain the device's current IP address using the operating system's network configuration module. For devices such as laptops that support GPS, the accompanying software can also obtain the device's real-time geographical location information by calling the corresponding GPS driver.

[0084] The software information refers to a list of all applications installed on the first computer's operating system, including attributes such as software name, publisher, version number, and installation date. Regarding software installation statistics, the accompanying software scans the device's hard drive partitions, reads the installation directory information of installed software, and identifies detailed information such as the name and version number of the installed software by comparing it with a software signature database.

[0085] In a preferred embodiment, the client program does not collect software information only during a one-time initialization process, but adopts an event-driven information collection mechanism.

[0086] For example, client programs can monitor system events related to software installation and uninstallation by registering with the operating system's file system monitoring interface or registry hooks. When such events are detected, an incremental scan and update of the software inventory is automatically triggered, and the updated information is pushed to a second computer immediately or according to a policy using a publish-subscribe model. The second computer (server), as a subscriber, receives and processes these incremental update information in real time, synchronizing them to the corresponding device files, thereby achieving real-time and accurate recording of changes in client software information on the server side. This automates information collection and reporting, significantly reducing manual intervention points, thus "liberating manpower."

[0087] The client program combines and encapsulates the collected hardware and software information with the device binding data generated in step 120 (which serves as the core for identity verification and association of data packets) to ultimately form complete device profile data.

[0088] This data packet not only identifies "who this device is (binding relationship)", but also precisely describes "what the specific configuration of this device is (asset details)", providing a complete data foundation for refined asset management and auditing in the backend.

[0089] In one embodiment, the software information is a list of installed applications obtained by calling the software manifest interface provided by the operating system or by scanning predetermined system directories and registry entries.

[0090] This embodiment illustrates two main technical approaches to software information acquisition.

[0091] The first approach is to call the standard software manifest interface provided by the operating system. For example, in Windows, this involves querying the Win32_Product or Win32_InstalledWin32Program class via WMI, or in Linux distributions that support package managers, it involves querying the dpkg, rpm, or snap database to obtain an authoritative list of installed software. This method yields a relatively standardized and complete manifest.

[0092] The second approach is to scan predetermined system directories and registry entries. For example, in a Windows system, scan the folder structure under the "Program Files" and "Program Files (x86)" directories, and simultaneously query entries under key paths in the registry.

[0093] This approach can more comprehensively uncover applications installed through non-standard methods or those not fully enumerated by the operating system interface. Client programs can utilize both approaches to ensure that the collected software list is as close as possible to the actual software installation status of the first computer.

[0094] Step 140: The first computer sends the device file data to the second computer.

[0095] In this embodiment of the application, this step describes the automated transmission process of asset information from the terminal device to the central management node.

[0096] Once the client program on the first computer generates complete device profile data, regardless of whether this data is generated for the first time after initial binding or updated during subsequent periodic inspections or when hardware or software changes are detected, it needs to be reported to the central management system. When the computer device connects to a specific network within the enterprise, the accompanying software packages and organizes the collected information. Then, through network communication protocols, this information is sent to the enterprise's management platform server.

[0097] The second computer is the remote central management server, whose network address or domain name is usually pre-configured in the client program. The sending action is automatically initiated by the client program, using the first computer's existing network connection (such as a corporate intranet or the internet) and standard network communication protocols (such as HTTP / HTTPS for RESTful API calls, or using publish / subscribe protocols like MQTT) to send the encapsulated device profile data as the request payload to the data receiving interface specified on the second computer. After receiving the information, the management platform stores it in a dedicated database for subsequent querying and analysis.

[0098] This process requires no human intervention, ensuring the timeliness of asset information updates. This allows the second computer to aggregate the latest asset status of all online first computers in near real-time, constructing a unified and dynamic view of enterprise assets.

[0099] Client programs typically also implement network anomaly handling mechanisms, such as temporarily storing data when the network is down and automatically retransmitting it after the network is restored, to ensure the reliability of data reporting.

[0100] Step 150: The second computer creates a device file based on the device file data; the device file is associated with the first computer.

[0101] In this embodiment of the application, the core processing logic and persistent storage process of the central management server for data reported by the terminal are described.

[0102] After receiving device file data from the first computer, the second computer's deployed data processing services (such as backend API services) first verify the data format and integrity, and then parse the data packets. The purpose of parsing is to extract key information used to uniquely identify the source device, namely the second hardware identifier. This identifier serves as the "primary key" for associating the reported data with existing records on the server or creating new records.

[0103] Establishing a device profile refers to the second computer creating a structured data record based on its internal database system. This record not only contains all the hardware and software information parsed from the device profile data, but more importantly, its storage location and attributes are logically bound to the second hardware identifier extracted from the data. This "association" means that in the server's data model, this profile record is definitively linked to its corresponding physical device (the first computer) through the core field of the second hardware identifier. Thus, a detailed digital asset profile is formed on the server side, precisely corresponding to each specific first computer. The server backend registers this information item by item and records changes in client software information in real time. This provides a unique and accurate data source for all subsequent management functions such as querying, statistics, auditing, and alarms.

[0104] In one embodiment, the step of creating the device profile includes:

[0105] The device profile data is parsed to obtain the second hardware identifier.

[0106] This process refers to the background service program of the second computer (server) first decoding and semantically parsing the structured data packet after receiving the device file data packet sent by the first computer.

[0107] The server unpacks the data layer by layer according to the preset data format specifications (such as JSON Schema, XML parsing template, or a specific binary protocol), and locates and extracts the key field "second hardware identifier" from the data packet.

[0108] For example, if the device profile data is in JSON format, the server will parse the JSON object, find a field named `second_hardware_id` or something similar, and read its value (e.g., a string of characters representing the motherboard serial number). The purpose of this step is to accurately separate the identifier that uniquely and reliably represents the physical device (the first computer) from the composite data packet containing mixed information (binding relationships, hardware details, software list), providing a target location basis for subsequent data persistence operations. The server may also perform data validation during this process, such as verifying whether the format of the second hardware identifier conforms to expected rules.

[0109] The device profile is created using the second hardware identifier as an index.

[0110] This process describes the core logic of the server using the resolved second hardware identifier for data storage. The server uses this second hardware identifier as a key "index" in database operations.

[0111] Specifically, the server program will initiate an "insert or update" operation to the database.

[0112] In this operation, the second hardware identifier is used as the primary key or unique index key value of the database table. The server attempts to create a new record in the database table storing the device profile, using this identifier as a condition. If a record with the same second hardware identifier already exists in the table, this operation may be considered an update to the existing record, overwriting or supplementing the old information with the newly received data; if it does not exist, a new record is successfully created, and the second hardware identifier is stored as the unique identifier of the record in the primary key field. At the same time, all other relevant information from the device profile data packet (such as the first hardware identifier, hardware details, software list, timestamp, etc.) is stored in the corresponding fields of the record.

[0113] In this way, the second hardware identifier establishes an immutable, one-to-one mapping between the device profile record in the server database and the first computer in the physical world. This is the cornerstone for the accurate execution of all subsequent device-based query, statistics, and management functions.

[0114] In one embodiment, the step of:

[0115] Step 160: In response to the received update information from the first computer, the second computer updates the established device file.

[0116] This application describes the core mechanism by which the technical solution of this application supports the dynamic maintenance of asset information.

[0117] After completing the initial information reporting, the client program on the first computer is not idle but configured to continuously monitor changes in the status of local assets. These changes may include the installation of new software, the uninstallation of old software, updates to specific hardware drivers, or periodic full data reviews based on policy. When such changes are detected or a predetermined time point is reached, the client program generates "update information." This update information can be an incremental change data packet derived from comparison or a full data packet containing the latest status, which must include key information for identifying itself (such as a secondary hardware identifier or device binding data).

[0118] The second computer continuously monitors its data receiving interface. This step is triggered when it receives such update information from any of the first computers. The second computer first parses the update information and extracts the identification information used to identify the source device (usually the same identifier used during the documentation process in step 150, such as the second hardware identifier). Subsequently, the server, supported by its internal database system, uses this identifier as a query condition to quickly locate the existing device profile record created for that device. After successful location, the server applies the new data content from the update information (such as the updated software list, modified hardware configuration items, the latest detection timestamp, etc.) to the profile record and performs an update operation. For example, it may overwrite the old list with the new software list or append a change log to the profile.

[0119] This step ensures that the device files stored on the second computer are not one-time snapshots, but rather a "living" record that dynamically evolves as the actual state of the first computer changes. It solves the problem of outdated information in traditional static asset ledgers that cannot reflect real-time status, ensuring the timeliness and accuracy of data on the management platform. Enterprises can grasp the actual status of their equipment assets at any time. This ensures that managers obtain the latest and most accurate asset view from the first computer by querying the second computer, greatly improving the real-time nature and effectiveness of asset management. At the same time, the standardized and automated update process avoids delays and errors that may occur with manual maintenance.

[0120] Furthermore, this application embodiment also supports efficient equipment inventory and on-site management via Near Field Communication (NFC). The external device integrates an NFC sensing chip. Using an NFC-enabled mobile device with corresponding software, when the mobile device approaches this device, computer equipment information will automatically pop up, providing functions such as information modification, recycling, and inventory. When an NFC device (such as a mobile phone) touches this device, the accompanying software on the NFC device will automatically display the basic information of the computer equipment, allowing equipment administrators to complete daily equipment inspections and inventory. With the help of NFC sensing technology and dedicated inventory tools, inventory personnel only need to approach the equipment to complete information reading and comparison, eliminating the need to check equipment information one by one as in traditional methods, significantly improving inventory efficiency.

[0121] In a preferred embodiment of the inventory function, the dedicated inventory tool is specifically a management application running on a mobile terminal (such as a smartphone or tablet). This application is configured to include: a near-field communication module (running a complete NFC protocol stack) for reading the unique identification information of external devices; a network communication module for data interaction with the second computer (server); a user interface for displaying device information and providing operation entry points; and an instruction parser. When the administrator performs an inventory operation (e.g., clicking "Mark as Inventory"), the application generates a management instruction set containing the operation instruction (corresponding to "Change Information, Recycling, Inventory, etc."), the device identifier, and the administrator's identity, and sends it to the server via the network. Upon receiving the instruction set, the server parses and executes it, triggering a state machine transition for the corresponding device file (e.g., updating the status from "Pending Inventory" to "Inventory"), thereby completing a closed-loop digital inventory operation.

[0122] This application further details the interaction process for near-field management via a mobile terminal. This process is executed by a management application running on the mobile terminal and includes the following steps:

[0123] Near Field Sensing and Identifier Reading: When the mobile terminal approaches an external device connected to the first computer, its NFC function is automatically triggered. The management application reads the identification information (e.g., the first hardware identifier or its derived signature) from the external device via the NFC channel.

[0124] Data query and server interaction: The management application will send the identification information it reads to the second computer device (i.e., the management server) via the network to request the device file information that is uniquely bound to the identification.

[0125] Information parsing and interface display: After verifying the request permissions, the server retrieves the corresponding information from the device database (such as device name, asset number, department using the device, current user, hardware and software overview, last reported time, etc.) and returns it to the mobile terminal. The management application receives the data, parses it, and presents it to the administrator in a clear, structured interface.

[0126] On-site operation and command generation: The application provides preset on-site management operation options in the display interface, such as: "Mark as inventory", "Request repair / replacement", "Change status (e.g., in use / idle / scrapped)", "Rebind user", "View complete file", etc. Administrators can select and confirm one or more operations according to the actual situation on site.

[0127] Command reporting and status synchronization: The management application packages the operation command confirmed by the administrator (such as "inventory completed") with the current device identifier, operation time, operator information, etc., to generate a management command data packet, and uploads it to the server.

[0128] Server Processing and Feedback: Upon receiving the instruction, the server immediately updates the relevant status fields in the corresponding device file (e.g., updating the "Last Inventory Time" to the current time, or generating a maintenance work order), and returns a confirmation message of successful processing to the mobile terminal. The mobile terminal application displays a success message, completing this near-field management interaction.

[0129] Through the above steps, this application transforms the traditional offline inventory and equipment management work, which relies on paper lists, manual records, and post-event data entry, into a closed-loop process based on digital identity recognition, real-time online interaction, and automatic data synchronization. This ensures accuracy while achieving a qualitative improvement in management efficiency.

[0130] Based on the aforementioned near-field management interaction process, this application also provides a dedicated mobile inventory terminal product. This terminal serves as the physical carrier for the aforementioned management application, constituting a complete management tool.

[0131] In one specific embodiment, the mobile inventory terminal is a portable electronic device with near-field communication (NFC) capabilities, such as a smartphone or tablet. The terminal includes:

[0132] 1. Near Field Communication Module: Integrates an NFC chip and antenna, used to automatically establish a communication link and read the identification information (such as a first hardware identifier) ​​stored therein when the device is near the external device.

[0133] 2. Network communication module: Supports cellular mobile networks (such as 4G / 5G) or wireless local area networks (Wi-Fi) for data interaction with a remote second computer (server).

[0134] 3. Processor and memory: The memory stores a computer program, and the processor executes the program.

[0135] 4. User interface: including a touch screen for presenting information and receiving user input.

[0136] The computer program is configured to, when executed by the processor, control the mobile inventory terminal to perform the following operations:

[0137] a) The identification information of the external device is sensed and read through the near-field communication module.

[0138] b) The identification information is sent to the server through the network communication module, and the device file information bound to the identification is returned by the server.

[0139] c) The received device file information is displayed through the user interface, and multiple operable options are presented, including "marked as inventory", "request repair", and "change status".

[0140] d) In response to the user's selection of the operable options, generate the corresponding management command, and upload the command and the identification information to the server through the network communication module to trigger the server to update the status of the corresponding device file.

[0141] This mobile inventory terminal integrates hardware reading, network communication, data parsing, and user interaction, eliminating the need for administrators to carry multiple tools (such as barcode scanners, paper lists, and separate recording devices). With just this single terminal, administrators can complete the entire process of device identification, information query, status confirmation, and data synchronization, achieving extreme simplification and efficiency in inventory and management.

[0142] In other possible implementations, the technical concept of this application can also be partially realized through different technical paths.

[0143] For example, Bluetooth technology could be considered to replace the aforementioned Near Field Communication (NFC) function to enable mobile terminals to identify and manage devices in the near field. However, Bluetooth technology may not be as convenient and reliable as NFC technology in terms of connection establishment stability, power consumption control, and distance sensing for precise "contact-based" inventory checks.

[0144] Furthermore, for the automatic collection of device information, it is theoretically possible to explore a method that does not rely on external devices but instead develops driver-level or system-level software deeply integrated into the operating system kernel to directly read and report device information. However, this approach typically faces more complex operating system compatibility challenges, higher development thresholds, and may introduce additional system security risks.

[0145] In contrast, the approach adopted in this application, which relies on the collaboration between external hardware devices and user-mode client software, offers better cross-platform compatibility, easier maintenance and deployment, and provides additional security binding at the hardware level, thus demonstrating comprehensive advantages in terms of practicality, security, and maintainability, while ensuring functionality.

[0146] The following is a preferred embodiment of the product described in this application, specifically illustrating the implementation of the "external device" as an independent protected object. This embodiment is... Figure 4 The hardware structure shown is detailed below.

[0147] Figure 4 This is a schematic diagram of the hardware structure of the external device provided in an embodiment of this application. Figure 4 As shown, the external device 400 is an independent hardware entity, the core of which includes: a physical interface unit 401, a control and storage unit 402, and a near-field communication unit 403.

[0148] The physical interface unit 401 is an electrical interface conforming to the USB or Type-C standard, used to establish a physical connection and bidirectional data communication channel with the first computer.

[0149] The control and storage unit 402 is the core processing and storage component of the external device 400. It includes a microcontroller (MCU) and a non-volatile memory (e.g., EEPROM or Flash) electrically connected to the MCU. The non-volatile memory stores a globally unique first hardware identifier, which serves as the device's hardware root of trust, during the manufacturing phase. The microcontroller is configured to: in response to a query command sent from a first computer via the physical interface unit 401, read the first hardware identifier from the non-volatile memory and return it via the physical interface unit 401; simultaneously, it manages the overall operating status of the device and can respond to trigger events from the near-field communication unit 403.

[0150] The near-field communication unit 403 integrates an NFC chip and a matching antenna, and is connected to the microcontroller of the control and storage unit 402. Specifically, this unit is configured such that when an NFC-enabled mobile terminal approaches within the sensing range, the NFC chip is activated, and a near-field communication link is established with the mobile terminal via the antenna. On this link, the near-field communication unit 403 is configured to provide the mobile terminal with the first hardware identifier, or a simplified code that has a unique mapping relationship with the first hardware identifier, for the mobile terminal to identify and trigger subsequent management processes.

[0151] Through the above hardware design, the external device 400 is configured to perform the following core functions: when connected to the first computer through the physical interface unit 401, it is configured to provide the first computer with its unique first hardware identifier to trigger the binding and information collection process; at the same time, through the near field communication unit 403, it is configured to respond to the near field sensing of the external NFC device and provide the first hardware identifier or the associated code to the device, thereby realizing fast device identification and management without relying on the computer's power-on status.

[0152] This application also provides another implementation of the computer device information processing method, namely, as a cloud-deployable device asset management service. In this service model, the second computer device serves as the cloud management platform of the service provider. This platform provides the following service process to enterprise customers:

[0153] Service subscription and initialization: The customer obtains the external device and deploys it on the computer device to be managed. After the device is connected, the computer automatically completes local binding and information collection, and registers the device profile data to the cloud platform.

[0154] Asset monitoring and visualization: The cloud platform continuously receives periodic updates from various customer computer devices and dynamically maintains a unified asset archive in the background. Customer administrators can log in to the platform via a web browser or a dedicated client to view real-time status dashboards, software compliance reports, and geographical distribution maps of all devices.

[0155] Remote Inventory and Task Management: Administrators create inventory tasks on the platform. On-site personnel use authorized mobile terminals to sequentially approach the external devices of each device for NFC reading. Each reading is equivalent to completing a check-in, and the inventory results (device identification, time, and location) are transmitted back to the platform in real time. The platform automatically compares the data with the task list and generates inventory progress and result reports.

[0156] Policy Enforcement and Security Control: The platform can issue unified security or management policies (such as prohibiting the installation of specific software) to client programs. Client programs execute these policies based on continuous authorization obtained from external devices. This service model enables centralized, service-oriented, and process-driven management of device assets.

[0157] This application further details the interaction process for near-field management via a mobile terminal. This process is executed by a management application running on the mobile terminal and includes the following steps:

[0158] Near Field Sensing and Information Retrieval: When the mobile terminal approaches an external device already connected to the first computer, its NFC function is automatically triggered. The management application reads the identification information of the external device (e.g., the first hardware identifier or its hash value) through the NFC channel.

[0159] Query and Information Display: The management application sends the read identification information to the second computer device (management server) via the network, requesting complete device profile information bound to that identification. After verifying permissions, the server returns basic device information (such as device name, model, user, last online time, etc.). The application presents this information in a clear and concise interface.

[0160] On-site Operation and Command Reporting: The application provides a series of on-site management operation buttons in the display interface, such as "Mark as Inventory," "Request Repair," "Change User," and "View Details." The administrator selects the appropriate operation based on the on-site situation and confirms. The application then uploads this operation command along with the device identifier to the server.

[0161] Server Synchronization and Feedback: After receiving the instruction, the server updates the status of the corresponding device file or generates a new work order, and sends a successful operation feedback to the mobile terminal. The terminal interface displays a success message. This interactive process transforms traditional paper-based inventory and manual registration into a digital, real-time synchronized closed-loop operation, greatly improving the accuracy and efficiency of on-site management.

[0162] Figure 2 This is a schematic diagram of the physical architecture of a computer equipment information processing system provided in an embodiment of this application. The system mainly includes computer equipment and a remote server.

[0163] The computer equipment includes device-supporting software, an inventory device with near field communication (NFC) functionality, an external USB or Type-C device, and a set of device asset information.

[0164] The accompanying software runs on the operating system of the computer device and is the core logic execution terminal of the system. It is configured to automatically execute device information acquisition, processing, and communication tasks in response to the access of external devices.

[0165] External USB or Type-C devices: These physically connect to the computer device via a standard interface. They internally store a unique hardware identifier (first hardware identifier), serving as the device's physical identity credential. Upon connection, they establish a data channel with the device's accompanying software.

[0166] An inventory device with NFC functionality is integrated or tightly coupled with the external device. It receives near-field reads or commands from a remote server and triggers a collaborative workflow between the external device and its accompanying software, serving as the physical interface for convenient on-site management (such as inventory and inspection).

[0167] Equipment asset information set: refers to various static and dynamic information collected from computer equipment by the software accompanying the device, specifically including: computer name, IP address, hardware serial number, MAC address, list of installed software, and real-time running status of antivirus software. This information is obtained through system calls or interface scanning and forms the basis of the equipment file data.

[0168] The remote server is the system's data center and management terminal, responsible for receiving, storing, and processing data from computer devices and responding to management commands.

[0169] The system's connection and data flow are as follows:

[0170] Downlink management command path: The remote server can send query or management commands to the inventory device (e.g., in an inventory scenario). Upon receiving the command, the inventory device triggers the connected external device. The external device then activates its accompanying software and initiates the information collection process.

[0171] Information Collection and Binding Path: The software accompanying the activated device reads its unique hardware identifier (first hardware identifier) ​​through an external device, and simultaneously collects the device asset information set of the local machine and its unique hardware identifier (second hardware identifier, such as the motherboard serial number). The software associates and encapsulates this information to generate device binding data and device profile data.

[0172] Data reporting path: The device's software generates equipment file data and sends it to a remote server via the network. Upon receiving the data, the server parses and stores it, creating or updating a unique digital equipment file corresponding to the computer device.

[0173] Information association path: Figure 2 In the system, each item in the device asset information set (computer name, IP address, etc.) points to an external device, indicating that this information is triggered by the external device and collected by the device's software, and then uniformly associated and reported through the logical channel where the external device is located.

[0174] Figure 3 This is a structural diagram of a computer device information processing system according to an embodiment of this application.

[0175] Secondly, embodiments of this application also provide a computer device information processing system for implementing the computer device information processing method described in any one of the embodiments of the first aspect, comprising a first computer device 300 and a second computer device 301.

[0176] exist Figure 2 In the physical architecture shown, the accompanying software of the device is used to implement the functions of each module of the first computer device; the remote server is used to implement the functions of each module of the second computer device. Figure 2 The external USB or Type-C device and the inventory device with NFC functionality together constitute the physical entity that triggers and connects to the first computer device.

[0177] In this embodiment, the computer device information processing system constitutes the physical and logical entity for implementing the aforementioned management method. The first computer device specifically refers to the target computer device within the enterprise that needs to be managed.

[0178] For example, an employee's office computer or laptop. This device has a dedicated software component (i.e., a client) deployed or installed to implement the functions of this method. The second computer device specifically refers to a central management server deployed remotely, responsible for receiving, processing, and storing reported information from each of the first computer devices.

[0179] The first computer device includes:

[0180] The first receiving module 303 is used to obtain a first hardware identifier in response to the access of an external device; the first hardware identifier belongs to the external device and is unique.

[0181] The first receiving module, in software, is a component in the client program responsible for monitoring hardware events and communication. Its core function is as follows: when the external device (an independent piece of hardware with a USB or Type-C interface, a built-in unique serial number, and an NFC chip) is inserted into the corresponding port of the first computer device, this module detects this hardware access event through the operating system interface. Subsequently, it obtains the first hardware identifier, i.e., the globally unique physical serial number of the external device, by sending a query command to the external device or directly reading its device descriptor. This process is completed automatically and requires no manual input.

[0182] The first determining module 304 is used to generate device binding data and device file data; the device binding data includes association information between the first hardware identifier and a second hardware identifier belonging to the first computer device; the device file data includes the device binding data and hardware information or software information of the first computer device.

[0183] The first determining module is the core processing unit of the client program. It performs two main functions: First, it obtains the second hardware identifier (such as the motherboard serial number) of the first computer device and logically associates it with the previously obtained first hardware identifier to generate device binding data, which is a credential representing the "external device-target computer" binding relationship. Second, the module actively calls the system interface to collect detailed hardware information (such as motherboard model and manufacturer) and software information (list of installed applications) of the first computer device, and combines this detailed information with the aforementioned device binding data to form complete device profile data.

[0184] The first sending module 305 is used to send the device file data to the second computer device;

[0185] The first sending module is the communication component of the client program. Once the device profile data is generated (whether after initial binding or during subsequent updates), this module is responsible for automatically uploading the data to the preset receiving address of the second computer device via a network connection (such as HTTP / HTTPS protocol). It is also typically responsible for handling network anomalies to ensure reliable data transmission.

[0186] The second computer device includes:

[0187] The second receiving module 306 is used to receive device file data from the first sending module.

[0188] The second receiving module is a server-side data receiving interface, such as a RESTful API endpoint or a message queue consumer. It continuously listens for network requests, receives device file data uploaded by the first sending modules of each first computer device, and performs preliminary format verification and parsing.

[0189] The second determining module 307 is used to establish an equipment file based on the equipment file data.

[0190] The second determining module is the core processing service on the server side. It performs deep analysis on the received device profile data and extracts the second hardware identifier as a key index. Then, based on this identifier, it performs operations in its background database: if a corresponding record does not exist, it creates a new device profile record and stores all the parsed information in it; if it already exists, it updates the existing record to ensure that the profile content is synchronized with the latest status of the front-end device.

[0191] The second sending module 308 is used to associate the established device file with the first computer device.

[0192] In this context, the second sending module does not refer to physical transmission, but rather to the establishment of the server-side database logic. Its function is to establish and maintain a permanent, one-to-one correspondence between the file record and a specific first computer device (uniquely represented by its second hardware identifier) ​​at the data level, through database design (such as setting the second hardware identifier as a primary key or unique index). This association ensures that each device file in the server can be accurately traced back to its corresponding physical device.

[0193] Through the collaborative work of the modules in the first and second computer devices, this system realizes a complete closed loop from the automatic collection, binding, and reporting of asset information by terminal devices to the centralized filing, association, and maintenance by the central server, providing an efficient, accurate, and automated management solution for enterprise computer equipment assets.

[0194] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0195] Therefore, this application also proposes a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods described in any embodiment of this application.

[0196] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0197] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0198] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0199] Furthermore, this application also proposes an electronic device (or computing device) including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any embodiment of this application.

[0200] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent memory in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media includes both permanent and non-persistent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information that can be accessed by the computing device. As defined in this article, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

[0201] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0202] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when an element is “connected” or “coupled” to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein may include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0203] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical, technical, and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0204] The above description is merely an embodiment of this application and is not intended to limit the scope 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 the claims of this application.

Claims

1. A computer device information processing method, characterized in that, Includes the following steps: In response to the access of an external device, the first computer obtains a first hardware identifier; the first hardware identifier belongs to the external device and is unique; A first computer generates device binding data; the device binding data includes association information between a first hardware identifier and a second hardware identifier; the second hardware identifier belongs to the first computer. The first computer generates device profile data; the device profile data includes the device binding data and the hardware or software information of the first computer. The first computer sends the device file data to the second computer; The second computer creates a device file based on the device file data; the device file is associated with the first computer.

2. The computer device information processing method according to claim 1, characterized in that, The device binding data also includes user identity information; The step of the second computer establishing a device file based on the device file data specifically includes: establishing a device file that is simultaneously associated with the first computer and the user identity information.

3. The computer device information processing method according to claim 1, characterized in that, The steps for generating device binding data include: Obtain the first hardware identifier and the second hardware identifier, and associate the two to generate the association information.

4. The computer device information processing method according to claim 1, characterized in that, The steps for creating the device file include: Parse the device file data to obtain the second hardware identifier; The device profile is created using the second hardware identifier as an index.

5. The computer device information processing method according to claim 1, characterized in that, The steps of the first computer obtaining the first hardware identifier and generating device binding data are executed by a client program automatically installed on the first computer and triggered by the external device. The client program is configured to block or restrict the sending of device file data to the second computer when the external device is not connected to the first computer.

6. The computer device information processing method according to claim 1, characterized in that, The software information is a list of installed applications obtained by calling the software manifest interface provided by the operating system or by scanning predetermined system directories and registry entries.

7. The computer device information processing method according to claim 1, characterized in that, It also includes the following steps: In response to the update information received from the first computer, the second computer updates the established device file.

8. A computer device information processing system, used to implement the computer device information processing method according to any one of claims 1-7, characterized in that, It includes a first computer device and a second computer device; The first computer device includes: The first receiving module is configured to obtain a first hardware identifier in response to the access of an external device; the first hardware identifier belongs to the external device and is unique; The first determining module is used to generate device binding data and device profile data; the device binding data includes association information between the first hardware identifier and a second hardware identifier belonging to the first computer device; the device profile data includes the device binding data and hardware information or software information of the first computer device. The first sending module is used to send the device file data to the second computer device; The second computer device includes: The second receiving module is used to receive device file data from the first sending module; The second determining module is used to create equipment files based on the equipment file data; The second sending module is used to associate the established device file with the first computer device.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-7.

Images