Pre-write attribution verification and directional transmission method and system for device behavior data

Abstract

The application discloses a method and system for pre-writing attribution verification and directional transmission of device behavior data. A server generates a relationship establishment code, receives confirmation information and device authorization information, and generates a relationship voucher of an association subject identifier, an account identifier, a device identifier, a permission boundary and data attribution rules after verification. An end device reports a device behavior data packet carrying a voucher identifier, an account identifier, a data type, a collection time and an integrity proof. The server performs voucher validity verification, permission boundary matching and subject consistency verification before data is written into a formal archive area, and writes the data into a corresponding formal archive area, rejects it or writes it into an isolation area. Isolated data maintains or updates subject attribution after re-verification, or is set to an invalid state. The scheme can reduce data attribution errors, prevent cross-border data from being filed, and maintain data separation and subject continuity in the same device multi-account and device replacement scenarios.

Description

Technical Field

[0001] This invention relates to the fields of data processing, data access control, terminal identity verification and data routing, and specifically to a method and system for pre-writing attribution verification and directed transmission of device behavior data. Background Technology

[0002] Smart learning terminals, mobile terminals, and terminals running educational applications continuously generate learning behavior data and device usage data during use. Existing systems typically write the generated data into corresponding data files based on login accounts or device identifiers, and then determine who can read the data based on access tokens, device management policies, or viewing permissions.

[0003] The above-mentioned solution can achieve conventional data recording and access control when accounts, devices, and actual users are stably associated. However, in scenarios where the same physical device is used successively by multiple users, accounts are used by non-corresponding users, users temporarily switch accounts, or multiple accounts within a household share a device, the actual user generating the data may differ from the user represented by the current account. If device behavior data is directly written to the current account's official data archive after it is generated, data from non-corresponding users will participate in subsequent profiling, statistics, and analysis, leading to incorrect data attribution and distorted analysis results.

[0004] Some existing solutions can restrict account logins to devices through device binding or machine codes, but these solutions primarily address the login entry point issue. When a device is replaced, it is often necessary to unbind the old device and re-establish the binding relationship. Historical and subsequent data may also be assigned to different data files due to changes in device identification. Using only the device as the basis for attribution also makes it difficult to distinguish multiple actual users on the same device.

[0005] Some authorization schemes control data return on the data reading side based on the authorization scope carried by the token, while some device management schemes control terminal functions or telemetry data reporting based on device policies. These schemes do not necessarily provide a combined verification of data type, relational credential validity, data integrity, and consistency of the actual acting entity before business data is written into the formal entity file, nor do they retain an intermediate state that allows for reconfirmation and reassessment of ownership when the entity's ownership is uncertain.

[0006] Therefore, a technical solution is needed to complete permission boundary matching and subject ownership verification before device behavior data is written to the formal archive area, and to write the data to the isolation area when the ownership is uncertain, and to maintain or update the subject ownership after reconfirmation, so as to reduce the entry of incorrectly owned data into the formal archive area, while maintaining data separation and continuity in scenarios with multiple accounts on the same device and device replacement. Summary of the Invention

[0007] 1. Before device behavior data is written to the official archive area, there is a lack of unified relationship credential validity verification, permission boundary matching, and subject consistency verification. Data generated by non-corresponding subjects may be incorrectly written to the current account's official archive area.

[0008] 2. When data types exceed the authorized scope, some systems only filter them during the reading or display process. The out-of-scope data has already been written into the official data archive, increasing invalid storage and expanding the boundaries of data use.

[0009] 3. Data with uncertain subject attribution lacks isolation of intermediate states, updatable data attribution markers, and traceable state transition mechanisms, making it difficult to reclassify the data to the correct subject afterward.

[0010] 4. When the device identifier changes or the same device corresponds to multiple accounts, if the data archive is based primarily on the device, it can easily lead to data fragmentation or mixing of different data. Technical solution

