Advertisement display verification method and device, and electronic equipment

Abstract

This application discloses a method, apparatus, and electronic device for verifying ad display. The method includes: sending an ad request to an advertising platform; receiving a delivery response corresponding to the ad request from the advertising platform; generating a sampling frame sequence based on behavioral feature data from a terminal device; dividing the sampling frame sequence into multiple sub-intervals and generating a session root commitment based on the cryptographic commitments corresponding to each sub-interval; generating a non-interactive proof based on verification parameters; and sending the cryptographic verification information to the advertising platform. This application addresses the technical problems caused by the over-reliance on plaintext data reporting from the client side and backend sampling analysis in existing ad display compliance verification methods, which leads to increased privacy risks, higher compliance costs, and low efficiency in cross-media reconciliation and dispute resolution.

Description

Technical Field

[0001] This application relates to the field of digital advertising measurement, and more specifically, to a method, apparatus, and electronic device for verifying advertising display. Background Technology

[0002] In the current digital advertising industry, ad display compliance verification (confirming whether ads meet preset standards such as visual and audibility requirements and dwell time) largely relies on front-end JavaScript (JS) code or Software Development Kits (SDKs) for data sampling. After sampling, this data is directly reported to the advertising platform or third-party auditing agency in plaintext form, i.e., unencrypted raw data, for analysis and judgment. However, this data processing and transmission mode is accompanied by a series of key issues, as follows:

[0003] 1. Because the sampled data is transmitted in plaintext, it is susceptible to various forms of tampering, such as using automated scripts, pre-recorded or speed-up playback techniques to fake user behavior, thereby affecting the accuracy and reliability of ad display compliance verification.

[0004] 2. Detailed user behavior data, including browsing habits, interaction behaviors, and even device-specific identifiers (device fingerprints), flows and is stored at various stages of the advertising industry chain, greatly increasing the possibility of user privacy information leakage.

[0005] 3. In environments spanning different media platforms and advertising service providers, the lack of a unified and credible measurement and verification standard makes it difficult to establish a solid trust relationship among the parties. This leads to frequent disputes during the reconciliation process, and the auditing work required to resolve these disputes is complex, time-consuming, labor-intensive, and costly.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This application provides a method, apparatus, and electronic device for verifying advertising display, which at least solves the technical problems caused by the excessive reliance of relevant advertising display compliance verification methods on edge plaintext data reporting and backend sampling analysis, resulting in increased privacy leakage risks, higher compliance costs, and low efficiency in cross-media reconciliation and dispute resolution.

[0008] According to one aspect of this application, a verification method for advertising display is provided, applied to a terminal device, comprising: sending an advertising request to an advertising platform; receiving a delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters for generating verification information; generating a sampling frame sequence based on behavioral feature data in the terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data; dividing the sampling frame sequence into multiple sub-intervals, and generating a session root commitment based on the cryptographic commitments corresponding to the multiple sub-intervals respectively; generating a non-interactive proof based on the verification parameters, and sending the cryptographic verification information to the advertising platform, wherein the cryptographic verification information includes: verification parameters, a session root commitment, and a non-interactive proof, and the cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

[0009] Optionally, a session root commitment is generated based on the cryptographic commitments corresponding to multiple sub-intervals, including: encoding the behavioral feature data of all sampled frames in each sub-interval into a corresponding structured data set; performing deterministic operations on the structured data set of each sub-interval based on the commitment algorithm to obtain a unique cryptographic commitment corresponding to each sub-interval; using the cryptographic commitments of multiple sub-intervals as leaf nodes, and according to predefined tree structure rules and hash linking rules, performing iterative hash calculations and linking from bottom to top based on the leaf nodes to obtain a verifiable data structure; and determining the cryptographic commitment of the root node of the verifiable data structure as the session root commitment.

[0010] Optionally, the behavioral feature data of all sampled frames in each sub-interval is encoded into a corresponding structured data set, including: performing cryptographic hash operations on the advertising identification information, challenge random number, and random seed to obtain an initial hash value; determining the hash value corresponding to each sampled frame based on the initial hash value and the behavioral feature data of the sampled frames collected sequentially in the sampled frame sequence; and encoding and concatenating the hash values ​​of the sampled frames belonging to each sub-interval in the order of frame number to form a structured data set for each sub-interval.

[0011] Optionally, based on the initial hash value and the behavioral feature data of the sampled frames collected sequentially in the sampled frame sequence, the hash value corresponding to each sampled frame is determined, including: generating complete frame data based on the behavioral feature data, timestamp information, and link hash value of each sampled frame, and performing a cryptographic hash operation on the complete frame data to obtain the hash value corresponding to the sampled frame. Specifically, for the first sampled frame in the sampled frame sequence, the link hash value used is the initial hash value; for samples other than the first sampled frame in the sampled frame sequence, the link hash value used is the hash value corresponding to the previous adjacent sampled frame.

[0012] Optionally, a non-interactive proof is generated based on the verification parameters, including: constructing private witness parameters for the zero-knowledge proof based on witness information, wherein the witness information includes: a sampled frame sequence, a random number used to generate the cryptographic commitment for each sub-interval, an authentication path used to verify the position of the session root commitment in a verifiable data structure, and verified environment elements selected from a predefined set of compliant environments; constructing public input parameters for the zero-knowledge proof based on the session root commitment and the verification parameters; and invoking the zero-knowledge proof system based on the private witness parameters and the public input parameters to generate the non-interactive proof.

[0013] Optionally, the method further includes: determining whether the resource status of the terminal device does not meet the preset requirements and whether the time taken to generate the non-interactive proof exceeds a preset threshold; if the resource status of the terminal device does not meet the preset requirements or the time taken to generate the non-interactive proof exceeds the preset threshold, after generating the session root commitment, sending the session root commitment to the advertising platform; after sending the session root commitment to the advertising platform, based on the same private witness parameters and public input parameters as those used to generate the session root commitment, calling the zero-knowledge proof system to generate the non-interactive proof; and sending the non-interactive proof to the advertising platform, wherein the non-interactive proof is used by the advertising platform to verify the non-interactive proof using the received session root commitment.

[0014] According to another aspect of this application, a verification method for advertising display is also provided, applied to an advertising platform, comprising: receiving an advertising request sent by a terminal device; if the advertising request meets preset delivery conditions, sending the advertising content corresponding to the advertising request and verification parameters for generating verification information to the terminal device; receiving cryptographic verification information sent by the terminal device, wherein the cryptographic verification information includes: verification parameters, a session root commitment, and a non-interactive proof; the session root commitment is generated by dividing the sampled frame sequence into multiple sub-intervals and based on the cryptographic commitments corresponding to the multiple sub-intervals respectively, and the sampled frame sequence is constructed based on behavioral feature data in the terminal device; the non-interactive proof is generated based on the verification parameters; and verifying the cryptographic verification information to determine whether the display status of the advertising content meets the requirements.

[0015] Optionally, the cryptographic verification information is verified, including: determining whether the version identifier of the verification parameter is consistent with the version identifier of the currently used verification parameter; if the version identifier of the verification parameter is consistent with the version identifier of the currently used verification parameter, verifying the non-interactive proof in the cryptographic verification information based on the verification parameter and the public input parameters of the zero-knowledge proof, wherein the public input parameters include at least: the session root commitment and the verification parameter.

[0016] Optionally, after verifying the cryptographic verification information, the method further includes: generating a verification receipt if the verification of the non-interactive proof in the cryptographic verification information passes, wherein the verification receipt includes at least one of the following: a session root commitment, a verification digest of the verification result, and timestamp information; marking the display behavior based on the advertising content if the verification of the non-interactive proof in the cryptographic verification information fails; and performing settlement business processing on the display behavior according to the verification result of the non-interactive proof in the cryptographic verification information.

[0017] Optionally, after verifying the cryptographic verification information, the method further includes: writing the information set into a message queue and storing the message queue in an object storage system, wherein the information set includes: advertising identification information, session root commitment, message digest of the verification receipt, and verification result; performing aggregate calculation on the non-interactive proofs corresponding to multiple verified advertising display records to generate an aggregate proof and determining the aggregate root digest corresponding to the aggregate proof; and saving the aggregate proof and the aggregate root digest corresponding to the aggregate proof to a distributed ledger system.

[0018] Optionally, the method further includes: sending a sampling instruction to the terminal device when the preset sampling conditions are met, wherein the sampling instruction includes at least one of the following verification requirements: requiring the terminal device to provide all or part of the field information of the target cryptographic commitment corresponding to the target sub-interval of a specified duration in the sampling frame sequence, and the authentication path of all or part of the field information in the verifiable data structure; requiring the terminal device to generate and submit an enhanced proof for the sampling frame sequence, wherein the enhanced proof is generated by applying a target constraint to the zero-knowledge proof circuit, wherein the zero-knowledge proof circuit is used to constrain the compliance of the sampling frame sequence, and the constraint strength of the target constraint is greater than the constraint strength used by the zero-knowledge proof circuit to generate the non-interactive proof.

[0019] According to another aspect of this application, an ad display verification device is also provided, comprising: a first sending module for sending an ad request to an ad platform; a first receiving module for receiving a delivery response corresponding to the ad request sent by the ad platform, wherein the delivery response includes at least: ad content and verification parameters for generating verification information; a construction module for generating a sampling frame sequence based on behavioral feature data in a terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data; a generation module for dividing the sampling frame sequence into multiple sub-intervals and generating a session root commitment based on the cryptographic commitments corresponding to the multiple sub-intervals; and a second sending module for generating a non-interactive proof based on the verification parameters and sending the cryptographic verification information to the ad platform, wherein the cryptographic verification information includes: verification parameters, a session root commitment, and a non-interactive proof, and the cryptographic verification information is used to verify whether the display status of the ad content meets the requirements.

[0020] According to another aspect of this application, an advertising display verification device is also provided, comprising: a second receiving module for receiving an advertising request sent by a terminal device; a third sending module for sending advertising content corresponding to the advertising request and verification parameters for generating verification information to the terminal device when the advertising request meets preset delivery conditions; the third receiving module for receiving cryptographic verification information sent by the terminal device, wherein the cryptographic verification information includes: verification parameters, a session root commitment, and a non-interactive proof; the session root commitment is generated by dividing the sampled frame sequence into multiple sub-intervals and based on the cryptographic commitments corresponding to the multiple sub-intervals respectively, and the sampled frame sequence is constructed based on behavioral feature data in the terminal device; the non-interactive proof is generated based on the verification parameters; and a verification module for verifying the cryptographic verification information to determine whether the display status of the advertising content meets the requirements.

[0021] In this application, the following steps are employed: sending an advertising request to an advertising platform; receiving a delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters for generating verification information; generating a sampling frame sequence based on behavioral feature data in the terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data; dividing the sampling frame sequence into multiple sub-intervals, and generating a session root commitment based on the cryptographic commitments corresponding to each of the multiple sub-intervals; generating a non-interactive proof based on the verification parameters, and sending the cryptographic verification information to the advertising platform, wherein the cryptographic verification information includes: verification parameters, a session root commitment, and a verification response. By combining zero-knowledge proof technology and a layered commitment mechanism, cryptographic verification information is used to verify whether the display status of advertising content meets the requirements. This achieves the goal of accurately verifying the compliance of advertising display while protecting user privacy. As a result, it reduces the risk of privacy leakage, reduces compliance costs, and improves the efficiency of cross-media reconciliation and dispute resolution. This solves the technical problems caused by the excessive reliance on plaintext data reporting from the client side and backend sampling analysis in the relevant advertising display compliance verification methods, which leads to increased risk of privacy leakage, increased compliance costs, and low efficiency of cross-media reconciliation and dispute resolution. Attached Figure Description

