Patent Description:
In a computer networked environment such as the internet, users may interact with third-party content items. These third-party content items, for example, advertisements, can be displayed on a web page associated with a respective publisher. These user can provide information to a publisher indicating interaction with a third-party content item.

<CIT> describes a method, device, cloud computing system and computer system to implement authentication/authorization, applicable in a cloud computing system of a multi-tenant domain, for use in implementing authentication/authorization for invoking different service.

<CIT> describes the present invention presents a method and device that allow computing device to mutually authenticate themselves in the context of a previously agreed transaction, without requiring a connection to a network backend at the time of authentication.

<CIT> describes a computer-implemented method includes: receiving a request for associating a first index of privileges and permissions with an identity token, the first index specifically encoding the privileges and permissions of a first subscriber in accessing transactional data of the requester, the request including the identity token that identifies a person and has been issued to the requester by a trusted entity through a vetting process; in response to determining that the identity token is valid and verifying that the requester is the person identified by the identity token, associating the first index of privileges and permissions of the first subscriber with the identity token; and providing the identity token associated with the first index of privileges and permissions of the first subscriber, the identity token enabling the first subscriber to access transactional data of the requester in accordance with the first index of privileges and permissions.

One technical issue addressed by the present disclosure is the difficulty in determining the identity of online users while preserving the privacy of the online users. Additionally, third-party content item distributors may want to verify the identity of a user visiting the web page of a publisher within a short, predetermined time frame (e.g., <NUM> milliseconds). However, accurately verifying the identity of a user would require many queries to outside sources responsible for verifying the identity of a user. This imposes unacceptable latency for certain third-party content item distributor platforms.

The challenges addressed in the present disclosure relate to providing a system capable of distributed verification of identity of online users while minimizing the number of queries to third party verifiers, while maintaining the privacy of the users to only trusted third-party content item distributors. A public key is issued to only the trusted third-party content item distributors, who are able to decrypt token data that is digitally-signed by a trusted issuer to verify the token data of a user in real-time. This minimizes the number of queries the verifying parties must make to verify the token data, which reduces network overhead and verification time.

Cookie based identity support does not support authentication by an issuer, nor does it prevent copying browser sessions, also called a "replay attack. " As a result, a browser cookie is a label rather than a trustworthy identity of an online user. Similarly, on devices such as connected televisions, a device identifier provides only a weak layer of protection. No other parties can verify device authenticity on behalf of the OEM. Replay attacks, where a copy of a browser session is made to create fraudulent content item requests, cannot be detected in these cases, nor can verification of identity take place in real-time as required by many third-parties. Thus, the technical solution disclosed herein is a marked improvement over existing technologies of identity verification and fraud detection.

The invention to which this European patent application is directed is defined in the independent claims.

Following below are more detailed descriptions of various concepts related to, and implementations of, methods, apparatuses, and systems of managing fraud resistant content item operations. The various concepts introduced above and discussed in greater detail below may be implemented in any of numerous ways, as the described concepts are not limited to any particular manner of implementation.

<FIG> is a block diagram depicting one implementation of an environment <NUM> for distributed real-time verification of online identity. The environment <NUM> includes at least one client computing system <NUM>. The client computing system <NUM> can include at least one processor (or a processing circuit) and a memory. The memory stores processor-executable instructions that, when executed on the processor, cause the processor to perform one or more of the operations described herein. The processor can include a microprocessor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), etc., or combinations thereof. The memory can include, but is not limited to, electronic, optical, magnetic, or any other storage or transmission device capable of providing the processor with program instructions. The memory can further include a floppy disk, CD-ROM, DVD, magnetic disk, memory chip, ASIC, FPGA, read-only memory (ROM), random-access memory (RAM), electrically-erasable ROM (EEPROM), erasable-programmable ROM (EPROM), flash memory, optical media, or any other suitable memory from which the processor can read instructions. The instructions can include code from any suitable computer-programming language. The client computing system <NUM> can include one or more computing devices or servers that can perform various functions.

In some implementations, the client computing system <NUM> can include applications such as a web browser configured to generate browser tokens. In such embodiments, the generated browser token may be associated with the domain of an issuer computer system <NUM>, and contain information about the web browser executed by the client computing system <NUM>. In some implementations, the client computing system <NUM> is configured to generate device tokens. In such embodiments, the generated device token may be associated with the domain of the issuer computing system <NUM>, and may contain device information about the client computing system <NUM>. The client computing system <NUM> may be configured to transmit the generated tokens to the issuer computing system <NUM> via the network <NUM>. In some implementations, the client computing system <NUM> is configured to communicate with an advertising auction system via the content item network <NUM>.

