Decentralized Privacy-Preserving Rewards with Cryptographic Black-Box Accumulators

Abstract

A distributed, trust-minimizing computer architecture for calculating rewards for users of an advertising system includes a cryptographic black-box accumulator (BBA), a cryptographic counter that can only be updated by the publisher. Attention applications request BBA initialization from guardians and then request updates to the BBA to track interactions between users of the attention application and ads on the attention application. The guardians sign updates to the BBA to reach agreement on the state of ad interactions. The attention application can improve user privacy by randomizing the BBA and submitting requests through anonymous channels so that participants cannot link two encounters with the BBA to each other or link the BBA to a specific attention application. Reward redemption requests are made based on a public policy and can be committed to a public blockchain for observers to verify that the protocol is operating correctly.

Description

[Technical Field]

[0001] The present disclosure relates to cryptographic communications in advertising reward systems.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This Patent Cooperation Treaty (PCT) patent application claims priority to U.S. Patent Application No. 63 / 017,604, entitled "Decentralized Privacy-Preserving Online Advertising," filed April 29, 2020, and incorporated herein in its entirety. [Background technology]

[0003] Content creators on the World Wide Web rely mostly on advertising to fund their activities. This system suffers from broken economic incentives in several ways. Existing web advertising involves exposing large amounts of sensitive information about users by categorizing them in a cloud, typically based on web trackers that monitor users across the web. Advertisements are then delivered to users embedded in content based on the match.

[0004] The current system is prone to rampant fraud, invasion of user privacy, and often involves fraudulent advertising behavior (video and audio usage, screen space consumption, tracking, etc.). The market for buying and selling digital advertising on the web is manipulated, shifting value from content creators, publishers, and consumers to rent-seeking advertising technology companies. Most of the revenue from the current system goes to advertising technology companies rather than content creators, and users are not compensated for the attention they pay to ads. Increasingly, users are choosing to block ads and web trackers entirely to prevent fraud, but this reduces publishers' and content creators' advertising revenue and does not fairly and economically support content creators.

[0005] Various attempts have been made to compensate users for paying attention to advertisements on the web, but all suffer from certain drawbacks. Previous attempts involved invasion of privacy domains and reliance on the continued presence and integrity of centralized parties. Previous attempts were susceptible to fraudulent activity that was very difficult or impossible for participants, let alone independent verifiers, to detect.

[0006] Therefore, a new type of computer architecture is needed that has a trustless, decentralized framework for matching users to advertisements on the web in a fair, privacy-respecting way that shares advertising revenue between content creators and ad viewers instead of intermediary advertising technology companies.

[0007] The accompanying drawings, in which like reference numerals refer to identical or functionally similar elements throughout the separate views, and which, together with the following detailed description, are incorporated into and form a part of this specification, serve to further illustrate embodiments of the concepts comprising the claimed invention(s) and to explain various principles and advantages of those embodiments. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram of a computer system architecture including a user of an attention application, a parent computing terminal, a web advertiser, and a separate reward verification component, according to some embodiments. [Figure 2] 1 is a diagram of a parent computing terminal that delivers an advertising catalog containing campaign advertisements to an end user who may view the campaign advertisements embedded in media content and from content publishers, according to some embodiments. [Figure 3]1 is a schematic diagram of a local ad catalog, its associated example ad policy vector, an ad vector initialized before a user pays attention to any ads, an ad vector updated to reflect actual ad interactions, and reward calculations, according to some embodiments. [Figure 4] 4 is a signal diagram of an exemplary exchange of black box accumulators (BBAs) between a parent computing terminal and a user of an attention application terminal, according to some embodiments. [Figure 5] FIG. 10 is a signal diagram of an exemplary generation of a reward proof by a user of an attention application terminal based on an exchange of a BBA that commits the reward proof to a blockchain for an independent reward verification component, according to some embodiments. [Figure 6] FIG. 2 is a block diagram of exemplary components of a parent terminal that manages advertising campaigns for advertisers in a distributed privacy-preserving online advertising system, according to some embodiments. [Figure 7] FIG. 10 is a diagram of an example alternative implementation of a decentralized, privacy-preserving online advertising system including an ad campaign facilitator deploying smart contracts on a blockchain to implement an ad policy smart contract and an escrow fund smart contract, according to some embodiments. [Figure 8] FIG. 10 illustrates an exemplary alternative implementation of an end user submitting an encrypted interaction vector to an Ad Policy smart contract to calculate an encrypted tally and share the encrypted tally with an Escrow Fund smart contract, which distributes the encrypted tally to viewer rewards, campaign manager fees, and advertiser refunds, respectively, according to some embodiments. [Figure 9] 1 is a flowchart of a workflow for establishing encrypted communication between an attention application terminal and a parent computing terminal using a black-box accumulator (BBA) in an attention reward architecture, according to some embodiments. [Figure 10] 1 is an exemplary system that may be useful for performing the functions described herein. DETAILED DESCRIPTION OF THE INVENTION

[0009] Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.

[0010] Components of the apparatus and methods have, where necessary, been represented by conventional symbols in the drawings, showing only the specific details relevant to understanding the embodiments of the invention, so as not to obscure the disclosure with details that will be readily apparent to those skilled in the art having the benefit of the description herein.

[0011] For purposes of this disclosure, it should be understood that the terms "ad" and "advertising" are used interchangeably. Reference is also made to an "attention application" or "attention application terminal" that allows end users to view advertisements embedded in media content from publishers or content creators. The term "attention application" applies to this disclosure with reference to a web browser that displays content to users from the World Wide Web, but should also be understood to encompass other types of applications that run on hardware and can display media content to users, such as e-readers, gaming platforms, smartphones, virtual reality systems, augmented reality systems, audiobook, music, and podcast playback systems, etc.

[0012] There has been a desire to have a mechanism that can circumvent the existing mechanisms of online advertising on the World Wide Web. The current situation has serious drawbacks, including reduced privacy for end users and reduced transparency to advertisers regarding the costs and performance of their advertising campaigns. Typical web browsing involves exposure to so-called web trackers that monitor users around the web, exposing sensitive private user information (browsing history, search logs, purchase history, map logs, etc.) to mysterious advertising network operators that mine user activity and collect and sell detailed demographic and consumer profiles of users. This results in highly targeted advertising that can be aversive to users, based on information that the user may wish to protect privately.

[0013] On the advertiser side, the market for placing ads can be heavily manipulated by unscrupulous ad network actors (e.g., by manipulating ad prices), and reliable feedback on ad campaign performance can be distorted to present an untrue picture of campaign effectiveness. Advertisers receive fraudulent analytics on their ad campaigns, content creators receive a cut from advertising revenue streams, user privacy is violated, and users are left without fair compensation for their attention.

[0014] Under existing systems, it is becoming increasingly common for users to turn to ad blockers and tracker blockers, which, while partially successful in protecting end-user privacy, block ads at the expense of publishers and content creators who completely lose the revenue they rely on. There are alternative reward systems to total ad blocking that aim to benefit users, content creators, and advertisers, but these systems all rely on trusted guardians or intermediaries on whom the systems depend. In many cases, users or observers have no way of determining whether the guardians are acting honestly with regard to paying rewards or analyzing advertising campaigns.

[0015] An example of a rewards system is Brave Rewards, included in the Brave Browser published by Brave Software, Inc. Under Brave Rewards, an ad catalog is pushed to the browser, and then the user is matched to ads locally using only the parts of their user profile that they deem acceptable. For example, users can decline to allow access to their web search query logs or browsing history for ad matching purposes. Ads can be shown to the user in toast messages or embedded in media content (e.g., embedded in the text of a web page). The catalog contains only well-behaved ads, meaning that there are no ads that attempt to perform deceptive or annoying behaviors (e.g., changing window focus, playing audio, playing video, false close buttons, etc.).

[0016] Brave Rewards allows advertisers to purchase advertising space in a catalog using blockchain tokens called Basic Attention Tokens (BAT), which are paid to users (e.g., on a mouse-end basis) in response to interactions with ads measured by the Brave Browser. The Brave Browser publisher is the guardian of the system and receives BAT, which users hold until they request payment for rewards, which may occur periodically, such as monthly. Depending on the quantity and quality of ad interactions and the rewards paid by advertisers, Brave Rewards users will receive payments of BAT, which may be made from the Brave Rewards guardian to the user in the browser's own cryptocurrency wallet or to a third-party managed wallet. The rewards described herein need not be in the form of BAT; rewards may include any type of blockchain token or another type of reward.

[0017] In a system like Brave Rewards, one aspect of trust involves trusting that the guardians accurately calculate accrued rewards to users. Users calculate rewards independently and have no way to verify that what is accrued has actually been paid. Confidence in the fairness of the system depends on the trustworthiness of the centralized guardian entity and may not be high if rewards cannot be audited by outsiders without any special access to the system.

[0018] Rewards network participants and advertisers may want the system to be privacy-respecting and trustless, so that users do not have to worry about whether guardians are honest or whether they are compromising their privacy by participating in reward payments. A fully decentralized rewards system without third-party guardians may not be practical. Rather than eliminating guardians entirely, the architecture of the present disclosure retains guardians but structures advertising campaigns and reward payments according to several design goals that allow for verification of the system's honesty while still respecting user privacy.