[0011] To address the aforementioned technical problems, this invention provides a method for attribution verification and directed transmission of device behavior data before it is written to a server. This method triggers relationship confirmation and device authorization through a relationship establishment code, generating a relationship credential that includes the associated subject, account, device, permission boundaries, and data attribution rules. The end device encapsulates the behavior data into a data packet carrying a credential identifier, account identifier, data type, collection time, and integrity proof. Before writing the data packet to the formal archive area, the server performs integrity or authenticity verification, relationship credential validity verification, permission boundary matching verification, and subject consistency verification executed according to trigger conditions. Based on the verification results, the server routes the data packet to the formal archive area, a rejection path, or an isolation area.

[0012] Data packets that fail the subject consistency check remain in an unconfirmed state in the isolation area and are not included in the formal profiling or analysis. If the reconfirmation result indicates that the data belongs to the original subject, the original subject identifier is retained and the data is written to the corresponding formal archive area; if the reconfirmation result indicates that the data belongs to another subject, the subject identifier in the data attribution mark is updated and the data is written to the formal archive area corresponding to the other subject; if the reconfirmation result is negative or the preset time limit is exceeded, the data is set to an invalid state.

[0013] The data ownership rules in the relationship certificate use the subject identifier or account identifier as the ownership basis and are separate from the device identifier. The same device can correspond to multiple independent accounts, relationship certificates, baseline behavioral feature templates, and formal archive areas; when the device is replaced, the device identifier or device fingerprint digest in the relationship certificate is updated, while the subject identifier, account identifier, and data ownership rules remain unchanged.

[0014] The present invention also provides a system corresponding to the above method and a computer-readable storage medium storing a computer program implementing the above method. Beneficial effects

[0015] 1. Performing combined verification before writing device behavior data into the official archive area can reduce the probability of non-corresponding subject data being incorrectly written into the official archive area, and reduce the impact of incorrectly attributed data on the official profile and analysis results.

[0016] 2. The permission boundary field set is matched packet by packet before data is written. Data that exceeds the permission boundary can be rejected or not persisted, thus narrowing the scope of data collection, storage and transmission.

[0017] 3. The quarantine area retains intermediate states awaiting confirmation and updatable data ownership markers, enabling data with uncertain ownership to be reclassified and written to the correct archive area after reconfirmation.

[0018] 4. Data ownership rules are based on subject identifier or account identifier, allowing multiple accounts on the same device to record data separately, and maintaining the continuous ownership of historical and subsequent data after device replacement.

[0019] 5. Forged, tampered, or replayed data packets can be identified through technologies such as device fingerprint digests, integrity certificates, serial numbers, or timestamps.

[0020] 6. Once a relationship credential is revoked, the filing and directed transmission of the corresponding data packet can be terminated immediately. Relationship establishment, credential modification, data routing, and isolation zone status transition can be written to the audit log, enabling traceability of the data processing process.

[0021] 7. Data whose ownership has been confirmed can be transmitted to the data receiving end or data analysis system within the authorized boundaries, providing a reliable data entry point for structured reports, anomaly alerts, threshold optimization, and model updates. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the overall system architecture of the present invention.

[0023] Figure 2 This is a flowchart illustrating the relationship establishment code generation, confirmation, and relationship credential establishment process of the present invention.

[0024] Figure 3 This is a flowchart illustrating the permission boundary generation and data type matching process of this invention.

[0025] Figure 4 This is a flowchart illustrating the encapsulation, integrity verification, and pre-writing validation of the device behavior data packets of this invention.

[0026] Figure 5This is a flowchart illustrating the verification results and data routing process before writing device behavior data in this invention.

[0027] Figure 6 This is a flowchart illustrating the process of assigning data to multiple accounts on the same device according to the present invention.

[0028] Figure 7 This is a flowchart illustrating the equipment replacement and continuous data attribution process of the present invention.

[0029] Figure 8 This is a flowchart illustrating the state transition and ownership migration of the isolation zone in this invention. Detailed Implementation

[0030] The present invention will be further described below with reference to the accompanying drawings and embodiments. The embodiments are used to explain the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art can make equivalent substitutions for terminal types, field names, digest algorithms, signature algorithms, behavioral characteristics, and storage structures without departing from the concept of the present invention.