[0022] 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:

[0023] Figure 1 This is a flowchart of an advertisement display verification method according to an embodiment of this application;

[0024] Figure 2This is a flowchart of another method for verifying advertisement display according to an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of an advertisement display verification system according to an embodiment of this application;

[0026] Figure 4 This is a flowchart of another method for verifying advertisement display according to an embodiment of this application;

[0027] Figure 5 This is a structural diagram of an advertising display verification device according to an embodiment of this application;

[0028] Figure 6 This is a structural diagram of an advertising display verification device according to an embodiment of this application;

[0029] Figure 7 This is a hardware structure block diagram of a computer terminal for an advertisement display verification method according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] According to an embodiment of this application, a method embodiment for verifying an advertisement display is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 1 This is a flowchart of an advertisement display verification method according to an embodiment of this application. The method is applied to a terminal device, such as... Figure 1 As shown, the method includes the following steps:

[0034] Step S101: Send an advertising request to the advertising platform.

[0035] In step S101, when a user accesses a webpage or application that includes an advertising plugin on a terminal device, the terminal device's software development kit or built-in advertising processing module sends a request to a pre-defined advertising platform. The advertising request may include at least one of the following: ad slot identifier, device information, geographic location (if authorized), and current page context, in order to match appropriate advertising content for display.

[0036] Step S102: Receive the delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters used to generate verification information.

[0037] In step S102, after receiving the request, the advertising platform matches the request parameters with the advertising inventory to determine suitable advertising content for display, and then returns a delivery response to the terminal device. The delivery response may carry the actual advertising creative to be displayed (e.g., images, video links, audio files, etc.) and verification parameters. Verification parameters are key information used to generate zero-knowledge proofs, including but not limited to the challenge random number nonce, the threshold parameter set θ (e.g., visible percentage threshold, audible duration requirement, etc.), the verification public key vk, or the verification parameter version number vk_version, used to guide the terminal device in generating correct verification information.

[0038] Step S103: Generate a sampling frame sequence based on the behavioral feature data in the terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data.

[0039] In step S103, after receiving the delivery response, the terminal device samples the user's advertising display behavior. Each sampling frame includes at least one of the following behavioral feature data: visible proportion vi, foreground focus flag fi, volume intensity ai, and interaction bit ei; in addition, each sampling frame may also include a timestamp ti. Wherein, visible proportion vi: represents the visible proportion of the advertisement in the viewport, represented by a fixed-point integer from 0 to 100; foreground focus flag fi: indicates whether the page containing the advertisement is in the foreground and has focus, and can take values ​​of 0 / 1; volume intensity or "not muted" flag ai: represents a fixed-point integer or Boolean value from 0 to 100; interaction bit ei: used to mark interactive behaviors such as scrolling, clicking, mouse entry, and key presses, and can take values ​​of 0 / 1; timestamp ti: can be a timestamp quantized in milliseconds or 10ms.

[0040] Behavioral feature data is quantized and mapped to fixed-point integers or Boolean values ​​during sampling; for example, visible percentage is mapped to integer values ​​from 0 to 100. The sampling frequency can be set to approximately 10Hz (i.e., once every 100 milliseconds), and dithering is used to increase the difficulty of forgery. The hash value of the previous frame is also added to each frame, forming a tamper-proof hash chain to further ensure the authenticity of the data.

[0041] Step S104: Divide the sampled frame sequence into multiple sub-intervals, and generate a session root commitment based on the cryptographic commitments corresponding to each of the multiple sub-intervals.

[0042] In step S104, during the sampling process, the collected frame sequence is divided into several sub-intervals according to preset rules, for example, each segment consists of 64 frames. For the frame data within each sub-interval, segment-level commitments (cryptographic commitments corresponding to each sub-interval) are generated using methods such as Pedersen commitments or multinomial commitments. Based on the above segment-level commitments, the terminal device further constructs a verifiable data structure, where the verifiable data structure is, for example, a hash tree, which can be a Merkle tree. In the Merkle tree, each segment commitment is used as a leaf node to form the session root commitment C_session. In this way, even if further verification is required, only the commitment value of the specific sub-interval and its Merkle path need to be provided, which can reduce the amount of data transmission and protect user privacy.

[0043] Step S105: Based on the verification parameters, generate a non-interactive proof and send the cryptographic verification information to the advertising platform. The cryptographic verification information includes: verification parameters, session root commitment, and non-interactive proof. The cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

[0044] In step S105, after completing sampling and commitment generation, the terminal device, using verification parameters, calls a zero-knowledge proof library or algorithm (such as the PLONK protocol) to generate a non-interactive proof π. This non-interactive proof includes information about whether the sampled frame sequence meets preset compliance conditions, but does not reveal specific behavioral data. The terminal device sends cryptographic verification information, including verification parameters, the session root commitment C_session, and the non-interactive proof π, to the advertising platform. Upon receiving the verification information, the advertising platform uses the corresponding verification function Verify(vk,X,π) to check the validity of the non-interactive proof π, where X is a public input including C_session. If the verification is successful, it indicates that the advertisement display meets the preset requirements; otherwise, it indicates that the advertisement display does not meet the preset requirements, and further sampling checks or remedial measures may need to be initiated.

[0045] Steps S101 to S105 above cleverly combine zero-knowledge proofs and layered cryptographic commitments to improve the accuracy and efficiency of ad display compliance verification while protecting user privacy and reducing compliance costs. The specific effects are as follows:

[0046] Because only encrypted commitment values ​​and zero-knowledge proofs are reported, rather than specific user behavior data, the spread of user privacy data in the advertising ecosystem can be significantly reduced, effectively mitigating the risk of privacy leaks and complying with relevant requirements.

[0047] By constructing hash chains and hierarchical commitments, and combining them with zero-knowledge proof verification by the verifier, the client can confirm in real time whether the ad display meets the preset compliance conditions without obtaining the original data, thereby improving the accuracy and response speed of verification and effectively identifying and preventing fraudulent behavior.

[0048] By transmitting only the necessary verification information—cryptographic commitments and zero-knowledge proofs—instead of the complete sequence of actions, and following the principle of data minimization, we can reduce the burden of communication, optimize the cost of data processing and storage, and also improve data security.

[0049] Settlement processing based on cryptographic verification information can automatically perform operations such as accounting, release or freeze of margin, and strategy adjustment without manual review, thereby improving the efficiency and automation of reconciliation across media platforms, reducing audit costs, and enhancing the transparency and fairness of advertising transactions.

[0050] Establishing a unified, cryptography-based verification standard provides a common foundation of trust between different media platforms, simplifies reconciliation processes, reduces disputes and audit costs caused by a lack of mutual trust, and promotes cooperation and efficiency improvement among all participants in the advertising ecosystem.

[0051] Furthermore, by incorporating a selective sampling mechanism, suspicious traffic can be thoroughly investigated without compromising the overall privacy protection framework. This facilitates timely adjustments to billing strategies, allows for penalties against suspected fraudulent activities, and improves the health and credibility of the advertising environment.

[0052] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0053] According to some optional embodiments of this application, the verification parameters include at least: a challenge random number.

[0054] Furthermore, the generation of a sampling frame sequence based on behavioral feature data from the terminal device can be achieved as follows: Based on a challenge random number and the frame number of the i-th sampling frame, generate the i-th random seed, where i is a positive integer not greater than n, n is the length of the sampling frame sequence, and n is a positive integer greater than 1; based on the i-th random seed, determine the sampling time offset of the i-th sampling frame within a predefined allowable offset range; combine the predefined baseline sampling time with the sampling time offset of the i-th sampling frame to obtain the actual sampling time of the i-th sampling frame; collect behavioral feature data at the actual sampling time to obtain the feature fields of the i-th sampling frame; generate a sampling frame sequence based on the feature fields of all sampling frames.

[0055] In this embodiment, after the terminal device requests and receives the advertising content and verification parameters, a quantitative sampling process for user behavior characteristics is initiated to capture indicators related to ad display compliance. Simultaneously, randomness is introduced to enhance data security and anti-spoofing capabilities. The specific sampling steps are as follows:

[0056] A random seed is generated using the challenge random number (nonce) carried in the ad delivery response and the sequence number (i) of the current sampled frame. Here, i is a positive integer ranging from 1 to n, where n represents the length of the total sequence of sampled frames collected by the terminal device during a specific ad display, and n itself is a positive integer greater than 1. This combination of methods ensures the uniqueness of each sampled frame and makes it difficult to predict or manipulate.

[0057] Based on the generated random seed, the terminal device determines the sampling time offset for each sampled frame by calculating the output of a random function. This sampling time offset is randomly selected within a predefined allowable range, for example, ±5 to 20 milliseconds. This random time offset helps defend against cheating methods such as pre-recorded playback and accelerated playback, because cheaters find it difficult to precisely replicate the randomly introduced time differences.

[0058] The terminal device adds a predefined baseline sampling time to the calculated sampling time offset to obtain the actual sampling time of each sampling frame. The baseline time can be the start time of the advertisement display. By introducing a random offset, the actual sampling time of each frame gains additional randomness, enhancing the unpredictability and security of the entire sampling process.

[0059] At the actual sampling moment corresponding to each frame, the terminal device collects and quantifies a series of behavioral feature data, including but not limited to visual proportion (vi), foreground focus marker (fi), volume intensity (ai), and interaction position (ei). This behavioral feature data reflects the user's actual interaction with the advertisement, providing a basis for compliance verification.

[0060] The feature fields of all collected sampling frames are organized and arranged in chronological order to form a complete sampling frame sequence. Each sampling frame includes not only the aforementioned behavioral feature data but also the hash value of the previous frame, thus constructing a tamper-proof hash chain to further ensure the integrity and authenticity of the data.

[0061] Through the above steps, the terminal device can generate a sequence of sampled frames that not only reflects the real interaction between the user and the advertisement in detail, but also has high security and anti-counterfeiting capabilities. This sequence serves as input for the subsequent generation of cryptographic commitments and zero-knowledge proofs, supporting efficient and accurate verification of advertisement display compliance while maximizing the protection of user privacy.

[0062] According to some alternative embodiments of this application, a session root commitment can be generated based on the cryptographic commitments corresponding to multiple sub-intervals, which can be achieved by the following method: encoding the behavioral feature data of all sampled frames in each sub-interval into a corresponding structured data set; performing deterministic operation processing on the structured data set of each sub-interval based on the commitment algorithm to obtain a unique cryptographic commitment corresponding to each sub-interval; using the cryptographic commitments of multiple sub-intervals as leaf nodes, and according to predefined tree structure rules and hash linking rules, performing iterative hash calculation and linking from bottom to top based on the leaf nodes to obtain a verifiable data structure; and determining the cryptographic commitment of the root node of the verifiable data structure as the session root commitment.

[0063] In this embodiment, the sampling frame sequence of the advertising display process is segmented. The sampling frames in each segment or sub-interval will be further processed to construct a cryptographic commitment value for verification. The specific steps are as follows.