The network <NUM> can include computer networks such as the internet, local, wide, metro or other area networks, intranets, satellite networks, other computer networks such as voice or data mobile phone communication networks, and combinations thereof. In some implementations, any of the key distribution infrastructure <NUM> or the content item network <NUM> may be the same as, or a part of, network <NUM>. The client computing system <NUM> of the environment <NUM> can communicate via the network <NUM>, for instance with at least one issuer computing system <NUM>. The network <NUM> may be any form of computer network that relays information between the client computing system <NUM> and the issuer computing system <NUM>, and one or more content sources, for example, web servers, advertising servers, amongst others. For example, the network <NUM> may include the Internet and/or other types of data networks, such as a local area network (LAN), a wide area network (WAN), a cellular network, satellite network, or other types of data networks. The network <NUM> can also include any number of computing devices (e.g., computer, servers, routers, network switches, etc.) that are configured to receive and/or transmit data within network <NUM>. The network <NUM> can further include any number of hardwired and/or wireless connections. For example, the client computing system <NUM> can communicate wirelessly (e.g., via WiFi, cellular, radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to other computing devices in network <NUM>.

The content item network <NUM> can include computer networks such as the internet, local, wide, metro or other area networks, intranets, satellite networks, other computer networks such as voice or data mobile phone communication networks, and combinations thereof. In some implementations, the content item network <NUM> may be the same as, or a part of, network <NUM>. The client computing system <NUM> of the environment <NUM> can communicate via the content item network <NUM>, for instance with at least one verifier computing system <NUM>. The content item network <NUM> may be any form of computer network that relays information between the client computing system <NUM> and at least one verifier computing system <NUM>, and one or more content sources, for example, web servers, advertising servers, amongst others. For example, the content item network <NUM> may include the Internet and/or other types of data networks, such as a local area network (LAN), a wide area network (WAN), a cellular network, satellite network, or other types of data networks. The content item network <NUM> can also include any number of computing devices (e.g., computer, servers, routers, network switches, etc.) that are configured to receive and/or transmit data within the content item network <NUM>. The content item network <NUM> can further include any number of hardwired and/or wireless connections. For example, the verifier computing system <NUM> can communicate wirelessly (e.g., via WiFi, cellular, radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to other computing devices in content item network <NUM>.

The key distribution infrastructure network <NUM> can include computer networks such as the internet, local, wide, metro or other area networks, intranets, satellite networks, other computer networks such as voice or data mobile phone communication networks, and combinations thereof. In some implementations, the key distribution infrastructure <NUM> may be the same as, or a part of, network <NUM>. The key manager computing system <NUM> of the environment <NUM> can communicate via the key distribution infrastructure network <NUM>, for instance with at least one issuer computing system <NUM> and/or at least one verifier computing system <NUM>. The key distribution infrastructure network <NUM> may be any form of computer network that relays information between the key manager computing system <NUM> and at least one verifier computing system <NUM> or at least one issuer computer system <NUM>, and one or more content sources, for example, web servers, advertising servers, amongst others. For example, the key distribution infrastructure network <NUM> may include the Internet and/or other types of data networks, such as a local area network (LAN), a wide area network (WAN), a cellular network, satellite network, or other types of data networks. The key distribution infrastructure network <NUM> can also include any number of computing devices (e.g., computer, servers, routers, network switches, etc.) that are configured to receive and/or transmit data within the key distribution infrastructure network <NUM>. The key distribution infrastructure network <NUM> can further include any number of hardwired and/or wireless connections. For example, the key manager computing system <NUM> can communicate wirelessly (e.g., via WiFi, cellular, radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to other computing devices in key distribution infrastructure network <NUM>.

The issuer computing system <NUM> can include servers or other computing devices operated by an issuer entity to authenticate and/or digitally sign token information such as a browser or device token received from a client computing system <NUM>. The issuer computing devices <NUM> can include a token signer component <NUM> and one or more encryption key components <NUM>. In some implementations, the issuer computing system <NUM> can provide third-party content items or creatives (e.g., ads) for display on information resources, such as a website or web page that includes primary content. The issuer computing system <NUM> can also provide information resources such as a web page that includes primary content. The issuer computing system <NUM> can include instructions or computational circuitry to generate a digital signature based on tokens that correspond to information associated with the client computing system <NUM>. The issuer computing system <NUM> can include instructions or computational circuitry to encrypt digitally-signed tokens that correspond to information associated with the client computing system <NUM>. The issuer computing system <NUM> may generate a composite token based on the one or more encryption key components <NUM> and the digital signature generated by the token signer component <NUM>. The issuer computing system <NUM> may generate the composite token by concatenating each of the encrypted digitally-signed tokens together into a single data structure. The issuer computing system <NUM> can provide the generated composite token to the client computing system <NUM> via the network <NUM>. The issuer computing system <NUM> can receive, ask for, accept, or otherwise query for both the token signer component <NUM> and/or the encryption key component <NUM> from key manager <NUM> over the key distribution infrastructure <NUM>. In some implementations, the key manager <NUM> may automatically send the token signer component <NUM> and/or the one or more encryption key component <NUM> to the issuer computing system <NUM> over the key distribution infrastructure <NUM>.

The verifier computing systems <NUM> can include servers or other computing devices operated by a content provider entity to provide verification of the authenticity of signed tokens received from the client computing system <NUM> through the content item network <NUM>. In some implementations, the signed tokens received from the content item network <NUM> may be a composite token. The verifier computing systems <NUM> may include a token verifier component <NUM> and a decryption key component <NUM>. The verifier computing systems <NUM> may provide third-party content items or creatives (e.g., ads) for display on information resources, such as a website or web page that includes primary content over the content item network <NUM>. The verifier computing systems <NUM> may only provide content items responsive to verifying the token associated with the client <NUM> using the decryption key component <NUM> and the token verifier component <NUM>. One or more verifier computing systems <NUM> can receive a composite token corresponding to a client computing system <NUM> over the content item network <NUM>. The composite token received from the content item network <NUM> may include one or more of encrypted digital signatures, one of which may correspond to one of the verifier computer systems <NUM>. Each of the verifier computing systems <NUM> that received a composite token can parse the composite token to enumerate the plurality of encrypted digitally-signed tokens. Each of the verifier computing systems <NUM> may use the decryption key component <NUM> to decode the encrypted digitally-signed token that corresponds to the verifier computing system <NUM>. The encrypted digitally-signed token may be determined to correspond with the verifier computing system <NUM> if the decoded digital signature in the encrypted digitally signed token can be verified using the token verifier component <NUM>. The token verifier component <NUM> can use a public key corresponding to the private key maintained by the issuer computing system <NUM> to verify the decoded digital signatures. In some embodiments, the verifier computing system <NUM> can receive, ask for, accept, or otherwise query for both the token verifier and the one or more decryption keys from key manager computing system <NUM> over the key distribution infrastructure <NUM>. In some implementations, the key manager computing system <NUM> may automatically send the token verifier component <NUM> and/or the decryption key component <NUM> to the verifier computing system <NUM> over the key distribution infrastructure <NUM>.

The client computing system <NUM>, the issuer computing system <NUM>, the verifier computing systems <NUM>, and the key manager computing system <NUM> can include a processor and a memory, i.e., a processing circuit. The memory stores machine instructions that, when executed on the processor, cause the processor to perform one or more of the operations described herein. The processor can include a microprocessor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), etc., or combinations thereof. The memory can include, but is not limited to, electronic, optical, magnetic, or any other storage or transmission device capable of providing the processor with program instructions. The memory may further include a floppy disk, CD-ROM, DVD, magnetic disk, memory chip, ASIC, FPGA, read-only memory (ROM), random-access memory (RAM), electrically-erasable ROM (EEPROM), erasable-programmable ROM (EPROM), flash memory, optical media, or any other suitable memory from which the processor can read instructions. The instructions can include code from any suitable computer-programming language.

The client computing system <NUM>, the issuer computing system <NUM>, the verifier computing systems <NUM>, and the key manager computing system <NUM> can also include one or more user interface devices. In general, a user interface device refers to any electronic device that conveys data to a user by generating sensory information (e.g., a visualization on a display, one or more sounds, etc.) and/or converts received sensory information from a user into electronic signals (e.g., a keyboard, a mouse, a pointing device, a touch screen display, a microphone, etc.). The one or more user interface devices can be internal to a housing of the client computing system <NUM>, the issuer computing system <NUM>, the verifier computing systems <NUM>, and the key manager system <NUM> (e.g., a built-in display, microphone, etc.) or external to the housing of the client computing system <NUM>, the issuer computing system <NUM>, the verifier computing system <NUM>, and the key manager computing system <NUM> (e.g., a monitor connected to the client computing system <NUM>, a speaker connected to the client computing system <NUM>, etc.), according to various implementations. For example, the client computing system <NUM>, the issuer computing system <NUM>, the verifier computing systems <NUM>, and the key manager computing system <NUM> can include an electronic display, which visually displays web pages using webpage data received from one or more content sources via the network <NUM>, the content item network <NUM>, or the key distribution infrastructure <NUM>.

The issuer computing system <NUM> can include at least one server. For instance, the issuer computing system <NUM> can include a plurality of servers located in at least one data center or server farm. In some implementations, the issuer computing system <NUM> can include information about the client computer system <NUM>. The issuer computing system <NUM> can include at least one token signer component <NUM>, and at least one encryption key component <NUM>. The token signer component <NUM> and encryption key component <NUM> each can include at least one processing unit, server, virtual server, circuit, engine, agent, appliance, or other logic device such as programmable logic arrays configured to communicate with other computing devices (e.g., the client computing system <NUM>, or the key manager computing system <NUM>) via the network <NUM> and/or the key distribution infrastructure <NUM>.

The token signer component <NUM> and the encryption key component <NUM> can include or execute at least one computer program or at least one script. The token signer component <NUM> and the encryption key component <NUM> can be separate components, a single component, or part of the issuer computing system <NUM>. The token signer component <NUM> and the encryption key component <NUM> can include combinations of software and hardware, such as one or more processors configured to execute one or more scripts.

The token signer component <NUM> can receive a first-party token from the client computing system <NUM> via the network <NUM>. In some embodiments, the first-party token may be associated with the domain of the issuer computing system <NUM>. In some embodiments, the first-party token may be generated by a browser that is executed on the client computing system <NUM>. In some other embodiments, the first-party token may be a device token generated by the client computing system <NUM>. In some embodiments, the token signer component <NUM> can receive a request from the client computing system <NUM> via network <NUM> to generate a first-party token. The request for a first-party token can include browser information corresponding to a browser executing on client computing system <NUM>. The request for a first-party token can include device information corresponding to the client computing system <NUM>. In some embodiments, the token signer component <NUM> can generate a first-party token responsive to the request from the client computing system <NUM>. The first-party token can correspond to the domain of the issuer computing system <NUM>. The token signer component <NUM> may receive a request for a composite token from the client computing system <NUM> via the network <NUM>. In some embodiments, the token signer component <NUM> may receive a request for a digitally-signed token from the client computing system <NUM> via the network <NUM>. The token signer component <NUM> can generate a time stamp corresponding to the receipt of the first-party token from the client computing system <NUM>. The time stamp may be generated based on the current time maintained by the issuer computing system <NUM>. The token signer component <NUM> can maintain one or more private keys corresponding to the issuer computing system <NUM>. In some embodiments, the one or more private keys are received from the key manager computing system <NUM> via the key distribution infrastructure <NUM>. The token signer component <NUM> can generate a digitally-signed first-party token using the one or more private keys. The token signer component <NUM> can provide the digitally-signed first-party token to the encryption key component <NUM> to generate one or more encrypted digitally-signed tokens. The token signer component <NUM> can provide the digitally-signed first-party token to the encryption key component <NUM> to generate a composite token comprising one or more encrypted digitally-signed tokens.

The encryption key component <NUM> can receive a digitally-signed first-party token from the token signer component <NUM>. In some embodiments, the encryption key component <NUM> can receive a request for a composite token from the client computing system <NUM> via the network <NUM>. In some embodiments, the encryption key component <NUM> can receive a request for an encrypted digitally-signed token from the client computing system <NUM> via the network <NUM>. The encryption key component <NUM> can maintain one or more encryption keys. In some embodiments, each of the one or more encryption keys are public keys corresponding to a verifier computing system <NUM>. In such embodiments, the verifier computing system <NUM> can maintain the private key associated with the corresponding public key maintained by the issuer computing system <NUM>. The one or more encryption keys can be received from the key manager computing system <NUM> via the key distribution infrastructure <NUM>. In some embodiments, encryption key component <NUM> can receive a request from token signer component <NUM> to generate one or more encrypted digitally-signed first-party tokens. In such embodiments, the encryption key component <NUM> may generate an encrypted digitally-signed token for each of the one or more encryption keys maintained by the encryption key component <NUM>. The encryption key component <NUM> may generate a composite token comprising the one or more encrypted digitally-signed tokens. In such embodiments, the encryption key component <NUM> can generate the composite token by concatenating each of the one or more encrypted digitally signed tokens into a single data structure. The encryption key component can provide the composite token to the client computing system <NUM>. In some embodiments, the encryption key component can provide the one or more encrypted digitally signed tokens to the client computing system <NUM>.

The verifier computing system <NUM> can include at least one server. For instance, the verifier computing system <NUM> can include a plurality of servers located in at least one data center or server farm. In some implementations, the verifier computing system <NUM> can include information about the client computer system <NUM>. The verifier computing system <NUM> can include at least one token verifier component <NUM>, and at least one decryption key component <NUM>. The token verifier component <NUM> and decryption key component <NUM> each can include at least one processing unit, server, virtual server, circuit, engine, agent, appliance, or other logic device such as programmable logic arrays configured to communicate with other computing devices (e.g., the client computing system <NUM>, or the key manager computing system <NUM>) via the content item network <NUM> and/or the key distribution infrastructure <NUM>.

The token verifier component <NUM> and the decryption key component <NUM> can include or execute at least one computer program or at least one script. The token verifier component <NUM> and the decryption key component <NUM> can be separate components, a single component, or part of the verifier computing system <NUM>. The token verifier component <NUM> and the decryption key component <NUM> can include combinations of software and hardware, such as one or more processors configured to execute one or more scripts.

The decryption key component <NUM> can receive a composite token corresponding to the client computing system <NUM> via the content item network <NUM>. The composite token can include one or more encrypted digitally signed tokens. In some embodiments, the composite token may include a first-party token and a time stamp, the first-party token being used to generate the encrypted digitally-signed portions of the composite token. In such embodiments, the decryption key component <NUM> can check if the received time stamp of the composite token is recent to determine if the composite token was sent as part of a replay attack. If the composite token is determined to be part of a replay attack, the decryption key component can ignore the composite token, ceasing further processing of the composite token by the verifier computing system <NUM>. The decryption key component <NUM> can receive a request from the content item network <NUM> to verify the authenticity of the composite token. The decryption key component <NUM> can receive a request from the content item network <NUM> to verify the one or more encrypted digitally signed tokens. The decryption key component <NUM> can maintain a decryption key. In some embodiments, the decryption key is a private key corresponding to the verifier computing system <NUM>. In such embodiments, the issuer computing system <NUM> maintains the public key associated with the corresponding private key maintained by the verifier computing system <NUM>.

The decryption key can be received from the key manager computing system <NUM> via the key distribution infrastructure <NUM>. The decryption key component <NUM> can enumerate each of the encrypted digitally-signed tokens in the composite token received from the content item network <NUM>. The decryption key component <NUM> can enumerate each of the encrypted digitally signed tokens received from the content item network <NUM>. The decryption key component <NUM> can attempt to decode each of the enumerated encrypted digitally-signed tokens using the private key maintained by the decryption key component <NUM> to generate a digitally-signed token corresponding to the respective encrypted digitally-signed token. In some embodiments, the decryption key component <NUM> may determine which of the enumerated digitally-signed tokens corresponds to the verifier computing system <NUM>. In such embodiments, the decryption key component <NUM> can decode the encrypted digitally-signed token that corresponds to the verifier computing system <NUM> using the private key to generate a digitally-signed token. The decryption key component <NUM> can provide the one or more generated digitally-signed tokens to the token verifier component <NUM>.

The token verifier component <NUM> can receive one or more digitally-signed tokens provided by the decryption key component <NUM>. The token verifier component can receive a first-party token and a timestamp. The token verifier component <NUM> can maintain a public key that corresponds to the private key maintained by the issuer computing system <NUM>. In some embodiments, the token verifier component can receive the public key from the key manager computing system <NUM> via the key distribution infrastructure <NUM>. The token verifier component <NUM> can verify the first-party token by verifying at least one of the digitally-signed tokens using the public key. For example, the token verifier component <NUM> can use the public key to decrypt each of the digitally-signed tokens received from the decryption key component <NUM> to generate one or more decoded token and time stamp pairs, each of the decoded token and time stamp pairs corresponding to a respective digitally-signed token. The token verifier component <NUM> can then compare each of the token and time stamp pairs to the first-party token and time stamp received by the verifier computing system <NUM> as a part of the composite token. If any of the token and time stamp pairs match the first-party token and time stamp received as a part of the composite token, the first-party token is considered verified. The composite token may contain more than one encrypted digitally signed token because each of the encrypted digitally signed tokens corresponds to a verifier computing system <NUM> that is authorized by the issuer computing system <NUM> to verify the authenticity of the first-party token. The digitally-signed tokens can be used as a digital-signature to verify the authenticity of the first-party token and time stamp. In some embodiments, the verifier computing system <NUM> can process the first-party token responsive to verifying the first-party token's authenticity.

<FIG> shows a block diagram depicting an example implementation of a key manager computing system <NUM>. The key manager computing system <NUM> can include a key management service <NUM>, a token signer binary <NUM>, a token verifier binary <NUM>, verifier encryption keys <NUM>, and verifier decryption keys <NUM>. In some implementations, the key management service <NUM> can be executed by an operating system of the key manager computing system <NUM>.

In some implementations, the key management service <NUM> can be an application programming interface provided by the operating system which the issuer computing system <NUM> and the verifier computing systems <NUM> can interface with to request token signer data and token verifier data. In some implementations, the issuer computing system <NUM> may authorize a decryption key to each verifier computing system <NUM> by interfacing with the key management service <NUM>. In some implementations, the key management service may provide the token signer component <NUM> private key to the issuer computing system <NUM> using the token signer binary <NUM>. In such implementations, the private key may be provided to the issuer computing system <NUM> via the key distribution infrastructure <NUM>. In some implementations, the key management service may provide the token verifier component <NUM> public key to the verifier computing system <NUM> using the token verifier binary <NUM>. In such implementations, the private key may be provided to the issuer computing system <NUM> via the key distribution infrastructure <NUM>. The key management service <NUM> can authorize certain verifier computing systems <NUM> by generating specific verifier encryption keys <NUM> and verifier decryption keys <NUM>. For example, the key management service <NUM> can receive a request to authorize only certain verifier computing systems <NUM> from the issuer computing system <NUM>. The key management service <NUM> can then generate verifier encryption keys (e.g., public keys) and verifier decryption keys (e.g., private keys), each of the public/private key pairs corresponding to the verifier computing systems <NUM> authorized by issuer computing system <NUM>. The key management service <NUM> can provide all of the public (encryption) keys to the encryption key component <NUM> of the issuer computing system <NUM> via the key distribution infrastructure <NUM>. The key management service <NUM> can distribute each of the private (decryption) keys to the respective authorize verifier computing systems <NUM>.

<FIG> shows a flow diagram of an example process <NUM> for the generation of an encrypted composite token. The process <NUM> includes generating a first-party token <NUM>, transmitting the first party token to the issuer <NUM>, digitally signing the first-party token using a private key <NUM>, selecting the ith verifier encryption key <NUM>, creating an encrypted digitally-signed token using the ith verifier encryption key <NUM>, determining if i is equal to the number of verifier encryption keys <NUM>, incrementing the register i <NUM>, generating a composite token from the encrypted digitally-signed tokens <NUM>, and providing the composite token to the party responsible for generating the first-party token <NUM>.

In further detail of step <NUM>, a party generates a first-party token. In some implementations, the first-party token may be associated with the domain of an issuer. In some implementations, the first-party token may include data from an application (e.g., a web browser). In some implementations, generating the first-party token includes device information from the device or system executing process <NUM>. Generating the first-party token may include generating a request for an encrypted digitally-signed token from an issuing party. The issuing party may also be called the issuer. Generating the first-party token may include generating a request for a composite token from the issuer. In some implementations, generating the first-party token may include generating a time stamp. In such implementations, the time stamp may be a time stamp with high resolution (e.g., millisecond or microsecond resolution, etc.).

In further detail of step <NUM>, a party transmits the first-party token to the issuer. Transmitting the first-party token to the issuer could include transmitting a time stamp generated by the party. In some embodiments, transmitting the first-party token can include transmitting a request for an encrypted digitally-signed token to the issuer. In some embodiments, transmitting the first-party token can include transmitting a request for a composite token to the issuer, the composite token comprising at least one or more encrypted digitally-signed tokens. Transmitting the first-party token could include transmitting a request for a digitally-signed token from the issuer.

In further detail of step <NUM>, the issuer digitally signs the first-party token transmitted in step <NUM> using a private key. In some embodiments, step <NUM> can include receiving, by the issuer, the digitally-signed token generated by the party in step <NUM>. In some embodiments, receiving, by the issuer, the digitally-signed token can include receiving a timestamp generated in step <NUM> or step <NUM>. In some embodiments, step <NUM> of the process can concatenate the first-party token and the time stamp into a token-timestamp pair. In step <NUM>, the issuer can sign digitally sign the first-party token using a digital signature algorithm (e.g., DSA, RSA, etc.). In some embodiments, the issuer can generate a digitally-signed token by using a digital signature algorithm on the token-timestamp pair. In some embodiments, a hash function (e.g., SHA-<NUM>, SHA-<NUM>, MD5, etc.) can performed using the first-party token as input to generate a hashed token. In some embodiments, a hash function can be performed using the token-timestamp pair as an input to generate a hashed token-timestamp pair. The issuer of process <NUM> can generate a digitally signed token using a digital signature algorithm on the hashed token. In some embodiments, the issuer of process <NUM> can generate a signed token using a digital signature algorithm on the hashed token-timestamp pair.

The process <NUM> includes selecting the ith verifier encryption key <NUM>. This process stage can be executed, for example, by the issuer computing system <NUM> to encrypt the digitally-signed token for all encryption keys maintained by the encryption key component <NUM>. In some embodiments, step <NUM> can include receiving one or more encryption keys that each correspond to a verifying party, where n is equal to the number of encryption keys. In some embodiments, the encryption keys may be received from a key manager, for example the key manager computing system <NUM>. In some embodiments, the encryption keys are public keys that correspond to a respective verifying party. In the first iteration of the loop created by process <NUM>, step <NUM> can select the first encryption key (ith, i=<NUM>). It should be understood that the one or more encryption keys can be selected in any order.

In further detail of step <NUM>, the process <NUM> can create an encrypted digitally-signed token using the ith verifier encryption key. In some embodiments, the process <NUM> uses an asymmetric encryption algorithm, where the encryption key is the public key and the private key belongs to a verifying party. The process <NUM> can create the encrypted digitally-signed token by encrypting the digitally signed token generated in step <NUM> with the ith encryption key selected in step <NUM>. In some embodiments, the encryption key may be a private key of a public/private key pair, where the public key is maintained by a verifying party. In some embodiments, step <NUM> does not encrypt the digitally-signed token generated in step <NUM>, and simply returns the digitally-signed token.

The process <NUM> includes creating the encrypted digitally-signed tokens corresponding to all of the encryption keys maintained by the issuer. For example, encryption key component <NUM> of the issuer computing system <NUM> can determine whether the currently created encrypted digitally-signed token is the nth encrypted digitally-signed token, where n corresponds to the number of encryption keys maintained by the encryption key component <NUM>. If no, then the encryption key component <NUM> can increment the counter i <NUM>, and select the next encryption key from the encryption keys maintained by the encryption key component <NUM>. In this manner, the issuer computing system <NUM> can create n encrypted digitally-signed tokens, where each of the n encrypted digitally-signed tokens corresponds to a verifying party, for example the verifier computing systems <NUM>.

In further detail of step <NUM>, the process <NUM> can generate a composite token from the encrypted digitally-signed tokens. The composite token can be generated by concatenating each of the encrypted digitally signed tokens into a single data structure. An example of this concatenation is illustrated in <FIG>. In this illustrative embodiment, 506a-n represent each of the encrypted digitally-signed tokens created in step <NUM>, where each of the n digitally-signed tokens corresponds to a verifying party, for example one of the verifier computing systems <NUM>. In some embodiments, the composite token can be generated by concatenating each of the encrypted digitally-signed tokens and the original first-party token and time stamp into a single data structure. An embodiment of the result of this concatenation is illustrated in <FIG>, where <NUM> is the original first-party token, <NUM> is the time stamp that corresponds to the original first-party token, and 506a-n are each of the n encrypted digitally-signed tokens. Although <FIG> illustrates the first-party token, time stamp, and encrypted digitally-signed tokens in a specific order, it should be understood that any of components may be excluded from the composite token, and any of these elements may appear in the composite token in any order.

In further detail of step <NUM>, process <NUM> provides the composite token to the party responsible for generating the first party token. The process <NUM> can provide the composite token generated in step <NUM> to the party who generated the first-party token in step <NUM>. For example, the issuer computing system <NUM> can transmit the composite token generated by the encryption key component <NUM> to the client computing system <NUM> via the network <NUM>. In some embodiments, the issuer can provide the composite token to the party responsible for generating the first-party token through a web interface. For example, the issuer computing system <NUM> can transmit the generated composite token via a web interface, and the client computing system <NUM> can receive the composite token as a part of a browser session.

<FIG> shows a flow diagram of an example process <NUM> for the verification of the contents of a composite token. The process <NUM> includes receiving a composite token <NUM>, enumerating each of the encrypted digitally-signed tokens in the composite token <NUM>, selecting the ith encrypted digitally-signed token <NUM>, decoding the encrypted digitally-signed token to generate a digitally-signed token <NUM>, verifying the validity of the digitally-signed token and generating a first-party token <NUM>, determining whether the encrypted token corresponds to the verifying party <NUM>, determining if i is equal to the number of encrypted digitally-signed tokens in the composite token n <NUM>, incrementing the register i <NUM>, ignoring the composite token <NUM>, and processing the valid first-party token <NUM>.

In further detail of step <NUM>, the process <NUM> can receive a composite token comprising one or more encrypted digitally-signed tokens. For example, one of the verifying computing systems <NUM> can receive a composite token from the content item network <NUM>. The composite token can include one or more encrypted digitally-signed tokens. The composite token can also include a first-party token and a time stamp. An example schematic of a composite token is illustrated in <FIG>. The process <NUM> can be executed by a party that needs to verify the authenticity of a first-party token. In some embodiments, the composite token may be received as a single data structure. In some other embodiments, the composite token may be received as a series of data structures. For example, the verifying party executing the process <NUM> may receive the encrypted digitally-signed tokens one at a time, and use them to create a composite token. In some embodiments, the first-party token may include a time stamp that corresponds to the creation of the first-party token. In such embodiments, the first-party token and time stamp can be included in the composite token.

In further detail of step <NUM>, the process <NUM> enumerates each of the encrypted digitally-signed tokens in the composite token received in step <NUM>. In some embodiments, enumerating each of the encrypted digitally-signed tokens includes extracting each encrypted digitally-signed token. In such embodiments, a first-party token and time stamp may also be extracted from the composite token. In such embodiments, the verifying party executing process <NUM> can compare the time stamp in the composite token to a predetermined value. The verifying party executing process <NUM> can compare the time stamp to check if the composite token is recent, and defend against potential replay attacks. In some embodiments, the composite token may be a predetermined data structure known to the verifying party executing the process <NUM>. In such embodiments, the verifying party may extract and enumerate each of the encrypted digitally-signed tokens by based off of the known offsets in the data structure. In some embodiments, enumerating each of the encrypted digitally-signed tokens may include assigning a numerical value to that corresponds to each of the encrypted digitally-signed tokens. For example, referring to <FIG>, each of the encrypted digitally-signed tokens 506a-n could be assigned a numerical value corresponding to its order in the composite token. Furthering this example, 506a could be assigned the value of <NUM>, 506b could be assigned the value of <NUM>, 506c could be assigned the value of <NUM>, and so on. In some embodiments, the verifying party executing step <NUM> can determine the number of encrypted digitally-signed tokens n included in the composite token received in step <NUM>.

The process <NUM> includes selecting the ith encrypted digitally-signed token <NUM>. This process stage can be executed, for example, by the verifier computing system <NUM> to decode each of the encrypted digitally-signed tokens comprising the composite token. In some embodiments, step <NUM> can include received a decryption key that corresponds to the verifying party executing process <NUM>. In some embodiments, the decryption key may be received from a key manager, for example the key manager computing system <NUM>. In some embodiments, the decryption key is a private key that corresponds to the verifying party executing process <NUM>. In such embodiments, the corresponding public key is maintained by the issuer responsible for generating the composite token. In the first iteration of the loop created by process <NUM>, step <NUM> can select the first encrypted digitally-signed token (ith, i=<NUM>). It should be understood that the one or more encryption keys can be selected in any order.

In further detail of step <NUM>, process <NUM> decodes the selected encrypted digitally-signed token to generate a digitally-signed token. The verifying party can decode encrypted digitally-signed token selected in step <NUM> and generate a digitally-signed token. For example, one of the verifier computing systems <NUM> could execute step <NUM> of the process <NUM> using the decryption key component <NUM>. To further the example, the decryption key component <NUM> of the verifier computing system <NUM> executing process <NUM> could receive the decryption key from the key manager computing system <NUM> via the key distribution infrastructure <NUM>. In some embodiments, step <NUM> of the process <NUM> could include receiving a decryption key from a key manager. In some other embodiments, the decryption key could be maintained or received by the verifying party executing process <NUM> prior to the execution of process <NUM>. In some embodiments, decoding the encrypted digitally-signed token is performed using a decryption algorithm (e.g., elliptic curve, RSA, etc.).

In further detail of step <NUM>, the digitally-signed token is verified to generate a first-party token. In some embodiments, the digitally-signed token is verified to generate a hash of a first-party token. The verifying party executing the process <NUM> can use a digital signature algorithm (e.g., elliptic curve, DSA, RSA, etc.) to decrypt the contents of the digitally-signed token generated in step <NUM>, the decrypted contents of the digitally-signed token being a first-party token and time stamp which can be used to verify the validity of the first-party token received in the composite token in step <NUM> of process <NUM>. In some embodiments, the decrypted contents of the digitally-signed token is a hash of a first-party token and time stamp. In some embodiments, the digital signature algorithm uses the public key of the issuer to decrypt the contents of the digitally-signed token. For example, the key manager computing system <NUM> may distribute a private key to the issuer computing system <NUM> and the corresponding public key to the verifier computing systems <NUM>. The issuer computing system <NUM> can use process <NUM> to generate a composite key, which is provided to the client computing system <NUM>. The client computing system <NUM> can provide the composite token to the content item network <NUM>, which can provide the composite token to one or more verifier computing systems <NUM>. The verifier computing systems can use process <NUM> to attempt to process the first-party token contained in the composite token. In this example, the verifier computing system <NUM> can use the public key corresponding to the private key maintained by the issuer computing system <NUM> to decrypt the digitally-signed token in step <NUM> to generate a first-party token and time stamp, or in some embodiments a hash of a first-party token and time stamp.

In further detail of step <NUM>, the process <NUM> determines if the decrypted contents of the digitally signed token correspond to the verifying party executing process <NUM>. For example, the composite token can contain more than one encrypted digitally-signed token. Each encrypted digitally-signed token can only be decrypted by an authorized verifying party. In this example, authorization is controlled by the distribution of decryption keys. Each decryption key can only successfully decrypt the contents of up to one of the encrypted digitally-signed tokens contained in the composite token. The verifying party can determine if the encrypted digitally-signed token corresponds to the verifying party executing process <NUM> by checking to see if the digital signature (i.e., the digitally-signed token generated in step <NUM>) matches the first-party token and timestamp included in the composite token received in step <NUM>. The verifying party can check if first-party token and time stamp generated in step <NUM> match the first-party token and time stamp received as a part of the composite token. In some embodiments, the step <NUM> may return a hash of the first-party token and timestamp. In such embodiments, step <NUM> computes a hash of the first-party token and time stamp received as a part of the composite token using a cryptographic hash function (e.g., SHA-<NUM>, SHA-<NUM>, MD5, etc.), and compares it to the value returned from the decryption of the digitally-signed token in step <NUM>. If the two values match, then the encrypted digitally-signed token corresponds to the verifying party, and the first-party token can be processed by the verifying party in step <NUM>. If no, then the verifying party executing the process <NUM> can determine if the current encrypted digitally-signed token is the nth encrypted digitally-signed token <NUM>. If no, then the verifying party executing process <NUM> can increment the counter i <NUM> and select the next encrypted digitally-signed token <NUM>. If the current encrypted digitally-signed token is the nth encrypted digitally-signed token, then none of the encrypted digitally-signed tokens in the composite token correspond to the verifying party executing process <NUM>, and the composite token is ignored <NUM>.

In further detail of step <NUM>, the verifying party executing process <NUM> can process the verified first-party token. In some embodiments, the verification process <NUM> can be performed in real-time without accessing outside servers or databases. In some embodiments, the processing of the first-party token includes consuming the data contents of the token. For example, the token may contain browser information. By verifying the authenticity of the first-party token, the verifying party can now associate the browser information contained in the first-party token with the party responsible for generating the first-party token, for example client computing system <NUM>. The verification process <NUM> allows verifying parties which may require very low-latency token authentication a method to verify the authenticity of the first-party token in under a predetermined amount of time, for example <NUM> milliseconds.

<FIG> shows the general architecture of an illustrative computer system <NUM> that may be employed to implement any of the computer systems discussed herein (including the client computing system <NUM>, the issuer computing system <NUM> and its components such as the token signer component <NUM> and the encryption key component <NUM>, the verifier computing systems <NUM> and its components such as the token verifier component <NUM> and the decryption key component <NUM>, and the key manager computing system and its components) in accordance with some implementations. The computer system <NUM> can be used to provide information via the network <NUM>, the content item network <NUM>, or the key distribution infrastructure <NUM> for display. The computer system <NUM> of <FIG> comprises one or more processors <NUM> communicatively coupled to memory <NUM>, one or more communications interfaces <NUM>, and one or more output devices <NUM> (e.g., one or more display units) and one or more input devices <NUM>. The processors <NUM> can be included in the client computing system <NUM>. The processors <NUM> can be included in the issuer computing system <NUM> or the other components of the issuer computing system <NUM> such as the token signer component <NUM> and the encryption key component <NUM>. The processors <NUM> can be included in the verifier computing systems <NUM> or the other components of the verifier computing systems <NUM> such as the token verifier component <NUM> and the decryption key component <NUM>. The processors <NUM> can be included in the key manager computing systems <NUM> or the other components of the key manager computing systems <NUM> such as the key management service <NUM>.

In the computer system <NUM> of <FIG>, the memory <NUM> may comprise any computer-readable storage media, and may store computer instructions such as processor-executable instructions for implementing the various functionalities described herein for respective systems, as well as any data relating thereto, generated thereby, or received via the communications interface(s) or input device(s) (if present). Referring to the key manager computing system <NUM> of <FIG>, the key manager computing system <NUM> can include the memory <NUM> to store information related to verifier encryption keys <NUM> and the verifier decryption keys <NUM>, among others. The processor(s) <NUM> shown in <FIG> may be used to execute instructions stored in the memory <NUM> and, in so doing, also may read from or write to the memory various information processed and or generated pursuant to execution of the instructions.

The processor <NUM> of the computer system <NUM> shown in <FIG> also may be communicatively coupled to or control the communications interface(s) <NUM> to transmit or receive various information pursuant to execution of instructions. For example, the communications interface(s) <NUM> may be coupled to a wired or wireless network, bus, or other communication means and may therefore allow the computer system <NUM> to transmit information to or receive information from other devices (e.g., other computer systems). While not shown explicitly in the system of <FIG>, one or more communications interfaces facilitate information flow between the components of the system <NUM>. In some implementations, the communications interface(s) may be configured (e.g., via various hardware components or software components) to provide a website as an access portal to at least some aspects of the computer system <NUM>. Examples of communications interfaces <NUM> include user interfaces (e.g., web pages), through which the user can communicate with the data processing system <NUM>.

The output devices <NUM> of the computer system <NUM> shown in <FIG> may be provided, for example, to allow various information to be viewed or otherwise perceived in connection with execution of the instructions. The input device(s) <NUM> may be provided, for example, to allow a user to make manual adjustments, make selections, enter data, or interact in any of a variety of manners with the processor during execution of the instructions. Additional information relating to a general computer system architecture that may be employed for various systems discussed herein is provided further herein.

Implementations of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software embodied on a tangible medium, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more components of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. The program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can include a source or destination of computer program instructions encoded in an artificially-generated propagated signal.

The features disclosed herein may be implemented on a smart television module (or connected television module, hybrid television module, etc.), which may include a processing module configured to integrate internet connectivity with more traditional television programming sources (e.g., received via cable, satellite, over-the-air, or other signals). The smart television module may be physically incorporated into a television set or may include a separate device such as a set-top box, Blu-ray or other digital media player, game console, hotel television system, and other companion device. A smart television module may be configured to allow viewers to search and find videos, movies, photos and other content on the web, on a local cable TV channel, on a satellite TV channel, or stored on a local hard drive. A set-top box (STB) or set-top unit (STU) may include an information appliance device that may contain a tuner and connect to a television set and an external source of signal, turning the signal into content which is then displayed on the television screen or other display device. A smart television module may be configured to provide a home screen or top level screen including icons for a plurality of different applications, such as a web browser and a plurality of streaming media services, a connected cable or satellite media source, other web "channels", etc. The smart television module may further be configured to provide an electronic programming guide to the user. A companion application to the smart television module may be operable on a mobile computing device to provide additional information about available programs to a user, to allow the user to control the smart television module, etc. In alternate implementations, the features may be implemented on a laptop computer or other personal computer, a smartphone, other mobile phone, handheld computer, a tablet PC, or other computing device.

The terms "data processing apparatus", "data processing system", "user device" or "computing device" encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The content request component <NUM>, the content selection component <NUM>, and the attribution component <NUM> can include or share one or more data processing apparatuses, computing devices, or processors.

The processes and logic flows can also be performed by, and apparatuses can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), for example. Devices suitable for storing computer program instructions and data include all forms of nonvolatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), plasma, or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can include any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

