Systems and methods for secure and compensated identification tokens

Abstract

Systems and methods for secure and revocable identification, e.g., by using revocable secure identification tokens. The systems and methods include opting into an identification service, issuing a secure token, installing a browser extension or a software development kit (SDK), intercepting and automatically completing a consent dialog of an application, receiving an advertisement, accruing credit to the consumer user based on viewing the advertisement, revoking, by the consumer user, the secure token, and reissuing another secure token to replace the revoked secure token. The revocation eliminates any connection between the revoked secure token and the consumer user. The reissuing creates a connection between the consumer user and the identification service.

Description

SYSTEMS AND METHODS FOR SECURE AND COMPENSATED IDENTIFICATIONTOKENSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application Serial Number 63 / 537,665, filed September 11, 2023, the entirety of which is incorporated herein for all purposes. BACKGROUND

[0002] Conventional techniques for tracking user access to network resources, including those in common use to support online advertising, involve the use of pseudonymous, static identifiers, commonly referred to as cookies or advertising IDs. There are many implementations of these IDs which may include device issued IDs (iOS Ad ID or Android ID for Advertising), heuristic fingerprinting or probabilistic IDs that use or combine multiple device attributes to create a likely unique individual device identifier, client IP addresses, and locally stored objects for identifying a unique device. These identifiers allow various services to monitor and track the activities of a given consumer or device. Some advantages of these identifiers are that, when they accompany records of actions, observations, or events, they enable effective correlation of what would otherwise appear to be a series of independent and unconnected events. A record of actions, events, or observations can be reliably split into a set of sub-series, each of which contains entries having the same identifier and therefore presumed to represent the actions, events, or observations from a single consumer or device (“tracking by consumer”). Tracking by consumer allows for more targeted advertising, improved measurement, frequency-capping of ads, and ease of use of websites, among other things.

[0003] More particularly, historical techniques for tracking users across multiple network resources including web-sites, mobile applications, progressive web applications, and embedded browsers involve the use of pseudonymous identifiers associated with a given consumer or device. These identifiers can be local to a given network resource (e.g., 1st party) or linked across network resources (e.g., 3rd party) through graphs of IDs (“3rd party identity graphs”) representing the many IDs assigned to the same consumer or device by each independent ID issuer - who share with each other, often in a pair-wise manner, the IDs they assigned. These 3rd party identity graphs may use a single form of an ID or associated multiple forms of IDs including 1st party cookies, 3rd party cookies, heuristic aggregations of network device attributes (i.e., what is commonlyreferred to as fingerprinting), hashed email addresses or other unique IDs. These 3rd party identity graphs are then used across network resources, e.g., in order to identify and track consumer behaviors and perform online activities, etc.. Some behaviors may include identifying consumers interests, measuring the effectiveness of advertising or commercial offers, targeting advertising or commercial offers, optimizing consumer experiences and measuring the effectiveness of advertising or consumer experiences.

[0004] Cookies and Advertising IDs have numerous disadvantages, including privacy and security concerns. For example, 3rd party cookies or advertising IDs may be used by interlopers to monitor user behavior for nefarious use. In addition, some forms of user identifiers are implemented without users understanding they are being created or not under the direct control of the user, so that their benefits do not necessarily accrue to the user.

[0005] The most common form of use of 3rd party cookies or advertising IDs is when the network device allows for the creation of or directly provides an ID that is accessible by a service running on top of a network device. Such implementations were ubiquitous but are now being deprecated, forcing the development of alternatives. Unfortunately, the alternatives that have been developed, including 3rd party heuristic IDs, email address hashing or other back-end identity services (client IP address use or others), are obfuscated from consumers. Consumers are not aware of these practices and are therefore unable to manage or control them.

[0006] A need exists for alternatives to cookies that are beneficial for users, support desired advertiser and advertiser supply ecosystem capabilities (“advertising use cases”), and overcome one or more of the shortcomings noted above.BRIEF SUMMARY