[0064] For each sub-interval in the sampling frame sequence, behavioral feature data of all sampling frames within that interval are collected. This behavioral feature data is encoded into a structured dataset to ensure data uniformity and standardization. A cryptographic commitment algorithm is then used as input to perform deterministic computation. The result of this deterministic computation is a cryptographic commitment associated with the feature data of all sampling frames within the sub-interval. A unique commitment value is generated for each sub-interval; this commitment value can be a hash digest of the sub-interval data and is influenced by a random number (nonce) to prevent data predictability.

[0065] The terminal device treats all cryptographic commitments generated in each sub-interval as leaf nodes and processes them using predefined tree structure rules (such as Merkle trees). From bottom to top, through iterative hash calculations and linking, the commitment values ​​of the leaf nodes are hashed pairwise, progressively aggregating to generate higher-level intermediate node commitments until the root node of the entire tree is formed. During the generation of intermediate and root node commitments, hash linking rules are followed to ensure data integrity and immutability.

[0066] The cryptographic commitment of the root node of the Merkle tree is determined as the session root commitment C_session. The session root commitment C_session is used to comprehensively reflect the feature data of the entire sampled frame sequence, but does not directly expose the user's specific behavioral information, thus providing key public input for subsequent verification while protecting privacy.

[0067] Through the above steps, the terminal device can effectively transform the original behavioral feature data into a series of sub-interval-level cryptographic commitments, then construct these cryptographic commitments into a verifiable data structure (Merkle tree), ultimately obtaining the session root commitment C_session. Furthermore, C_session can serve as one of the inputs to a zero-knowledge proof circuit to generate a non-interactive proof π, thereby proving to the verifier that the advertisement display meets preset compliance conditions without sharing the original data, while ensuring data security and privacy protection.

[0068] Specifically, encoding the behavioral feature data of all sampled frames within each sub-interval into a corresponding structured data set can be achieved as follows: perform cryptographic hashing on the advertising identification information, challenge random number, and random seed to obtain an initial hash value; based on the initial hash value and the behavioral feature data of the sampled frames collected sequentially in the sampled frame sequence, determine the hash value corresponding to each sampled frame; encode and concatenate the hash values ​​of the sampled frames belonging to each sub-interval according to the frame sequence number to form a structured data set for each sub-interval.

[0069] The above method takes the ad identifier information ad_id, the challenge random number nonce, and the random seed as input, and uses a cryptographic hash function H to generate an initial hash value h0. With the generation of each sampling frame i of the ad display, its behavioral feature data is compared with the hash value h of the previous frame. {i-1} They are input together into the hash function H, producing the hash value h of the current frame. i This method forms a tamper-proof hash chain. Any modification to the sampled frame data will cause irreversible changes to the hash value of the corresponding frame and all subsequent frames, helping to verify the authenticity and integrity of the data. Within each sub-interval of the sampled frame sequence, the hash values ​​h of all sampled frames are... i The data is encoded and concatenated according to frame sequence numbers to generate a structured data set unique to that sub-interval. This operation transforms the data characteristics within the sub-interval into a form that is easy to process and verify, while maintaining the serialization properties of the data, making subsequent commitment generation more convenient.

[0070] Specifically, based on the initial hash value and the behavioral feature data of the sampled frames collected sequentially in the sampled frame sequence, the hash value corresponding to each sampled frame is determined. This can be achieved by the following method: Based on the behavioral feature data, timestamp information, and link hash value of each sampled frame, complete frame data is generated, and a cryptographic hash operation is performed on the complete frame data to obtain the hash value corresponding to the sampled frame. Specifically, for the first sampled frame in the sampled frame sequence, the link hash value used is the initial hash value; for samples that are not the first sampled frame in the sampled frame sequence, the link hash value used is the hash value corresponding to the previous adjacent sampled frame.

[0071] The above method follows these steps: For each frame in the sampled frame sequence, construct complete frame data including behavioral feature data, timestamp information, and a link hash value. For the first frame in the sequence, the initial hash value h0 generated above is used; while for each frame i that is not the first frame, the link hash value h0 is used. {i} The hash value h of its directly preceding frame i-1 {i-1} A cryptographic hash operation is performed on the complete frame data of each frame to produce a hash value h that is closely related to all the information in that frame. {i} The above calculation process ensures that even slight changes in the data will produce a distinctly different hash value, thus enabling the detection of any potential tampering with the sampled frame data.

[0072] Through the above process, the terminal device calculates a unique hash value for each frame in the sampled frame sequence. These hash values ​​are organized into a chain-like structure, known as a hash chain. The hash chain begins with an initial hash value, and the hash value of each subsequent frame is linked to the hash value of the previous frame, ultimately forming a tamper-proof chain capable of verifying the integrity and consistency of the entire sampled frame sequence. Through this cryptographically based hash chaining mechanism, the terminal device can not only quantify and sample user behavior data but also generate hash values ​​and commitments that can be used for subsequent verification without revealing specific data details.

[0073] In some optional embodiments of this application, generating a non-interactive proof based on verification parameters can be achieved by the following method: constructing private witness parameters for the zero-knowledge proof based on witness information, wherein the witness information includes: a sampled frame sequence, a random number used to generate the cryptographic commitment for each sub-interval, an authentication path used to verify the position of the session root commitment in a verifiable data structure, and verified environment elements selected from a predefined set of compliant environments; constructing public input parameters for the zero-knowledge proof based on the session root commitment and verification parameters; and invoking the zero-knowledge proof system based on the private witness parameters and public input parameters to generate a non-interactive proof.

[0074] In this embodiment, a complete sequence of sampled frames generated during the ad display process is collected as core data witness. A random number is determined when generating the cryptographic commitment for each sub-interval, ensuring the unpredictability and uniqueness of the commitment. Furthermore, an authentication path is recorded to verify the exact location of the session root commitment within a verifiable data structure (such as a Merkle tree), where the authentication path may include hash link information from the sub-interval commitment to the session root commitment. Verified environment elements, such as SDK version, browser type, or device certificate, are selected from a predefined set of compliant environments, where these environment elements help prove that the ad display occurred in a trusted environment, rather than a simulated or fraudulent environment.

[0075] Centered on the session root commitment C_session, and combining the verification parameter version number vk_version, the challenge random number nonce, the threshold parameter set θ (including the visible time threshold T1, the audible time threshold T2, the interaction count threshold K, etc.), the time window [t_begin, t_end], and the Merkle root or accumulator root Root(S) of the compliant environment set S, a public input parameter X for zero-knowledge proof is constructed. This public input parameter is exposed to the verifier (advertising platform) and is used to prove the consistency of the generation process and verify the compliance of the display, without exposing sensitive user behavior data or environmental details.

[0076] A terminal device or SDK holding private witness parameters and public input parameters invokes a zero-knowledge proof system to generate a non-interactive proof π. This proof π verifies that the terminal device possesses the correct data and commitment value corresponding to the public input X, i.e., the sampled frame sequence does indeed meet the preset compliance conditions, without directly revealing data details. The generation of proof π relies on the sampled frame sequence, random number, authentication path, and environment elements in the private witness parameters, and the session root commitment C_session, threshold, and version information in the public input parameters. The non-interactive nature of the proof is ensured through the Fiat-Shamir transformation, meaning the proof can be generated without the direct participation of the verifier.

[0077] Specifically, the common input parameters for zero-knowledge proof can be constructed based on the session root commitment and verification parameters, which can be achieved as follows: the cryptographic commitment of the compliant environment set is determined as the root value of the compliant environment set, wherein the cryptographic commitment of the compliant environment set includes: hash tree root or accumulator value; the session root commitment, verification parameters, and the root value of the compliant environment set are used together as the common input parameters for zero-knowledge proof.

[0078] The compliance environment set includes all predefined environment elements, such as trusted software development kit versions, browser types, device certificate hashes, etc., to ensure that the display of advertisements runs in a secure and compliant environment.

[0079] Using hash tree techniques or accumulator mechanisms, the cryptographic commitments of all environment elements within the compliant environment set are processed to generate a highly condensed root value. If a hash tree is used, it is obtained by constructing a Merkle tree and calculating its root hash; if an accumulator is used, a value representing all members of the set is generated through specific mathematical constructions. Regardless of the method, this root value serves as the cryptographic commitment of the compliant environment set, ensuring the integrity and consistency of the set members while maintaining data privacy.

[0080] The previously calculated session root commitment C_session, the verification parameter version number vk_version, and the root value of the aforementioned compliant environment set (i.e., the hash tree root or accumulator value) are integrated into a common input parameter X for the zero-knowledge proof. The construction of the common input parameter X ensures that the verifier can confirm whether the ad display meets the standards and is conducted in a compliant environment based on this information, without obtaining specific user behavior or environment details. C_session represents the commitment to behavioral data throughout the session, vk_version represents the specific parameter version used for verification, and the root value of the compliant environment set is a key indicator proving the compliance of the display environment.

[0081] In some preferred embodiments, the zero-knowledge proof is constructed using a zero-knowledge proof circuit configured to constrain the compliance of the sampled frame sequence. The zero-knowledge proof circuit includes a first sub-circuit, a second sub-circuit, a third sub-circuit, a fourth sub-circuit, and a fifth sub-circuit. The first sub-circuit performs the following constraint: based on behavioral feature data and timestamps in the sampled frame sequence, it verifies that the cumulative duration of at least one type of valid interaction is not less than a corresponding preset duration threshold. The second sub-circuit performs the following constraint: based on the interaction events recorded in the sampled frame sequence, it verifies that the number of interactions within a global or local time window is not less than a corresponding preset duration threshold. The circuit has several constraints: a threshold for the number of sampling attempts; a third sub-circuit for verifying that the sampling time interval between adjacent sampling frames is within the allowed range, and for verifying that the sampling frame sequence maintains the continuity and integrity of the data through a chained hash structure; a fourth sub-circuit for verifying that the sampling of the sampling frame sequence occurs within a predefined set of compliant environments, and for cryptographically binding the verified environment elements with the sampling process of the sampling frame sequence; and a fifth sub-circuit for ensuring the consistency between the sampling frame sequence and the cryptographic commitments corresponding to the multiple sub-intervals generated based on the sampling frame sequence, and for constraining the correctness of the authentication path from the cryptographic commitment corresponding to each sub-interval to the session root commitment.

[0082] Specifically, the first sub-circuit is used to perform the following constraints: for the i-th sampling frame, a first indicator is constructed, which indicates that the visibility ratio of the i-th sampling frame is not lower than a first threshold and the foreground focus flag is true; and the sum of the products of the first indicators of all sampling frames and the corresponding sampling time intervals is constrained to be not lower than a first cumulative duration threshold; where i is a positive integer not greater than n, n is the length of the sampling frame sequence, and n is a positive integer greater than 1; and for the i-th sampling frame, a second indicator is constructed, which indicates that the volume level of the i-th sampling frame is not lower than a second threshold; and the sum of the products of the second indicators of all sampling frames and the corresponding sampling time intervals is constrained to be not lower than a second cumulative duration threshold.

[0083] The second sub-circuit is used to impose the following constraints: constraining the total number of interactive events recorded in all sampling frames to be no less than a preset interactive count threshold; or constraining the total number of interactive events to be no less than the corresponding window interactive count threshold within a time window consisting of any consecutive predetermined number of sampling frames.