The computing systems such as the issuer computing system <NUM>, the verifier computing systems <NUM>, the client computing systems <NUM>, and the key manager computing system <NUM> can include clients and servers. For example, the issuer computing system <NUM>, the verifier computing systems <NUM>, the client computing systems <NUM>, and the key manager computing system <NUM> can include one or more servers in one or more data centers or server farms. In some implementations, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device).

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations of the systems and methods described herein.

For example, the token signer component <NUM> and the encryption key component <NUM> can be part of the issuer computing system <NUM>, a single module, a logic device having one or more processing modules, one or more servers, or part of a search engine.

Having now described some illustrative implementations and implementations, it is apparent that the foregoing is illustrative and not limiting, having been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts and those elements may be combined in other ways to accomplish the same objectives. Acts, elements and features discussed only in connection with one implementation are not intended to be excluded from a similar role in other implementations or implementations.

Any implementation disclosed herein may be combined with any other implementation, and references to "an implementation," "some implementations," "an alternate implementation," "various implementation," "one implementation" or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the implementation may be included in at least one implementation. Such terms as used herein are not necessarily all referring to the same implementation. Any implementation may be combined with any other implementation, inclusively or exclusively, in any manner consistent with the aspects and implementations disclosed herein.

References to "or" may be construed as inclusive so that any terms described using "or" may indicate any of a single, more than one, and all of the described terms.

Where technical features in the drawings, detailed description or any claim are followed by reference signs, the reference signs have been included for the sole purpose of increasing the intelligibility of the drawings, detailed description, and claims.

Claim 1:
A computer-implemented method, comprising:
receiving, by an issuer and from a client device, data comprising a first party token specifying device information of the client device;
digitally signing, by the issuer, the first party token using a private key of the issuer to create a digitally-signed token;
encrypting, by the issuer, multiple instances of the digitally-signed token to create multiple encrypted versions of the digitally-signed token, wherein different instances of the encrypted versions of the digitally-signed token are each encrypted with a different respective public key of a different respective verifying party;
generating, by the issuer, a composite token that includes the multiple encrypted versions of the digitally-signed token; and
transmitting, by the issuer, the composite token that includes the multiple encrypted versions of the digitally-signed token to the client device.