[0031] like Figure 1 As shown, the system includes a first terminal 100, a second terminal 200, a user device 300, a server 400, a data receiving terminal 500, and a data analysis system 600. The first terminal 100 and the second terminal 200 are relationship participants; either terminal can initiate a relationship establishment request, and the other is used for confirmation. In a family education scenario, the first terminal 100 can be a guardian's terminal, and the second terminal 200 can be a minor's terminal. The user device 300 can be the same physical device as the second terminal 200, or it can be a separate learning machine, tablet computer, mobile terminal, or a terminal running educational applications.

[0032] In this specification, the "formal archive area" refers to a logical storage area used to store data that has passed pre-write verification and is ready to participate in formal statistics, profiling, or analysis. It can be implemented using database tables, data sets, partitions, object storage directories, or record status fields. The "isolation area" refers to a logical storage area used to store data whose ownership has not yet been determined or whose ownership consistency verification has failed. It can also be implemented using independent database tables, message queues, cache areas, or isolation status fields.

[0033] The "relationship establishment code" in this specification is a coded object used in the process of establishing association relationships. In specific products, the applicant may name this relationship establishment code "information code"; the product name does not change its technical attributes as a relationship identifier, timeliness control, and confirmation entry point. like Figure 2As shown, either the first terminal 100 or any of the user devices 300 submits a relationship establishment request to the server 400. The server 400 generates a relationship establishment code and returns it to the initiating end. The initiating end provides the relationship establishment code to the other end by displaying a QR code, numeric string, character code, dynamic link, or near-field communication tag. The other end inputs, scans, or confirms the relationship establishment code and submits the confirmation information to the server 400.

[0034] An example data structure for a relationship establishment code is: {code_id, relation_id, initiator_id, nonce, expire_at, verifier}. Here, code_id is the code identifier, relation_id is the identifier of the relationship to be established, initiator_id is the initiator identifier, nonce is a one-time random number, expire_at is the expiration period, and verifier is the server signature, message authentication code, or verifiable token. After successful confirmation, the server (400 status code) adds the nonce to the used set or updates the code_id status to consumed to prevent replay. The expiration period can be configured according to the business scenario, for example, from 30 seconds to 30 minutes.

[0035] The relationship establishment code is uniformly generated by server 400, which facilitates the unified execution of uniqueness verification, validity period verification, and replay protection. Its bidirectional nature is reflected in the fact that both the first terminal 100 and the user device 300 can initiate a generation request, which is then confirmed by the other end. The server can also proactively generate the relationship establishment code and send it to both participating ends for confirmation. The device authorization information submitted by the end device 300 includes at least the device identifier, and may also include the device fingerprint, application instance identifier, account login status, operating system information, and authorization time. The device fingerprint can be generated by combining at least two of the following: application instance identifier, persistent device identifier, hardware parameters, operating system parameters, display parameters, installation time parameters, time zone parameters, and runtime environment parameters.

[0036] In one implementation, the end device 300 normalizes, sorts, and concatenates the selected device parameters, and then generates a device fingerprint digest using SHA-256, SHA-3, or other digest algorithms. The server 400 stores the digest but not all the original device parameters. When a device system upgrade causes some parameters to change, the server can perform fingerprint drift tolerance based on the number of stable parameters, the weight of the changed parameters, and the most recent successful credentials; if the changes exceed preset conditions, the device replacement process is initiated.

[0037] After the relational credential is generated, server 400 provides verification parameters to end device 300. Verification parameters can be a symmetric verification key associated with the credential identifier, asymmetric key information, a short-term signature token, or a combination thereof. In one implementation, the server uses the master key and credential identifier to generate a credential verification key through a key derivation function and sends it to the secure storage area of ​​the end device via a secure channel; in another implementation, the end device holds the private key, and the server stores the corresponding public key. like Figure 3 As shown, server 400 can provide multiple permission boundary templates. The permission boundary field set can be represented using a bitmap, key-value set, data type whitelist, rule set, or rule tree. The first terminal 100 selects or adjusts the template, another participating terminal views and confirms it, and server 400 writes the final permission boundary into the relational credential. Technically, the formation of permission boundaries can be achieved by converting the terminal's selection and confirmation results into structured fields, eliminating the need for human intervention during data packet processing.