[0084] The third sub-circuit is used to impose the following constraints: constrain the timestamp difference between adjacent sampled frames to be between the preset minimum and maximum intervals; constrain the frame hash value of the i-th sampled frame to be equal to the result of a cryptographic hash operation on the visibility ratio, foreground focus flag, volume level, interactive event, timestamp of the i-th sampled frame and the frame hash value of the (i-1)-th sampled frame, where the hash value of the 0th frame is the initial hash value calculated based on the initial parameters.

[0085] It should be further noted that the verification parameters may include at least one of the following: a first threshold, a second threshold, a first cumulative duration threshold, a second cumulative duration threshold, an interaction count threshold, a minimum interval, and a maximum interval. These verification parameters serve as common inputs and can be configured to support different ad placement strategies without changing the circuit structure.

[0086] As some optional embodiments of this application, Figure 1 The verification method for the displayed advertisement also includes the following steps: determining whether the resource status of the terminal device does not meet the preset requirements and whether the time taken to generate the non-interactive proof exceeds a preset threshold; if the resource status of the terminal device does not meet the preset requirements or the time taken to generate the non-interactive proof exceeds the preset threshold, after generating the session root commitment, sending the session root commitment to the advertising platform; after sending the session root commitment to the advertising platform, based on the same private witness parameters and public input parameters as those used to generate the session root commitment, calling the zero-knowledge proof system to generate the non-interactive proof; and sending the non-interactive proof to the advertising platform, wherein the non-interactive proof is used by the advertising platform to verify the non-interactive proof using the received session root commitment.

[0087] It should be noted that, considering the resource limitations and time sensitivity that terminal devices may face during the zero-knowledge proof generation process, this embodiment introduces a flexible fault tolerance and retry mechanism to ensure that the verification process can be completed smoothly even under adverse conditions, without compromising privacy protection and the integrity of verification. This mechanism specifically includes the following process.

[0088] The system assesses the current resource status of the terminal device to check if it meets preset resource requirements, such as sufficient CPU and memory resources. Simultaneously, it detects the time taken to generate non-interactive proofs and determines if it exceeds a preset time threshold.

[0089] If the terminal device's resources are insufficient to immediately generate a non-interactive proof, or if the proof generation time is expected to exceed a preset threshold, then after generating the session root commitment C_session, it will be sent directly to the advertising platform without waiting for proof generation. This ensures that necessary commitment information can be submitted in a timely manner even under adverse conditions, avoiding data loss due to resource or time issues.

[0090] After the commitment is sent first, a non-interactive proof π is generated by calling the zero-knowledge proof library based on the same private witness parameter W and public input parameter X. The private witness parameter W includes key information such as the sampling frame sequence, commitment random number, Merkle authentication path, and environment elements. The public input X includes data such as C_session, threshold parameter, nonce, and verification parameter version number vk_version. This asynchronous processing method allows proof generation to be completed when terminal resources are restored or idle, without affecting the immediate transmission of the commitment.

[0091] Once the non-interactive proof π is successfully generated, it is sent to the advertising platform. The generation of proof π relies on the same set of private witness parameters W and public input parameters X as the session root commitment C_session, ensuring contextual consistency of the proof. Upon receiving proof π, the advertising platform can verify it using the existing C_session without needing to wait for or request a complete proof again, thus speeding up the entire verification process.

[0092] Through the above steps, even in situations of resource constraints or time pressure, it is ensured that the session root commitment C_session is delivered to the advertising platform in a timely manner. The subsequent asynchronous generation and reporting of the non-interactive proof π makes the verification process both efficient and secure, maintaining the dual goals of privacy protection and verification accuracy. This method improves the flexibility and adaptability of the process without affecting the verification results, making it suitable for various terminal devices and network conditions.

[0093] Specifically, determining whether the resource status of the terminal device does not meet the preset requirements and whether the time taken to generate the non-interactive proof exceeds the preset threshold can be achieved through the following method: receiving a submission instruction sent by the advertising platform, wherein the submission instruction is sent when the behavioral risk score of the terminal device is less than the preset threshold, and the behavioral risk score is determined based on cross-media or cross-platform statistical feature data, which includes at least one of the following: historical verification pass rate, feature data distribution index, and similarity with abnormal sample features; responding to the submission instruction, determining whether the resource status of the terminal device does not meet the preset requirements and whether the time taken to generate the non-interactive proof exceeds the preset threshold.

[0094] It's worth explaining that when an advertising platform issues a submission instruction based on the behavioral risk score of a terminal device, it means that the device's current risk score is below a preset safety threshold. The behavioral risk score is derived through comprehensive analysis of statistical characteristic data across media or platforms. This statistical characteristic data may include the device's historical verification pass rate, distribution indicators of the characteristic data (such as standard deviation and mean, used to assess the normal fluctuation range of the data), and the feature similarity with known anomalous samples. A low-risk score indicates that the terminal device's activity pattern is consistent with normal behavior, reducing the need for additional verification. The entity submitting the low-risk score can, while ensuring semantic consistency in verification, adopt the aforementioned "submit commitment first, then asynchronously supplement proof" approach.

[0095] As some other optional embodiments of this application, Figure 1 The verification method for the displayed advertisement further includes the following steps: loading and running the executable code image used to perform the target operation in the trusted execution environment of the terminal device, wherein the target operation includes: generating a sampling frame sequence, generating a session root commitment, and generating a non-interactive proof; invoking the remote proof function of the trusted execution environment to generate an integrity proof, wherein the integrity proof includes: the metric value of the executable code image, the identity information of the trusted execution environment, and the cryptographic binding of the running configuration of the trusted execution environment; and sending the integrity proof to the advertising platform, wherein the integrity proof is used by the advertising platform to verify the trusted status of the trusted execution environment based on a pre-stored list of valid metric values ​​and an authentication public key.

[0096] In this embodiment, an executable code image specifically designed to perform the target operation is loaded into the trusted execution environment of the terminal device. The target operation includes the entire process of generating a sampling frame sequence, generating a session root commitment C_session based on this sequence, and generating a non-interactive proof π based on C_session and other common input parameters. The trusted execution environment is a hardware-level isolation and protection mechanism that provides a sealed space for encrypted storage and execution code, ensuring that external parties cannot access its internal running state or data.

[0097] Within the trusted execution environment, a remote authentication function is invoked to create an integrity certificate. This integrity certificate includes not only a metric of the executable code image—a hash or digest of the code image—to prove the code has not been tampered with; it also includes the identity information of the trusted execution environment, such as the device ID or the public key of the hardware security module, to verify the authenticity and legitimacy of the execution environment; and the runtime configuration of the trusted execution environment, such as memory size and execution permissions. Cryptographic binding ensures the integrity and immutability of these configuration parameters during the operation of the trusted execution environment.

[0098] The generated integrity certificate is sent to the advertising platform. Upon receiving the integrity certificate, the advertising platform verifies the trusted state of the trusted execution environment based on its pre-stored list of valid metrics (i.e., hash values ​​of a set of known, tamper-proof executable code) and the authentication public key. If a metric included in the remote certificate matches one of the metrics in the list, and the identity information is verified via the public key, then it can be confirmed that the target code is running flawlessly in the trusted environment, ensuring the integrity and trustworthiness of the sampling frame sequence construction, session root commitment generation, and non-interactive certificate generation processes.

[0099] Through the above steps, not only can flexible adaptation to the resource status of terminal devices and privacy protection be achieved, but also the trustworthiness of the execution environment is enhanced. By performing key operations and generating remote proofs in a trusted execution environment, the entire verification process is protected from malicious code injection or execution environment tampering, thereby improving the accuracy and security of ad display compliance verification.

[0100] Figure 2 This is a flowchart of another method for verifying advertisement display according to an embodiment of this application. This method is applied to an advertising platform, such as... Figure 2 As shown, the method includes the following steps:

[0101] Step S201: Receive an advertising request sent by the terminal device.

[0102] In step S201, the advertising platform receives an advertising request from a terminal device. This advertising request can originate from various terminal devices, including but not limited to web browsers, mobile applications, or desktop clients, where the terminal device seeks to obtain content for a specific advertising space for display.

[0103] Step S202: If the advertising request meets the preset delivery conditions, send the advertising content corresponding to the advertising request and the verification parameters used to generate verification information to the terminal device.

[0104] In step S202, the advertising platform performs a preliminary review of the received advertising request to check whether it meets the preset delivery conditions. Delivery conditions may involve requirements related to time, geographic location, target audience, or ad placement. If the advertising request is confirmed to meet the delivery conditions, the advertising platform sends the advertising content and verification parameters used to generate verification information to the terminal device. These verification parameters include, but are not limited to, a challenge random number (nonce), a verification public key or verification parameter version number (vk_version), and a threshold parameter for the preset compliance conditions.

[0105] Step S203: Receive cryptographic verification information sent by the terminal device, wherein the cryptographic verification information includes: verification parameters, session root commitment, and non-interactive proof; the session root commitment is generated by dividing the sampled frame sequence into multiple sub-intervals and based on the cryptographic commitments corresponding to the multiple sub-intervals respectively, and the sampled frame sequence is constructed based on behavioral feature data in the terminal device; the non-interactive proof is generated based on the verification parameters.

[0106] Among them, the cryptographic verification information is passed Figure 1 The verification method shown in the advertisement display is obtained.

[0107] In step S203, the advertising platform receives cryptographic verification information sent by the terminal device. This cryptographic verification information consists of three key parts: verification parameters, the session root commitment C_session, and the non-interactive proof π. The session root commitment C_session is calculated in the terminal device by segmenting the entire sampled frame sequence, calculating the cryptographic commitment for each sub-interval, and then using these segment-level commitments to construct a verifiable data structure (e.g., a Merkle tree), derived from the tree root. The sampled frame sequence includes all behavioral feature data collected by the terminal device during the advertisement display, such as viewing percentage, foreground focus state, volume level, interaction events, and timestamps. The non-interactive proof π is generated by the terminal device after applying a zero-knowledge proof protocol to the sampled frame sequence and its session root commitment C_session based on the verification parameters. The non-interactive proof allows the advertising platform to verify the display compliance without needing to know specific user behavior data.

[0108] Step S204: Verify the cryptographic verification information to determine whether the display status of the advertisement content meets the requirements.

[0109] In step S204, the advertising platform performs a comprehensive verification of the received cryptographic verification information. Specifically, this involves calling the verification function Verify(vk,X,π), where vk is the verification public key, X is the public input parameter including the session root commitment C_session, and π is the non-interactive proof. If the verification function returns True, it indicates that the display of the advertising content meets the preset requirements; otherwise, it is considered that the display may be in violation of regulations or fail to meet standards. After successful verification, the advertising platform can execute settlement, reward distribution, and other strategies accordingly, while simultaneously updating the behavioral risk score of the terminal device.

[0110] The following are Figure 2 The steps shown are illustrated and explained by way of example.

[0111] According to some optional embodiments of this application, the verification of cryptographic verification information can be achieved by the following method: determining whether the version identifier of the verification parameter is consistent with the version identifier of the currently used verification parameter; if the version identifier of the verification parameter is consistent with the version identifier of the currently used verification parameter, verifying the non-interactive proof in the cryptographic verification information based on the verification parameter and the public input parameters of the zero-knowledge proof, wherein the public input parameters include at least: session root commitment and verification parameters.