[0019] Disclosed herein is a new decentralized computer architecture that includes novel cryptographic proofs that solve problems associated with previous reward systems. Previous systems required users to reveal too much private information about their ad interactions and trusted a centralized entity or guardian to be honest in paying rewards. Advertisers also needed to trust that the centralized guardian accurately measured ad performance and spent advertising budgets according to the advertiser's instructions. The disclosed system avoids these problems through the novel use of a cryptographic mechanism called a Black Box Accumulator (BBA) in conjunction with a decentralized architecture. For purposes of this disclosure, a BBA may be referred to as a BBA token or BBA identifier, since it is simply a string of cryptographic material. Under the disclosed system, users can have high confidence that the rewards they received were actually paid. Advertisers can independently verify the proofs with a high degree of confidence that their ad campaigns are being attacked by fraudulent activity. External observers can also verify the cryptographic proofs to audit the system and verify that the protocol is operating correctly. In embodiments, the proofs can be stored and / or verified on the blockchain, providing trustless verification that observers can easily read the blockchain public ledger. In other embodiments, the reward payments themselves can be made on the blockchain, thereby providing the complete set of information needed to verify the protocol.

[0020] Our distributed architecture includes several design goals to achieve the aforementioned objectives. One design goal is to support reward calculation based on a user's ad interactions and reward verification without leaking information about the user's ad information behavior. Users can independently calculate rewards and prove the accuracy of their calculations without specifically disclosing which ads they interacted with.

[0021] Another design goal is to allow all participants and observers to verify that the protocol is running correctly, thereby improving confidence in the fairness of the system, by verifying that reward claims are calculated correctly. A final design goal is to allow advertisers to verify that the rewards claimed by users are correctly calculated based on true advertising interactions. If these goals are achieved, participants will have reliable proof that they do not need to trust a centralized guardian to be honest, which is an improvement over existing reward systems in terms of fairness, privacy, and reliability.

[0022] Achieving these goals is critical to the safety, privacy, and security of users of the present architecture. It is paramount that attackers cannot decipher intercepted BBA or word requests, since doing so would represent a privacy violation and undermine trust in the system. The current state of web advertising relies on trust, and users endure a breach of that trust whenever their personal profiles, browsing histories, query histories, location histories, and so on are exposed to advertising technology companies, who mine, sell, package, and resell that information for all it's worth. If users are expected to discourage ad blockers and participate in advertising and reward systems, they must have confidence that no attacker can see through the system and mine the personal content they find within. Furthermore, users and advertisers need to have confidence that the rewards protocol is operating correctly, that users are not being deceived when rewards are deposited, and that advertisers are not being victimized by fraud when the protocol says a real user correctly interacted with an ad.

[0023] To achieve the above goals, the computer architecture described herein solves several problems that existed in previous ad reward systems. One problem is linkability at the ad interaction level. Linking a specific ad interaction to a specific user would reveal information about the user that the user may want to protect privacy. While a single ad interaction may not seem to reveal much about a particular user, if participants in the system are able to track all ad interactions by a single user, as is typical for users who regularly browse the web, a potentially very detailed picture of the user emerges. In contrast, the architecture disclosed herein protects against linkability at the ad interaction level.

[0024] The next problem solved by this architecture is linkability between any two ad interactions. If two ad interactions are known to have been performed by the same user, a profiling opportunity exists that could violate the user's privacy, even if the user's identity is unknown. In this architecture, two ad interactions cannot be linked by the campaign facilitator, nor by the advertiser. Only the user who created both ad interactions can create a link.

[0025] Another problem solved by the present architecture is that of the privacy of advertiser campaign analytics. When advertisers join the system, they may want to collect advertising metrics to evaluate whether the cost of placing an advertisement is worth it. If such advertising metrics were available to outsiders, it could represent a leak of valuable commercial information or information of another nature that could harm the advertiser. Thus, only the campaign facilitator and the advertiser have visibility into the performance of the advertising campaign.

[0026] Next is the concept of interaction state update verifiability, which means that a user can verify that the current state of their ad interaction has been correctly recognized and recorded by the guardian to reflect new ad interactions after they occur. Next, the architecture has decentralized reward request verifiability, which means that any participant or observer can verify that a reward request from a user is valid with respect to the state of the interaction so that it can be accepted by the guardian. The results of reward verification can be committed to a public blockchain for visibility purposes.

[0027] FIG. 1 is a diagram of a computer system architecture 100 with a user 102 of an attention application 104, a parent terminal 106 (also referred to herein as an ad campaign facilitator or facilitator or parent component), a web advertiser 108, and a separate reward verification component 110, according to some embodiments. The computer system architecture 100 includes a concept known as a black-box accumulator (BBA) 112. A BBA is a type of signed, tamper-resistant cryptographic token that functions like a counter, allowing a user to collect and sum values ​​in a privacy-preserving manner. In this architecture 100, the BBA encodes an ad interaction vector, which is a vector where each index corresponds to an advertisement in an advertisement catalog. Incrementing an index in the ad interaction vector represents an ad interaction between the user 102 and the advertisement corresponding to the incremented index. Because a BBA can only be updated by its creator, the attention application terminal 104 and the parent terminal 106 pass the BBA 112 back and forth to perform this update. The attention application terminal 104 requests that a counter be incremented based on ad interactions, and if the request is deemed valid, the parent terminal 106 signs the update to the BBA 112. In this way, the attention application 104 and parent terminal 106 can mutually agree on the number and validity of ad interactions by the user 102 on a rolling basis as ad interactions occur.

[0028] A key feature of BBA is that a publisher cannot later link an encounter with a BBA to a specific user. For purposes of this disclosure, an encounter with a BBA is referred to as a "show" event. If a parent terminal 106 encounters a BBA at a show event, the parent terminal 106 cannot link that show event to a previous show event. The BBA design also protects against attackers attempting to cheat the system by falsely claiming to have collected more ad interactions than authorized. The BBA design provides unlinkability, privacy, and integrity of the encoded ad interaction vectors.

[0029] The workflow described herein can be divided into five stages: 1) interaction state initialization, 2) interaction state update, 3) reward calculation, 4) reward verification, and 5) anonymous and scalable payment. These stages are described at a high level with reference to Figure 1, while Figures 4 and 5 explain the algorithm applied in BBA in more detail.

[0030] In the first phase of the architecture 100, interaction state initialization, the attention application terminal 104 requests a newly initialized BBA 112 from the parent terminal 106 over the channel 114. In the initialized state, the BBA 112 corresponds to zero reward because the user 102 has not yet interacted with any reward-bearing advertisements on the attention application terminal 104. The channel 114 may be an anonymous channel to protect the user 102's private information from being leaked through the initialization request. After the user 102 interacts with one or more advertisements on the attention application terminal 104, the attention application terminal 104 can begin the process of updating the BBA to reflect the advertisement interactions. The update can occur after all advertisement interactions, in a batch process, after a certain number of advertisement interactions have been queued, based on the passage of a certain period of time, or the like. To update the BBA 112, the attention application 104 sends a copy of the BBA 112 along with a notification of which interactions have occurred. Similar to the initialization request, the channel 114 through which the attention application 104 sends the BBA 112 is an anonymous channel such that the parent terminal 106 cannot link the request to any previous requests made by the same user 102. When the parent terminal 106 receives notification of the BBA and user advertisement interaction from the attention application terminal 104, the parent terminal 106 updates the BBA 112 according to the interaction encoded in the request and returns it to the attention application terminal 104. The attention application terminal 104 can then verify the accuracy of the update of the BBA 112.

[0031] In addition to exchanging BBAs 112 with parent terminals 106, the attention application terminals can broadcast the BBAs 112 over the broadcast encrypted channel 103. The broadcast encrypted channel 103 is a many-to-many channel between the attention application terminals 104, parent terminals 106, and advertisers 108. All reward update requests made by the attention application terminal 104 are encrypted and issued over the broadcast encrypted channel 103 to which the parent terminals 106 and advertisers 108 have read access. In this configuration, the parent terminal 106 and advertisers are receiving BBA 112 updates over the same channel so that the advertisers 108 can have confidence that the parent terminal 106 is honestly applying updates to the advertisers' 108 advertising campaigns.

[0032] In an embodiment, it may be considered a privacy enhancement for an advertiser 108 that the advertiser 108 only has read access to messages from its own campaigns and not to messages related to other advertisers' advertising campaigns. Rather than directly encrypting the BBA for a particular advertiser 108, the broadcast encryption channel 103 distributes keying information that allows qualified advertisers 108 to reconstruct the content encryption key, while a revoked or unauthorized user finds insufficient information to recover the key. In this configuration, an advertiser 108 would be forced to collude with an unauthorized advertiser to share a key that would result in unauthorized access. This is unlikely, since each advertiser 108 would in fact be violating its own privacy by doing so. The guardian 106 can process all messages published on the broadcast channel and decrypt them to update the user's interaction state.