[0038] In one bitmap implementation, each bit of the bitmap corresponds to a preset data type identifier, such as learning duration, task completion status, answer records, review records, reading duration, oral practice records, total device usage time, application usage period, continuous usage time, nighttime usage period, and abnormal operation records. A bit value of 1 indicates that writing or transmission is allowed, and a bit value of 0 indicates that it is not allowed. The bitmap length can be 32 bits, 64 bits, 128 bits, or an expandable length.

[0039] An example data structure for a relational credential is: {cred_id, subject_a, subject_b, account_id, device_digest, scope_set, attribution_rule, receiver_id, issued_at, expire_at, revoked, risk_level, audit_seq}. Here, cred_id is the credential identifier, subject_a and subject_b are the subject identifiers at both ends of the relationship, account_id is the account identifier, device_digest is the device fingerprint digest, scope_set is the permission boundary field set, attribution_rule is the data ownership rule field set, receiver_id is the data receiver identifier, and revoked indicates the revocation status.

[0040] The `attribution_rule` prioritizes attributing data to the subject represented by `subject_b` or `account_id`, rather than using `device_digest` as the sole attribution criterion. Therefore, the same device can support multiple accounts generating independent relational credentials and independent data archives. Relational credentials can be stored as server database records or encoded as signed tokens; regardless of the medium, the server can query or verify the structured fields based on the credential identifier. The user terminal device 300 collects device behavior data. Device behavior data includes learning data and device usage data. Learning data may include learning duration, task completion status, answer response latency, error type, review records, reading behavior, oral practice, and task switching records; device usage data may include device usage duration, application usage time period, continuous usage duration, nighttime usage status, application switching, and abnormal operation records.

[0041] like Figure 4 As shown, an example of a device behavior data packet data structure is: {cred_id, account_id, type_id, payload, collected_at, seq, integrity_proof}. Where cred_id is the relational credential identifier, account_id is the current account identifier, type_id is the data type identifier, payload is the data payload, collected_at is the collection time, seq is the incrementing sequence number, and integrity_proof is the integrity or authenticity proof.

[0042] In one implementation, the end device 300 uses the credential verification key to calculate the HMAC-SHA256 message authentication code on the data packet field; in another implementation, the end device uses a private key to generate a digital signature; authenticity verification can also be completed using a short-term signature token issued by the server and a transport layer secure channel. `seq`, `collected_at`, and a random number can be used to identify duplicate reports or replayed data packets.

[0043] The user device (300) can pre-validate the `type_id` based on the permission boundaries of the local cache. Data that does not match may not be persisted or reported. Local pre-validation is used to reduce invalid data collection and transmission, but the server-side pre-write validation serves as the final basis for whether to enter the formal archive area. like Figure 4 and Figure 5As shown, server 400 performs a combined verification before writing device behavior data packets to the official archive area. First, it verifies integrity_proof based on the verification parameters and checks whether the sequence number (seq) or timestamp meets the anti-replay requirements. Second, it queries or verifies relationship credentials based on cred_id, checking their validity period, revocation status, account identifier, and device identifier or device fingerprint digest. Third, it matches type_id with scope_set to determine whether the data type is allowed to be written or transmitted. Fourth, it performs subject consistency verification when the data packet belongs to a preset data type, contains sufficient behavioral characteristics, the cumulative sample count reaches a threshold, or a risk rule is triggered.

[0044] If the integrity or authenticity verification, relational credential validity verification, and permission boundary matching verification all pass, and subject consistency verification is not required or passes, the server 400 generates a data ownership tag based on the attribute_rule, writes the data packet to the official archive area corresponding to account_id or subject_id, and forwards the data allowed by scope_set or its digest to the data receiver 500 corresponding to receiver_id.

[0045] Data packets that fail to match permission boundaries can be rejected, discarded, or only retained as rejection logs without business payloads, and will not be written to the official archive area. Data packets that fail the subject consistency check are written to the isolation area and set to a pending confirmation status, and will not participate in formal profiling, statistics, or analysis until confirmed.

[0046] An example data structure for data attribution tagging is: {record_id, cred_id, subject_id, account_id, source_digest, type_id, state, risk_flag, visible_to, collected_at, written_at}. Here, subject_id is a subject identifier that can be updated during attribution migration, and state can be archived, pending, migrated, or invalid. Subject consistency checks are not enforced on all data types. For data that only represents device on / off times, total usage time, etc., and does not contain individual behavioral characteristics, only the aforementioned three checks can be performed. For data that contains behavioral rhythms, such as answering questions, inputting data, switching tasks, or continuous operations, or data triggered by risk rules, subject consistency checks are performed.