[0007] Therefore, in one embodiment, a method / system / device for systems and methods for secure and compensated identification, e.g., by using revocable, secure identification tokens that compensate users, is presented. By way of example, in one embodiment, the method includes a consumer opting into an identification service, the identification service issuing a secure token used to pseudonymously identify the consumer across network devices. In one example, the method includes installing a browser extension. In another example, the method includes using a software development kit (SDK), such as one that is suitable for embedding in another application or mobile app. In a further example, the method includes intercepting and automaticallycompleting a user prompt / dialog of an application. In another specific implementation, the method includes allowing a 3rd party advertising service to receive the secure token. In such cases, the method may include receiving an advertisement on the network device, accruing credit to the consumer user based on the value of the advertisement, paying out the credit to the consumer via direct or indirect means, revoking, by the consumer user, the secure token, and reissuing another secure token to replace the revoked secure token. For instance, the revocation eliminates any connection between the revoked secure token and the consumer user’s future observable actions. Such actions can then be associated with the new token. And the reissuing creates a new connection between the consumer user and those other parties who may be authorized by the identification service to observe the token along with observable events, including those relevant to advertising, tracking, targeting, and measuring. In such a case, changing the token (e.g., resetting it) does not change the nature of identity between the consumer and the identity service, but rather changes the identity that third-parties, using the identity, can observe. The reset breaks the link between the consumer's future actions and their past actions, because the new actions will only be observable in association with the new ID. The old ID will not be observable again.

[0008] In another embodiment, a system is presented that comprises the consumer device, a centralized server, and an advertising server. The system implements the method noted above.

[0009] Technological advantages of the presented technique include direct consumer control over the provision of said token, replication of the token onto the consumer’s multiple devices where it can then be provided to third parties under consumer control (if they access the network through more than one device), security and efficiency of authentication of the user and allowing the user to accrue credit for allowing 3rd party usage of the token. For instance, when compared to conventional authentication techniques, the present technique is more efficient due to the reduced use of system resources when a secure token is issued in advance by the system. In addition, authorized parties attempting to unify observations obtained from monitoring the user’s actions taken via their different devices have a greatly simplified task of doing so, as all actions observable when the same token is available can be easily unified under that token. By contrast, conventional solutions must employ lossy and error-prone techniques for resolving different IDs presented via different devices.

[0010] The above embodiments are exemplary only. Other embodiments as described herein are within the scope of the disclosed subject matter.BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0011] So that the manner in which the features of the disclosure can be understood, a detailed description may be had by reference to certain embodiments, some of which are illustrated in the accompanying drawings. It is to be noted, however, that the drawings illustrate only certain embodiments and are therefore not to be considered limiting of its scope, for the scope of the disclosed subject matter encompasses other embodiments as well. The drawings are not necessarily to scale, emphasis generally being placed upon illustrating the features of certain embodiments. In the drawings, like numerals are used to indicate like parts throughout the various views, in which:

[0012] FIGS. 1 A-1F are flowcharts of a service for secure and revocable identification tokens, in accordance with one or more aspects set forth herein;

[0013] FIGS. 2A-2C depict a consumer user opting into a service as described in FIGS. 1A- 1F, in accordance with one or more aspects set forth herein;

[0014] FIG. 2D depicts activation of a software development kit (SDK) and issuance of a pseudonymous identifier on behalf of the user of FIGS. 2A-2C, in accordance with one or more aspects set forth herein;

[0015] FIG. 2E depicts the addition of a browser extension to the browser of FIG. 2C, in accordance with one or more aspects set forth herein;

[0016] FIG. 2F depicts automatic completion of a consent dialog in an application by the service activated in FIG. 2D, in accordance with one or more aspects set forth herein;

[0017] FIG. 2G depicts an advertisement call in the application depicted in FIG. 2F, in accordance with one or more aspects set forth herein;

[0018] FIG. 2H depicts provisioning of the pseudonymous identifier in the application of FIG. 2G, in accordance with one or more aspects set forth herein;

[0019] FIG. 21 depicts conversion tracking by the service of FIGS. 1 A-1B, in accordance with one or more aspects set forth herein;

[0020] FIG. 2J depicts the process of FIGS. 2F-2I occurring in a browser extension, in accordance with one or more aspects set forth herein; and

[0021] FIGS. 2K-2N depict consumer management of the service of FIGS. 1A-1B, in accordance with one or more aspects set forth herein.

[0022] Corresponding reference characters indicate corresponding parts throughout several views. The examples set out herein illustrate several embodiments, but should not be construed as limiting in scope in any manner.DETAILED DESCRIPTION

[0023] The present disclosure relates to systems and methods for secure, compensated and revocable identification, e.g. by using revocable secure identification tokens. Advantageously, the systems and methods are under the control and direction of the consumer, so that the consumer may knowingly agree to the terms and conditions thereof. As noted above, conventional techniques make use of 3rd party identity graphs which are hidden from the consumer, provide only secondary benefits, and are not centrally manageable by consumers. By contrast, the present technique embeds code into web browsers and mobile device applications, using either browser extensions or software development kits and application programming interfaces, that allows coordination of a centralized identity service across consumer devices. Through this coordination, pseudonymous unique identification tokens may be issued and revoked as needed to achieve the goals of tracking consumer usage of advertising, compensating users for the use of their identity token, centralizing consumer control over the usage of their identity token, and avoiding the ability for the token to be permanently traceable back to the consumer user.