[0033] Because individual ad interactions are likely to be associated with only small reward payments, it is likely desirable for the attention application terminal 104 to accumulate multiple updates of the BBA 112 before requesting a reward payment. When it is appropriate to request a reward payment (e.g., if requested by the user 102, such as at the end of the month), the attention application terminal 104 can calculate the reward due to the user 102 based on the most recent BBA 112 received from the guardian 106. The attention application 104 can perform this calculation because it knows how much each ad interaction should pay due due to the ad policy vector, as described in more detail with reference to FIG. 3, and because it knows how many ad interactions the user 102 had with those ads over the relevant time period. Thus, the reward calculation is a local calculation that can be performed at the attention application terminal 104 and does not rely on trusting any other participants in the system. Knowledge of the advertising policy vector is an improvement over existing advertising reward systems, since users of existing systems have no way to check whether the rewards they receive are accurate.

[0034] The attention application terminal 104 then generates a proof 116 of correctness of the outstanding rewards and transmits the proof 116 along with the reward request and signature to the guardian terminal 106. Similar to the exchange of the BBA 112, the transmission of the proof 116 may occur over an anonymous channel, such as channel 114. In an embodiment, the transmission of the reward request and proof of correctness may be transmitted to the guardian 106 by committing the proof 116 and request to the blockchain 124. The blockchain 124 may be a public ledger from which any participant can obtain a copy on a read-only basis. Committing the proof 112 to the public blockchain 124 has several benefits. One benefit is that the blockchain 124 itself may support the computation of the correctness verification of the proof 122. For example, the operation of committing a batch of proofs 122 may include broadcasting a valid blockchain transaction that, once confirmed by the blockchain 124, invokes a smart contract, which is meant to reference executable code on the blockchain. The smart contract can perform proof verification in a manner that provides high confidence because the proof has actually been checked by all nodes on the blockchain's network and is only included in the chain if all nodes agree on the proof's accuracy. An observer in this scenario can simply check their copy of the blockchain 124 to see if the proof is deemed correct. In other embodiments, the checking of the proof 112 need not occur on-chain. The verifier component 110 is an observer that may perform the determination of the correctness of the proof 122 off-chain. An advantage of sending the proof of correctness 116 and reward request via the blockchain 124 is that the verifier component 110 can check the proof 116 and publish the results to any interested party, thereby increasing confidence in the correct operation of the protocol.

[0035] Even if the blockchain 124 does not include smart contracts that check the accuracy of the proofs 122, the blockchain 124 at least serves as a timestamp for the batch of proofs 122 so that the verifier component 110 and any other observers can be confident that the proofs 122 have existed in at least an unaltered state from the time they were included in the blockchain 124. The verifier component 110 can have a high degree of confidence that the proofs 122 have not been altered because an attacker wishing to tamper with the proofs 122 would be forced to attack the entire blockchain 124 and change any previously verified information, which may include computationally expensive or even infeasible operations such as redoing all of the proofs of work that occurred after the time the batch of proofs 122 was verified.

[0036] The parent terminal 106 verifies the proof of accuracy 116 and, if the proof 116 is acceptable, pays the reward 118. In the example shown in Figure 1, the reward 118 is a BAT blockchain token, the transfer of which is accomplished via a public blockchain to the wallet of the attention application 104 or via a custodial solution where the reward 118 is assigned to an account associated with the user 102 and / or the attention application terminal 104.

[0037] FIG. 2 is a diagram 200 of a parent terminal 202 that delivers an ad catalog 204 containing campaign ads 201 from a content publisher 218 to end users 206 and 210 who may view the campaign ads embedded in media content 214 and 216, according to some embodiments. The system disclosed herein differs from existing ad networks in the way it matches users to ads. In existing systems, ad networks collect information about users, such as by tracking them across the web using trackers. Web trackers are typically invisible to users but continue to monitor users long after they visit websites. Trackers relay user information to ad networks, often information that users consider sensitive personal information. Users are typically completely unaware of the tracking until a spooky ad appears, leaving them wondering how they were targeted by that ad. In such a system, a centralized advertising network builds a profile of a user that can include broad classifications including market segments in which the user is interested or a potential consumer, the user's location, demographic information (e.g., age, gender, race, etc.), the user's income bracket, etc. Advertisement matching is then performed by the advertising network in the cloud against the user's profile, and advertisements are sent to the user in the context of the media content the user is consuming.

[0038] In contrast, in our system, the entire ad catalog is pushed to the user, and ad matching occurs locally in the user's attention application, using only information about the user that the user consents to be used in the ad matching process. While existing ad networks may know an unsettling amount about the user, even the most intrusive tracking practices are unlikely to collect all the data about the user that is available in the attention application itself (e.g., browsing history, search logs, map query logs, email keyword matching, etc.). Therefore, matching locally against a large ad catalog can be much more private and potentially more accurate than existing cloud-based ad networks.

[0039] The ad catalog 204 may include the entirety of the ads available on the system 200, or the ad catalog 204 may have versions of the ad catalog, such as specific catalogs that target only specific regions. If all users fetch the same catalog, potentially sensitive personal information is unlikely to be leaked, but a segmented catalog may at least reveal something about the user (e.g., that the user resides in Asia). On the other hand, as the catalog grows, the overhead costs associated with transmitting the catalog and storing it locally at the attention application increase.

[0040] In system 200, one of the functions of parent terminal 202 is to deliver an advertisement catalog 204 to exemplary end users 206 and 210. The advertisement catalog 204 may include a collection of digital advertisements with creative assets for advertisements sponsored by advertisers who have contributed reward budgets in an escrow smart contract. Once received by attention application terminals 208 and 212, the advertisements in the catalog 204 can be matched to the respective users 206 and 210 according to the privacy permissions those users grant to their user profiles local to the attention applications 208 and 212 for media content 214 and 216 received from content publishers 218.

[0041] 2, media content 214 matched to the attention profile of user 206 local to attention application 208 will match campaign ad 201, and campaign ad 201 will receive an impression with user 206. In other cases, media content 216, etc. matched to the attention profile of user 210 on attention application terminal 212 will result in a different ad than catalog 204 shown to user 210. Regardless of whether campaign ad 201 matches a user, the matching process remains privacy-preserving compared to the ad network matching case in the cloud because users 206 and 210 control whether and how their sensitive personal information is used for ad matching purposes, and the matching stays on the local attention application that the user controls, preventing the leaking of sensitive information across the web as occurs with web trackers.

[0042] 3 is a schematic diagram 300 of a local ad catalog 302, its associated exemplary ad policy vector 308, an ad vector 310 initialized before a user pays attention to any ads, an ad vector 312 updated to reflect actual ad interactions, and reward calculations, according to some embodiments. The ad catalog 302 includes various ads that may be pushed to an attention application 306 for local matching as a user 304 views media content. The ad catalog 302 may be arranged in the form of a vector, with each ad corresponding to one index in the vector. Thus, the exemplary catalog 302 shown in FIG. 2 can be considered an 8-tuple, where ad 316 occupies the first index position in the vector and ad 318 occupies the last index position in the vector.

[0043] As mentioned above, it is a design goal of the architecture disclosed herein that the user 304 be able to calculate accrued rewards so that they can verify that the protocol is operating correctly and as intended. To do this, they need knowledge of the ad policy vector 308. The ad policy vector 308 is a vector of the same length as the ad catalog, and each index in the ad policy vector 308 corresponds to the ad occupying the same position in the ad catalog vector 302. The ad policy vector 308 may be periodically published by the guardian through a privacy-preserving channel. Thus, the attention application 306 can read the ad policy vector and apply it as described herein without leaking any data related to the user 304.

[0044] 3, index 320 corresponds to the first advertisement in the catalog, index 322 corresponds to the fourth advertisement in the catalog, and index 324 corresponds to the last advertisement in the catalog. The value of each index in the advertisement policy vector 308 indicates the magnitude of the reward owed to user 304 if user 304 pays attention to the advertisement when viewing content on attention application 306. Thus, advertisements 316, 317, and 318 are associated with advertisement payouts of 1 unit, 7 units, and 2 units, respectively.

[0045] The ad interaction vector 310 is shown in Figure 3 in an initialized state where each index in the vector is a zero or null value. The initialized state of the ad interaction vector 310 corresponds to no interaction by the user 304 with any ads in the catalog. The ad interaction vector will appear as shown in 310 before any browsing and ad interaction by the user 304, or immediately after a reward payment.

[0046] As the user 304 views media content and interacts with advertisements, the attention application 306 maintains a count of the particular advertisements the user has interacted with and increments the corresponding index in the advertisement interaction vector. The advertisement interaction vector 312 shows an example state after the user 304 has interacted once with the third advertisement (326), once with the sixth advertisement (328), and three times with the eighth advertisement (330) in the catalog. The accrued reward for the user 304 at any given time is calculated as the scalar product between the advertisement interaction vector 312 and the advertisement policy vector 308. An example of a scalar product calculation between the two vectors 308 and 312 is shown by reward calculation 314, in which the corresponding indexes in each of the two vectors are multiplied and the results are summed to produce the resulting accrued reward.