[0047] In one rule-based scoring implementation, a feature vector x is extracted from the current data packet or data packets within a preset time window. The features may include the mean and standard deviation of the response time, error type distribution, task switching interval, input rhythm, usage time distribution, and operation sequence features. The server maintains a baseline mean vector μ, a dispersion vector σ, and a weight vector w for each account, and calculates the deviation score D = Σw_i × |x_i - μ_i| / (σ_i + ε), where ε is a positive number to prevent the denominator from being zero. When D is greater than a threshold T, the subject consistency check is deemed to have failed.

[0048] In another implementation, the deviation can be calculated using Euclidean distance, weighted distance, cosine distance, Mahalanobis distance, isolated forest, single-class classifier, or a trained classification model. When using Mahalanobis distance, a regularization term can be added to the covariance matrix or a generalized inverse can be used to avoid the matrix being non-invertible under small sample conditions.

[0049] In the initial stage of account creation, if the number of confirmed samples in the official archive area is lower than the cold start threshold N, entity consistency verification can be omitted, verification weight reduced, or only deterministic risk rules can be used. Data that has been reconfirmed to belong to this account is used to update the baseline template; data that has been confirmed to belong to other entities or is invalid is not used for updates. The server can adjust the threshold T based on the false positive rate in the quarantine area, false negative feedback, and the risk level of different data types. like Figure 8 As shown, data packets in the quarantine zone have at least four states: pending confirmation, ownership confirmation, ownership migration, and invalid. Data packets enter the quarantine zone in the pending confirmation state. If the reconfirmation result indicates that the packet belongs to the original subject, the `subject_id` remains unchanged, the status is updated to ownership confirmation or archived, and written to the original subject's official archive area. If the reconfirmation result indicates that the packet belongs to another subject, the `subject_id` is updated to the other subject's identifier, the status is updated to ownership migration or migrated, and written to the other subject's official archive area. If the confirmation result is negative or no confirmation result is obtained within a preset time limit, the status is updated to invalid, and no official archive area is written.

[0050] Reconfirmation can be submitted by the first terminal 100, by the current user on the user device 300, by both participating terminals submitting separately and taking effect after the results are consistent, or by the server generating candidate subjects based on the baseline of other accounts under the same device and then confirming them by any participating terminal. For high-risk operations such as changes in permission boundaries, confirmation from both participating terminals can be required; for data ownership correction between multiple accounts in a family, confirmation can be made by a pre-configured confirmation terminal.

[0051] The preset time limit can be configured according to data type and risk level, for example, from 1 hour to 7 days. One implementation uses 72 hours. Data awaiting confirmation in the isolation zone is not visible to ordinary data receivers; only a summary notification of "Records awaiting confirmation exist" is displayed. Each state transition is written to the audit log. like Figure 6 As shown, the fingerprint digest of the same device can correspond to multiple account identifiers. Server 400 maintains relationship credential A, relationship credential B, baseline behavioral feature template A, baseline behavioral feature template B, and formal archive area A and formal archive area B for account A and account B, respectively. Each data packet reported by the end device 300 carries the current account identifier, and the server performs verification and writing based on the current account identifier and the corresponding relationship credential.

[0052] When the deviation of account A declared in the data packet from baseline template A exceeds the threshold, while the deviation from the baseline template of account B under the same device is below the candidate threshold, the server can write the subject corresponding to account B as a candidate subject to the isolation record, but will not directly migrate it before reconfirmation. After confirmation, the subject_id is updated and written to archive area B.

[0053] This implementation allows multiple entities to share a single physical device, while ensuring that each account's data is separately attributed, formally archived, and analyzed. When different entities use different devices, data is processed independently based on their respective account identifiers, relationship credentials, and device authorization information. like Figure 7 As shown, after receiving a device replacement request, the server (400) invalidates the verification parameters corresponding to the old device and sets the old device identifier or fingerprint digest to an invalid, historical, or standby state. When any participating end initiates a new relationship establishment request, the server generates a new relationship establishment code; the new user device submits confirmation information and device authorization information.

