Publisher-authorized activation in a cookie-free authentication environment
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- LIVERAMP
- Filing Date
- 2022-07-08
- Publication Date
- 2026-06-16
Smart Images
Figure 0007874715000027 
Figure 0007874715000028 
Figure 0007874715000029
Abstract
Description
Technical Field
[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 224,021, filed Jul. 21, 2021. Such application is hereby incorporated by reference in its entirety.
Background Art
[0002] Third-party cookies are cookies set on a web browser by a website other than the website the user is currently accessing at the time the cookie is set. Third-party cookies have long been used by those who wish to supply messages in a programmatic real-time bidding environment or by message servers to track a user's browsing activity on the Internet. By tracking this activity, messaging parties may provide targeted messages, generate virtual user profiles, or perform web analytics. However, web browsers are currently moving towards a "cookie-less" environment where third-party cookies are no longer available or will soon become unavailable.
[0003] Currently, systems have emerged that provide web content publishers with means for identifying or authenticating those readers in a cookie-less environment. These systems overcome the loss of cookies for identification purposes, but nonetheless must ensure the privacy of personal information about the web publisher's readers. Privacy protection presents new challenges in a cookie-less environment. Therefore, systems and methods for improving the protection of reader privacy in such an environment are desired.
[0004] The references described in this background section are not admitted to be prior art with respect to the present invention.
Summary of the Invention
Means for Solving the Problems
[0005] This invention relates to a system that enables publishers to specify access to person-based identifiers in a cookie-free authentication environment. By giving publishers the ability to grant access to these identifiers only to trusted parties, data "breaks" (i.e., inappropriate or accidental use of personal information) are greatly reduced. Permissions are controlled by encrypting the same identifier using one of several keys, so that only parties to whom the publisher wishes to grant access associated with a particular key can access the information.
[0006] In a specific embodiment, an application programming interface (API) operated by the resolution vendor accepts publisher identifiers, breaks those identifiers down to individuals, and then returns an "envelope" data structure containing encrypted identifiers for each individual. A "sidecar" process handles the decryption and re-encryption of the envelope as needed to support the identification environment. For example, the sidecar decrypts the envelope into identifiers usable by the demand-side platform in a real-time bidding programmatic environment.
[0007] By enabling the dynamic association of envelope keys to individual publisher API keys, publishers can control which downstream parties are allowed to access the keys. This avoids the problems of traditional technologies involving “universal” identifiers, which have issues with authorization and data leakage. This is also more flexible than solutions that involve only a single global level of encryption, where publishers have no control over which parties can access the keys. Finally, in some embodiments, the control layer is even “upstream” in the real-time bidding programmatic ecosystem, thereby enabling more sophisticated control and business logic than traditional identification systems that merely encrypt or decrypt at the limits of real-time bidding capabilities.
[0008] These and other features, purposes and advantages of the present invention will be better understood from the following detailed description of preferred embodiments and the appended claims, together with the drawings, as described below. [Brief explanation of the drawing]
[0009] [Figure 1] This is a flowchart illustrating a method according to one embodiment of the present invention. [Figure 2] This is a swim lane diagram illustrating the method in a broader programmatic environment. [Figure 3] This is a hardware diagram showing the system for implementing the methods shown in Figures 1 and 2. [Modes for carrying out the invention]
[0010] Before describing the present invention in further detail, it should be understood that the scope of the present invention is limited solely by the claims, and therefore the invention is not limited to the specific embodiments described, and that the terms used when describing the specific embodiments are for the purpose of describing those specific embodiments only and are not intended to limit them.
[0011] Next, with reference to Figure 1, a method according to one embodiment of the present invention may be described. Publisher 10 may be any website that provides content desired by users in the form of Publisher Digital Properties. Publisher Digital Properties may be any individual digital assets containing content that users deem desirable, including, but not limited to, news, entertainment, and social media, and may include text content, audio content, photographic content, or video content. Publisher 10 wishes to generate revenue from its content creation by placing paid messages on its website, such as banner messages or embedded messages.
[0012] To generate more revenue from these messages, Publisher 10 hopes that the messages posted on its website are relevant to its readers' interests or purchasing habits, thereby increasing the likelihood that viewing these messages will lead to responses and ultimately sales. In this way, Publisher 10 may collect information from its readers, such as by requesting email addresses, mobile phone numbers, or other identifiers, in order to send offers to readers and / or to log in to view some or all of the content available on Publisher 10's website. In the embodiment of Figure 1, email 11 is used. Email addresses 11, mobile phone numbers, or other information provided by readers may be used as identifiers. However, for privacy reasons, this identifier is encrypted before it is used in the process described herein. The identifier may be hashed, for example, as one method of encryption, before further processing takes place.
[0013] Once identifiers are collected, they are sent to the Resolution Vendor API 12. In a manner invisible to the Publisher 10, the Resolution Service Vendor provides API 12, responding to API calls that include an encrypted identifier corresponding to an unencrypted identifier, and an identifier with an "envelope" data structure that potentially contains other data or metadata. The purpose of API 12 is to provide a front-end to a system that can use hashed identifiers to reliably and anonymously identify the individual to whom the identifier belongs and to return the encrypted identity information "envelope" to the Publisher (as described below). This process is performed using the Resolution Vendor's identity information graph.
[0014] An identification graph is a data structure containing nodes for large-scale collection of subjects, such as consumers located in a geographical or geopolitical region. Nodes correspond to touchpoints for such subjects, and edges in the graph connect nodes corresponding to the same subject. A corresponding subject (e.g., a consumer) can be identified by searching the identification graph for hashed identifiers. A link is an identifier uniquely associated with a specific subject from among a large number of such subjects, such as all individuals in a particular geographical or geopolitical region. Links can be of any form, including, for example, numerical or alphanumeric identifiers. One such service that provides these types of links is the RampID service provided by LiveRamp, Inc. in San Francisco, California. RampID is a link uniquely and persistently associated with a specific individual, business, or household. In this case, identifiers entered by the publisher 10 may be converted into encrypted identifiers contained within the envelope. The envelope is an encrypted container containing one or more encrypted links along with relevant metadata.
[0015] Once the envelope is returned, publisher 10 may then set a first-party cookie or local storage object on the reader's browser. This first-party cookie contains the envelope. Note that since this cookie is set by publisher 10, from the reader's browser's perspective, it is provided by the website being viewed and not by a third party. Since the envelope is effectively a first-party cookie and not a third-party cookie, this system can therefore operate in environments where third-party cookies are blocked, or even on browsers where they are blocked.
[0016] In step 14, the Resolution Service Vendor determines whether a publisher-specific envelope (with a publisher-specific encrypted identifier) is desired in this instance. If not, the system operates in the usual manner, returning an envelope with standard encryption and authorization through the Resolution API 12, and that envelope is returned to the Publisher 10. Otherwise, processing moves to the Publisher Envelope Key Database 16. Note that if the publisher desires a publisher-specific envelope, the publisher must provide a publisher-specific envelope key in the API call to the Resolution API 12. The Publisher Envelope Key Database 16 provides a lookup function that enables matching the publisher-specific envelope key against a database of links maintained by the Resolution Service Vendor.
[0017] In step 18, the resolution service vendor further determines (based on the information provided during the Resolution API 12 call) whether the publisher wishes to further restrict access to authorized demand-side platforms (DSPs) or other downstream recipient identifiers. In a programmatic real-time bidding environment, a DSP is a system that enables buyers of a digital messaging inventory to manage bids for the right to publish their messages to various publishers. In this case, the publisher subnetwork association database 20 may be used to apply additional associations between specific encrypted reader identifiers and specific subnetworks.
[0018] Some time after setting a first-party cookie, the envelope is read from the user's browser and passed to the supply-side platform (SSP). The SSP can be a preferred SSP22 or a less preferred SSP24 in this system. The SSP is a messaging exchange contracted by the publisher, used to programmatically sell the messaging space in an automated manner within a programmatic environment. The SSP implements a service provider “sidecar”26, as shown in Figure 1. The sidecar26 is a subsystem for managing the secure decryption and decryption of identifiers used in the real-time bidding programmatic system. It generates platform-encoded links (such as RampID identifiers) at a speed that makes the system operational in a real-time bidding programmatic environment. This speed is important because failure to provide platform-encoded links within a sufficiently small time frame would result in users experiencing significant delays in making the publisher website usable, rendering the system inoperable.
[0019] Sidecar 26 may include authorization functions by managing links and periodically checking for updates to encoded information, and may periodically report telemetry information. Sidecar 26 generates identifiers for use by downstream platforms, such as DSPs (as further described below with reference to Figure 2). DSPs are used on the marketing (i.e., "demand" side) to buy messaging impressions from exchanges in an automated, real-time bidding manner, although their functionality is similar to that of SSPs as described above. DSP identifiers are each encrypted as described above. Once the encrypted identifiers are distributed to various DSPs, programmatic real-time bidding for publisher inventory to people or agencies wishing to send messages can then proceed in the usual manner without the need for third-party cookies or device identifiers.
[0020] If Publisher 10 has an envelope that it needs to return from Resolution API 12, as just explained, Publisher 10 can then send that envelope to a “favorable” (i.e., trusted) SSP 22 or an unfavorable SSP 24. However, only a favorable SSP 22 can be decrypted using Sidecar 26. The purpose of Sidecar 26 is to provide encryption / decryption services for envelopes quickly and efficiently in a secure environment. Sidecar 26, however, cannot decrypt envelopes from publishers that have designated an SSP as an unfavorable SSP 24. On the other hand, Sidecar 26 can also optionally use subnetwork associations to decrypt identifiers for favorable SSPs 22. Publisher-specific envelopes and identifier-consumer subnetwork relationships are pushed to a favorable sidecar instance in Sidecar Check In Service (SCIS) 28. As shown in Figure 1, a preferred SSP22 may pass the envelope to a less preferred SSP24, but the less preferred SSP24 is still unable to decrypt and use those identifiers using the sidecar 26. Thus, this process prevents the less preferred SSP24 from misusing the identifiers against the publisher's wishes.
[0021] Next, with reference to the swim lane chart in Figure 2, an embodiment of the present invention can be described in the broader context of a programmatic real-time bidding environment. This ecosystem includes a publisher and a resolution vendor, as well as one or more exchange / supply-side platforms (SSPs) and demand-side platforms (DSPs). Processing may be initiated at the resolution vendor, which maintains a platform database 40. The platform database 40 includes a set of addresses for integrated messaging exchange / supply-side platforms and demand-side platforms that may be used in a real-time bidding programmatic ecosystem. The publisher executes a request to retrieve information from the platform database 40, such as by an HTTP "GET" command through the publisher user interface (UI). The publisher then selects an exchange or DSP in a platform selection step 42. This information is returned to the resolution vendor, such as by an HTTP "POST" command.
[0022] The resolution vendor, at step 44, receives an exchange or DSP selection and generates a key and an associated subnetwork as per the publisher's request. The resolution vendor then, at step 44, push-distributes the updated configuration. The SSP receives this configuration at the configuration acceptance step 48. The publisher makes an API call to the API maintained by the resolution vendor for the purpose of generating an envelope at step 50. The resolution vendor's sidecar creates a response envelope based on the configuration at step 52, and the envelope is sent to the publisher during the API call response at step 54. At this point, the publisher has an envelope with an appropriately encrypted identifier and associated data or metadata contained in the envelope with this specific configuration of the system.
[0023] Once the publisher has the envelope, a message request is sent to the exchange / SSP. At step 56, the exchange sidecar attempts to process the envelope. In decision block 58, the exchange / SSP determines whether the sidecar has the corresponding link or key. If the sidecar does not have the corresponding link or key, access is denied and the process stops at step 62. If the sidecar has the corresponding link or key, in decision block 60, it is determined whether appropriate permission has been granted. If the sidecar does not have the corresponding link or key, access is denied and the process stops at step 62. Otherwise, the exchange may receive an identifier for targeting at step 64. Further, if a bid request from the demand side is received in a real-time bidding environment, the DSP may also receive an identifier at step 66.
[0024] Figure 3 provides an overview of the hardware configuration for implementing a publisher, a resolution vendor, and an exchange / SSP component of a system according to some embodiments of the present invention. These components include a publisher system 70, an SSP 72, the publisher system 10 described above, and a sidecar system 74. In order to operate in real-time bidding requirements, the processing must be done at a fast speed, otherwise, it should be noted that the delay that occurs when setting a message on a user's web page at the publisher site would be too large for the system to function effectively. To operate the sidecar, the exchange must, in some embodiments, have one or more central processing unit cores operating at a base frequency of 2 GHz or higher, networking capabilities with 300 MB or more of available RAM, support for an x86 or ARM instruction set, and sufficient disk space.
[0025] It should be noted that in alternative embodiments of the present invention, different encryption methods (e.g., asymmetric rather than symmetric) can be applied. Information other than the subnetwork can be used to permit downstream use. Applications other than the sidecar can handle the processing. Data sharing can occur beyond the real-time bidding / messaging workflow.
[0026] The present invention offers several advantages in the various process implementations described herein. Due to the speed at which the process operates and its real-time functionality, the process has no user-noticeable delay and therefore does not affect the user experience on the publisher's website. In various implementations, the present invention avoids third-party cookie issues by writing envelopes to persistent first-party storage associated with the user's browser, such as in flash memory or a hard drive. In some configurations, the present invention can easily interface with adapters used in real-time bidding programmatic ecosystems (e.g., prebid.js) and can also easily interface with various third-party systems, such as the Privacy Manager JavaScript API for LiveRamp's Consent Management Platform (CMP) in San Francisco, California. Furthermore, in some embodiments, the present invention can present a customizable modal for requesting the user's email address, mobile phone number, or other personal information, which can be configured by passing a configuration object at runtime.
[0027] While the present invention has been described in relation to applications where a cookie cache is used to store link envelopes, the invention is not limited thereto. In other implementations, the invention may apply to channels where hardware device identifiers are available to publishers, as is currently the case with respect to mobile devices, including smartphones. In other implementations, the invention may also apply to channels where device identification information is absent or incomplete, such as Internet Protocol (IP) addresses on addressable televisions or television set-top boxes.
[0028] A more detailed description of the software components of the implementation of the present invention may be given below. In one embodiment, the present invention is implemented as a client-side solution for a publisher that provides to detect email entries on a website, including a login interaction, and to send updates to the user by email or text. The publisher uses a JavaScript® library provided as part of the solution and is required to instantiate it in a configuration object so that the provider can recognize the instantiation. It may be included in the source HTML header as a self-hosted JavaScript® file or served directly. If the library name is something like ats.js, the self-hosted script is: <script src="” / public / javascript / ats.js”">< / script> It may look like this. This can be included just before the closing tag to ensure the page is fully rendered and ready for user interaction. For high-latency pages, ats.js can be appended to . To get the library started, script tags like the ones shown below may be used.
number
[0029] The library manages discovery (unless the identifier is passed directly), identity analysis, and persistence. Demand partners can then retrieve the link envelope from its stored location, either via a direct JavaScript call or by the prebid.js user ID module. Publishers are provided with the JavaScript® library and documentation information to implement the solution from their end. Specifically, the publisher team pulls down the ats.js library and the standard prebid.js core library, along with a proprietary pre-bid adapter that supports identity envelopes. Once installed, the system receives an email address (or, in an alternative embodiment, another identifier) as input from the user through the publisher site. Here, we assume the user accesses the publisher website for desired news or other publisher content. In this example, the user navigates to the appropriate webpage using the Safari browser on their iPhone® device. The user is presented with a request to allow data sharing and responds affirmatively. The user is then presented with the desired content. After reading, a modal slides down the screen, asking the user for their email address to receive content updates directly in their email inbox. Users who wish to receive these updates agree and return to the publisher's home page. In this case, the publisher user employs an identification envelope in a typical programmatic real-time bidding solution.
[0030] The resolution vendor provides the publisher with code to be placed in the header of the publisher's website. As previously explained, once user identification information is provided to the site, the API converts the personal information (such as email) into an identification token (an envelope containing a link) and stores it in the first-party cookie context on the user's browser. Upon page load or subsequent page visits, the header bidder reads the link in the envelope from the first-party cookie and passes it to the SSP. Each SSP then passes the link envelope to the provider's "sidecar" to convert the identifier to a DSP. The DSP identifier is passed to the DSP along with other information about the inventory in the programmatic real-time bid request. The DSP can then make an optimally notified bid with links that are linked to both first-party and third-party data.
[0031] As can be seen, this system and method provides publishers with a JavaScript® library that they can easily embed into their properties. The code should not execute until consent is properly collected as required by applicable law, but it should execute as soon as the page can be interacted with by a user. The library may reference a common set of cascading style sheet (CSS) selectors for the "common" locations of identifiers, e.g., input[type=text]. Publishers may embed additional CSS selectors in either the library file itself or a file containing only the additional selectors. Using the configured CSS selectors, the system can use common email regular expressions (regex), e.g.,
number
number
[0032] Configuration options allow publishers to instruct how and when personal information should be converted into a secure, encrypted link envelope. The placementID should be used in the configuration object to confirm a specific instantiation of the solution with the provider and associate it with a specific publisher. ats.js has two basic operating modes: direct and discovery. In direct mode, the publisher directly provides identifiers to the ATS library. If the publisher already has user login information, the publisher can ensure that user login information is available upon request by directly including it in the publisher's configuration. If the publisher knows that a user provides an identifier on a property but cannot provide it to the supplier (for example, if there is a newsletter signup provided by a Marketo or Mailchimp widget), the provider can use a DOM (document object model) or URL (uniform resource locator) driven discovery method. Using direct, the publisher might pass a plain text email address as follows (the provider here is LiveRamp):
number
number
number
[0033] Furthermore, there are several advanced configuration options that are not expected to be used very often. By default, envelopes are written to first-party cookies (along with generation timestamp and version information). Publishers can alternatively instruct the solution to write to local storage objects by changing the storageType attribute.
number
number
number
number
number
[0034] Generally, the only ats.js function that will be called is ats.start(config). This function is its own HTML <script>タグ中に配置され、ats.jsのための<script>タグのすぐ後にパブリッシャーの構成オブジェクトとともに呼び出されるべきである。他の可能な関数呼び出しはats. retrieveEnvelope(callback)であり得、それは、構成されたストレージからエンベロープをフェッチし、コールバック関数は随意である。関数がコールバックなしで呼び出された場合、プロミスが戻される。機能がコールバックありで呼び出された場合、エンベロープ値が戻される。別の可能な関数はats.triggerDetection();である。この関数は、パブリッシャーの構成において指定されたCSSセレクタを用いてDOM要素を走査する。
[0035] いくつかの実装形態では、ats.jsはprebid.jsに接続するように最適化されるので、先在するオープン·ソースprebid.jsはats.jsとともに使用される。適切に構成されたprebid.jsファイルがダウンロードされると、パブリッシャーは、必要とされる情報をリンク·ユーザIDモジュールに渡すためにpbjs.setConfigを更新するべきである。prebid.jsのための構成は以下に示されている。
数
[0036] 直接アクセスされるJavaScript(登録商標)ライブラリの基礎になるAPIの場合、API呼のためのクエリ·パラメータは、pid(パートナーID番号)と、it(電子メールの識別子タイプ、すなわち、ハッシュされた電子メール、ハッシュされた電話番号など)と、iv(未加工電子メールのハッシュ)と、ct(APIに渡される承諾のタイプ、たとえば、それがGDPRの下で求められるTCFv.1.1又はv2互換承諾文字列であるか否かを示す)と、cv(関連がある承諾文字列値)とを含む。ハッシング法は、例として、MD5、SHA1、及びSHA256を含み得る。好ましくは、すべてのスペース、タブ、及び他の空の文字は処理の前にプレーンテキスト電子メールから削除され、大文字はすべて小文字に変換される。「フェイク」電子メールは識別され、削除される。電話番号の場合、フォーマッティングは、好ましくは、処理の前に削除されるべきである。API呼からの応答は、成功した場合、
数
[0037] 上記で説明した実装形態において、本発明はサードパーティ·クッキーの使用を必要としないが、代替実装形態では、そのような機能が与えられ得る。たとえば、アドレス指定能力を高めるために、代替実装形態は標準の画像マッチ·ピクセルの削除をサポートし得る。この場合、パブリッシャーはサービス·プロバイダにピクセル識別子を要求する。ピクセル識別子が取得されると、これは、以下に与えられる例示的なコードを用いてats.js構成中に与えられ得る。
数
[0038] いくつかの実装形態では、本発明はソーシャル·メディア·ログイン情報と一体化され得る。ソーシャル·ログインは、与えられた情報の有効性において最小の摩擦と高い信頼性をもつ、ユーザを登録するための強力なツールであり得る。たとえば、フェイスブック·プラットフォームとの一体化が望まれる場合について考える。パブリッシャーは、パブリッシャーが、ats.jsとともに使用するためにフェイスブックAPIからユーザ電子メールを取得することを可能にする、フェイスブックJavaScript SDK(software development kit)を使用する可能性がある。パブリッシャーは、以下の実例のようにHTMLコードを使用して「フェイスブックでログイン」ボタンを実装し得る。
数
数
数
[0039] 様々な実装形態では、本発明はまた、Googleタグ·マネージャなど、ウェブサイト·タグ·マネージャと一体化され得る。現在実装されているGoogleタグ·マネージャを使用すると、パブリッシャーは、最初にurl、https: / / tagmanager.google.comに移動し、次いで「新しいタグ」をクリックする。「Untitled Tag」というタグ名は、次いで、「ATS JavaScript」など、作成されるタグを識別するためのものに変更される。ユーザは、次いで、タグ構成セクションをクリックし、「タグ·タイプを選定する」の下で「カスタムHTMLタグ」をクリックする。以下の例示的なHTMLコードが使用され得、パブリッシャーはそれ自体のplacementIDをREPLACE_ME値に置き換える。
数
[0040] いくつかの実装形態では、本発明は、ハッシュされた電子メール·アドレス及び電話番号などの一般的な識別子の代わりに、カスタム識別子(カスタムID)の使用をサポートし得る。この機能を実装するために、マッピング·ファイルがサービス·プロバイダに送られ得る。一実例では、ファイルは、パブリッシャー企業名と、アップロードのタイプと、下線によって区切られたISO8601フォーマットにおける現在の日付とを含んでいるべきである。一実例は「IansCompany_AKP_2020-03-01.tsv」であろう。ファイルのコンテンツは、この実例では、「CID」及び「電子メール·アドレス」と題する、2つのタブ区切りの列である。第1の列は、パブリッシャーがats.jsシステムに入力するユーザIDを含んでいる。第2の列は、SHA-256ハッシュされた電子メール·アドレスを含んでいる。電子メール·アドレスはダウンケースであるべきであり、正確な結果を保証するために、空白はハッシュするより前に削除されるべきである。ファイルはSFTP(SSH File Transfer Protocol)を介してプロバイダに送られ得る。
[0041] プロバイダが、パブリッシャーの第1のマッピング·ファイルの取り込みの成功を確認すると、パブリッシャーは、次いで、新たに作成されたカスタム識別子のためのats.jsを構成する。プロバイダは、構成中に含まれるべきアカウントIDをパブリッシャーに与える。customerIDRegex中の識別子のための正規表現も含まれるべきである。正規表現により、識別子が予想されるパターンに一致することをats.jsが検証することが可能になる。未加工識別子とともにats.jsを使用することと同様に、パブリッシャーは、識別子を(customerIDとして)直接構成パラメータに渡すか、又はats.jsを検出モードで動作させるかのいずれかを行うことができる。検出が使用される場合、パブリッシャーは、「detectionSubject」:「customerIdentifier」が、detectionTypeなど、何らかの他の必要とされる属性と一緒に渡されることを保証するべきである。サンプル構成カスタムID検出は以下のようになる。
数
数
[0042] いくつかの実装形態では、本発明は、電子メール·ニュースレター製品からURLに渡された電子メールを受け付ける能力を有し得る。概して、電子メールは元の受信者以外の個人に転送され得るので、ユーザからのダイレクト·ログインは、ユーザのために何のデータが処理されるのかの最良の透過性を与え、また、パブリッシャーが正確な識別情報を有することを保証するので、その手法を活用することが好ましい。とはいえ、電子メール·ニュースレター製品からの電子メールを利用することは、しかしながら、それらの電子メール·サービス·プロバイダ(ESP:email service proider)中に識別子ユーザの大量のプールをすでに有するパブリッシャーのために有用であり得る。ats.jsがこれらの識別子を活用することを可能にするために、パブリッシャーは、サイトを訪れるためにユーザがクリック·スルーするときに識別子を渡すように、それの標準ニュースレター又は取引電子メールを修正するべきである。パブリッシャーは、追加のクエリ·パラメータを追加するために新しいリンクを追加し(又は既存のリンクを修正し)、次いで、ユーザの電子メール·アドレスの動的に入力された表現を表すために[電子メール]を追加する。1つの例示的なURLは、https: / / authenticated-traffic-solution.com?user_id=[email]であり得る。次に、パブリッシャーは、それのキャンペーン·モニターを経由した電子メール·アドレスを検出し、分析するようにats.jsを構成する。パブリッシャーの実際のplacementIDと、リンクをセット·アップするときに使用されるクエリ·パラメータとを使用するために、以下の例示的なJavaScript(登録商標)が使用され、修正され得る。
数
[0043] 電子メール·キャンペーンのためにメールチンプ(mailchimp)が使用される特定の実例では、追加のクエリ·パラメータが、ユーザの電子メール·アドレスの動的に入力された表現に*|EMAIL|*を追加する。例示的なURLは、https: / / authenticated-traffic-solution.com?user_id=*|email|*であろう。パブリッシャーは、次いで、リンクを更新するために「挿入」をクリックするであろう。プレビューでは、パブリッシャーは、<<Test Email Address>>と入力された電子メール·マクロを見ることになる。稼働中に、このフィールドは受信側の電子メールを入力される。パブリッシャーは、次いで、メールチンプを通して渡された電子メール·アドレスを検出し、分析するようにats.jsを構成し、以下の例示的な構成が使用され得る。
数
[0044] 本明細書で説明するシステム及び方法は様々な実施例においてハードウェアとソフトウェアの任意の組合せによって実装され得る。たとえば、一実施例では、本システム及び方法は、それの各々が、プロセッサに結合されたコンピュータ可読記憶媒体上に記憶されたプログラム命令を実行する1つ又は複数のプロセッサを含む、コンピュータ·システム又はコンピュータ·システムの集合によって実装され得る。プログラム命令は、本明細書で説明された機能を実装し得る。図に示され、本明細書で説明された様々なシステム及び表示は例示的な実装形態を表す。任意の方法の順序は変更され得、様々な要素が追加、修正、又は省略され得る。
[0045] 本明細書で説明するような計算システム又は計算デバイスは、本発明の様々な実装形態の一部を形成する、クラウド·コンピューティング·システム又は非クラウド·コンピューティング·システムのハードウェア部分を実装し得る。コンピュータ·システムは、限定はしないが、コモディティ·サーバ、パーソナル·コンピュータ·システム、デスクトップ·コンピュータ、ラップトップ又はノートブック·コンピュータ、メインフレーム·コンピュータ·システム、ハンドヘルド·コンピュータ、ワークステーション、ネットワーク·コンピュータ、コンシューマ·デバイス、アプリケーション·サーバ、ストレージ·デバイス、電話、携帯電話、又は、一般に、任意のタイプの計算ノード(computing node)、計算ノード(compute node)、計算デバイス(compute device)、及び / 又は計算デバイス(computing device)を含む、様々なタイプのデバイスのいずれかであり得る。計算システムは、入出力(I / O:input / output)インターフェースを介してシステム·メモリに結合された、(それらのいずれかが、シングルスレッド又はマルチスレッドであり得る複数の処理コアを含み得る)1つ又は複数のプロセッサを含む。コンピュータ·システムは、I / Oインターフェースに結合されたネットワーク·インターフェースをさらに含み得る。
[0046] 様々な実施例では、コンピュータ·システムは、1つのプロセッサを含むシングル·プロセッサ·システムか、又は複数のプロセッサを含むマルチプロセッサ·システムであり得る。プロセッサは、計算命令を実行することが可能な任意の好適なプロセッサであり得る。たとえば、様々な実施例では、それらは、様々な命令セット·アーキテクチャのいずれかを実装する汎用プロセッサ又は組込みプロセッサであり得る。マルチプロセッサ·システムにおいて、プロセッサの各々は、必ずしもそうであるとは限らないが、一般的に同じ命令セットを実装し得る。コンピュータ·システムはまた、ローカル·エリア·ネットワーク、ワイド·エリア·ネットワーク、又はインターネットなど、通信ネットワークを介して他のシステム及び / 又は構成要素と通信するための1つ又は複数のネットワーク通信デバイス(たとえば、ネットワーク·インターフェース)を含む。たとえば、計算デバイス上で実行しているクライアント·アプリケーションは、様々なサブシステムにおいて実装されるようなクラウド·コンピューティング又は非クラウド·コンピューティング環境において、本明細書で説明されたシステムの構成要素のうちの1つ又は複数を実装する単一のサーバ又はサーバのクラスタ上で実行しているサーバ·アプリケーションと通信するために、ネットワーク·インターフェースを使用し得る。別の実例では、コンピュータ·システム上で実行しているサーバ·アプリケーションのインスタンスは、他のコンピュータ·システム上に実装され得るアプリケーションの他のインスタンスと通信するためにネットワーク·インターフェースを使用し得る。
[0047] 計算デバイスはまた、1つ又は複数の永続ストレージ·デバイス及び / 又は1つ又は複数のI / Oデバイスを含む。様々な実施例では、永続ストレージ·デバイスは、ディスク·ドライブ、テープ·ドライブ、固体メモリ、他の大容量ストレージ·デバイス、又は任意の他の永続ストレージ·デバイスに対応し得る。コンピュータ·システム(又は分散型アプリケーション又はその上で動作しているオペレーティング·システム)は、要求通りに、永続ストレージ·デバイス中に命令及び / 又はデータを記憶し得、必要に応じて、記憶された命令及び / 又はデータを取り出し得る。たとえば、いくつかの実施例では、コンピュータ·システムは制御プレーン又は制御システムの1つ又は複数のノードを実装し得、永続ストレージは、そのサーバ·ノードに取り付けられたSSD(solid-state drive)を含み得る。複数のコンピュータ·システムは、同じ永続ストレージ·デバイスを共有し得るか、又は、永続ストレージ·デバイスのプール中のデバイスが同じ又は異なるストレージ技術を表す、永続ストレージ·デバイスのプールを共有し得る。
[0048] コンピュータ·システムは、1つ又は複数のプロセッサによってアクセス可能なコード / 命令及びデータを記憶し得る1つ又は複数のシステム·メモリを含む。システム·メモリは、たとえばアクセス速度に基づいてメモリ中の情報をスワップするように設計されたシステム中に複数のレベルのメモリ及びメモリ·キャッシュを含み得る。インターリービング及びスワッピングは仮想メモリ実装における永続ストレージに拡張し得る。メモリを実装するために使用される技術は、例として、スタティック·ランダムアクセス·メモリ(RAM:random-access memory)、ダイナミックRAM、読取り専用メモリ(ROM:read-only memory)、不揮発性メモリ、又はフラッシュ型メモリを含み得る。永続ストレージと同様に、複数のコンピュータ·システムは同じシステム·メモリを共有し得るか、又はシステム·メモリのプールを共有し得る。1つ又は複数のシステム·メモリは、本明細書で説明されたルーチンを実装するために1つ又は複数のプロセッサによって実行可能であるプログラム命令を含んでいることがある。様々な実施例では、プログラム命令は、バイナリ、アセンブリ言語、Java(登録商標)などの任意のインタープリタ型言語、C / C++などのコンパイラ型言語、又はそれの任意の組合せにおいて符号化され得る。ここで与えられた特定の言語は例にすぎない。いくつかの実施例では、プログラム命令は複数の別個のクライアント、サーバ·ノード、及び / 又は他の構成要素を実装し得る。
[0049] いくつかの実装形態では、プログラム命令は、UNIX(登録商標)、LINUX、ソラリス(登録商標)、MacOS(登録商標)、又はMicrosoft Windows(登録商標)など、様々なオペレーティング·システムのいずれかであり得る、オペレーティング·システム(図示せず)を実装するために実行可能な命令を含み得る。プログラム命令のいずれか又はすべては、様々な実装形態によるプロセスを実行するようにコンピュータ·システム(又は他の電子デバイス)をプログラムするために使用され得る、その上に命令を記憶した非一時的コンピュータ可読記憶媒体を含み得るコンピュータ·プログラム製品又はソフトウェアとして与えられ得る。非一時的コンピュータ可読記憶媒体は、機械(たとえば、コンピュータ)によって読取り可能な形態(たとえば、ソフトウェア、処理アプリケーション)において情報を記憶するための任意の機構を含み得る。概して、非一時的コンピュータアクセス可能媒体は、磁気又は光媒体、たとえば、I / Oインターフェースを介してコンピュータ·システムに結合されたディスク又はDVD / CD-ROMなど、コンピュータ可読記憶媒体又はメモリ媒体を含み得る。非一時的コンピュータ可読記憶媒体はまた、コンピュータ·システムのいくつかの実施例中にシステム·メモリ又は別のタイプのメモリとして含まれ得るRAM又はROMなど、任意の揮発性又は不揮発性媒体を含み得る。他の実装形態では、プログラム命令は、ネットワーク·インターフェースを介して実装され得るなど、ネットワーク及び / 又はワイヤード又はワイヤレス·リンクなどの通信媒体を介して伝達される(たとえば、搬送波、赤外線信号、デジタル信号など)の光、音響又は他の形態の伝搬信号を使用して通信され得る。ネットワーク·インターフェースは、他のコンピュータ·システム又は任意のタイプの外部電子デバイスを含み得る他のデバイスとインターフェースするために使用され得る。一般に、システム·メモリ、永続ストレージ、及び / 又はネットワークを通してアクセス可能な他のデバイス上のリモート·ストレージは、データ·ブロック、データ·ブロックのレプリカ、データ·ブロックに関連付けられたメタデータ及び / 又はそれらの状態、データベース構成情報、及び / 又は本明細書で説明するルーチンを実装する際に使用可能な任意の他の情報を記憶し得る。
[0050] いくつかの実装形態では、I / Oインターフェースは、ネットワーク·インターフェース又は他の周辺インターフェースを通して含む、システム中のプロセッサと、システム·メモリと、任意の周辺デバイスとの間のI / Oトラフィックを協調させ得る。いくつかの実施例では、I / Oインターフェースは、1つの構成要素(たとえば、システム·メモリ)からのデータ信号を、別の構成要素(たとえば、プロセッサ)によって使用するために好適なフォーマットに変換するための任意の必要なプロトコル、タイミング又は他のデータ変換を実行し得る。いくつかの実施例では、I / Oインターフェースは、たとえば、周辺構成要素相互接続(PCI:Peripheral Component Interconnect)バス規格又はユニバーサル·シリアル·バス(USB:Universal Serial Bus)規格の変形態など、様々なタイプの周辺バスを介して取り付けられるデバイスのためのサポートを含み得る。また、いくつかの実施例では、システム·メモリへのインターフェースなど、I / Oインターフェースの機能の一部又は全部はプロセッサに直接組み込まれ得る。
[0051] ネットワーク·インターフェースは、コンピュータ·システムと、たとえば、(1つ又は複数のストレージ·システム·サーバ·ノード、1次ノード、読取り専用ノード、及び / 又は本明細書で説明したデータベース·システムのクライアントを実装し得る)他のコンピュータ·システムなど、ネットワークに取り付けられた他のデバイスとの間でデータが交換されることを可能にし得る。さらに、I / Oインターフェースはコンピュータ·システムと様々なI / Oデバイス及び / 又はリモート·ストレージとの間の通信を可能にし得る。入出力デバイスは、いくつかの実施例では、1つ又は複数のディスプレイ端末、キーボード、キーパッド、タッチパッド、走査デバイス、音声認識デバイス又は光学認識デバイス、又は1つ又は複数のコンピュータ·システムによってデータを入力する又は取り出すために好適な任意の他のデバイスを含み得る。これらは、特定のコンピュータ·システムに直接接続し得るか、又は、一般に、クラウド·コンピューティング環境、グリッド計算環境、又は複数のコンピュータ·システムを伴う他のシステム中の複数のコンピュータ·システムに接続し得る。コンピュータ·システムと通信している複数の入出力デバイスが存在し得るか、又はコンピュータ·システムを含む分散型システムの様々なノード上に分散され得る。本明細書で説明したユーザ·インターフェースは、CRTディスプレイ、LCDディスプレイ、LEDディスプレイ、及び他のディスプレイ技術を含み得る、様々なタイプのディスプレイ·スクリーンを使用して、ユーザに見え得る。いくつかの実装形態では、入力は、タッチスクリーン技術を使用してディスプレイによって受信され得、他の実装形態では、入力は、キーボード、マウス、タッチパッド、又は他の入力技術、又はこれらの技術の任意の組合せを通して受信され得る。
[0052] いくつかの実施例では、同様の入出力デバイスはコンピュータ·システムとは別個であり得、ネットワーク·インターフェースを介してなど、ワイヤード又はワイヤレス接続を介してコンピュータ·システムを含む分散型システムの1つ又は複数のノードと対話し得る。ネットワーク·インターフェースは、一般的に、1つ又は複数のワイヤレス·ネットワーキング·プロトコル(たとえば、Wi-Fi / IEEE802.11、又は別のワイヤレス·ネットワーキング規格)をサポートし得る。ネットワーク·インターフェースは、たとえば他のタイプのイーサネット(登録商標)·ネットワークなど、任意の好適なワイヤード又はワイヤレス一般データネットワークを介して通信をサポートし得る。さらに、ネットワーク·インターフェースは、アナログ音声ネットワーク又はデジタル·ファイバー通信ネットワークなど、電気通信 / テレフォニー·ネットワークを介して、ファイバー·チャネルSAN(storage area network)などストレージ·エリア·ネットワークを介して、又は任意の他の好適なタイプのネットワーク及び / 又はプロトコルを介して通信をサポートし得る。
[0053] 本明細書で説明した分散型システム実施例のいずれか、又はそれらの構成要素のいずれかは、クラウド·コンピューティング環境における1つ又は複数のネットワークベース·サービスとして実装され得る。たとえば、データベース·システムのデータベース階層内の読取り書込みノード及び / 又は読取り専用ノードは、本明細書で説明した分散型ストレージ·システムをネットワークベース·サービスとしてクライアントに採用するデータベース·サービス及び / 又は他のタイプのデータ·ストレージ·サービスを提示し得る。いくつかの実施例では、ネットワークベース·サービスは、ネットワークを介した相互動作可能なマシンツーマシン対話をサポートするように設計されたソフトウェア及び / 又はハードウェア·システムによって実装され得る。ウェブ·サービスは、ウェブ·サービス記述言語(WSDL:Web Services Description Language)など、機械処理可能なフォーマットで記述されたインターフェースを有し得る。他のシステムは、ネットワークベース·サービスのインターフェースの説明によって規定された様式でネットワークベース·サービスと対話し得る。たとえば、ネットワークベース·サービスは、他のシステムが呼び出し得る様々な動作を定義し得、他のシステムが様々な動作を要求するときにそれに準拠することが期待され得る、特定のアプリケーション·プログラミング·インターフェース(API)を定義し得る。
[0054] 様々な実施例では、ネットワークベース·サービスは、ネットワークベース·サービス要求に関連付けられたパラメータ及び / 又はデータを含むメッセージの使用によって要求又は呼び出され得る。そのようなメッセージは、拡張可能マークアップ言語(XML:Extensible Markup Language)など特定のマークアップ言語に従ってフォーマットされ得、及び / 又はシンプル·オブジェクト·アクセス·プロトコル(SOAP:Simple Object Access Protocol)などのプロトコルを使用してカプセル化され得る。ネットワークベース·サービス要求を実行するために、ネットワークベース·サービス·クライアントは、要求を含むメッセージをアセンブリし、そのメッセージを、ハイパーテキスト転送プロトコル(HTTP)などのインターネットベース·アプリケーション·レイヤ転送プロトコルを使用して、ウェブ·サービスに対応するアドレス指定可能なエンドポイント(たとえば、ユニフォーム·リソース·ロケータ(URL))に伝達し得る。いくつかの実施例では、ネットワークベース·サービスは、メッセージベースの技法ではなくレプレゼンテーショナル·ステート·トランスファ(REST:Representational State Transfer)技法を使用して実装され得る。たとえば、REST技法に従って実装されたネットワークベース·サービスは、PUT、GET、又はDELETEなど、HTTPメソッドに含まれるパラメータを介して呼び出され得る。
[0055] 別段に明記されていない限り、本明細書で使用するすべての技術用語及び科学用語は、本発明が属する技術分野における当業者によって一般的に理解されるものと同じ意味を有する。本明細書で説明したものと同様の又は等価な任意の方法及び材料も本発明の実施又は試験において使用され得るが、本明細書では、限られた数の例示的な方法及び材料について説明した。本明細書における発明的概念から逸脱することなく、はるかに多い改変が可能であることが当業者に明らかになろう。
[0056] 本明細書で使用するすべての用語はコンテキストと一致する最も広い可能な様式で解釈されるべきである。特に、「含む(comprise)」及び「含む(comprising)」という用語は、非排他的な様式で、要素、構成要素、又はステップを指すと解釈されるべきであり、参照された要素、構成要素、又はステップは、明確に参照されていない他の要素、構成要素、若しくはステップと存在するか、又は利用されるか、又は組み合わせられ得ることを示す。本明細書でグループ化が使用されるとき、グループのすべての個々のメンバー、並びにグループの可能なすべての組合せ及びサブ副組合せは本開示中に個別に含まれるものとする。本明細書で範囲が述べられているとき、本開示は、特に、その範囲中のすべての点とその範囲内のすべての副範囲とを含むものとする。本明細書で引用されたすべての参考文献は、本明細書の開示との不一致がない限り、参照により本明細書に組み込まれる。
[0057] 本発明について、例示的なものにすぎず、添付の特許請求の範囲に記載されている本発明の全範囲に限定するものではない、いくつかの好ましい実施例及び代替実施例を参照しながら説明した。< / script>
Claims
1. It is a programmatic real-time bidding environment, A resolution provider system including an Application Programming Interface (API), A publisher system comprising a publisher digital property configured to receive a personal identifier from a user browser and transmit the personal identifier and a publisher-specific key to the resolution provider system by a call to the API, wherein the publisher-specific key corresponds to the publisher system among a plurality of different publisher systems in the programmatic real-time bidding environment, An identification information graph communicating with the resolution provider system, wherein the identification information graph includes a plurality of links, and the resolution provider system is configured to use the personal identifier to search the identification information graph in order to identify a link in the identification information graph that corresponds to an individual uniquely associated with the personal identifier. A publisher key database communicating with the resolution provider system, wherein the publisher key database includes a plurality of envelope keys, and the resolution provider system is configured to search the publisher key database using the publisher-specific key to find a publisher-specific envelope key from among the plurality of envelope keys, At least one supply-side platform (SSP) configured to receive the envelope, A sidecar communicating with the SSP is configured to receive the envelope from the SSP and decode the envelope using the publisher-specific envelope key in order to generate an encoded link for the platform. Includes, The resolution provider system is further configured to generate a publisher-specific encrypted identifier, create an envelope containing the encrypted identifier, and encrypt the identifier using the publisher-specific envelope key in order to send the envelope from the resolution provider system to the publisher system via the API. A programmatic real-time bidding environment in which the publisher system is further configured to set the envelope as a first-party cookie on the user browser.
2. The programmatic real-time bidding environment according to claim 1, further comprising a publisher subnetwork association database communicating with the resolution provider system, wherein the resolution provider system is configured to further receive authorized subnetwork indicators in the API, to look up the publisher subnetwork association database to identify subnetworks from within the programmatic real-time bidding environment in order to thereby restrict downstream use of the envelope, and to return the subnetworks to the publisher system.
3. The programmatic real-time bidding environment according to claim 2, wherein the sidecar is further configured to decode the envelope using the publisher-specific envelope key in order to generate a link encoded to the platform in real time.
4. The programmatic real-time bidding environment according to claim 3, wherein the SSP comprises at least one preferred SSP and at least one unpreferred SSP, the preferred SSP being configured to access the publisher-specific envelope key to generate a link encoded to the platform, but the unpreferred SSP not having access to the publisher-specific envelope key.
5. The system further includes a Sidecar Check-In Service (SCIS) communicating with the said sidecar, the SCIS being a Downstream Demand-Side Platform (DSP) The programmatic real-time bidding environment according to claim 4, configured to receive the subnetwork and the publisher-specific envelope key in order to allow access to the downstream demand-side platform (DSP) only if the subnetwork is a member of the subnetwork.
6. A system for activating without permitted cookies in a programmatic environment, An identification information graph, wherein the identification information graph includes multiple nodes corresponding to individuals and edges corresponding to relationships between individuals, In the aforementioned programmatic environment, a publisher key database containing multiple publisher keys corresponding to each of multiple publishers, It is a resolution provider system, Application Programming Interface (API) and One or more computer processors, The memory space containing the stored instructions This includes, and when the instruction is executed by the one or more computer processors, Receiving a personal identifier from one of the aforementioned multiple publishers, which is entered in a user browser communicating with the publisher system and presented to the API, Receiving a publisher-specific key presented in the API from one of the multiple publishers, wherein the publisher-specific key is associated only with one of the multiple publishers. To find a link in the identification information graph at a node in the identification information graph corresponding to an individual uniquely associated with the personal identifier, a search of the identification information graph is performed using the personal identifier; To find the publisher-specific envelope key corresponding to one of the aforementioned multiple publishers, a search of the publisher key database is performed using the publisher-specific key, To generate a publisher-specific encrypted identifier, the identifier is encrypted using the publisher-specific envelope key, Creating an envelope, wherein the envelope is a data structure containing a publisher-specific encrypted identifier, Sending the envelope to one of the plurality of publishers, wherein the one of the plurality of publishers can set the envelope as a first-party cookie on the user browser. A resolution provider system that causes one or more computer processors to perform the above-mentioned tasks. A system that includes this.
7. The memory space of the resolution provider system further has instructions stored therein, and when the instructions are executed by the one or more computer processors, The API receives an authorized subnetwork indicator, In order to thereby restrict the downstream use of the envelope, identify the subnetwork from within the programmatic environment, The subnetwork is returned to one of the multiple publishers. The system according to claim 6, wherein the one or more computer processors perform the above.
8. The present invention further includes a sidecar that communicates with a supply-side platform (SSP) that communicates with one of the aforementioned multiple publishers, and the sidecar communicates with a supply-side platform (SSP) that communicates with one of the aforementioned multiple publishers, One or more sidecar processors, The sidecar memory space contains the stored commands and This includes, and when the instruction is executed by one or more sidecar processors, Receiving an envelope from the SSP, wherein the SSP receives the envelope after it has been set in the user browser and read from the user browser. To generate a platform-encoded link, the envelope is decoded using the publisher-specific envelope key. The system according to claim 7, wherein the one or more sidecar processors perform the operation.
9. The system according to claim 8, further comprising instructions causing the one or more sidecar processors to decode the envelope using the publisher-specific envelope key in order to generate a platform-encoded link in real time when the sidecar memory space is executed by the one or more sidecar processors.
10. The system according to claim 9, further comprising instructions causing the one or more sidecar processors to send a platform-encoded link to at least one downstream demand-side platform (DSP) in the programmatic environment when the sidecar memory space is executed by the one or more sidecar processors.
11. The system according to claim 10, wherein when the sidecar memory space is executed by the one or more sidecar processors, the one or more sidecar processors cause the one or more sidecar processors to transmit the envelope to a preferred SSP and a non-preferred SSP, the preferred SSP having access to the publisher-specific envelope key to generate a link encoded to the platform, but the non-preferred SSP not having access to the publisher-specific envelope key.
12. The system further includes a sidecar check-in service (SCIS) that communicates with the sidecar, and the SCIS communicates with the sidecar. One or more SCIS processors, A SCIS memory space having instructions stored therein, wherein when the instructions are executed by the one or more SCIS processors, the downstream demand-side platform (DSP) In order to allow access to the downstream demand-side platform (DSP) only if the subnetwork is a member of the subnetwork, one or more SCIS processors are made to receive the subnetwork and the publisher-specific envelope key, with SCIS memory space and The system according to claim 11, including the following:
13. A computerized method for activating a programmatic real-time bidding environment without allowing cookies, wherein the method is: In a publisher system including publisher digital properties, the steps include receiving a personal identifier from the user's browser, A step of transmitting the encrypted personal identifier and publisher-specific key from the publisher system to the resolution provider system, wherein the publisher-specific key is associated only with the publisher system among a plurality of different publisher systems in the programmatic real-time bidding environment, The resolution provider system includes the steps of using the personal identifier to search the identification information graph in order to find a link in the identification information graph corresponding to an individual uniquely associated with the personal identifier, In the resolution provider system, the steps include: searching the publisher key database using the publisher-specific key in order to find the publisher-specific envelope key; To generate a publisher-specific encrypted identifier, the steps include: encrypting the identifier using the publisher-specific envelope key; In the resolution provider system, the step of creating an envelope is a step of creating an envelope in which the envelope is a data structure containing an encrypted identifier. The steps include sending the envelope from the resolution provider system to the publisher system, In the publisher system, the steps include setting the envelope on the user browser and Computerized methods, including those mentioned above.
14. The computerized method according to claim 13, wherein the resolution provider system includes an application programming interface (API) for receiving the personal identifier and the publisher-specific envelope key in an API call from the publisher system.
15. The computerized method according to claim 14, wherein the envelope further includes metadata.
16. The computerized method according to claim 14, wherein the step of setting the envelope on the user browser includes the step of setting a first-party cookie.
17. The steps include receiving an authorized subnetwork indicator in the API call of the resolution provider system, In the publisher subnetwork association database, the steps include identifying subnetworks from within the programmatic real-time bidding environment in order to thereby restrict the downstream use of the envelope, The steps of returning the subnetwork to the publisher system and The computerized method according to claim 14, further comprising:
18. The steps include: after the envelope is set in the user browser, the user browser reads the envelope and sends the envelope to the supply-side platform (SSP); The steps include sending the envelope to the sidecar associated with the SSP, In the sidecar, the steps include: decoding the envelope using the publisher-specific envelope key in order to generate a link encoded on the platform; The computerized method according to claim 17, further comprising:
19. The computerized method according to claim 18, further comprising the step of decoding the envelope using the publisher-specific envelope key in order to generate an encoded link to the platform in real time in the sidecar.
20. The computerized method according to claim 19, further comprising the step of sending a link encoded to the platform from the sidecar to at least one downstream demand-side platform (DSP) in the programmatic real-time bidding environment.
21. The computerized method according to claim 20, further comprising the steps of transmitting the envelope to a preferred SSP and a non-preferred SSP, wherein the preferred SSP has access to the publisher-specific envelope key to generate a link encoded to the platform, but the non-preferred SSP does not have access to the publisher-specific envelope key.
22. In the Sidecar Check-in Service (SCIS), the downstream demand-side platform (DSP The computerized method according to claim 21, further comprising the step of receiving the subnetwork and the publisher-specific envelope key in order to allow access to the downstream demand-side platform (DSP) only if the subnetwork is a member of the subnetwork.