[0047] FIG. 4 is a signal diagram of an exemplary exchange of a black-box accumulator (BBA) between a guardian terminal 402 and a user 404 of an attention application 406, according to some embodiments. The BBA consists of a state, a hidden commitment to the state, and a digital signature for the commitment. The hidden commitment is a public commitment of a private state. A commitment scheme is a cryptographic primitive that allows a user to commit to selected values ​​or selected statements in a hidden state from others. In this architecture, the commitment is committed to a private ad interaction vector. The guardian 402 signs the commitment to verify that the new state is correct. Later, the guardian terminal 402, or any other participant, can verify whether the hidden state is valid without learning about the committed values ​​by checking whether the public commitment was signed by the guardian.

[0048] The BBA can be randomized by the attention application terminal 406 without losing the integrity of the data structure. This is an important quality and a significant improvement in privacy, as randomization prevents two show events (e.g., an update request, the disclosure of the BBA to another party, etc.) from being linkable. Another important quality is that the state of the BBA can remain hidden during update operations by the publisher. This means that the publisher only knows the state of the BBA at the time of initialization, when its state is zero, and does not know its state after receiving an update request from the attention application terminal 406. As discussed above with respect to FIG. 1, the BBA can be viewed as a counter or tracker of the interaction state between the user 404 and the ads that the user 404 has paid attention to on the attention application terminal 406 over a period of time. The interaction state is encoded as a vector, as described in more detail with reference to FIG. 3, where each index in the vector represents how many valid interactions the user has had with a particular ad. An initialized ad interaction vector for a catalog of N ads would be represented with all zero indices as follows: int_state=[int_ad0,int_ad1,int_ad2,...,int_ad N ]=[0,0,0,...0] Then, after the user 402 has completed interacting with several ads, for example, the user 402 interacts with ad01, ad22, and ad N If you interact with the ad four times, your ad interaction vector will look like this: int_state=[1,2,0,...4]

[0049] As mentioned above, the BBA can be considered a private counter that can only be updated by the issuer. If the guardian terminal 402 is the issuer of the BBA, only the guardian 402 can perform state updates to the BBA. Thus, the BBA can only accumulate state updates that the guardian component 402 considers valid. When the attention application 406 detects an ad interaction with the user 404, the attention application can periodically send the BBA to the guardian component 402 along with a notification requesting an update to the ad interaction vector. Perhaps the guardian component 402 will apply fraud detection checks to prevent attacks from dishonest attention application terminals 406. For example, the guardian 402 may rate-limit the attention application terminal 406 if it claims too many ad interactions within a limited period of time or if the guardian 402 is able to track known suspicious attention applications based on a wallet or other fingerprint unique to the attention application 406.

[0050] 4 tracks ad interactions by user 404 so that both parent component 402 and user 404 agree on the current state of interactions at any given time. In this configuration, BBAs are linked to the attention application terminal 406 (e.g., the attention application's cryptocurrency wallet) during issuance and redemption. This link protects the property that rewards based on BBAs are only redeemable by the owner of the attention application 406 to which the BBA was issued. This configuration also facilitates decentralized and trustless computation of rewards.

[0051] Before describing the BBA procedure shown in Figure 4 in detail, some terminology and notation will be adopted. In this disclosure, λ denotes a security parameter. To indicate that a is randomly chosen from a set A, we write $ / ←A. Vector notation is in bold italics, so that

number

number

number

number

[0052] In some configurations of BBA, users are required to provide zero-knowledge proofs of ownership of valid tokens or certificates. The architecture of this disclosure avoids zero-knowledge proofs in the Shaw procedure by using structure-protecting signatures on equivalence classes, referred to herein as SPS-EQ. SPS-EQ takes a tuple (h, g) of group elements and signs it. The signature consists of all exponents of the pair [(h, g)], primarily (h) for any c∈Zp. c ,g c ) can be matched to all elements of the equivalence class represented by . By matching a signature to another element of the equivalence class, the owner of the signature has made both instances unlinkable. In other words, the owner has randomized the tuple and the signature.

[0053] In the architecture of the present disclosure, the attention application terminal 406 maintains an SPS-EQ signature, called σ, over the vector (C, P), which is the commitment of the state, or in other words, the number of times the user 404 has interacted with each advertisement. For the structure of the commitment, the present disclosure follows the idea of ​​algebraic MAC, PS signature, or CL signature, which encode various counters in exponents.

[0054] Each BBA has a unique identifier that is spent when redeeming a reward. The BBA contains randomness that is selected by the Attention Application Terminal 406 to protect the privacy of the request. The Attention Application Terminal 406 owns the commit state, BBA identifier, and randomness used for the token, generating the following formula:

number

number

number

[0055] 4, the attention application 406 requests the issuance of a new BBA in operation 408. The request may be based on initializing a new attention application terminal 406 that did not previously have a BBA, restarting a reward cycle after a previous BBA has been redeemed, etc. The request operation 408 includes a request for a signature on a tuple.

number

number

[0056] Upon receiving the request 408, the guardian terminal 402 executes an operation 410 to issue and sign a new BBA. The operation 410 includes verifying the proof provided in the request operation 408 from the attention application terminal 406. If the verification check is successful, the operation 410 includes generating an SPS-EQ via the pair σ, resulting in a new signed BBA. In an operation 412, the guardian 402 sends the new signed BBA, and the attention application terminal 406 stores the BBA, the signature σ, and the randomization used during the request R=k.

[0057] The attention application terminal 406 then presents the media content along with the advertisement to the user 404 in operation 414. The attention application builds an advertisement interaction counter when the user 404 interacts with the advertisement on the attention application terminal 406. The advertisement interaction counter is used because the attention application terminal 406 cannot update the BBA itself, and only the parent terminal 402, the issuer of the BBA, can update the BBA. The advertisement interaction counter is used to create a notification requesting an update that the parent terminal 402 can send to the parent component 402, which can update and sign a new BBA. The advertisement interaction counter may simply be a vector with length N (if there are N advertisements in the catalog), where each index in the vector corresponds to the number of times the user 404 has viewed the corresponding advertisement. After receiving a reward, the advertisement interaction counter may be “zeroed out,” meaning that the attention application 406 resets to zero the list of advertisement interactions for which rewards are pending.

[0058] When the attention application terminal 406 is in a standby state (e.g., when the user 404 requests it, when a time period has elapsed, when a minimum number of rewards have been paid, etc.), the attention application randomizes the BBA in operation 416. The randomization operation 416 is possible because it relies on the SPS-EQ. In particular, the attention application randomizes the BBA in operation 416 by calculating:

number

number

[0059] Then, in operation 420, the attention application terminal 406 sends T' and the signature σ' adapted to the new randomized representation. If the advertisement j is the one notified during the event, upon receipt, the guardian 402 analyzes τ' = (τ1', τ2') and verifies the validity of the signature σ'. In operation 422, the guardian terminal 402 applies the requested state update to the BBA if the request is considered valid, so that:

number

[0060] FIG. 5 is a signal diagram 500 of an example generation of a reward proof by a user 504 of an attention application 506 based on an exchange of a BBA with a guardian 502, who commits the reward proof to a blockchain 508 for independent reward verification, according to some embodiments. At 510, the attention application 506 and guardian 502 exchange BBAs initialized by the guardian terminal 502 and updated as requested by the attention application terminal 506, as described in FIG. 4. The exchange of BBAs continues until the user 504 accumulates enough rewards to request reward payment. Reward payment can be triggered by an on-demand request of the user 504, such as when the BBA accumulates a threshold amount, on a periodic schedule, or by the user's 504's request. Clarification should be made regarding terminology and notation related to the BBA during the exchange process 510. The BBA may be referred to as a BBA tuple.

number

number

number

number

[0061] One of the design principles of the current architecture is that any reward payment must be accompanied by a publicly available proof of correctness so that various participants can be confident that the system is operating correctly. Operation 512 is where the attention application terminal 506 generates such a proof. To understand the structure of the proof generated in operation 512, a more detailed consideration of the SPS-EQ signature scheme is instructive. The SPS-EQ signature scheme is described by the following five algorithms: (1) BGGen(1 λ ): Security Parameter 1 λ When inputting, output bilinear group Description

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0062] Based on the above algorithm for SPS-EQ signatures and their verification functions, the Attention Application 506 can perform a provable calculation of the reward. For the purposes of this description, it is assumed that the user 50 has interacted with an advertisement on the Attention Application 506, and therefore the advertisement interaction notification is not null. The published vector, the advertisement policy vector, is assumed to be a public vector that is published or at least known to the Attention Application 506.

number

number

number

[0063] Operation 512 involves derandomizing the BBA and adapting the signature to the new representation by calculating ChgRep(M,σ,f,pk). The attention application 506 then reveals the BBA's identifier, calculates the inner product between the counter vector (also called the advertisement state vector) and the advertisement policy vector, proves that the addition of all counters does not exceed the limit (L) set by the guardian 502 for anti-fraud purposes, and generates a zero-knowledge proof of correctness. Res=<c、p> Then, the attention application 502 generates the following proof:

number

[0064] After the reward proof is calculated in operation 512, the attention application 506 sends the reward proof to the guardian 502 in operation 514. The guardian begins checking the reward proof in operation 516 by verifying the zero-knowledge proof.

number

number

number