[0054] After successful verification, the server updates the device identifier or device fingerprint digest in the original relationship credential, or generates a new relationship credential associated with the original subject identifier and account identifier, and provides new verification parameters to the new user device. During the update process, subject_a, subject_b, account_id, and attribute_rule remain unchanged, so historical data does not need to be migrated, and subsequent data generated by the new device continues to be written to the official archive area of ​​the same subject.

[0055] If the verification parameters of the old equipment become invalid, data packets generated using the old parameters will be rejected during the integrity or credential validity verification phase. The equipment replacement process can be completed automatically and does not require permanently binding data files to a single machine code. The first path is the server relay path. The user device 300 reports data packets to the server 400. After the server completes pre-write verification, attribution processing, and formal archiving, it transmits the data, summary, or analysis results permitted by the access boundaries to the data receiving end 500. This path is suitable for cross-network transmission, server analysis, and unified auditing.

[0056] The second path is the end-to-end auxiliary path. Using a locally cached copy of the relational credentials and permission boundaries, the end device 300 sends a temporary digest within the permitted range to the data receiver 500 via LAN, Bluetooth, NFC, or an encrypted point-to-point channel. Simultaneously, it reports the original data packet or digest data to the server 400 to complete pre-write verification. If the server verification fails, it can send a correction, withdrawal, or risk flag to the data receiver. The temporary digest in the end-to-end auxiliary path does not replace the attribution processing result of the server's official archive area. The data analysis system only reads data in the official archive area that is in the archived or migrated state. Data in the pending or invalid state is not included in the official profile and model updates. Data that has been de-identified or anonymized and permitted by the permission boundaries can be used to statistically analyze the false positive rate of subject consistency, threshold stability, device switching characteristics, and multi-account usage characteristics of different data types.

[0057] The server can generate structured analysis results, anomaly alerts, or terminal usage strategy prompts based on data in the official archive area. An example of structured output is: {suggestion_id, subject_id, trigger_rule_id, evidence_digest, risk_level, recommendation_code, generated_at}. Here, trigger_rule_id represents the triggering rule, evidence_digest represents the data summary supporting the result, and recommendation_code corresponds to a preset description template or subsequent processing strategy.

[0058] In family education implementation scenarios, the data receiving end 500 can display a learning task completion summary, device continuous use timeout reminder, abnormal operation reminder, or communication suggestions based on the recommendation_code. The above-mentioned display content is a structured output of data that has already passed technical verification and attribution processing, without changing the core processing flow of attribution verification before writing in this invention. Server 400 can generate relationship establishment codes for temporary experiences or tasks. Temporary relationship credentials have a short validity period, and their data ownership rules indicate that the data is written to a temporary archive area or a quarantine area, rather than directly to the official archive area of ​​an existing entity.

[0059] When a temporary user creates a formal account, the data ownership marker of the temporary data can be updated to the formal entity's identifier after confirmation, and the data can be migrated to the formal archive area of ​​that entity. Temporary data without a formal account can be invalidated, deleted, or used only for statistics that do not involve individual profiles after the expiration of the validity period, after de-identification. This implementation method can reduce the mixing of temporary data into existing entity archives. The first terminal 100 or the user device 300 can submit a credential change request. The request may include adjusting permission boundary fields, shortening or extending the validity period, changing the data receiving end, changing the device identifier, or setting a revocation status. The server can require another participating end to reconfirm based on the type of change.

[0060] After the revocation takes effect, data packets carrying the corresponding credential identifier are rejected during the relationship credential validity verification phase. The server records the generation and consumption of relationship establishment codes, confirmation information, device authorization information, generation and modification of relationship credentials, verification results and routing destinations of each data packet, isolation zone state transitions, data ownership tag updates, and directed transmission results.

[0061] Audit logs can be appended to, and each log entry can save a summary of the previous log entry to form a chained verification structure. Audit log fields may include audit_id, event_type, cred_id, record_id, actor_id, old_state, new_state, result_code, and event_time. Server 400 can consist of one or more physical servers, cloud computing nodes, edge computing nodes, or containerized services. The relationship establishment code generation module, relationship credential generation module, verification module, data routing module, attribution processing module, directed transmission module, isolation zone management module, and auditing module can be deployed on the same computing node, or distributed through message queues or remote procedure calls.