[0112] In this embodiment, the first step is to check whether the verification parameter version identifier (vk_version) included in the received cryptographic verification information is consistent with the verification parameter version currently being used in the system. Because different versions of verification parameters may correspond to different verification circuit structures and rules, ensuring version consistency can avoid verification errors caused by parameter mismatch. If it is confirmed that the verification parameter version identifier is consistent with the currently used verification parameter version identifier, the verification parameter (vk) and the common input parameter (X) from the terminal device will be used to verify the non-interactive proof π. The common input parameter X includes at least the session root commitment C_session and the verification parameter vk, and may also include other key information such as the ad identifier ad_id, the ad slot identifier slot_id, the threshold parameter θ (including the visible percentage threshold x, the audible duration thresholds T1 and T2, the interaction count threshold K, etc.), and the time window [t]. begin ,t end The verification function Verify(vk,X,π) is called to check whether the non-interactive proof π is valid for the given vk and X. If the verification passes, it means that the advertising display behavior of the terminal device meets the preset compliance conditions and requirements.

[0113] By following the steps above, user privacy can be protected while efficiently and accurately confirming ad display compliance. The consistency of version identification and the effective verification of non-interactive proofs together ensure accurate verification of ad display compliance even without acquiring or storing the complete original behavioral data uploaded by the terminal device.

[0114] According to some alternative embodiments of this application, after verifying the cryptographic verification information, the following steps may be performed: if the verification of the non-interactive proof in the cryptographic verification information passes, a verification receipt is generated, wherein the verification receipt includes at least one of the following: a session root commitment, a verification digest of the verification result, and timestamp information; if the verification of the non-interactive proof in the cryptographic verification information fails, the display behavior based on the advertising content is marked; and the display behavior is processed for settlement business according to the verification result of the non-interactive proof in the cryptographic verification information.

[0115] In this embodiment, the version identifier vk_version of the verification parameter is first extracted from the received cryptographic verification information. This version identifier is then compared with the version identifier of the verification parameter used by the current advertising platform to ensure that both are using the same version of the verification parameter. This check step avoids verification errors caused by parameter version mismatches, ensuring the accuracy and consistency of the verification process.

[0116] If the version identifiers of the verification parameters are confirmed to be consistent, the advertising platform will use the received verification parameters and the common input parameters of the zero-knowledge proof to jointly participate in the verification of the non-interactive proof π. The common input parameters include at least the session root commitment C_session and the verification parameters themselves. The session root commitment C_session is sent from the terminal device and is the root value of a Merkle tree constructed from segmented cryptographic commitments calculated by segmenting the sampled frame sequence. It is a crucial data digest in the entire proof process, used to represent all behavioral feature data collected by the terminal device during ad display. By calling the verification function and inputting the verification parameter vk, the common input parameter X (where X includes at least C_session), and the non-interactive proof π, the advertising platform can verify whether the proof generated by the terminal device is valid, thereby confirming the ad display compliance. For example, if the verification function returns True, it indicates that the non-interactive proof π is valid and the ad content display meets the preset requirements; if it returns False, it indicates that there is an anomaly or non-compliance.

[0117] Through the above steps, the advertising platform can efficiently and accurately verify the compliance of ad displays. At the same time, thanks to the characteristics of zero-knowledge proof, it can complete the verification process without acquiring or storing the complete original behavioral data sequence uploaded by the terminal device, thereby reducing the risk of privacy leakage and meeting the increasingly stringent privacy protection regulations.

[0118] Specifically, after verifying the cryptographic verification information, the following steps can be performed: write the information set into a message queue and store the message queue in an object storage system. The information set includes: advertising identification information, session root commitment, message digest of the verification receipt, and verification result; perform aggregate calculation on the non-interactive proofs corresponding to multiple verified advertising display records to generate an aggregate proof and determine the aggregate root digest corresponding to the aggregate proof; save the aggregate proof and the aggregate root digest corresponding to the aggregate proof to a distributed ledger system.

[0119] For example, after verifying the ad display compliance, the ad platform generates a set of information and writes it to a message queue. This set includes at least the ad identifier (ad_id), the session root commitment (C_session), the verification receipt message digest (receipt_hash), and the verification result (result). The message queue serves as a buffer for temporary storage and processing, ensuring that data is processed and backed up in an orderly manner before being written to persistent storage.

[0120] The information collection in the message queue is persistently stored in an object storage system. Object storage systems provide highly available and scalable data storage solutions, suitable for long-term storage of large amounts of data, while also facilitating subsequent auditing and retrieval. By storing the information collection in an object storage system, a permanent archive of the ad display verification results is achieved, providing a reliable data source for subsequent auditing processes, dispute resolution, and data mining.

[0121] For multiple verified ad display records, the advertising platform or on-chain contract performs a non-interactive proof π aggregation calculation. Specifically, this involves selecting multiple verified non-interactive proofs and generating an aggregated proof using recursive aggregation or batch aggregation algorithms. The design goal of aggregated proofs is to reduce data storage requirements on the blockchain; by merging multiple proofs into one, block space usage and verification fees can be significantly reduced.

[0122] While generating the aggregation proof, the corresponding aggregation root digest is calculated. The aggregation root digest, obtained through a cryptographic hash function, uniquely identifies the set of aggregation proofs. The aggregation proof and its corresponding aggregation root digest are then stored in a distributed ledger system. This distributed ledger system, such as a blockchain, provides a decentralized, immutable storage environment suitable for storing data records requiring high trust and transparency.

[0123] Through the above steps, not only can the efficient storage and management of the verification results of advertising display compliance be achieved, but also the generation and storage of aggregated proofs can reduce the storage pressure on the blockchain and optimize the cost-effectiveness of verification and auditing.

[0124] In some optional embodiments of this application, Figure 2The verification method for the advertisement display shown further includes the following steps: under the condition of meeting the preset sampling conditions, a sampling instruction is sent to the terminal device, wherein the sampling instruction includes at least one of the following verification requirements: requiring the terminal device to provide all or part of the field information of the target cryptographic commitment corresponding to the target sub-interval of a specified duration in the sampling frame sequence, and the authentication path of all or part of the field information in the verifiable data structure; requiring the terminal device to generate and submit an enhanced proof for the sampling frame sequence, wherein the enhanced proof is generated by applying a target constraint to the zero-knowledge proof circuit, wherein the zero-knowledge proof circuit is used to constrain the compliance of the sampling frame sequence, and the constraint strength of the target constraint is greater than the constraint strength used by the zero-knowledge proof circuit to generate the non-interactive proof.

[0125] It is worth noting that, in implementing the zero-knowledge proof-based privacy-protected ad display compliance verification process, a flexible sampling mechanism is designed in this embodiment to further enhance the accuracy of verification and the ability to identify suspicious behavior. When the terminal device or display process meets the preset sampling conditions, the advertising platform sends detailed sampling instructions to the terminal device to verify the compliance status of the ad display. The preset sampling conditions may be triggered by various factors, such as abnormal display pass rate, low conversion rate, or the terminal device's behavior pattern being similar to known abnormal samples. The following are the verification requirements details included in the sampling instructions:

[0126] The sampling instruction requires the terminal device to provide detailed information on the cryptographic commitments for a specific duration target sub-interval within the sampled frame sequence. This includes, but is not limited to, partial fields of all or selected sampled frame data within the target sub-interval, such as visibility percentage, foreground focus state, and volume level, as well as the authentication path of these fields within a verifiable data structure (e.g., a Merkle tree). The authentication path proves that these fields indeed originate from a specific session root commitment C_session, helping the verifier confirm the integrity and consistency of the data without accessing the entire sampled frame sequence, thus protecting user privacy while completing the validity check.

[0127] Another sampling inspection instruction requires the terminal device to generate and submit an enhanced proof. This enhanced proof is generated by adding additional target constraints to the zero-knowledge proof circuit. The strength of these target constraints exceeds that used in the generation of conventional non-interactive proofs (π). In other words, the enhanced proof not only includes the metrics required for conventional compliance verification but also constrains more dimensional features of the sampled frame sequence, such as higher time consistency requirements, more complex interaction pattern analysis, or finer-grained device environment monitoring. This more targeted proof helps the verifier gain deeper insights into the terminal device's display process and effectively identify potential anomalies or fraudulent behavior.

[0128] By sending random inspection instructions for the above verification requirements, the verification party can conduct a thorough and detailed review of the compliance of ad display performance without compromising user privacy. This random inspection mechanism not only strengthens the rigor of the verification process but also improves the accuracy of identifying abnormal traffic, providing a more reliable measurement basis and dispute resolution mechanism for cross-media and platform advertising transactions.

[0129] Preferably, the specified duration and the field range of all or part of the field information are determined based on the behavioral risk score of the terminal device. The behavioral risk score is determined based on statistical characteristic data determined across media or platforms, including at least one of the following: historical verification pass rate, characteristic data distribution index, and similarity with abnormal sample characteristics. The value of the behavioral risk score is positively correlated with the degree of behavioral risk, and the behavioral risk score is positively correlated with the specified duration and the field range of all or part of the field information.

[0130] It should be noted that the behavioral risk score of the terminal device directly affects the specified duration and the scope of all or part of the field information required in the sampling inspection instruction. The determination of the behavioral risk score is based on cross-media or cross-platform statistical characteristic data. This data includes multiple aspects, specifically including but not limited to the following: Historical verification pass rate: Tracking and analyzing the results of advertising display compliance verification submitted by the terminal device over a past period. The pass rate reflects whether the device's behavior is normal or not; an excessively low pass rate may indicate abnormal operation. Characteristic data distribution indicators: Considering the distribution of behavioral characteristic data generated by the terminal device during advertising display, such as the mean, variance, or median of indicators like viewability, volume level, and interaction frequency. Abnormal statistical distributions, such as data being overly concentrated around certain thresholds, may indicate human manipulation or interference from automated scripts. Similarity to anomalous sample characteristics: Comparing the terminal device's behavioral characteristic data with known abnormal or non-compliant behavioral patterns and calculating the similarity score between the two. A high similarity score may indicate potential risks in the terminal device's behavior.

[0131] The behavioral risk score is calculated by comprehensively considering the aforementioned statistical characteristics. Its value is positively correlated with the degree of behavioral risk, meaning that a higher score indicates a greater likelihood of suspicious device behavior. Based on this score, advertising platforms can dynamically adjust the requirements for random inspections. Specifically, the specified inspection duration and the range of fields required are positively correlated with the behavioral risk score. This means that for terminal devices with high behavioral risk scores, advertising platforms will require data over a longer period and a wider range of fields to more comprehensively check the compliance of their display performance and reduce the risk of fraud and cheating.

[0132] Conversely, for terminal devices with lower behavioral risk scores, their compliance verification can be subject to shorter random checks, and the provided field information will be more limited. This reduces interference with user privacy and the burden of data transmission while ensuring verification accuracy, and also lowers the platform's operating costs. In this way, effective monitoring and dynamic adjustment of terminal device behavioral risks can be achieved, ensuring that user privacy is protected while improving the accuracy and efficiency of ad verification.

[0133] In summary, behavioral risk scoring is a key factor in determining the specified duration and range of field information in the sampling instructions. The above steps ensure that the verification process is both rigorous and reasonable, enabling timely detection and handling of potential abnormal behaviors while avoiding unnecessary interference with normal users, reflecting the principles of refined management and efficient operation.