[0065] It should be understood that the attention application terminal 506 opens the identifier of the BBA at the time of the reward request, which is sufficient to mark the BBA as used so that the BBA does not become the basis for subsequent reward requests, and to link the BBA to the corresponding attention application terminal 506 for reward payments.

[0066] As mentioned above, one design goal of the architecture is for an observer to be able to verify that the protocol is operating correctly, which means independent verification that the user 504 received the reward payment to which they are entitled. One way to achieve this goal is for the observer to have access to the proof computations performed on the blockchain 508. The guardian terminal 502 can commit one or more proofs to the blockchain in operation 520, with an optional batching operation 518 in which two or more proofs are combined into a single blockchain transaction. While FIG. 5 illustrates operation 520 as the guardian component 502 committing reward proofs to the blockchain 508, in other embodiments, the attention application 506 itself can commit reward proofs directly to the blockchain 508. For practical purposes, if transaction fees on the blockchain 508 are too high, it may not be economical for the attention application 506 to commit proofs. Therefore, the batching operation 518 can be used to save on blockchain transaction costs. Furthermore, parent terminal 502 may be a more sophisticated user of blockchain 508 than user 504 and may therefore be able to avoid overpaying blockchain transaction fees, whereas user 504 may not be able to avoid overpaying.

[0067] Ideally, the blockchain 508 is one that can support the execution of the SPS-EQ verification algorithm described herein through on-chain execution of the SPS-EQ algorithm. If the blockchain 508 can support such computation, an observer need only obtain a copy of the blockchain 508 or access to a copy of the blockchain 508 so that they can verify the accuracy of the proofs. In embodiments, reward payments may be made in the form of tokens that have value on the blockchain 508, such that proof verification and payment verification can be accomplished in the same set of smart contracts. However, in practice, the SPS-EQ computation may be too complex and uneconomical for the blockchain 508 to implement. Alternatively, the guardian may centrally compute the SPS-EQ algorithm and sign the BBA using a different signature scheme (e.g., Schnorr signatures), allowing the user 504 to make reward claims on-chain without the expensive signature verification procedure.

[0068] 6 is a block diagram 600 of example components of a parent terminal 602 that performs the functions described herein and interfaces with advertisers 624 and end users 626 in a distributed architecture, according to some embodiments. The parent components may include computer hardware and computer software components. Examples include a memory that stores instructions for performing the functions described herein and a computer processor for executing the instructions. Another example includes a network transceiver coupled to a computer network, such as the Internet, for performing the communication functions described herein. A further example includes a human interface component for an operator of the parent terminal 602 to instruct the components to perform the functions described herein.

[0069] One component of the guardian 602 is the ad policy vector component 604, which negotiates an ad policy vector with advertisers 624. In particular, the ad policy vector component receives one or more advertisements from the advertisers 624 for inclusion in an ad catalog that is pushed to the attention application of the end user 626. Each advertisement accepted from the advertiser 624 includes a reward value to be paid to the end user 626 who interacts with the advertisement on the attention application. The ad policy vector component 604 places the ad policy vector with an index corresponding to the advertisement in the catalog, where the value received from the advertiser 624 is the value of the index of the received advertisement. Another component of the guardian 602 is the ad catalog component 606. The ad catalog component 606 organizes online advertisements into a catalog of local attention applications that match the user. The ad catalog component 606 may periodically push new or updated ad catalogs to the attention application of the end user 626. The smart contract component 608 deploys the escrow fund smart contract and the advertising policy smart contract on the blockchain 622.

[0070] The encryption component 610 performs several functions of the architecture described herein. One of the functions of the encryption component 610 is structure-protecting signatures for equivalence classes (SPS-EQ) that contain the enumerated algorithms of the SPS-EQ scheme. λ ), KeyGen(BG), Sign(M,sk), Verify(M,σ,pk), and ChgRep(M,σ,f,pk). The encryption component 610 uses the SPS-EQ algorithm to check the proof of the reward submitted by the user. The encryption component 610 also includes a keystore and source of entropy sufficient to generate encryption keys and encryption key pairs from an address space large enough to perform the aforementioned operations. The encryption component 610 also performs the additively homomorphic encryption functions described herein.

[0071] The attention reward component 612 is operable to submit blockchain operations and / or request from the management platform to distribute rewards to users 626. In embodiments, the attention reward component accesses blockchain funds from an escrow fund smart contract and disburses funds according to the advertising policy vector and proof of attention from end users. The advertiser refund component broadcasts a blockchain transaction to refund advertisers 624 if the advertising campaign ends without depleting the blockchain funds contributed by the advertisers 624.

[0072] Another component of the guardian 602 is the BBA component 614. The BBA component 614 is equipped to receive requests to initialize a BBA from new attention applications, receive requests to update the BBA with notification of which ads have been viewed by the user 626 since the last BBA update, and cooperate with the encryption component 610 to sign the BBA updates. The campaign notification component 616 aggregates campaign metrics for notification to advertisers 624. The network communication component performs network transmissions with other participants, including the blockchain 622.

[0073] 7 is a diagram of an exemplary alternative implementation of a decentralized, privacy-preserving online advertising system 700 with an ad campaign facilitator 702 deploying smart contracts on a blockchain to implement an ad policy smart contract 704 and an escrow fund smart contract 706, according to some embodiments. The implementation described in FIG. 7 is an alternative implementation to other implementations described herein. For example, some of the guardian's tasks are instead performed by smart contracts on the blockchain. The alternative implementation may have some disadvantages compared to the BBA implementation, such as a potential lack of scalability when blockchain transaction costs are high.

[0074] Smart contracts 704 and 706 assume some of the roles of a centralized authority, such as a guardian, that needs to be trusted, as in a non-decentralized rewards system. It should be clarified that, in this disclosure, the term "smart contract" does not refer to a typical legal contract governed by contract law, in the sense of an agreement with rights and obligations between two parties. Instead, a smart contract in this context should be interpreted to mean a program consisting of computer code executed by a set of validators on a decentralized blockchain network according to a set of consensus rules. A smart contract is a computer program that is executed by all validators on the blockchain network and has a deterministic output that is added to the blockchain if all validators agree on the computer program's output. Therefore, the output of the computer program needs to be deterministic so that all validators executing the code arrive at the same output. A smart contract may rely on inputs by participants signed with cryptographic keys, and such inputs may include invoking specific functions of the smart contract computer program. A smart contract can write state data to the chain so that other smart contracts executed in the future can read the state data and incorporate it into their own smart contract programs.

[0075] In the example illustrated in Figure 7, the smart contract runs on a side chain 712 that is periodically established, e.g., at points 716, 718 relative to the main chain 714. The selection of the side chain (and main chain) is a design choice that balances the required throughput, transaction costs, smart contract execution costs, and security of the respective chains. Because the expected transaction costs of the system described herein at scale would be prohibitive for existing public blockchains, some kind of side chain 712 is likely required. However, depending on the blockchain selected, the system may be implemented directly on the main chain 714 if the chain's parameters are acceptable based on the system's expected throughput.

[0076] In configuration 700, the specific role of the centralized reward authority is replaced by smart contracts 704 and 706 and a campaign facilitator 702. The campaign facilitator 702 is responsible for negotiating advertiser policies for sponsored advertising (e.g., cryptographically proven user rewards per ad impression, number of impressions per ad funded by the campaign, etc.), configuring and deploying smart contracts 704 and 706, and processing on-chain payments of digital blockchain assets. While the campaign facilitator 702 handles these tasks, the system remains decentralized, and therefore requires zero trust from each other, because all participants can verify that all other participants execute the protocol correctly. An important consequence of this configuration is that any individual, organization, and / or consortium of entities can participate as a campaign facilitator. The campaign facilitator 702 may initially perform operations that appear to require trust by other participants, such as owning reward payments sent by an escrow smart contract using zero-knowledge proofs to protect the privacy and confidentiality of payment blockchain transactions (e.g., rewards to users for ad interactions, refunds to advertisers for unused campaign budgets, fees to itself for its campaign manager duties, etc.). However, other participants can check the numbers in these confidential transactions to at least view the correct amounts sent to various recipients without revealing their identities due to the campaign manager's use of zero-knowledge proof transactions. Thus, a fraudulent campaign manager will be caught, eliminating the need to truly trust the campaign manager as would typically be the case if a centralized entity controlled even part of the system.

[0077] 7, an advertiser 708 desires to develop an advertising campaign based on a single campaign advertisement 710 on a distributed privacy-preserving online advertising system that is shown to a relevant demographic of potential consumers. Initially, the advertiser 708 submits the sponsored advertisement 710 to the campaign facilitator 702 along with an advertising policy vector P. The advertising policy vector P represents the reward per advertising impression and campaign scope to be paid to each viewer of the sponsored advertisement 710 in terms of the number of views eligible for the reward.

[0078] To transmit the campaign ads and policy vector P710 to the campaign facilitator 702, the advertiser 708 exchanges a symmetric encryption key for each ad campaign with the campaign facilitator 702. The advertiser 708 then encrypts the corresponding ad campaign and transmits it to the campaign facilitator 702 along with the ad creative that constitutes the sponsored ad itself. The campaign facilitator 702 decrypts the campaign ads and policy vector 710 to verify whether the policy vector P is as agreed upon, then merges the encrypted policies of different advertisers into the encrypted policy vector to yield Enc(P), and then deploys two public smart contracts 704 and 706 corresponding to a version of the ad catalog that includes the campaign ads 710.