[0062] The user-end device 300 includes a processor, a memory, a communication module, and a device authorization module, a data acquisition module, a data packet encapsulation module, and a data reporting module running on the processor. When a computer program is stored in a computer-readable storage medium and executed by the processor, it can implement the aforementioned method steps. Computer-readable storage media include, but are not limited to, read-only memory, random access memory, solid-state memory, disk, optical disk, and non-transitory network storage media.

[0063] 100: First terminal; 200: Second terminal; 300: User device; 400: Server; 500: Data receiving end; 600: Data analysis system.

[0064] The first terminal 100 and the second terminal 200 are used to initiate or confirm relationship establishment requests; the user terminal device 300 is used to generate device authorization information, collect and report device behavior data; the server 400 is used for relationship establishment code generation, relationship credential generation, pre-write verification, data routing, attribution processing, isolation zone management, targeted transmission and auditing; the data receiving terminal 500 is used to receive data or analysis results within the boundary; the data analysis system 600 is used for feature extraction, baseline maintenance, threshold optimization and structured analysis.

Claims

1. A method for attribution verification and directed transmission of device behavior data before writing, applied to a server, characterized in that, include: In response to a relationship establishment request submitted by a first terminal or user device, a relationship establishment code with an association identifier and a validity period is generated, and the relationship establishment code is sent to the initiator of the relationship establishment request; Receive confirmation information submitted by a confirmation terminal different from the initiating terminal for the relationship establishment code, and device authorization information submitted by the user terminal device; The relationship establishment code, confirmation information and device authorization information are verified. After the verification is successful, a relationship certificate is generated. The relationship certificate is associated with at least the certificate identifier, the first subject identifier, the second subject identifier, the account identifier, the device identifier or the device fingerprint digest, the permission boundary field set and the data ownership rule field set, and the verification parameters associated with the relationship certificate are provided to the user device. Receive device behavior data packets reported by the user terminal device, wherein the device behavior data packets carry at least the credential identifier, the current account identifier, the data type identifier, the collection time, and the integrity certificate; Before writing the device behavior data packet into the formal archive area, the device behavior data packet is subjected to integrity or authenticity verification, relationship credential validity verification and permission boundary matching verification. When the device behavior data packet meets the preset subject consistency verification trigger condition, the subject consistency verification is performed on the device behavior data packet. Based on the verification results, the device behavior data packets are routed as follows: when all verifications pass, a data ownership marker is generated or updated according to the data ownership rule field set, and the device behavior data packets are written to the official archive area corresponding to the current account identifier or the subject identifier in the data ownership marker. Data that conforms to the permission boundary field set is then directed to the data receiving end corresponding to the first subject identifier. When the permission boundary matching verification fails, the device behavior data packets are rejected or prevented from being written to the official archive area. When the subject consistency verification fails, the device behavior data packets are written to the isolation area and set to a pending confirmation state, and are not written to any official archive area. In response to the reconfirmation result of the device behavior data packet in the isolation zone with an pending status, if the reconfirmation result indicates that it belongs to the original subject, the subject identifier in the data attribution mark is retained and written into the corresponding formal archive area; if the reconfirmation result indicates that it belongs to another subject, the subject identifier in the data attribution mark is updated and written into the formal archive area corresponding to the updated subject identifier; or if the reconfirmation result is negative or no reconfirmation result is obtained within a preset time limit, the device behavior data packet is set to an invalid state.

2. The method according to claim 1, characterized in that, The relationship establishment request is initiated by either the first terminal or the user device. The relationship establishment code is generated by the server and confirmed by the other terminal. The relationship establishment code includes at least a code identifier, a relationship identifier, a one-time random number, a validity period, and verification information. After the relationship establishment code is successfully confirmed, the server sets the one-time random number to a used state to prevent the relationship establishment code from being reused.

3. The method according to claim 1, characterized in that, The permission boundary field set is represented by at least one of bitmap, key-value set or rule set, and each data type identifier is mapped to the corresponding field in the permission boundary field set; the data ownership rule field set uses the subject identifier or account identifier as the data ownership benchmark, and makes the data ownership benchmark independent of the device identifier.