[0134] Preferably, the sampling inspection is triggered based on at least one of the following conditions: the verification pass rate of the traffic source or advertising slot to which the terminal device belongs exceeds a preset first pass rate threshold; the conversion rate of the traffic source or advertising slot to which the terminal device belongs is lower than a preset conversion rate threshold; the feature data distribution of the sampled frame sequence meets a preset abnormal distribution condition; the terminal device is a device accessing the advertising platform for the first time; and the similarity between the feature data provided by the terminal device and the preset abnormal sample features exceeds a preset similarity threshold.

[0135] Specifically, if the verification pass rate of the traffic source or ad placement belonging to a terminal device significantly exceeds the preset first pass rate threshold, it may indicate some form of manipulation or automated generation of compliance reports to evade stricter data review. While a high pass rate may seem positive on the surface, if it exceeds the normal statistical range, it should raise concerns, as it could be the result of unnatural or human intervention.

[0136] Conversion rate refers to the percentage of users who take the expected action (such as a click or purchase) after an ad is displayed. If the conversion rate of the traffic source or ad placement for a particular device is significantly lower than the preset conversion rate threshold, it may indicate that although the ad display meets the criteria, actual user engagement is very low, or it may even be because the display environment does not truly attract user attention. In such cases, random checks can help further verify the authenticity of the display environment and the naturalness of user behavior.

[0137] The advertising platform continuously analyzes the characteristic data distribution of the sampled frame sequences, such as the distribution of visible percentage, volume level, or frequency of interactive events. If the characteristic data distribution of the sampled frame sequences deviates significantly from the preset normal behavior pattern and meets the preset abnormal distribution conditions, this may indicate unnatural behavior patterns or potential fraudulent activities. In this case, initiating a random sampling procedure can help identify the specific cause of the anomaly.

[0138] For terminal devices that are accessing the advertising platform for the first time, the platform will automatically trigger random inspection instructions to establish trust and ensure data quality. This will require more detailed display data and proof to verify whether their behavior patterns meet the standards and expectations, thus avoiding the introduction of unknown risks by unreviewed devices.

[0139] Advertising platforms maintain an anomalous sample database, which includes feature datasets flagged as suspicious or fraudulent behavior. If the feature data provided by a terminal device shows a similarity exceeding a preset similarity threshold with these pre-defined anomalous sample features, it indicates that its behavioral pattern may align with known non-compliant behavior. In this case, initiating random checks is necessary to further investigate and confirm whether genuine violations exist.

[0140] Through the aforementioned triggering conditions, the advertising platform can flexibly conduct random checks on terminal devices to varying degrees, preventing resources from being wasted on low-risk display data while ensuring data quality and compliance in high-risk situations, thus achieving a dual balance between precise risk control and efficient operation.

[0141] Preferably, the verification parameters include at least a set of threshold parameters, wherein the threshold parameters in the set of threshold parameters are parameters used in the zero-knowledge proof circuit to constrain the compliance of the sampled frame sequence, and the threshold parameters are generated based on at least one of the following factors: ad placement configuration information, user profile information, device type information, and network condition information.

[0142] Understandably, the dynamic generation mechanism of the threshold parameter set ensures the flexibility and adaptability of the verification process. It can adjust the specific standards for compliance verification based on real-time changes in ad placement configuration, user profiles, device types, and network conditions, thereby improving the accuracy and effectiveness of verification. This method not only copes with the ever-changing advertising environment but also promotes fairer and more transparent advertising transactions, reduces disputes caused by changing conditions, and protects user privacy without acquiring or storing complete raw behavioral data uploaded by terminal devices. In this way, it is possible to improve the quality of advertising performance monitoring while simultaneously ensuring data security and privacy protection.

[0143] Figure 3 This is a schematic diagram of an advertisement display verification system according to an embodiment of this application, such as... Figure 3As shown, the system includes: terminal devices / SDK, advertising platform side, and supporting infrastructure. The advertising platform side includes: a delivery and response module, an aggregator module, a verification module (Verifier / on-chain contract), a settlement and margin management module, a sampling / challenge module, and an audit and traceable storage module; the terminal devices / SDK includes: 2. Terminal SDK modules (Web / Android / iOS, etc.). The specific functions of each module are as follows.

[0144] The delivery and response module is used to receive advertising requests, return advertising materials for requests that meet the delivery conditions, and send parameter information for proof generation and verification, including challenge random number nonce, display threshold parameter, and verification public key or verification parameter version number vk_version, etc.

[0145] The client-side SDK module (Web / Android / iOS, etc.) is used to perform jitter sampling on multi-dimensional features such as visual proportion, foreground focus, volume, interactive events, and timestamps locally according to a preset sampling strategy, build an anti-tampering hash chain, generate a hierarchical commitment value, and generate the corresponding zero-knowledge proof π based on the public parameters; then, {commitment C, proof π, public parameters} is reported.

[0146] The Aggregator module is used to perform format validation, batch processing, and optional recursive / aggregate proof generation on the data uploaded from the client side; and writes the validation results and related summaries to the audit log or message queue.

[0147] The verification module (Verifier / on-chain contract) is used to verify the zero-knowledge proof π based on the verification key vk. When the verification is successful, the verification result is passed to the settlement module or recorded in a trusted environment such as a blockchain.

[0148] The settlement and margin management module is used to record transactions, release and freeze margin or escrow funds, impose penalties for default, and adjust related strategies based on the verification results.

[0149] The sampling / challenge module is used to initiate sampling or challenges on some sessions based on preset risk rules or statistical anomalies, requiring selective disclosure of corresponding data or submission of sub-proofs with stronger constraints; and to adjust the settlement strategy based on the sampling results.

[0150] The audit and traceability storage module is used to write verification-related event and proof summaries to message queues and object storage, saving only necessary summaries and commitment values, following the principle of data minimization, and providing a basis for subsequent auditing and traceability.

[0151] Figure 4This is a flowchart of another method for verifying advertisement display according to an embodiment of this application, which is described below in conjunction with... Figure 3 and Figure 4 This section details the specific process for verifying ad display methods.

[0152] Step S401, End-side sampling and quantization (data acquisition).

[0153] Step S4011: Set the sampling elements and frequency.

[0154] The sampling frame of the terminal SDK may include: visual percentage vi, foreground focus flag fi, volume intensity or "not mute" flag ai, interaction bit ei, and timestamp ti.

[0155] The sampling frequency can be set to approximately 10Hz (i.e., the adjacent sampling interval Δt ≈ 100ms), or it can be configured to other frequencies such as 5–30Hz depending on the terminal performance and service requirements. To facilitate calculations over a finite domain, continuous real numbers can be mapped to fixed-point integers, for example: vi = round(viewport_ratio 100).

[0156] To mitigate the risk of attacks such as pre-recorded playback fitting, a dithering sampling method can be employed. For example, a pseudo-random function PRF(nonce,i) can be used to introduce a sampling time offset of ±5–20ms per frame based on the nonce in the delivery response.

[0157] The sampling frequency can be set to approximately 10Hz (i.e., the adjacent sampling interval Δt ≈ 100ms), or it can be configured to other frequencies such as 5–30Hz depending on the terminal performance and service requirements. To facilitate calculations over a finite domain, continuous real numbers can be mapped to fixed-point integers, for example: vi = round(viewport_ratio 100).

[0158] To mitigate the risk of attacks such as pre-recorded playback fitting, a dithering sampling method can be employed. For example, a pseudo-random function PRF(nonce,i) can be used to introduce a sampling time offset of ±5–20ms per frame based on the nonce in the delivery response.

[0159] Step S4012: Construct a tamper-proof hash chain.

[0160] Construct a hash value for each sampled frame: frame i =(vi||fi||ai||ei||ti||h {i-1} ), h i =H(frame i ).