[0079] Referring now to the smart contracts 704, 706, there are several functions performed by each smart contract. The Policy smart contract 704 is responsible for verifying user reward claims and payment methods. The Ad Policy smart contract 704 also stores the encrypted policy vector Enc(P). The Escrow Fund smart contract 706 is the sole owner of the ad campaign advertiser funds set aside for the purpose of funding the ad campaign. In the example illustrated in FIG. 7 , the advertiser funds for funding the ad campaign are digital asset blockchain tokens (e.g., ERC20 tokens on the Ethereum blockchain) originally held by the Escrow Fund smart contract 706. The Escrow Fund smart contract 706 is responsible for making reward payments to users who view the sponsored campaign ad 710, making refunds to the advertiser 108 if there are found to be remaining funds at the end of the campaign, and releasing processing fees to the campaign facilitator 702 if such payments are included in the policy vector P. For clarity, when we say that the escrow fund smart contract 706 is “responsible” for these actions, we mean that the smart contract 706 contains computer code that, when executed by all validators of the sidechain 712, changes state so that the associated blockchain digital assets are transferred in the appropriate amounts to wallets controlled by receiving participants in the sidechain 712 or mainchain 714.

[0080] Next, the escrow fund smart contract 706 creates a vector S with the symmetric key of the advertiser 708 and the private keys of any other advertisers participating in the ad campaign of the same version of the ad catalog. Thus, the vector S is a vector S=[S1, S2, ..., S N] and encrypts S to form a vector Enc(S) that contains each element of S encrypted with a sidechain validator node's public key. The ad policy smart contract 104 then stores ENC(S) on its own on the sidechain 712, allowing validators on the sidechain 712 to decrypt and apply the corresponding policy on the user ad interaction vector.

[0081] Once the ad policy smart contract 704 is deployed, the advertiser 708 can verify whether Enc(P) indeed encodes the policy agreed upon with the campaign facilitator 702. In particular, the advertiser 708 (and any other advertisers running concurrent campaigns) fetch the Enc(P) vector from the public storage area of ​​the ad policy smart contract 704, decrypt the policy Enc(P[i]) using their respective symmetric keys i, and verify that it is the value agreed upon in operation 720. Next, the advertiser 708 fetches the smart contract address of the escrow fund smart contract 706 (e.g., an address on the Ethereum network where blockchain digital assets can be sent and held) and transfers to it a sufficient amount of blockchain digital assets to fund the ad campaign. The amount of funds required is determined by the number of impressions per ad desired by the advertiser 708, its portion of the agreed-upon policy, and the processing fee paid to the campaign facilitator 702. After the campaign ends, the advertiser 708 can receive a refund based on the final number of impressions viewed and / or clicked by end users. By obtaining campaign funds in operation 720, the advertiser 708 implicitly acknowledges and agrees to the deployed ad policies. If the advertiser 708 does not agree to the deployed ad policies, it can refuse to fund the contract. The advertiser's 108 campaign is considered initialized and verified once the campaign facilitator 702 verifies that the advertiser 708 (and any other advertisers participating in campaigns running on the same version of the ad catalog, which may be numerous depending on the size and content of that version of the ad catalog) have contributed campaign funds with the escrow fund smart contract 706, for example, by checking a copy of the sidechain ledger provided by a validator or maintained by the campaign facilitator 702 itself.

[0082] The system disclosed herein achieves improved privacy by using a novel additively homomorphic encryption scheme to calculate payments to viewers of sponsored ads while keeping user clicks private in a manner that is auditable by advertisers and does not require the trust of any central authority. This system therefore changes the rules of the game for online advertising. Participation can appeal to users who may currently find themselves blocking ads as their only option to avoid fraud. Performing ad matching locally in the user's attention application, using only ad-matching inputs that the user is authorized to use, avoids interaction with web trackers running malicious ad networks. Publishers and end users alike are compensated for attention spent on sponsored ads and for the inclusion of ads on websites by splitting the advertising revenue pie among themselves, instead of taking almost nothing if they are involved in a centralized ad network. Sponsored ad advertisers can have cryptographic assurance that their ads were legitimately viewed by users in their target demographic or consumer group, and can recoup advertising budgets for campaigns that did not reach the target number of members in their target demographic or consumer group. Thus, the system is an improvement to the field of digital online advertising.

[0083] A new scheme for encrypted vectors representing ad policies and user interactions with ads uses the principles of additive homomorphic encryption. The encryption functions used by the scheme include at least three specific encryption functions based on public and private key pairs of the type understood by users of asymmetric or public key encryption. The key pairs are generated based on an input source of sufficient entropy to essentially guarantee that the generator holds only one copy of the private key associated with the public key, since it is computationally infeasible for an attacker to independently guess or brute force the private key. The first of the three functions is an encryption function that, given a public key and a message, outputs a ciphertext, C = Enc(pk,M). The second is a decryption function that, given a ciphertext and a private key, outputs a decrypted message, M = DEC(sk,C). The third is a signing function that, given a message and a private key, outputs a signature on the message, S = Sign(sk,M). Additive homomorphism is special because it guarantees that the addition of two ciphertexts, C1 = Enc(pk,M1) and C2 = Enc(pk,M2), encrypted under the same key is the addition of the encryption of that message: in other words, C1 + C2 = Enc(pk,M1 + M2).

[0084] Other cryptographic methods and blockchain concepts that may be used in the systems disclosed herein are familiar to those skilled in the art. These include zero-knowledge proofs, distributed key generation (DKG), and the use of sidechains. Zero-knowledge proofs allow a prover to prove to another participant (e.g., a verifier) ​​that a particular statement is true via a private input without disclosing any other information from that input other than whether the particular statement is true. Zero-knowledge proofs allow advertisers to accept cryptographic proof that a target user viewed an advertisement without revealing the user's identity or the user's click. DKGs allow a group of participants to decentralize the generation of public and private key pairs, a process typically performed by a single participant. Essentially, DKGs "shard" the private keys so that each participant in a generation shares a private key, but no participant gains full private key knowledge. In some cases, the private keys may be sharded such that only a subset of shard holders need to join their shards together to create enough private keys to utilize the three additive homomorphic encryption functions disclosed above. DKGs are used in the system disclosed herein to generate public and private key pairs for each advertising campaign, where sensitive information is encrypted. Therefore, DKG schemes are more secure than leaving sensitive information and digital blockchain assets under a single key, which is more likely to be lost or damaged. Sidechains are a scaling solution for blockchains; they have greater capacity, expected lower fees, or other operational parameters that allow for the volume of transactions the system requires. Sidechains can periodically revert to the main blockchain, which has greater security. One type of sidechain that can be used is a proof-of-authority chain, where validators of the chain's consensus rules are selected from a semi-trusted group that may include a portion of the participants in the advertising system, rather than relying on computationally expensive consensus mechanisms such as proof-of-work or more complex systems that rely on fair distribution of coins such as proof-of-stake.

[0085] Figure 8 is a diagram of an exemplary alternative implementation 800 of an end user 802 submitting an encrypted interaction vector 806 to an ad policy smart contract 808 for computing an encrypted tally and sharing the encrypted tally with an escrow fund smart contract 814, which distributes viewer rewards 816, campaign manager fees 818, and refunds to advertisers 824, respectively, according to some embodiments. The system 800 is compatible with the alternative implementation described with reference to Figure 7, and lacks some elements of other implementations, such as BBA. There may also be drawbacks to the alternative implementation, such as uneconomical on-chain operations if the blockchain has high transaction costs.

[0086] When a user 802 views a campaign ad on the Attention Application 804, the Attention Application 804 creates a cryptographic proof to prove it. The Attention Application 804 creates a temporary cryptographic public and private key pair (PK, SK) and obtains a public threshold key generated by a consensus pool. Using these two keys, the Attention Application 804 encrypts an ad interaction vector (e.g., impressions subject to the ad policy governing the campaign ad) representing the user's 802 attention to the campaign ad to generate two ciphertexts: (1) an EncVec used to claim ad rewards, and (2) an EncVec used to notify the advertiser 824. The EncVec is sent from the Attention Application 804 to the Ad Policy Smart Contract 808 in operation 806.

[0087] The interaction vectors from many users are then aggregated into an encrypted tally. Unlike systems that rely on a centralized authority, in system 800, the encrypted tally is calculated by the Ad Policy smart contract 808 running on a side chain 810. As with other examples, the choice of side chain 810 can vary from the main blockchain depending on the chain's relevant parameters (e.g., cost, scaling, throughput, speed, etc.). In one embodiment, the Attention Application 804 invokes a public endpoint on the Ad Policy smart contract 808 and sends both ciphertexts, EncVec and EncVec'. To calculate the encrypted sum of rewards, the user can have a validator on the side chain 810 execute the Ad Policy smart contract 808 as follows: (1) decrypt each policy vector P[i] using Enc(S), (2) apply the additive homomorphism of the underlying encryption scheme to the EncVec ciphertext, and (3) store the result (e.g., Aggr.Res) in the public store of the advertising policy smart contract 808.