[0024] Conventional systems have many deficiencies. For instance, in conventional systems, users are plagued with consent dialogs, and the consumer gets no direct benefit, leading to consumer dissatisfaction, disenfranchisement, and fear. In addition, conventional ad technologies are now subject to regulations and scrutiny, and some may not meet emerging privacy regulations in Europe, Asia and the Americas.

[0025] The present technique offers numerous consumer benefits. For instance, consumers may opt-into the system and receive compensation for use of their identity token. This can lead to increased willingness to allow the use of their identity as well as increased loyalty through services that allow for the disbursement of the “cash back” accrued from the use of this identity. At the same time, the present technique offers a secure and technological solution to the 3rdparty cookie problems noted above, while preserving the use of a token. By directing that their ID be changed,consumers can obtain a fresh (previously unseen and un-profiled) advertising identity. Various stakeholders gain numerous benefits from the present techniques. Consumers are able to take back agency over their identity, receive compensation for opt-in targeting, and reduce annoying consent popups. Consumers also gain increased transparency, including the ability to see the identities of participating advertisers or advertiser service providers, and are able to learn how many ads were purchased (for display to the consumer) and at what cost. Knowing the identity of these actors and when presented with shortcuts in the product user interface to link to such providers, consumers can take additional actions that such providers may offer. Advertising industry participants can use the secure tokens set forth herein in a manner analogous to conventional cookies, but receive more coverage for targeting and reporting. Financial institutions can now participate in the advertising business, and can increase customer loyalty through such programs that reward consumers.

[0026] FIGS. 1A-1G are flowchart of a service for secure and revocable identification tokens. For instance, FIG. 1A depicts the opt-in process. In one embodiment, the issuing app 101 at block 1 shows an offer to the user for the identity service. At block 2 the offer is accepted. At block 3 an SDK is activated. At block 4, server 103 creates the ID token. At block 5, the server 103 returns the token to the app. Note that all calls to the server described herein may be synchronous or asynchronous server calls.

[0027] Next, with respect to the example of FIG. IB, the content app 102 at block 5 makes an ad call using the SDK, leading to an SDK interaction between the issuing app 101 and server 103 to validate the usage state of the consumer identity (via synchronous or asynchronous call) and via the content app 102 to provide the ID. At block 17, the server 103 validates the usage state of the client. Continuing, the content app 102 at block 7 initiates an ad call with the ID. Next, at block 8 the ad is displayed, and spend is recorded at block 9. The spend amount may be reported immediately to the server 103, or communicated after some delay. The server 103 at block 10 reports the spend to the payment service 104 at block 11. Subsequently, the payment service 104 at block 12 aggregates the spend and issues payment once funds are received or an alternate payment trigger state is met.

[0028] A browser based example of ID provisioning, use and payment is depicted in FIG. 1C. For instance, a browser toolbar 105 interacts with a browser 106. The browser 106 at block 5makes an ad call using the SDK, leading to an SDK interaction between the browser toolbar 105 and server 103 via the browser 106. At block 17, the server 103 synchronously or asynchronously validates the usage state (e.g., is the ID active or revoked, is the ad tech provider provisioned or revoked) of the client. Continuing, the browser 106 at block 7 initiates an ad call with the ID. Next, at block 8 the ad is displayed, and spend is recorded at block 9. The server 103 at block 10 reports the spend to the payment service 104 at block 11. Subsequently, the payment service 104 at block 12 aggregates spend and issues payment once funds are received or an alternative payment trigger state is met.

[0029] An ID management example is depicted in FIG. ID. For instance, the issuing app 101 at block 13 provides an access link to the user. This allows the server 103 at blocks 10, 14 to display a user interface (UI). At block 14, the UI allows id token management and at block 10 spend is reported to the user. Continuing, the payment service 104 at block 15 aggregates spend and issues payment at block 16.

[0030] An ID provisioning example is depicted in FIG. IE. For instance, the content app 102 at block 5 makes an ad call using the SDK, leading to an SDK interaction between the issuing app 101 and server 103 via the content app 102. At block 17, the server 103 synchronously or asynchronously validates the usage state of the client. At block 6 the ID is retrieved via the SDK. Continuing, the content app 102 at block 7 initiates an ad call with the ID.