[0161] Where h0 = H(ad_id||nonce||seed). The above construction concatenates the frame sequences into a hash chain, so if an intermediate frame is tampered with, it can be detected during verification. Regarding time consistency, adjacent timestamps can be required to satisfy: t {i+1} -t i ∈[δ min ,δ max For example, [60ms, 300ms], to tolerate reasonable end-side jitter.

[0162] In addition, frame i It may also include derived metrics for describing temporal behaviors such as scrolling, clicking, dragging, and volume changes. These derived metrics also participate in the hash chain and commitment calculation.

[0163] Step S402: Construct the commitment structure and common inputs (data commitments).

[0164] Step S4021: Construct hierarchical commitments. Divide the sampled frames into multiple segments (e.g., every 64 frames per segment). Generate segment-level commitments for each segment vector using Pedersen or multinomial commitment methods. Construct a Merkle tree using each segment commitment as leaves to form the session root C_session. The common inputs of the session may include: ad identifier ad_id, ad slot identifier slot_id, verification parameter version number vk_version, challenge random number nonce, threshold parameter set θ={x,T1,T2,K,…}, time window [t_begin,t_end], and session root C_session, etc.

[0165] Step S4022: Determine the selective disclosure capability. Due to the use of a segment-level Merkle structure, when sampling is required, only the segment leaf and its authentication path corresponding to a certain time interval can be disclosed to prove that the data in that interval is consistent with the session root commitment, thereby avoiding the disclosure of the complete behavioral trajectory.

[0166] Step S403, Construction of explicit statements and sub-circuits (proof implementation). Let the witness include: W = {sequence (vi,fi,ai,ei,ti), segment commitment random number, Merkle authentication path, environment element elem}; the common input X is: X = {C_session,θ,nonce,vk_version,Root(S)}, where Root(S) is the Merkle root or accumulator root of the compliant environment set (e.g., SDK / browser version, certificate hash, etc.).

[0167] Furthermore, to facilitate the construction of the proof system, the circuit can be divided into multiple relatively independent sub-circuits.

[0168] Sub-circuit A (visual + front-end cumulative time): Construct indicator Ii=1[(v i ≥x)∧(f i =1)],Verify ΣI i ·Δt i ≥T1, where Δt i =t {i+1} -t i Or a fixed step size.

[0169] Sub-circuit B (Audible Cumulative Duration): Indicator J i =1[a i ≥θ a ], verify ΣJ i ·Δt i ≥T2.

[0170] C Subcircuit (Interactive Counting): Verifying Σe i ≥K or "In a window of any length L, the number of interactions is ≥KL".

[0171] D-subcircuit (Time Consistency and Hash Chain): Constraint t {i+1} -t i ∈[δ min ,δ max ], and verify h i =H(vi,fi,ai,ei,ti,h{i-1}); When using proof systems such as PLONK, comparison and hash preimage verification can be achieved through lookup tables and range proofs.

[0172] E-subcircuit (Anonymous Environment Compliance Set Membership Proof): Verifies elem∈S (via Merkle path or accumulator witness) and binds elem to the session sampling process (e.g., participating in the calculation of h0), constraining the display to occur in a compliant environment without exposing the specific device identity.

[0173] F-subcircuit (commitment consistency): Verifies the consistency between the sampled sequence and the segment commitment, as well as the correctness of the Merkle path from the segment leaf to the session root C_session.

[0174] Step S404, End-side process (method implementation). Specifically, the end-side method may include the following steps:

[0175] Step S4041, pull advertisement: The terminal device initiates an advertisement request, and the delivery and response module returns the advertisement material as well as the threshold parameter θ, the verification parameter version vk_version, the challenge random number nonce, and the environment set root(S) or its identifier.

[0176] In some optional embodiments, the threshold parameter set θ can be dynamically generated by the delivery and response module based on factors such as ad placement configuration, user profile, device type, or network conditions, and then distributed as a common input. The client-side, when generating zero-knowledge proofs, only relies on the distributed θ and does not need to know the rules governing the threshold generation.

[0177] Step S4042, Jitter Sampling and Hash Chain Construction: The SDK starts a sampling timer to collect (vi,fi,ai,ei,ti) at the aforementioned frequency and constructs a hash chain.

[0178] According to some optional embodiments of this application, the sampling frame i In addition to basic fields such as visibility ratio (vi), foreground focus flag (fi), volume level (ai), and interactive event (ei), additional granular behavioral features describing temporal changes can be added, such as the amount and rate of change of the visible area before and after scrolling or clicking, the time interval between consecutive operations, and volume change trends. These granular features are incorporated into the frame-level hash chain and segmented commitment calculation as components of the sampled frame. Within the zero-knowledge proof circuit, they are used to impose finer-grained constraints on the temporal consistency of the display process and attention change trajectories, thereby improving the ability to identify abnormal displays or simulated manipulation behaviors without exposing the specific original behavioral sequence to the verifier.

[0179] Step S4043, commitment generation: Divide the sampled frame sequence into several segments according to preset rules, calculate the segment-level commitment for each segment, and build a Merkle tree on this basis to obtain the session root commitment C_session, which serves as one of the common inputs for subsequent zero-knowledge proofs.

[0180] Step S4044, proof generation: Using the witness W associated with the sampled frame and the common input X containing parameters such as the session root commitment C_session as input, call the zero-knowledge proof library that follows the PLONK protocol to generate a non-interactive proof π. The library internally achieves non-interactivity through the Fiat-Shamir transformation.

[0181] Step S4045, Report data: Send {C_session,π,θ,ad_id,slot_id,vk_version,nonce,meta} to the verification end or aggregator.

[0182] Step S4046, Fault Tolerance and Retry: When the computing power on the edge is insufficient or the proof generation time exceeds the preset threshold, the method of "submitting the commitment first and then supplementing the proof asynchronously" can be adopted without changing the verification semantics; this variant can be recorded as a dependent embodiment.

[0183] According to some alternative embodiments of this application, the verification end can assign risk scores or trust levels to entities maintaining their data, such as media platforms, traffic sources, terminal accounts, or device identifiers. Based on these scores / trust levels, it can dynamically determine whether to allow the entity to use asynchronous supplementary proof mode, and the time interval and field range of commitment openings required in cases of verification failure, overdue supplementary proof, or random inspection. Entities with high trust levels can obtain a more lenient asynchronous supplementary proof strategy or a smaller commitment opening range while ensuring semantic consistency in verification. Entities with low trust levels can be configured to prioritize synchronous proof mode, or have increased random inspection frequency and require a wider range of commitment openings to strengthen monitoring and risk control.

[0184] It should be noted that, under the general threat model of this application, it is assumed that a malicious actor cannot alter the generated sampling frame sequence and its corresponding commitment without compromising the collision resistance and commitment binding of the hash function. Therefore, if the terminal-side sampling frame sequence is encoded into the hash chain and the session root commitment C_session, it cannot be tampered with afterward without being detected. However, for a powerful adversary who can completely control the terminal execution environment, it is still possible to forge input data during the sampling stage (e.g., by directly constructing fake sampling frames through an emulator or injection framework).

[0185] To address this type of source-level forgery risk, this application can incorporate the following extended measures: In some optional implementations, the sampling and proof logic is deployed in a trusted execution environment, and the binary and key configurations executed on the end side are verified through a remote proof mechanism; On the other hand, a sampling and selective disclosure strategy, cross-media or cross-platform statistical anomaly detection, and the aforementioned behavioral risk scoring mechanism are introduced to increase the sampling frequency and commitment disclosure range for suspicious entities, thereby increasing the implementation cost and detection probability of large-scale forgery without changing the basic semantics of commitment and zero-knowledge proof.

[0186] Step S405, Server / Contract Verification and Settlement (Verification Implementation). Specifically, the advertising platform-side method may include the following steps:

[0187] Step S4051, Parameter verification: Check whether vk_version is consistent with the version of the verification parameter currently being used.

[0188] Step S4052, verification: Call the verification function Verify(vk,X,π). If the verification passes, generate a receipt containing information such as C_session, digest hash, and timestamp.

[0189] Step S4053, Settlement Processing: Based on the verification results, record the transaction, release or freeze the margin, or trigger corresponding strategy adjustments for this demonstration. Verification failures or anomalies can be flagged for subsequent analysis.

[0190] Step S4054, Auditing and Storage: Write {ad_id, slot_id, C_session, receipt_hash, result} into the message queue and object storage for subsequent auditing and tracing.

[0191] Step S4055, optional aggregation processing: recursively or in batches aggregate multiple valid exposure proofs and save the aggregated root hash and aggregated proof on the chain to reduce on-chain storage and computation costs.

[0192] Step S406, Sampling / Challenge State Machine (Risk Handling Implementation).

[0193] Step S4061: Configure sampling trigger conditions. Sampling or challenge processes can be triggered based on one or a combination of the following conditions: the pass rate of a certain traffic source or ad placement is significantly higher than the historical percentile or similar control; the conversion rate is significantly lower than the control at the same level; the time series indicators are abnormal, such as the sampling variance being too small or a large number of samples being concentrated near the threshold; the newly accessed entity has a high similarity to the existing abnormal samples.

[0194] Step S4062: Generate a sampling inspection instruction. When the sampling inspection conditions are met, the verification end can issue a sampling inspection instruction to the terminal device or aggregator. The instruction may include requiring the necessary fields (such as volume range labels instead of original values) and their Merkle authentication paths for the segment leaf openings corresponding to a sub-interval of length 2–5 seconds; or requiring the submission of a reinforced sub-circuit proof π′ containing stricter time or spectral constraints.

[0195] Step S4063, determine the ruling and consequences. Based on the results of the random inspection or challenge, one of the following actions may be taken: Random inspection passed: maintain or restore the normal settlement strategy; partially passed: adopt a discount accounting or downgrade accounting strategy according to the degree of deviation; random inspection failed or the response was not completed within the specified time: freeze or forfeit the deposit, add to the watch list, etc.

[0196] Throughout the sampling process, only necessary time segments and tag information are disclosed, without requiring the complete behavioral trajectory to be revealed, which helps to reduce the impact on user privacy.

[0197] In steps S401 to S406 on the terminal device, a time-based jitter sampling strategy is used to sample the advertising display status of each frame, including but not limited to information such as visible percentage, foreground focus, volume status, interactive events, and timestamps. The sampled data is encrypted and hashed to form a hash chain, ensuring data integrity and immutability. Further processing using a hierarchical commitment structure divides the series of sampled frames into segments, generating a segment-level commitment for each segment. These segment-level commitments form the leaf nodes of a Merkle tree, resulting in the session root commitment C_session. The characteristics of the Merkle tree allow the verifier to require only the commitment of a specific segment and its authentication path when needed, without having to obtain the entire behavior sequence, achieving the goals of data minimization and de-identification.

[0198] Furthermore, on the entry side such as the server or blockchain, a series of dedicated zero-knowledge proof sub-circuits are designed to verify the commitments and proofs uploaded from the end side.

[0199] Furthermore, after receiving the cryptographic verification information (session root commitment C_session, non-interactive proof π, public input parameters, etc.) reported by the client, the verification end initiates the verification process. The verification process includes checking the consistency of the verification parameter version identifier (vk_version) and verifying the non-interactive proof π using the verification key (vk). Upon successful verification, the verifier only needs to retain necessary digest information (such as the session root commitment C_session, timestamp, and verification result) to confirm the compliance of the ad display, and then perform accounting and deduction operations. This eliminates the need for long-term storage of complete plaintext behavioral data, significantly reducing the risk of privacy leaks.

[0200] To further enhance the system's robustness and resistance to attacks, selective access and sampling mechanisms are also provided. When the verification end detects potential risk signals, such as abnormal verification pass rates, excessively low conversion rates, or suspected cheating behavior, it can request the end to submit the commitment value and authentication path of the sampled frame data corresponding to a specific sub-circuit within a specific time period, or request the generation and submission of a more stringent strengthening sub-proof π'. This mechanism allows the system to conduct in-depth reviews when necessary without changing the basic verification semantics, improving the ability to identify suspicious traffic and the response speed to abnormal behavior.

[0201] In summary, steps S401 to S406 above provide a comprehensive solution that protects user privacy while ensuring the accuracy of ad display verification by combining hash chain sampling and hierarchical commitment structure on the end side with zero-knowledge proof sub-circuit combination and selective opening sampling mechanism on the entry side.

[0202] Figure 5 This is a structural diagram of an advertisement display verification device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0203] The first sending module 51 is used to send advertising requests to the advertising platform.

[0204] The first receiving module 52 is used to receive the delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters used to generate verification information.

[0205] The construction module 53 is used to generate a sampling frame sequence based on behavioral feature data in the terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data.

[0206] The generation module 54 is used to divide the sampled frame sequence into multiple sub-intervals and generate a session root commitment based on the cryptographic commitments corresponding to the multiple sub-intervals.

[0207] The second sending module 55 is used to generate a non-interactive proof based on the verification parameters and send the cryptographic verification information to the advertising platform. The cryptographic verification information includes: verification parameters, session root commitment, and non-interactive proof. The cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

[0208] It should be noted that the above Figure 5 The modules in the above can be program modules (e.g., a set of program instructions that implement a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0209] It should be noted that, Figure 5 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 1 as well as Figure 4 The relevant descriptions of the embodiments shown will not be repeated here.

[0210] Figure 6 This is a structural diagram of an advertisement display verification device according to an embodiment of this application, such as... Figure 6 As shown, the device includes:

[0211] The second receiving module 61 is used to receive advertising requests sent by the terminal device.

[0212] The third sending module 62 is used to send the advertising content corresponding to the advertising request and the verification parameters used to generate verification information to the terminal device when the advertising request meets the preset delivery conditions.

[0213] The third receiving module 63 is used to receive cryptographic verification information sent by the terminal device. The cryptographic verification information includes: verification parameters, session root commitment, and non-interactive proof. The session root commitment is generated by dividing the sampled frame sequence into multiple sub-intervals and based on the cryptographic commitments corresponding to the multiple sub-intervals. The sampled frame sequence is constructed based on behavioral feature data in the terminal device. The non-interactive proof is generated based on the verification parameters.

[0214] Verification module 64 is used to verify cryptographic verification information to determine whether the display status of the advertising content meets the requirements.

[0215] It should be noted that the above Figure 6 The modules in the above can be program modules (e.g., a set of program instructions that implement a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0216] It should be noted that, Figure 6 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2 as well as Figure 4 The relevant descriptions of the embodiments shown will not be repeated here.