[0088] In operation 812, the user 802 may request payment corresponding to the interaction vector in the encrypted tally via the attention application 804. The attention application 804 generates a payment request that is published to the ad policy smart contract 808, containing all the information necessary to receive those advertising rewards. In one embodiment, the attention application 804 creates a temporary blockchain account that is used only once per request, then fetches the encrypted tally, decrypts the encrypted tally to obtain the decrypted reward, and then generates a proof of successful decryption. In this manner, the attention application 804 generates a payment request consisting of the following four tuples: L = [decrypted tally, encrypted tally, signing reward, proof of correct decryption]

[0089] The attention application 804 then encrypts L with the public key of the campaign facilitator 820 to obtain EncL= The attention application 804 then calculates a digest of the payment request by hashing L (e.g., using a SHA-256 hash function). The resulting digest is used as the commitment value of EncL in case the campaign facilitator 820 cheats.

[0090] A valid payment request therefore consists of the following tuple: ε=[EncL,C], where C is the digest of the payment request.

[0091] Finally, the Attention Application 804 invokes the public endpoint of the Ad Policy smart contract 808 with ε as input. The Ad Policy smart contract 808 stores all payment requests in its public store area of ​​the payment buffer until the Escrow Fund smart contract 814 clears them as paid by paying out the blockchain digital asset funds. Settlements by the Escrow Fund smart contract 814 are made in a confidential manner to protect the privacy of the system. For the purposes of this disclosure, a confidential transaction in cryptocurrency or blockchain digital assets means a transaction in which the amount of the coin transaction is hidden.

[0092] To achieve confidential transactional payment of payment requests, the campaign facilitator 802 fetches all payment requests from the ad policy smart contract 808, decrypts all entries, and calculates the total amount of funds needed to settle all pending payments. The campaign facilitator 802 then invokes a public function of the escrow fund smart contract 814 to request that a given amount of blockchain digital assets needed to cover the payment be transferred to an operational account owned by the campaign facilitator 802. If the campaign facilitator 802 behaves fraudulently (e.g., by requesting an incorrect amount of blockchain digital assets), such fraudulent behavior will be detected by advertisers or users who can prove the fraudulent behavior.

[0093] The campaign facilitator 802 then settles each pending reward payment by first verifying the correct decryption proof and then using a confidential payment scheme. After correctly finalizing the payment, if there are no disputes or complaints from the user or advertiser, the campaign facilitator 802 receives a processing fee from the escrow fund smart contract 814 at 818. If there are any unused contributed funds, the advertiser 824 wishes to be refunded. To process the refund, the escrow fund smart contract 814 utilizes the total number of clicks per ad vector calculated by the consensus pool during the advertiser's announcement. Based on this vector and the agreed-upon reward, the escrow fund smart contract 814 proceeds by returning the unused funds to the advertiser.

[0094] 9 is a flowchart of a workflow for establishing encrypted communication between an attention application terminal and a parent computing terminal with an attention accumulator (BBA), according to some embodiments. Operation 902 requests a signature for the BBA from the parent computing terminal. At initialization, the BBA contains a null ad interaction vector because the user of the attention application has not yet interacted with any ads. Under this architecture, only the parent computing terminal may update the BBA, so the initialized BBA is signed with a private key owned by the parent. Therefore, any future updates to the BBA should only be generated with a signature by the same private key. Operation 902 is the only time the parent computing terminal can determine which ads the user has interacted with (zero). The request in operation 902 also includes a source of randomness provided by the attention application computing system.

[0095] A receive operation 904 receives the signature for the BBA and stores the signature, the BBA, and a source of randomness for future operations. A detect operation 906 detects user interaction with a matched advertisement from the advertisement catalog and provides a notification that increments an advertisement interaction counter based on the user interaction and updates the advertisement interaction vector. Because only the issuing parent computing system can update portions of the BBA, the attention application cannot directly update the advertisement interaction vector. Therefore, the notification is used to attach to requests to the parent computing system and update the BBA accordingly. The parent computing system may check the notification for fraudulent requirements (e.g., reject the notification if it claims too many advertisement interactions over a period of time, if the notification comes from a known fraudulent attention application, etc.). If the notification is accepted by the parent computing system, it can be updated accordingly and a new BBA signed.

[0096] A sending operation 908 sends the notification and the randomized BBA to the parent terminal. Randomizing the BBA breaks the link between the randomized BBA and the BBA's previous and future show events. Therefore, the parent computing system cannot track the user's ad interactions because it only knows the ad interactions included in the notification and cannot decrypt what ad interactions are included in the BBA. A receiving operation 910 receives the updated BBA signed with the parent private key.

[0097] A request operation 912 requests a reward based on the ad interaction vector and calculates a proof of correctness therefor. The parent computing system or any other participant or observer in the system can verify the proof of correctness to know whether the requested reward is appropriate based on the ad interaction vector and the ad policy vector, without knowing the ads the attention application user interacted with. The request may be made to a public blockchain where interested parties can look up the reward for independent computation. In embodiments, the public blockchain itself can execute smart contract code that performs the verification computation, so that observers only need to check their copy of the blockchain to know whether the reward is accurate. Thus, observers can know whether the protocol is operating correctly across many users simply by checking their copy of the public blockchain.

[0098] FIG. 10 is a diagram of a system 1000 that may be useful in implementing distributed privacy-preserving rewards using encrypted black-box accumulators. FIG. 10 shows an example system (labeled as processing system 1000) that may be useful in implementing the described techniques. The processing system 1000 may be a client device, such as a smart device, a connected device, an Internet of Things (IoT) device, a laptop, a mobile device, a desktop, a tablet, or a server / cloud device. The processing system 1000 includes one or more processors 1002 and memory 1004. The memory 1004 generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 1010 resides in the memory 1004 and is executed by the processor 1002.

[0099] Modules or segments of one or more application programs 1012, such as a cryptographic operation module 1044 and an attention application 1046, are loaded into memory 1004 and / or storage 1020 and executed by processor 1002. In some implementations, cryptographic operation module 1044 is stored in read-only memory (ROM) 1014 or write-once, read-many (WORM) memory. Data, such as external event data sources, may be stored in memory 1004 or storage 1020 and may be retrievable by processor 1002 for use by, for example, oracle manager 1044 and attention application 1046. Storage 1020 may be local to processing system 1000 or remote, may be communicatively connected to processing system 1000, or may comprise another server. Storage 1020 may store resources requestable by a client device (not shown). Storage 1020 may include secure storage such as one or more platform configuration registers (PCRs) managed by one or more trusted platform modules (TPMs), which may be implemented within the chip or by a trusted execution environment (TEE).

[0100] The processing system 1000 includes a power supply 1016 that is powered by one or more batteries or other power sources and provides power to the other components of the processing system 1000. The power supply 1016 may be connected to an external power source that overrides or recharges the internal battery or other power source.

[0101] Processing system 1000 may include one or more communications transceivers 1030, which may be connected to one or more antennas 1032, to provide network connectivity (e.g., via a mobile telephone network, Wi-Fi, Bluetooth, etc.) to one or more other servers and / or client devices (e.g., mobile devices, desktop computers, or laptop computers). Processing system 1000 may also include a network adapter 1036, which is a type of communications device. Processing system 1000 may use network adapter 1036 and any other type of communications device to establish connections over a wide area network (WAN) or a local area network (LAN). It should be understood that the network connections shown are exemplary, and that other communications devices and means for establishing communications links between processing system 1000 and other devices may be used.

[0102] The processing system 1000 may include one or more input devices 1034 to allow a user to input commands and information (e.g., a keyboard or mouse). The input devices 1034 may further include other types of input, such as multimodal input, voice input, graffiti input, motion detection, facial recognition, physical fingerprints, etc. These and other input devices may be coupled to the server by one or more interfaces 1038, such as a serial port interface, a parallel port, a universal serial bus (USB), etc. The processing system 1000 may further include a display 1022, such as a touchscreen display.

[0103] Processing system 1000 may include a variety of tangible processor-readable storage media and intangible processor-readable communication signals, including virtual and / or cloud computing environments. Tangible processor-readable storage may be embodied by any available medium that can be accessed by processing system 1000, including both volatile and nonvolatile storage media, removable and non-removable storage media. Tangible processor-readable storage media excludes intangible communication signals and includes volatile and nonvolatile, removable and non-removable storage media implemented in any method or technology for storage of information such as processor-readable instructions, data structures, program modules, or other data. Tangible processor-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium used to store desired information and that can be accessed by processing system 900. In contrast to tangible processor-readable storage media, intangible processor-readable communication signals may embody computer-readable instructions, data structures, program modules, or other data residing in a modulated data signal such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, intangible communication signals include signals that travel through wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0104] Benefits, advantages, solutions to problems, and any elements that may cause or make more noticeable any benefit, advantage, or solution should not be construed as critical, necessary, or essential features or elements of any or all claims. The present invention is defined solely by the appended claims, including any modifications made during the filing of this application, and all equivalents of those claims as issued.