[0031] An ID use example is depicted in FIG. IF. For instance, the content app 102 at block 7 initiates an ad call with the ID, at block 8 the ad is displayed, and spend is recorded at block 9. The server 103 at block 10 records the spend.

[0032] A payment example is depicted in FIG. 1G. After spend is recorded by the server 103 at block 10, the payment service 104 at block 15 aggregates spend and issues payment at block 16.

[0033] By way of explanation, FIGS. 2A-2N, depict further details of the operations of the system and method depicted and described with respect to FIGS. 1A-1G, as demonstrated in the various user interfaces.

[0034] FIGS. 2A-2C depict a consumer user opting into a service as described in FIGS. 1A- 1G. For instance, at user interface 200A a consumer may opt into the service. At user interface 200B or 200C, the consumer consents to such a service.

[0035] FIG. 2D depicts activation of a software development kit (SDK) and issuance of a pseudonymous identifier on behalf of the user of FIGS. 2A-2C. For instance at user interface 200D, for a mobile device based application, once the consumer is enrolled, an SDK is activated on the distributor’s (e.g., a bank) application. The application then calls the server and provisions a pseudonymous identifier, or secure token, on behalf of the consumer. Similarly, at user interface 200E of FIG. 2E, in another embodiment, the implementation of the service may take the form of a browser extension.

[0036] In one specific example, the identifier (ID) may be issued as follows. First, authorized parties, such as users, are provided with a means to securely obtain from the ID service operator a “secret” S. For example, secret S may be a cryptographically random number of 128 bits that varies by time ( / ). Time t, for example, could be the 64-bits representing the integer number of milliseconds since the UNIX epoch. In one implementation, new values are chosen for S after regular spans of time, such as once per day.

[0037] Continuing the example, next, a secure channel is established between an authorized party and the service operator using standard cryptographic practices. This channel is used for the purpose of exchanging values of S. In conjunction with access control, such a setup lets the service operator ensure only authorized parties have access to values of S, and that new values of S are unpredictable and that authorized parties must continue to be authorized in order to have access to future observations of a given consumer’s actions .

[0038] By design, pCMAIDs, which are computed with values of S as one of their input factors, are only usable by entities that can obtain the various values of S. Further, to encrypt the CMAID into the protected form, an additional random number (for example another 128 bit integer) is used. This additional random number, a cryptographic salt ‘s’, is shared and distributed along with the encrypted CMAID. Further, in this example, to produce the encrypted CMAID, a hash function that generates from input at least 128-bits of hash value is used. For example, a suitable hash function is the SHA-256 hash function. The chosen hash function is invoked on a concatenation of the bits of s and S, producing a hash of s and S denoted HsS. Thereafter, the 128 bits of the CMAID are transformed using the exclusive OR (XOR) operation and the left-most 128 bits of HsS. This resulting bit string is the encrypted CMAID, or eCMAID. Finally, the protected CMAID string (pCMAID) is then built by concatenating the literal string “ri-” (without the quotecharacters) with the base-64 representation of the concatenated bits of t, s, and eCMAID. The pCMAID is then shared via the API call.

[0039] To recover the true form of the CMAID, an authorized party first decodes the base-64 “transport armor” on the concatenated bits of t, s, and eCMAID. Then, the authorized party obtains (looks up, queries) from the identity service provider (identification service) the S for the time t which itself is obtained from the pCMAID. Then it generates HsS using the obtained S and s from the pCMAID. Finally, it performs the exclusive OR operation using the left-most 128 bits of HsS and eCMAID as operands. The result of this XOR operation is the CMAID in its true (unencrypted) form.

[0040] FIG. 2F depicts automatic completion of a consent dialog in an application by the service activated in FIG. 2D. For instance, user interface 200F shows that the consumer’s default preferences are passed into a typical consent dialog via an API by the service or distribution partner application (with an embedded SDK) once the service has been activated.

[0041] Subsequent to activation of the service, and as shown in FIG. 2G, user interface 200G depicts an advertisement call in the application. In such a call, service partners include the client side SDK in their ad tags or ad payloads. These are passed to the consumer device application, which then registers the ads and notifies the central server, which accrues benefits to the consumer user. The client side SDK may also be implemented by the content creator / distributor / app / site owner.

[0042] FIG. 2H depicts provisioning of the pseudonymous identifier in the application of FIG. 2G.