[0217] Figure 7 A hardware block diagram of a computer terminal for implementing a verification method for advertising display is shown. Figure 7 As shown, the computer terminal 70 may include one or more processors 702 (shown as 702a, 702b, ..., 702n in the figure) 702 (processor 702 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 704 for storing data, and a transmission module 706 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 7 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 70 may also include... Figure 7 The more or fewer components shown, or having the same Figure 7 The different configurations shown.

[0218] It should be noted that the aforementioned one or more processors 702 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 70. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0219] The memory 704 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the advertisement display verification method in this embodiment. The processor 702 executes various functional applications and data processing by running the software programs and modules stored in the memory 704, thereby realizing the aforementioned advertisement display verification method. The memory 704 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 704 may further include memory remotely located relative to the processor 702, and these remote memories can be connected to the computer terminal 70 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0220] The transmission module 706 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 70. In one example, the transmission module 706 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 706 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0221] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 70.

[0222] It should be noted here that, in some optional embodiments, the above... Figure 7 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 7 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0223] It should be noted that, Figure 7 The computer terminal shown is used to execute Figure 1 as well as Figure 2 The verification method for the advertisement display shown above also applies to this electronic device, and will not be repeated here.

[0224] This application embodiment also provides a non-volatile storage medium, which includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-mentioned verification method for advertising display.

[0225] A non-volatile storage medium performs the following functions: sending an advertising request to an advertising platform; receiving a delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters used to generate verification information; generating a sampling frame sequence based on behavioral feature data in the terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data; dividing the sampling frame sequence into multiple sub-intervals, and generating a session root commitment based on the cryptographic commitments corresponding to the multiple sub-intervals; generating a non-interactive proof based on the verification parameters, and sending the cryptographic verification information to the advertising platform, wherein the cryptographic verification information includes: verification parameters, session root commitment, and non-interactive proof, and the cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

[0226] This application also provides an electronic device, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-mentioned method for verifying advertising display.

[0227] The processor is used to run a program that performs the following functions: sending an advertising request to an advertising platform; receiving a delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters for generating verification information; generating a sampling frame sequence based on behavioral feature data in the terminal device, wherein each sampling frame in the sampling frame sequence includes at least behavioral feature data; dividing the sampling frame sequence into multiple sub-intervals, and generating a session root commitment based on the cryptographic commitments corresponding to the multiple sub-intervals; generating a non-interactive proof based on the verification parameters, and sending the cryptographic verification information to the advertising platform, wherein the cryptographic verification information includes: verification parameters, session root commitment, and non-interactive proof, and the cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

[0228] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0229] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0230] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0231] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0232] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0233] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0234] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0235] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for verifying advertisement display, characterized in that, Applied to terminal devices, including: Send an ad request to the advertising platform; The system receives a delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters for generating verification information; Based on the behavioral feature data in the terminal device, a sampling frame sequence is generated, wherein each sampling frame in the sampling frame sequence includes at least the behavioral feature data; The sampled frame sequence is divided into multiple sub-intervals, and a session root commitment is generated based on the cryptographic commitments corresponding to the multiple sub-intervals. Based on the verification parameters, a non-interactive proof is generated, and the cryptographic verification information is sent to the advertising platform. The cryptographic verification information includes the verification parameters, the session root commitment, and the non-interactive proof. The cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

2. The method according to claim 1, characterized in that, Based on the cryptographic commitments corresponding to the multiple sub-intervals, a session root commitment is generated, including: Encode the behavioral feature data of all sampled frames within each sub-interval into a corresponding structured data set; Based on the commitment algorithm, deterministic operations are performed on the structured data set of each sub-interval to obtain a unique cryptographic commitment corresponding to each sub-interval. The cryptographic commitments of the multiple sub-intervals are used as leaf nodes, and according to the predefined tree structure rules and hash linking rules, iterative hash calculation and linking are performed from bottom to top based on the leaf nodes to obtain a verifiable data structure. The cryptographic commitment of the root node of the verifiable data structure is determined as the session root commitment.

3. The method according to claim 2, characterized in that, The behavioral feature data of all sampled frames within each sub-interval are encoded into a corresponding structured data set, including: Cryptographic hashing is performed on the advertisement identification information, the challenge random number, and the random seed to obtain the initial hash value; Based on the initial hash value and the behavioral feature data of the sampled frames collected sequentially in the sampled frame sequence, the hash value corresponding to each sampled frame is determined; The hash values ​​of the sampled frames belonging to each sub-interval are encoded and concatenated in order of frame number to form a structured data set for each sub-interval.

4. The method according to claim 3, characterized in that, Based on the initial hash value and the behavioral feature data of the sampled frames sequentially collected in the sampled frame sequence, the hash value corresponding to each sampled frame is determined, including: Based on the behavioral feature data, timestamp information, and link hash value of each sample frame, complete frame data is generated, and a cryptographic hash operation is performed on the complete frame data to obtain the hash value corresponding to the sample frame. Specifically, for the first sample frame in the sample frame sequence, the link hash value used is the initial hash value; for samples that are not the first sample frame in the sample frame sequence, the link hash value used is the hash value corresponding to the previous adjacent sample frame.

5. The method according to claim 1, characterized in that, Based on the verification parameters, a non-interactive proof is generated, including: Based on the witness information, construct the private witness parameters for zero-knowledge proof, wherein the witness information includes: the sampling frame sequence, the random number used to generate the cryptographic commitment for each sub-interval, the authentication path used to verify the position of the session root commitment in the verifiable data structure, and verified environment elements selected from a predefined set of compliant environments; Based on the session root commitment and the verification parameters, construct the common input parameters for the zero-knowledge proof; Based on the private witness parameters and the public input parameters, the zero-knowledge proof system is invoked to generate the non-interactive proof.

6. The method according to claim 1, characterized in that, The method further includes: Determine whether the resource status of the terminal device does not meet the preset requirements and whether the time taken to generate the non-interactive proof is greater than a preset threshold; If the resource status of the terminal device does not meet the preset requirements or the time taken to generate the non-interactive proof exceeds the preset threshold, the session root commitment will be sent to the advertising platform after the session root commitment is generated. After the session root commitment is sent to the advertising platform, the non-interactive proof is generated by calling a zero-knowledge proof system based on the same private witness parameters and public input parameters as those used to generate the session root commitment. The non-interactive proof is sent to the advertising platform, wherein the non-interactive proof is used by the advertising platform to verify the non-interactive proof using the received session root commitment.

7. The method according to claim 1, characterized in that, The method further includes: An executable code image for performing the target operation is loaded and run in the trusted execution environment of the terminal device, wherein the target operation includes: constructing the sampled frame sequence, generating the session root commitment, and generating the non-interactive proof; The remote authentication function of the trusted execution environment is invoked to generate an integrity certificate, wherein the integrity certificate includes: a metric value of the executable code image, the identity information of the trusted execution environment, and a cryptographic binding of the running configuration of the trusted execution environment; The integrity certificate is sent to the advertising platform, wherein the integrity certificate is used by the advertising platform to verify the trusted status of the trusted execution environment based on a pre-stored list of valid metrics and an authentication public key.

8. A method for verifying advertisement display, characterized in that, Applied to advertising platforms, including: Receive advertising requests sent by terminal devices; If the advertising request meets the preset delivery conditions, the advertising content corresponding to the advertising request and the verification parameters used to generate verification information are sent to the terminal device. The terminal device receives cryptographic verification information, which includes: verification parameters, a session root commitment, and a non-interactive proof; the session root commitment is generated by dividing the sampled frame sequence into multiple sub-intervals and based on the cryptographic commitments corresponding to the multiple sub-intervals respectively; the sampled frame sequence is constructed based on behavioral feature data in the terminal device; and the non-interactive proof is generated based on the verification parameters. The cryptographic verification information is verified to determine whether the display status of the advertisement content meets the requirements.

9. The method according to claim 8, characterized in that, Verifying the cryptographic verification information includes: Determine whether the version identifier of the verification parameter is consistent with the version identifier of the currently used verification parameter; If the version identifier of the verification parameter is consistent with the version identifier of the currently used verification parameter, the non-interactive proof in the cryptographic verification information is verified based on the verification parameter and the common input parameters of the zero-knowledge proof, wherein the common input parameters include at least: the session root commitment and the verification parameter.

10. The method according to claim 8, characterized in that, After verifying the cryptographic verification information, the method further includes: If the non-interactive proof in the cryptographic verification information is verified successfully, a verification receipt is generated, wherein the verification receipt includes at least one of the following: the session root commitment, a verification digest of the verification result, and timestamp information; If the verification of the non-interactive proof in the cryptographic verification information fails, the display behavior based on the advertising content is marked. Based on the verification result of the non-interactive proof in the cryptographic verification information, the display behavior is processed for settlement.

11. The method according to claim 10, characterized in that, After verifying the cryptographic verification information, the method further includes: The information set is written into a message queue and the message queue is stored in an object storage system. The information set includes: advertising identification information, the session root commitment, the message digest of the verification receipt, and the verification result. The non-interactive proofs corresponding to multiple verified ad display records are aggregated and calculated to generate an aggregated proof, and the aggregated root digest corresponding to the aggregated proof is determined. The aggregate proof and the corresponding aggregate root digest are saved to the distributed ledger system.

12. The method according to claim 8, characterized in that, The method further includes: Under the condition that the preset sampling conditions are met, a sampling instruction is sent to the terminal device, wherein the sampling instruction includes at least one of the following verification requirements: The terminal device is required to provide all or part of the field information of the target cryptographic commitment corresponding to the target sub-interval of a specified duration in the sampling frame sequence, and the authentication path of all or part of the field information in the verifiable data structure; The terminal device is required to generate and submit an enhanced proof for the sampled frame sequence, the enhanced proof being generated by applying a target constraint to a zero-knowledge proof circuit, wherein the zero-knowledge proof circuit is used to constrain the compliance of the sampled frame sequence, and the constraint strength of the target constraint is greater than the constraint strength used by the zero-knowledge proof circuit to generate the non-interactive proof.

13. A verification device for advertising display, characterized in that, include: The first sending module is used to send advertising requests to the advertising platform; The first receiving module is configured to receive the delivery response corresponding to the advertising request sent by the advertising platform, wherein the delivery response includes at least: advertising content and verification parameters for generating verification information; A construction module is used to generate a sampling frame sequence based on behavioral feature data in a terminal device, wherein each sampling frame in the sampling frame sequence includes at least the behavioral feature data; The generation module is used to divide the sampled frame sequence into multiple sub-intervals and generate a session root commitment based on the cryptographic commitments corresponding to the multiple sub-intervals respectively. The second sending module is used to generate a non-interactive proof based on the verification parameters and send the cryptographic verification information to the advertising platform. The cryptographic verification information includes the verification parameters, the session root commitment, and the non-interactive proof. The cryptographic verification information is used to verify whether the display status of the advertising content meets the requirements.

14. A verification device for advertising display, characterized in that, include: The second receiving module is used to receive advertising requests sent by the terminal device; The third sending module is used to send the advertising content corresponding to the advertising request and the verification parameters for generating verification information to the terminal device when the advertising request meets the preset delivery conditions. The third receiving module is used to receive cryptographic verification information sent by the terminal device, wherein the cryptographic verification information includes: the verification parameters, the session root commitment, and the non-interactive proof; the session root commitment is generated by dividing the sampled frame sequence into multiple sub-intervals and based on the cryptographic commitments corresponding to the multiple sub-intervals respectively; the sampled frame sequence is constructed based on behavioral feature data in the terminal device; the non-interactive proof is generated based on the verification parameters. The verification module is used to verify the cryptographic verification information to determine whether the display status of the advertisement content meets the requirements.

Images