[0105] The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Moreover, in the foregoing Detailed Description, it will be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as separately claimed subject matter.

[0006] Embodiments disclosed herein include a method for establishing encrypted communication between an attention application terminal and a parent terminal using a black-box accumulator (BBA) in an attention reward architecture, the method comprising: receiving, at the attention application terminal, an advertisement (ad) catalog with N advertisements; and receiving an advertisement policy vector (P) of length N, where each index in the advertisement policy vector corresponds to an advertisement in the catalog and represents a reward value for interaction with the corresponding advertisement at the attention application terminal; and requesting a signed BBA tuple from the parent terminal, the method comprising:

number

number

number

number

number

number

[0106] An embodiment of any of the preceding embodiments may further comprise: a new BBA tuple and signature owned by the attention application terminal, represented by:

number

number

number

[0107] An embodiment of any of the preceding embodiments includes, at the attention application, receiving a reward based on proof of accuracy of the outstanding reward and zeroing an advertisement interaction counter.

[0108] An embodiment of any of the preceding embodiments includes sending the communication from the attention application terminal to the parent terminal through an anonymous channel.

[0109] An embodiment according to any of the preceding embodiments includes the operation of transmitting the BBA tuple τ, the randomized BBA tuple τ′, and the new BBA tuple from the attention application terminal through a broadcast encryption terminal.

[0110] An embodiment of any of the preceding embodiments includes the operation of sending the BBA tuple τ and the request for the reward based on the proof of the unpaid reward being committed to a public blockchain by the attention application terminal.

[0111] An embodiment of any of the preceding embodiments includes a smart contract equipped to verify the calculation of a proof of unpaid reward committed to the public blockchain, and recording the verification to the blockchain if the proof of unpaid reward is correct.

[0112] In an embodiment disclosed herein, a distributed system for establishing cryptographic communications using a black-box accumulator (BBA) in an attention reward architecture comprises a computer network communications interface, a memory storing instructions, and a processor, which, when executing the instructions, causes the processor to request an initialized BBA from a parent computing system, receive the initialized and signed BBA from the parent computing system, record ad interactions with a user of the attention application computing system along with displayed ads from an ad catalog to yield an ad interaction counter, randomize the BBA to yield a randomized BBA, send the randomized BBA and a notification requesting an update of the randomized BBA according to the ad interaction counter, receive a signed and updated BBA according to the notification requesting an update of the randomized BBA, generate a reward proof based on the signed and updated BBA and an ad policy vector, and commit the reward proof to a public blockchain based on the signed and updated BBA.

[0113] In an embodiment of any of the preceding embodiments, the act of committing the reward proof to the public blockchain based on the signed and updated BBA includes indirectly committing the reward proof by sending the reward proof to a parent computing system.

[0114] An embodiment of any of the preceding embodiments includes wherein communication between the attention application and the parent computing system occurs according to an anonymous channel.

[0115] An embodiment of any of the preceding embodiments includes a smart contract equipped to verify the calculation of a proof of unpaid reward committed to the public blockchain, and recording the verification to the blockchain if the proof of unpaid reward is correct.

[0116] An embodiment of any of the preceding embodiments includes that communication between the attention application and the parent computing system occurs according to a broadcast encrypted channel, and only qualified advertisers can read the communication under a distributed keying configuration.

Claims

1. 1. A method for establishing encrypted communication between an attention application terminal and a parent terminal using a black box accumulator (BBA) in an attention reward architecture, comprising: receiving an advertisement catalog with N advertisements at the attention application terminal, where N corresponds to a quantity of the advertisement catalog; receiving an advertising policy vector (P) of length N, wherein each index in the advertising policy vector corresponds to an advertisement in the advertising catalog and represents a reward value for interaction with the advertisement at the attention application terminal; Sending a signed BBA tuple initialization request to the parent terminal, requesting a counter using a source of randomness provided by the attention application terminal, the counter being initialized to zero, the initialization request including a request for a first signature via the BBA tuple; receiving the first signature from the parent terminal; storing, at the attention application terminal, the first signature σ, the BBA tuple τ, and the source of randomness used in the initialization request; matching advertisements from the advertisement catalog with users of the attention application terminal; displaying the matched advertisement to the user at the attention application terminal; Detecting, at the attention application terminal, a user interaction with the matched advertisement; repeatedly and automatically incrementing an advertisement interaction counter based on the detected user interactions to provide notifications requesting updates to an advertisement interaction vector; randomizing the BBA tuple τ to generate a randomized BBA tuple; sending the randomized BBA tuple τ′ to the parent terminal along with the notification requesting the update to the advertising interaction vector; receiving a second signature from the parent terminal via a new BBA tuple; upon receiving the second signature via the new BBA tuple, storing an updated randomization in the attention application terminal; and verifying that the new BBA tuple is an accurate reflection of the advertisement interaction state requested in the notification requesting an update of the advertisement interaction vector.

2. At the attention application terminal, derandomizing the new BBA tuple to provide proof of accuracy of the accrued reward; disclosing the BBA's identifier; calculating a dot product between the ad interaction vector and the ad policy vector; Proving that all counter additions do not exceed the limits set by the parent terminal; and 10. The method of claim 1, further comprising: generating a zero-knowledge proof of correctness and transmitting the proof of correctness to the parent terminal, thereby generating a request for a reward based on the proof of the outstanding reward.

3. receiving, at the attention application terminal, a reward based on the verification of accuracy of the outstanding reward; and zeroing the advertisement interaction counter.

4. The method of claim 1, wherein sending the initialization request includes sending the initialization request through an anonymous channel.

5. The method of claim 1, wherein transmitting the randomized BBA tuple includes transmitting the randomized BBA tuple from the attention application terminal through a broadcast encryption terminal.

6. 2. The method of claim 1, further comprising: committing the BBA tuple τ and the request for a reward to a public blockchain by the attention application terminal based on proof of an outstanding reward.

7. 7. The method of claim 6, wherein the public blockchain includes a smart contract equipped to verify the computation of a proof of accrued rewards committed to the public blockchain, and if the proof of accrued rewards is correct, record the verification on the public blockchain.

8. 1. A distributed system for establishing cryptographic communications using a black-box accumulator (BBA) in an attention reward architecture, the distributed system comprising: An attention application computing system including a computer network communications interface, a memory storing instructions, and a processor, the instructions, when executed, causing the processor to: Requesting an initialized BBA from a parent computing system; receiving an initialized and signed BBA from the parent computing system; recording advertisement interactions with users of the attention application computing system along with advertisements displayed from an advertisement catalog to provide an advertisement interaction counter; randomizing the BBA to provide a randomized BBA; sending the randomized BBA and a notification requesting an update of the randomized BBA according to the advertisement interaction counter; receiving a signed, updated BBA in accordance with the notification requesting an update of the randomized BBA; generating a reward certificate based on the signature and the updated BBA and advertising policy vector; and committing the reward proof to a public blockchain based on the signature and the updated BBA.

9. The system of claim 8, wherein to commit the reward proof, the instructions are executed by the processor to send the reward proof to the guardian computing system, causing the reward proof to be committed to the public blockchain.

10. The system of claim 8 , wherein communication between the attention application computing system and the parent computing system occurs according to an anonymous channel.

11. 10. The system of claim 8, wherein the public blockchain includes a smart contract equipped to verify the computation of a proof of accrued rewards committed to the public blockchain, and record a verification to the public blockchain if the proof of accrued rewards is correct.

12. 9. The system of claim 8, wherein communications between the attention application computing system and the parent computing system are conducted according to a broadcast encrypted channel, and only qualified advertisers can read the communications under a distributed keying arrangement.

13. 1. A distributed system for establishing cryptographic communications using a black-box accumulator (BBA) in an attention reward architecture, the distributed system comprising: a computer network communications interface; a memory for storing instructions; and a processor, the processor, when executing the instructions, causing the processor to: receiving a request for initialization of the BBA from the attention application computing system; Initialize and sign a BBA with a null advertising interaction vector with a private key; Sending the BBA to the attention application computing system; receiving a notification requesting an update of the randomized BBA according to the randomized BBA and an advertisement interaction counter on the attention application computing system; applying a state update to the randomized BBA and signing the randomized BBA with a private key to result in an updated and signed randomized BBA; sending the updated and signed randomized BBA to the Attention Application Computing System; Retrieving a public blockchain copy of the reward payment request and proof of accuracy of the updated and signed randomized BBA reward; determining whether the proof of accuracy of the updated signed randomized BBA reward is valid; If the updated and signed randomized BBA is valid, the distributed system broadcasts a blockchain transaction that sends a reward to the attention application computing system.

14. The system described in claim 13, wherein the instructions are executed by the processor to receive the request for the initialization BBA, and the request for the initialization BBA is received through an anonymous channel.

15. The system of claim 13 , wherein communication with the attention application computing system occurs according to a broadcast encrypted channel.

16. 14. The system of claim 13, wherein the public blockchain includes a smart contract equipped to verify the computation of a proof of accrued rewards committed to the public blockchain, and record a verification to the public blockchain if the proof of accrued rewards is correct.

Images