4. The method according to claim 1, characterized in that, The device authorization information includes a device identifier and a device fingerprint generated from at least two device parameters, wherein the device parameters are selected from application instance identifier, persistent device identifier, hardware parameters, operating system parameters, display parameters, installation time parameters, and operating environment parameters; the server stores a digest of the device fingerprint; the verification parameters include at least one of symmetric verification key, asymmetric key information, or signature token, and the integrity proof is generated by message authentication code, digital signature, or the signature token.

5. The method according to claim 1, characterized in that, The subject consistency verification includes: extracting at least two behavioral features from device behavior data packets that meet the preset subject consistency verification trigger conditions, wherein the behavioral features are selected from response latency features, error type distribution, task switching interval, input rhythm, usage period, and operation sequence; calculating the deviation of the behavioral features from the baseline behavioral feature template corresponding to the current account identifier; determining that the subject consistency verification fails when the deviation exceeds a preset threshold, and determining that the subject consistency verification passes when the deviation does not exceed the preset threshold; and updating the baseline behavioral feature template using data confirmed to belong to the current account identifier.

6. The method according to claim 1, characterized in that, The device behavior data packets in the isolation zone have a pending confirmation state, an attribution confirmation state, an attribution migration state, and an invalid state; the reconfirmation result is submitted by the first terminal, the user device, or jointly by the first terminal and the user device, or confirmed by any participating party after the server generates a candidate attribution subject; each state transition and each update of the data attribution mark in the isolation zone is written to the audit log.

7. The method according to claim 1, characterized in that, When the same user device corresponds to multiple account identifiers, the server maintains independent relationship credentials, baseline behavior feature templates, and formal archive areas for each account identifier, and assigns data ownership according to the current account identifier in the device behavior data packet. When a device is replaced, the verification parameters corresponding to the original user device become invalid, the server receives the device authorization information of the new user device and updates or regenerates the device identifier or device fingerprint digest in the relationship credentials, while keeping the subject identifier, account identifier, and data ownership rules unchanged.

8. The method according to claim 1, characterized in that, Also includes: In response to a credential change request submitted by a participating party in the relationship, update the permission boundary field set, validity period, data receiver, or revocation status of the relationship credential; After the revocation status takes effect, the device behavior data packets carrying the corresponding credential identifier are rejected; after the data written to the formal archive area is anonymized or desensitized, the subject consistency verification results and reconfirmation results are statistically analyzed, and the preset threshold is adjusted or the analysis model is updated accordingly. Based on the data in the formal archive area, structured analysis results, anomaly alerts, or terminal usage policy prompts are generated and transmitted to the data receiving end when permitted by the permission boundary field set.

9. A system for attribution verification and directional transmission of device behavior data before writing, characterized in that, This includes servers and end-user devices; The server includes: a relationship establishment code generation module, used to generate a relationship establishment code in response to a relationship establishment request; a relationship credential generation module, used to generate a relationship credential containing an associated subject identifier, account identifier, device identifier or device fingerprint digest, permission boundary field set, and data ownership rule field set after the confirmation information and device authorization information have been verified; a verification module, used to perform integrity or authenticity verification, relationship credential validity verification, permission boundary matching verification, and subject consistency verification performed according to trigger conditions before the device behavior data packet is written to the formal archive area; a data routing module, used to write the device behavior data packet to the corresponding formal archive area, reject it, or write it to the isolation area according to the verification results; an ownership processing module, used to generate or update the data ownership mark of the device behavior data packet; a directed transmission module, used to transmit data that conforms to the permission boundary field set to the data receiving end; and an isolation area management module, used to control the state transfer and ownership migration of the device behavior data packet in the isolation area according to the reconfirmation result. The user-end device includes: a device authorization module for generating and submitting device authorization information; a data acquisition module for collecting device behavior data; a data packet encapsulation module for generating a device behavior data packet carrying a credential identifier, current account identifier, data type identifier, acquisition time, and integrity proof; and a data reporting module for reporting the device behavior data packet to the server.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it causes the processor to implement the method of any one of claims 1 to 8.

Images