[0043] FIG. 21 depicts conversion tracking using the pseudonymous identifier. For example, this tracks how many clicks on ads presented to the consumer are converted to sales, in order to calculate compensation for the consumer or participants in the advertising value chain that were involved

[0044] FIG. 2J depicts the process of FIGS. 2F-2I occurring in a browser extension.

[0045] FIGS. 2K-2N depict consumer management of the service of FIGS. 1A-1B.

[0046] Generally stated, disclosed herein, are systems and methods for secure and revocable identification. For instance, the method includes: opting into an identification service by a consumer user; issuing a secure token affiliated with the identification service; passing, whenrequested, the identification token to an advertising service; receiving, at the network service (i.e., website, application, progressive web application or other digital consumer content consumption platform), an advertisement from an advertising service; and accruing credit to the consumer user based on using the identification token to select the advertisement.

[0047] In one embodiment, the method further includes reporting on the set of advertising services to which the identity token is provided, managing the set of advertising services to which the identity token is provided, viewing the payment accrued by the use of the identity token in aggregate and by advertising service with a centralized server, or through a user interface presented in mobile, web, or progressive web app user interfaces and communicated with a centralized server via API calls.

[0048] In another embodiment, the method further includes enabling revoking, by the consumer user, the secure token; and subsequently when requested by the consumer user, reissuing another secure token to replace the revoked secure token, wherein the revocation eliminates any historical connection between the revoked secure token and the consumer user. In a further example, the method further includes providing a consumer-facing user interface for managing consent preferences.

[0049] In one implementation, the method includes providing a consumer-facing user interface for managing revocation of the secure token. In another implementation, the method includes the use of an API to automatically configure “consent dialogs” using consumer determined consent preferences. For example, the identity token is provided via an SDK to SDK API. In a further example, the spend associated with the identity token by authorized users is tracked for the purposes of payment of the value accrued to the consumer user. In another example, the identity token is provided via a user installed toolbar or extension. In another embodiment, the consumer exercises the option to replace the secure identity token with a predetermined timespan.. This reidentification limit accompanies the token or can be obtained by reference with the token. The reidentification limit, when examined by participating advertisers or advertiser supply chain providers, is interpreted as the time before which no actions or information previously collected about the consumer (by way of any means, including a previously issued secure identification token) and their online behavior should be associated or used in conjunction with the newly created secure identity token.

Claims

CLAIMSWhat is claimed is:

1. A method for secure and revocable identification, the method comprising: opting into an identification service by a consumer user; issuing a secure token affiliated with the identification service; passing, when requested, the identification token to an advertising service; receiving an advertisement from an advertising service; and accruing credit to the consumer user based on using the identification token to select the advertisement.

2. The method of claim 1, further comprising reporting on the set of advertising services to which the identity token is provided, managing the set of advertising services to which the identity token is provided, viewing the payment accrued by the use of the identity token in aggregate and by advertising service with a centralized server, or through a user interface presented in mobile, web, or progressive web app user interfaces and communicated with a centralized server via API calls.

3. The method of claim 1, further comprising enabling revoking, by the consumer user, the secure token; and subsequently when requested by the consumer user, reissuing another secure token to replace the revoked secure token, wherein the revocation eliminates any historical connection between the revoked secure token and the consumer user.

4. The method of claim 1, further comprising providing a consumer-facing user interface for managing consent preferences.

5. The method of claim 3, further comprising providing a consumer-facing user interface for managing revocation of the secure token.

6. The method of claim 1, further comprising the use of an API to automatically configure consent dialogs using consumer determined consent preferences.

7. The method of claim 1 where the identity token is provided via an SDK to SDK API.

8. The method of claim 5 where the identity token is provided via an SDK to SDK API9. The method of claim 1 where the spend associated with the identity token by authorized users is tracked for the purposes of payment of the value accrued to the consumer user.

10. The method of claim 1 where the identity token is provided via a user installed toolbar or extension.

11. The method of claim 1 where the consumer exercises the option to replace the secure identity token with a predetermined timespan.

12. A method for secure and revocable identification, the method comprising: opting into an identification service by a consumer user; issuing a secure token affiliated with the identification service; passing, when requested, the identification token to an advertising service; receiving an advertisement from an advertising service; accruing credit to the consumer user based on using the identification token to select the advertisement; enabling revoking, by the consumer user, the secure token; and subsequently when requested by the consumer user, reissuing another secure token to replace the revoked secure token, wherein the revocation eliminates any historical connection between the revoked secure token and the consumer user.

Images