Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application and Claims
This action is in reply to the application filed on 4/11/2025 and Applicant’s response to Examiner’s Restriction Requirement on 7/8/2026, Applicant elects Group I, claims 1-8, without traverse.
This communication is the first action on the merits.
Claims 1-20 is/are currently pending, claim 1-8 have been examined as per Applicant’s Election to Examiner’s Restriction Requirement, claim 9-20 are withdrawn from consideration.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 7 are rejected under is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as failing to set forth the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant(s) regard as their invention.
Claim 7 recites “…a browsing user has opted out of a category …”, “…a browsing user has opted out of a category …”, it is not clear if these elements refer to the same browsing user and same category. Appropriate correction is required.
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1 recites, “A … method (2700) of managing one or more tracking tools in a …, comprising:
receiving (2710), at a …, a request from a … comprising an identity graph comprising one or more entries for one or more identifiers associated with a user of the … for one or more marketing partners, …;
detecting (2720), … associated with the one or more marketing partners and identifying the user;
requesting (2730), from the one or more marketing partners, the one or more identifiers to place in the one or more entries of the …;
collecting (2750), by the …, one or more activities of the user …;
transmitting (2760) the one or more activities, enriched with the previously collected identity graph stored as …;
associating (2770), by the …, the one or more activities with an event format associated with each of the one or more marketing partners; and
forwarding (2780) the one or more activities to the one or more marketing partners according to the respective event format. ”
Analyzing under Step 2A, Prong 1:
The limitations regarding, …managing one or more tracking tools in a …, comprising: receiving (2710), at a …, a request from a … comprising an identity graph comprising one or more entries for one or more identifiers associated with a user of the … for one or more marketing partners, …; detecting (2720), … associated with the one or more marketing partners and identifying the user; requesting (2730), from the one or more marketing partners, the one or more identifiers to place in the one or more entries of the …; collecting (2750), by the …, one or more activities of the user …; transmitting (2760) the one or more activities, enriched with the previously collected identity graph stored as …; associating (2770), by the …, the one or more activities with an event format associated with each of the one or more marketing partners; and forwarding (2780) the one or more activities to the one or more marketing partners according to the respective event format.…., under the broadest reasonable interpretation, can include a human using their mind and using pen and paper to perform the above identified limitations, therefore, the claims recite a mental process.
Further, … managing one or more tracking tools in a …, comprising: receiving (2710), at a …, a request from a … comprising an identity graph comprising one or more entries for one or more identifiers associated with a user of the … for one or more marketing partners, …; detecting (2720), … associated with the one or more marketing partners and identifying the user; requesting (2730), from the one or more marketing partners, the one or more identifiers to place in the one or more entries of the …; collecting (2750), by the …, one or more activities of the user …; transmitting (2760) the one or more activities, enriched with the previously collected identity graph stored as …; associating (2770), by the …, the one or more activities with an event format associated with each of the one or more marketing partners; and forwarding (2780) the one or more activities to the one or more marketing partners according to the respective event format…, are human managing tools to track human activities for human marketing partners, which are, fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships or interactions between people, therefore the claims recite certain methods of organizing human activities.
Accordingly, the claims recite a mental process, certain methods of organizing human activities, and thus, the claims are directed to an abstract idea under the first prong of Step 2A.
Analyzing under Step 2A, Prong 2:
This judicial exception is not integrated into a practical application under the second prong of Step 2A.
In particular, the claims recite the additional elements beyond the recited abstract idea identified under Step 2A, Prong 1, such as:
Claim 1: computer implemented, browser (310, 315), website server (330, 340), browser for one or more website pages comprising the website, the one or more website pages comprising a tag (336) configured to load a cookie onto the browser, the cookie, the cookie defining a data format, by the tag, one or more cookie data, cookie, loading (2740), by the website server, the cookie onto the browser, on the one or more website pages, cookies, to one or more identity servers according to the data format
Claim 8: domain name system (DNS) addresses
, and pursuant to the broadest reasonable interpretation, as an ordered combination, each of the additional elements are computing elements recited at high level of generality implementing the abstract idea, and thus, are no more than applying the abstract idea with generic computer components.
Further, these additional elements generally link the abstract idea to a technical environment, namely the environment of a computer.
Additionally, with respect to, “…receiving…”, “…requesting…”, “….collecting…”, “…transmitting…”, “…forwarding…”, “…presenting…”, “…sending…”, “…receiving…”, “…sync…”, these elements do not add a meaningful limitations to integrate the abstract idea into a practical application because they are extra-solution activity, pre and post solution activity - i.e. data gathering – “…receiving…”, “…requesting…”, “….collecting…”, “…transmitting…”, “…sending…”, “…presenting…”, “…receiving…” data output – “…forwarding…”, “…sync…”
Analyzing under Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception under Step 2B.
As noted above, the aforementioned additional elements beyond the recited abstract idea are not sufficient to amount to significantly more than the recited abstract idea because, as an order combination, the additional elements are no more than mere instructions to implement the idea using generic computer components (i.e. apply it).
Additionally, as an order combination, the additional elements append the recited abstract idea to well-understood, routine, and conventional activities in the field as individually evinced by the applicant’s own disclosure, as required by the Berkheimer Memo, in at least:
[0003] There are a multitude of tracking technologies in use on the internet. The use of tags and cookies to track user behavior is well known. A given company may have various accounts that are all tracking their users’ behavior. For instance, a single user may be tracked by GoogleTM, MetaTM, TiktokTM, XTM/TwitterTM, and other accounts. Each of these parties may load a tag within the websites the user visits to track their online history and collect data about pages visited, items purchased, and more. While users give up their own data during these exchanges, so do websites. A user might visit burger-co.com, for example. During that visit Burger-Co’s website tags are tracking the user’s usage of the website, data that Home Depot and the user may want better controlled. Data collection by multiple browser tags can slow down Burger-Co’s website during a visit and expose data to 3rd-parties unnecessarily, reflecting poorly on Burger-Co in the mind of consumers and affecting the user’s likelihood to further engage (e.g., browse products, purchase, etc.).
[00048] There currently exist certain challenges to the handling of internet browser tags and other tracking technologies. A given user may have 10 or more cookies identifying them within downstream systems. And a given website may have 10 or more tags collecting user activity on the website, including those cookies. For example, a given website (website.com) may have marketing partnerships with e.g., Google, Meta, and others. Each marketing partner may install a tag on the website, and each tag may load software/cookies onto a user’s browser during their visit to website.com. If each tag is collecting and transmitting data when the user visits a website, this can slow down the user’s visit and their browser, possibly reflecting badly on the website owner and hurting their conversion rates. The website owner may also wish to prevent any fraudulent, disruptive, or unintended activity occurring as a result of a tag’s behavior on a user’s browser. The website owner may also wish to extract the maximum value from website interactions, through accurate reporting of data to maximize its own commercial relationships with advertisers and other third parties. This can be difficult if multiple tags are running on a user’s browser and each collecting unique data in unique formats. It is also challenging to ensure that each tag or cookie is complying with data privacy preferences by users and/or legal statutes prohibiting certain types of tracking or data collection
[00067] Sync injector design process 3100 can be performed by e.g., tag/identity sync system 350 and/or tag/identity server(s) 360 of Figure 6, or by other computing device embodiments described herein. Regarding terminology, a distinction should be made between a ‘sync injector’ and a ‘sync module’ as used herein. For purposes of the present disclosure, a sync injector refers to the full code library/framework provided by system 50 or 300 (e.g., tracking servers 340 of Figure 6) for the purpose of the site owner deploying this library on their website in order to execute many different forms of synchronization with its various commercial marketing partners, such as Google Ads, Facebook, etc. For example, sync system 350 may provide a sync injector to ABC Company for use on abccompany.com. That sync injector can manage synchronization with e.g., Google Ads, TikTok, etc. A ‘sync module’ refers to partner-specific code deployed by the sync injector. For example, a sync injector for abccompany.com can deploy, e.g., a Google Ads sync module for interfacing/synchronizing data with Google Ads, a TikTok sync module for interfacing/synchronizing data with Tiktok, etc. As further described below, various sync injectors or sync modules may be created/deployed by/shared by tag/identity sync system 350 of Figure 6 for use by e.g., website server 330 to provide website(s) 332 for user 305 to browse. A given sync injector (e.g., for abccompany.com) may comprise any number of individual sync modules for each of the commercial partners that ABC Company wishes to integrate. A sync injector may comprise or be populated with additional modules for other tasks, e.g., PII-related functionality, cross domain syncing, or other modules.
[00072] Returning to step 3190, the builder server retrieves core sync injector code from sync injector core library 3185 to build a new sync injector for e.g., ABC Company. The builder server can then take the information received from steps 3105 to 3170 (for specific vendors, cross domain modules, and/or PII modules) and populate the appropriate vendor logic retrieved from main sync module repository 3180, and retrieve any custom built sync modules from custom built sync module repository 3155. The builder server can then populate the core sync injector code with e.g., sync modules for the customer’s desired vendors (Facebook, X, etc.) populated with information collected, any custom-built sync modules 3155, cross domain module(s) if desired, and/or PII module(s) if desired, and build the sync injector to be used at abccompany.com.
[00085] At 3310, a cross-domain ID is collected. This may identify a user/website visitor, such as a username, email address, number ID, or other identifier that identifies a user with respect to e.g., a Google account, Facebook account, X account, etc. In certain embodiments the ID may be anonymized or edited or redacted to remove personally identifying information. At 3320, a redirect chain is triggered according to a supplied endpoint list. This list may provide instructions/APIs/server addresses for confirming or authenticating the collected cross-domain IDs. At 3330, the redirect chain hits each A-record (address record) endpoint in priority order. Orders of priority can be set in a variety of ways. At 3340, the process can check each cross-domain ID with each related vendor site (e.g., site1.com, site2.com, etc.) via communicating with each vendor’s website/domain (e.g., their DNS layer A-record). At 3350, the customer (e.g. website manager or owner) system may ingest information received from the vendor sites. At 3360, the customer logic can check if a cross-domain ID header exists for each successive A-record. At 3370, if an existing ID is found, then the cross-domain ID and/or related information can be returned to the client/browser. This ID or related information can be collected and stored with user data that is further processed with regard to other processes as described herein, such as identity syncing process 120 of Figure 2.
[00094] Figure 8 shows a schematic block diagram of a computing device 2500 (or components thereof) according to certain embodiments of the present disclosure. Computing device 2500 can comprise portions or more of e.g., user devices 310, 315, website server(s) 330, tracking server(s) 340, tag/identity system 350, and/or tag/identity server 360 or other types of computing devices as described further below in other embodiments. Computing device 2500 may comprise computers, smartphones, tablets, servers, databases, other computing devices, and/or combinations of the foregoing. Components of computing device 2500 could in some embodiments be distributed across multiple physical hardware components or locations. Computing device 2500 may be configured to perform a variety of functionalities and/or methods described herein, including the functionalities described or illustrated with respect to Figures 1 to 5 and other figures and embodiments described below.
[00095] Computing device 2500 includes processor 2501 that is operatively coupled via a bus 2502 to an input/output interface 2505, a power source 2513, a memory 2515, a RF interface 2509, network communication interface 2511, and/or any other component, or any combination thereof. Certain computing devices 2500 may utilize all or a subset of the components shown in e.g., Figure 8 or other figures. The level of integration between the components may vary from one embodiment to another. Further, certain computing device 2500 (or components thereof) may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.
[00096] The processor 2501 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in memory 2515. Processor 2501 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processor 2501 may include multiple central processing units (CPUs).
[00097] In the example, input/output interface 2505 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices, such as screen 2506. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into computing device 2500. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.
[00098] In some embodiments, the power source 2513 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 2513 may further include power circuitry for delivering power from the power source 2513 itself, and/or an external power source, to the various parts of computing device 2500 via input circuitry or an interface such as an electrical power cable.
[00099] Memory 2515 may be configured to include memory such as random-access memory (RAM) 2517, read-only memory (ROM) 2519, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, other storage medium 2521, and so forth. In one example, the memory 2515 includes one or more application programs 2525, an operating system 2523, web browser application, a widget, gadget engine, or other application, and corresponding data 2527. Memory 2515 may store, for use by the computing device 2500, any of a variety of various operating systems or combinations of operating systems. An article of manufacture, such as one including a simulation system or communication system may be tangibly embodied as or in memory 2515, which may be or comprise a device-readable storage medium.
[000100] Processor 2501 may be configured to communicate with an access network or other network using the RF interface 2509 or network connection interface 2511. The RF interface 2509 or network connection interface 2511 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna. In the illustrated embodiment, communication functions of the RF interface 2509 or network connection interface 2511 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof.
[000101] Although the computing devices described herein (e.g., servers, computers, databases, etc.) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.
[000102] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.
[000103] It will be appreciated that computer systems are increasingly taking a wide variety of forms. In this description and in the claims, the terms “controller,” “computer system,” or “computing system” are defined broadly as including any device or system—or combination thereof—that includes at least one physical and tangible processor and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. By way of example, not limitation, the term “computer system” or “computing system,” as used herein is intended to include personal computers, desktop computers, laptop computers, tablets, hand-held devices (e.g., mobile telephones, PDAs, pagers), microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, multi-processor systems, network PCs, distributed computing systems, datacenters, message processors, routers, switches, and even devices that conventionally have not been considered a computing system, such as wearables (e.g., glasses).
[000104] The computing system also has thereon multiple structures often referred to as an “executable component.” For instance, the memory of a computing system can include an executable component. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods, and so forth, that may be executed by one or more processors on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media. The structure of the executable component exists on a computer-readable medium in such a form that it is operable, when executed by one or more processors of the computing system, to cause the computing system to perform one or more functions, such as the functions and methods described herein. Such a structure may be computer-readable directly by a processor—as is the case if the executable component were binary. Alternatively, the structure may be structured to be interpretable and/or compiled—whether in a single stage or in multiple stages—so as to generate such binary that is directly interpretable by a processor.
[000105] The terms “component,” “service,” “engine,” “module,” “control,” “generator,” or the like may also be used in this description. As used in this description and in this case, these terms—whether expressed with or without a modifying clause—are also intended to be synonymous with the term “executable component” and thus also have a structure that is well understood by those of ordinary skill in the art of computing.
[000106] In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer, processor, and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term “processor” or “controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
[000107] In general, the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor, or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques, or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
[000108] While not all computing systems require a user interface, in some embodiments a computing system includes a user interface for use in communicating information from/to a user. The user interface may include output mechanisms as well as input mechanisms. The principles described herein are not limited to the precise output mechanisms or input mechanisms as such will depend on the nature of the device. However, output mechanisms might include, for instance, speakers, displays, tactile output, projections, holograms, and so forth. Examples of input mechanisms might include, for instance, microphones, touchscreens, projections, holograms, cameras, keyboards, stylus, mouse, or other pointer input, sensors of any type, and so forth.
Furthermore, as an ordered combination, these elements amount to generic computer components receiving or transmitting data over a network, performing repetitive calculations, electronic record keeping, and storing and retrieving information in memory, which, as held by the courts, are well-understood, routine, and conventional. See MPEP 2106.05(d).
Moreover, the remaining elements of dependent claims do not transform the recited abstract idea into a patent eligible invention because these remaining elements merely recite further abstract limitations that provide nothing more than simply a narrowing of the abstract idea recited in the independent claims.
Looking at these limitations as an ordered combination adds nothing additional that is sufficient to amount to significantly more than the recited abstract idea because they simply provide instructions to use a generic arrangement of generic computer components to “apply” the recited abstract idea, perform insignificant extra-solution activity, and generally link the abstract idea to a technical environment. Thus, the elements of the claims, considered both individually and as an ordered combination, are not sufficient to ensure that the claim as a whole amounts to significantly more than the abstract idea itself. Since there are no limitations in these claims that transform the exception into a patent eligible application such that these claims amount to significantly more than the exception itself, claims 1-8 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-8 is/are rejected under 35 U.S.C. 102 as being unpatentable by US Patent Publication to US20110022681A1 to Simeonov, (hereinafter referred to as “Simeonov”).
As Claim 1, Simeonov teaches: A computer implemented method (2700) of managing one or more tracking tools in a browser (310, 315), comprising: ([0015])
receiving (2710), at a website server (330, 340), a request from a browser for one or more website pages comprising the website, the one or more website pages comprising a tag (336) configured to load a cookie onto the browser, the cookie comprising an identity graph comprising one or more entries for one or more identifiers associated with a user of the browser for one or more marketing partners, the cookie defining a data format; (in at least [0015] Affiliate. An organization that controls, is controlled by, or is under common control, with, another organization... First Party. First Party is an entity that is the owner of an entity a consumer knowingly has visible interactions with or has Control over this entity and its Affiliate Web sites…Intermediary 100. An entity (business or machine, program or process) that observes or participates in a targeting interaction between a consumer and a first party. For example, if a consumer accesses www.cnn.com from their browser at home, the browser, a privacy protection plugin in the browser, the anti-virus/spyware system on the consumer's PC that monitors HTTP traffic, the home router and the consumer's Internet access provider could be examples of intermediaries…Policy engine 102. A machine, program or process which takes part in determining how a targeting interaction would complete. A policy engine works with zero or more policy and profile stores (optionally via their managers) and zero or more policy engines. Policy manager 104. A machine, program or process which optionally manages operations on one or more policy stores (optionally via their managers). In typical embodiments the policy manager allows policy stores to be accessed remotely with appropriate levels of security, availability, reliability and performance. Policy managers play an important role in the disclosed architecture as they allow the possibility of a user's policy to be discovered and retrieved by an entity under the right conditions without a specific interaction between the user and the entity. For example, an ad exchange may be given the right to know that a certain user has opted out of AdNetA and AdNetB but has opted into AdNetC, information which may significantly affect the outcome of a targeting interaction as well as may eliminate some of the need of frequent redirecting of ad targeting request in the case of Web sites. Policy managers may use protocols, such as XDI (eXtensible Data Interchange) and the like, to share, synchronize and link data between themselves and profile managers. They are preferably discoverable via a number of mechanisms including, but not limited to registries, XRDS, etc. Policy store 106. The logical place where targeting policy information about an entity is kept. [0039] When the user's browser requests a URL from the manager cookies or other information may be passed which allow the manager to identify the user…Third Party. An entity is a Third Party to the extent that it engages in targeting on non-Affiliate's places of presence (sites, applications, etc.) [0057] an HTTP header identifying a policy in URI space would be a good implementation option as, differently from cookies, it can be sent to all URLs and it can support multiple policies. [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine [0075] Some pieces of information may belong in both policies and profiles. For example, an opt-out or opt-in statement in a user's policy may have representation as opt-out and opt-in flags and other data in that user's profiles managed by various participants in targeting interactions. [0076] Profile content and processing preferably are entity- and implementation-specific to a large extent. However, there are certain aspects of profiles, especially those referring to PII and industry-standard concepts such as opt-in, opt-out, visit lists/graphs, categories and keywords associated with the profile. Those would benefit from having a standardized representation which would make it easier for managers (privacy, profile and policy) and targeting engines to communicate. If there is no standardized representation, the various manager components can provide value-added functionality that enables interoperability. [0105] The policy fragment preferably has one binary piece of data: whether a user chooses to opt out or not. The scope preferably applies to domains and IP addresses under the control of entities the user chooses to opt out of. The privacy manager simplifies the process of users identifying their opt-out scope, e.g., by showing known entity names and behind the scenes mapping those to a set of URLs. The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains. UserInControl makes a reasonable effort to maintain an up-to-date registry of entities allowing opt-out via cookies and the specific format of these cookies that can be used by policy engines looking to encode the opt-out policy fragment in cookie form. [0108] the policy engine is embedded in an intermediary on the user's device such as a browser plugin developed by UserInControl. In addition to offering the policy engine in the form of a plugin or other software integrated into an intermediary, UserInControl may offer a web page which through a series of HTTP requests (typically, appropriately parameterized redirects) to entities that (a) the user has chosen to opt out of and (b) support opt-out cookies installs these opt-out cookies on a user's device. In a way, the code behind this web pages acts as a crude policy engine. [0144] This architecture can be integrated with such a privacy-safe ad targeting system. One such ad targeting system uses a synthetic construct, referred to as an audience certification assertion (ACA) or audience query tag (AQT), which is designed to be independent of any given request for an ad and any given consumer profile. A given ACA encapsulates a request or query for certain contextual, behavioral and/or demographic information into an opaque, effectively invisible token. In this manner, the privacy risk associated with such information is concentrated in the entity that creates and manages the ACA tokens. Advertisers create campaigns using the tokens, and ad serving technologies use the tokens to determine which ads to serve in response to given ad requests. The token certifies that the ad that is about to be displayed satisfies the targeting criteria associated with the request, and that the request has been satisfied in a privacy-safe manner. [0152] the switch can happen at any point in the interaction path. It can happen on the user's device, e.g., via modifying the contents of a Web page. It can happen at an intermediary. It can happen at the target by the target's ad server including an ad tag for the user's targeting engine.)
detecting (2720), by the tag, one or more cookie data associated with the one or more marketing partners and identifying the user; (in at least [0039] in the case of HTTP, this can happen via an HTTP request header with a URL that points to a location where the user policy can be downloaded. Other HTTP variations may include URL parameters, cookies, etc. [0052] organization may maintain a machine-readable registry of members that are in compliance and together with the URI spaces they manage as first parties. Policy engines may know to check that registry and cache this information to expedite processing. For interactions with entities that support the policy, the policy engine may then modify interaction context appropriately. For example, it may add an opt-out cookie with a particular name and value or a specially formatted HTTP header to indicate a user's opt-out status. [0056] whenever enabled by the protocol, it is desirable to have a mechanism for identifying multiple policies in the same interaction so that intermediaries can be supported. One possible approach is to have a single reference to a dynamic policy managed by a single policy manager such that intermediaries, rather an inserting additional policy fragments or references to such, augment the dynamic policy by communicating with the policy manager. [0057] an HTTP header identifying a policy in URI space would be a good implementation option as, differently from cookies, it can be sent to all URLs and it can support multiple policies. [0099] a policy engine may modify interaction context to enforce certain policies. For example, currently many P3P engine would delete (or deny the ability to set) third party cookies if the user so requests. In another example, a policy engine may automatically delete known tracking cookies if a user requests that.)
requesting (2730), from the one or more marketing partners, the one or more identifiers to place in the one or more entries of the cookie, loading (2740), by the website server, the cookie onto the browser; (in at least [0039] When the user's browser requests a URL from the manager cookies or other information may be passed which allow the manager to identify the user. [0052] Policy engines may know to check that registry and cache this information to expedite processing. For interactions with entities that support the policy, the policy engine may then modify interaction context appropriately. For example, it may add an opt-out cookie with a particular name and value or a specially formatted HTTP header to indicate a user's opt-out status. [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie.)
collecting (2750), by the cookie, one or more activities of the user on the one or more website pages; (in at least [0080] Tracking relates to the fact that in traditional advertising approaches various third parties that a user often has no relation with have the ability to recognize the user across multiple requests (pages, sites, etc.). Through tracking third parties can collect a stream of information based on user activities. Tracking is typically used for profile building. Profile building describes the ability of these third parties to derive a set of information about the user. Typically, profiles are developed as a result of direct tracking of users. However, profiles can also be developed independently using a number of techniques such as third party database integration, capturing ad targeting information provided by the entity selling the ad space, etc. One of the most troubling parts of existing profile architectures is that there is no good way to ascertain which party ends up with which profile data. This typically happens due to profile leakage, a term referring to the fact that to execute a targeted ad request the requester, e.g., a Web publisher, may often send targeting information to the ad provider, e.g., an ad network, with the goal of receiving an ad that will monetize better. Therefore, the ad request itself reveals or leaks some profile information, e.g., gender, age range, interests, etc. to the ad provider. [0085] It should be noted that a click (or other activation, e.g., an SMS response) to an ad may eventually take the user to a place controlled either by an advertiser or someone focused on ad delivery (ad network, exchange, etc.). At that point, little can be done to prevent these third parties from attempting to track user behavior. One approach is contractual. As above, compliance can be monitored through statistical testing. Another approach is to remove (de-parameterize) the target of engagement, e.g., have all differently targeted audience groups for the same campaign land on the same Web page.)
transmitting (2760) the one or more activities, enriched with the previously collected identity graph stored as cookies, to one or more identity servers according to the data format; (in at least [0015] The privacy manager then may allow the user to modify her policy such that she opts out of behavioral targeting with AdNetA, which would also modify her profile stored at AdNetA accordingly. It may also allow her to switch her category of interest from baseball to football with AdNetB, which would also modify her profile there. A privacy manager typically has user-facing UI. [0076] profiles, especially those referring to PII and industry-standard concepts such as opt-in, opt-out, visit lists/graphs, categories and keywords associated with the profile. Those would benefit from having a standardized representation which would make it easier for managers (privacy, profile and policy) and targeting engines to communicate. If there is no standardized representation, the various manager components can provide value-added functionality that enables interoperability. [0080] Tracking relates to the fact that in traditional advertising approaches various third parties that a user often has no relation with have the ability to recognize the user across multiple requests (pages, sites, etc.). Through tracking third parties can collect a stream of information based on user activities. Tracking is typically used for profile building. Profile building describes the ability of these third parties to derive a set of information about the user. Typically, profiles are developed as a result of direct tracking of users. However, profiles can also be developed independently using a number of techniques such as third party database integration, capturing ad targeting information provided by the entity selling the ad space, etc. One of the most troubling parts of existing profile architectures is that there is no good way to ascertain which party ends up with which profile data. This typically happens due to profile leakage, a term referring to the fact that to execute a targeted ad request the requester, e.g., a Web publisher, may often send targeting information to the ad provider, e.g., an ad network, with the goal of receiving an ad that will monetize better. Therefore, the ad request itself reveals or leaks some profile information, e.g., gender, age range, interests, etc. to the ad provider. [0084] To address the targeting issue at a fundamental level the ability of ad providers to track (through cookies in the web domain, for example) must be significantly limited. This can happens in one of two ways. If there is trust, it can happen contractually. If there is no trust, it happens through some type of proxying mechanism that would be protocol-specific and application architecture-specific. [0085] It should be noted that a click (or other activation, e.g., an SMS response) to an ad may eventually take the user to a place controlled either by an advertiser or someone focused on ad delivery (ad network, exchange, etc.). At that point, little can be done to prevent these third parties from attempting to track user behavior. One approach is contractual. As above, compliance can be monitored through statistical testing. Another approach is to remove (de-parameterize) the target of engagement, e.g., have all differently targeted audience groups for the same campaign land on the same Web page. [0105] The policy fragment preferably has one binary piece of data: whether a user chooses to opt out or not. The scope preferably applies to domains and IP addresses under the control of entities the user chooses to opt out of. The privacy manager simplifies the process of users identifying their opt-out scope, e.g., by showing known entity names and behind the scenes mapping those to a set of URLs. The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains. UserInControl makes a reasonable effort to maintain an up-to-date registry of entities allowing opt-out via cookies and the specific format of these cookies that can be used by policy engines looking to encode the opt-out policy fragment in cookie form. [0106] The ideal policy engine on the user side looks at the domain or IP address of an HTTP request and, based on that context and the user's policy, modifies the outgoing HTTP request to either add an opt-out cookie and/or an opt-out header and, if the user so requires, a global opt-out header (which will go out with every HTTP request). In addition, the ideal policy engine implementation preferably includes an HTTP header with a link to the user's policy manager at UserInControl. The policy engine may reject known tracking cookies for entities the user has opted out of even if there is no known way to communicate an opt-out request to those entities or if they have for some reason failed to act on the opt-out request.)
associating (2770), by the one or more identity servers (360), the one or more activities with an event format associated with each of the one or more marketing partners; and (in at least [0085] It should be noted that a click (or other activation, e.g., an SMS response) to an ad may eventually take the user to a place controlled either by an advertiser or someone focused on ad delivery (ad network, exchange, etc.). At that point, little can be done to prevent these third parties from attempting to track user behavior. One approach is contractual. As above, compliance can be monitored through statistical testing. Another approach is to remove (de-parameterize) the target of engagement, e.g., have all differently targeted audience groups for the same campaign land on the same Web page. [0144] Advertisers create campaigns using the tokens, and ad serving technologies use the tokens to determine which ads to serve in response to given ad requests. The token certifies that the ad that is about to be displayed satisfies the targeting criteria associated with the request, and that the request has been satisfied in a privacy-safe manner. [0170] To reduce the costs of user management and to improve interoperability among enterprises, federated computing spaces have been created. A federation is a loosely-coupled affiliation of enterprises that adhere to certain standards of interoperability. The federation provides a mechanism for trust among those enterprises with respect to certain computational operations for the users within the federation. As one of ordinary skill in the art will appreciate, aspects of the disclosed architecture may be implemented across a “federation.” Thus, for example, most ad networks, data aggregators, and ad exchanges store information about users to use for targeting more relevant ads. This information ranges from simple opt-out preferences, which will opt out a user from being tracked and/or targeting by an entity, to information about users' behaviors and interests. Managing these preferences is difficult. For example, there is no easy way for a consumer to opt out of tracking by a set of entities by policy, i.e., if a user wishes to allow tracking only by companies that do not share their data with third parties, the consumer would have to visit the privacy policy pages of multiple networks, digest that information, and opt-out individually of them by locating the opt out link on each of those companies' web sites. Although some companies are beginning to expose to users exactly what they know about them (and to offer consumers a way to add, delete, and edit that information), consumers still have to visit each of those companies' web sites separately to perform these actions. According to this disclosure, federated consumer preference management data is captured and maintained across mobile/online with respect to ad targeting information. In one embodiment, a federated API provides a toolkit that enables any third party to build consumer-facing transparency tools. An opt-out and preferences federation API is set of services that allow th8ird parties to build consumer-facing tools that help consumers manage these types of preferences globally (i.e., in one place and across all networks, exchanges, etc.).)
forwarding (2780) the one or more activities to the one or more marketing partners according to the respective event format. (in at least [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0105] The policy fragment preferably has one binary piece of data: whether a user chooses to opt out or not. The scope preferably applies to domains and IP addresses under the control of entities the user chooses to opt out of. The privacy manager simplifies the process of users identifying their opt-out scope, e.g., by showing known entity names and behind the scenes mapping those to a set of URLs. The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains. UserInControl makes a reasonable effort to maintain an up-to-date registry of entities allowing opt-out via cookies and the specific format of these cookies that can be used by policy engines looking to encode the opt-out policy fragment in cookie form. [0151] if Bob loves his Toyota Prius, he may prefer to elect Toyota as the sponsor of all auto-related sites he visits via the SponsorYourself ad network. The network guarantees $5 eCPM payout. If NewHybridVehicles.com's web site is willing to accept a targeting engine switch for payouts above $4 eCPM, the targeting engine switch can happen.)
As Claim 2, Simeonov teaches: The method of claim 1, further comprising
monitoring the transmitting and the requesting for one or more metrics. (in at least [0150] A policy negotiation may be used to activating this type of targeting engine instead of the default targeting engine that the entity delivering the ads/content chooses to use. For example, if a user's policy specifies that they have this capability enabled on a given device under certain arrangements (compensation, for example) and if the interaction target's policy specifies that it is open to targeting engine replacement under certain arrangement (guaranteed minimum eCPM, for example) and if the policy engines determine that there is overlap in the arrangements, then the user-configured targeting engine may be activated. [0151] if Bob loves his Toyota Prius, he may prefer to elect Toyota as the sponsor of all auto-related sites he visits via the SponsorYourself ad network. The network guarantees $5 eCPM payout. If NewHybridVehicles.com's web site is willing to accept a targeting engine switch for payouts above $4 eCPM, the targeting engine switch can happen.)
As Claim 3, Simeonov teaches: The method of claim 1, wherein the one or more activities comprise at least one of:
page visits; purchase amount; clicks; videos watched; advertisements clicked on. (in at least [0080] Tracking relates to the fact that in traditional advertising approaches various third parties that a user often has no relation with have the ability to recognize the user across multiple requests (pages, sites, etc.). Through tracking third parties can collect a stream of information based on user activities. Tracking is typically used for profile building. Profile building describes the ability of these third parties to derive a set of information about the user. Typically, profiles are developed as a result of direct tracking of users. However, profiles can also be developed independently using a number of techniques such as third party database integration, capturing ad targeting information provided by the entity selling the ad space, etc. One of the most troubling parts of existing profile architectures is that there is no good way to ascertain which party ends up with which profile data. This typically happens due to profile leakage, a term referring to the fact that to execute a targeted ad request the requester, e.g., a Web publisher, may often send targeting information to the ad provider, e.g., an ad network, with the goal of receiving an ad that will monetize better. Therefore, the ad request itself reveals or leaks some profile information, e.g., gender, age range, interests, etc. to the ad provider. [0084] To address the targeting issue at a fundamental level the ability of ad providers to track (through cookies in the web domain, for example) must be significantly limited. This can happens in one of two ways. If there is trust, it can happen contractually. If there is no trust, it happens through some type of proxying mechanism that would be protocol-specific and application architecture-specific. [0085] It should be noted that a click (or other activation, e.g., an SMS response) to an ad may eventually take the user to a place controlled either by an advertiser or someone focused on ad delivery (ad network, exchange, etc.). At that point, little can be done to prevent these third parties from attempting to track user behavior. One approach is contractual. As above, compliance can be monitored through statistical testing. Another approach is to remove (de-parameterize) the target of engagement, e.g., have all differently targeted audience groups for the same campaign land on the same Web page. [0150] A policy negotiation may be used to activating this type of targeting engine instead of the default targeting engine that the entity delivering the ads/content chooses to use. For example, if a user's policy specifies that they have this capability enabled on a given device under certain arrangements (compensation, for example) and if the interaction target's policy specifies that it is open to targeting engine replacement under certain arrangement (guaranteed minimum eCPM, for example) and if the policy engines determine that there is overlap in the arrangements, then the user-configured targeting engine may be activated. [0151] if Bob loves his Toyota Prius, he may prefer to elect Toyota as the sponsor of all auto-related sites he visits via the SponsorYourself ad network. The network guarantees $5 eCPM payout. If NewHybridVehicles.com's web site is willing to accept a targeting engine switch for payouts above $4 eCPM, the targeting engine switch can happen.)
As Claim 4, Simeonov teaches: The method of claim 1,
wherein the one or more marketing partners comprise at least one of: Twitter/X; Google; Facebook; Meta; Pinterest. (in at least [0006] A variation of the do not contact database is an opt-out program such as the one that allows users of Google services to opt out of behavioral targeting. In a common embodiment, opt-out programs are implemented on the Internet through opt-out cookies stored in consumers' browsers. This is a highly unreliable approach as cookies disappear due to expiration, software updates, cookie store resets and other factors. [0170] To reduce the costs of user management and to improve interoperability among enterprises, federated computing spaces have been created. A federation is a loosely-coupled affiliation of enterprises that adhere to certain standards of interoperability. The federation provides a mechanism for trust among those enterprises with respect to certain computational operations for the users within the federation. As one of ordinary skill in the art will appreciate, aspects of the disclosed architecture may be implemented across a “federation.” Thus, for example, most ad networks, data aggregators, and ad exchanges store information about users to use for targeting more relevant ads.)
As Claim 5, Simeonov teaches: The method of claim 1,
wherein at least one of the one or more identifiers comprises personally identifying information (PII). (in at least [0075] Some pieces of information may belong in both policies and profiles. For example, an opt-out or opt-in statement in a user's policy may have representation as opt-out and opt-in flags and other data in that user's profiles managed by various participants in targeting interactions. [0076] Profile content and processing preferably are entity- and implementation-specific to a large extent. However, there are certain aspects of profiles, especially those referring to PII and industry-standard concepts such as opt-in, opt-out, visit lists/graphs, categories and keywords associated with the profile. Those would benefit from having a standardized representation which would make it easier for managers (privacy, profile and policy) and targeting engines to communicate. If there is no standardized representation, the various manager components can provide value-added functionality that enables interoperability.)
As Claim 6, Simeonov teaches: The method of claim 1, further comprising:
receiving (4510), from a client user, identification of one or more consent categories; (in at least [0075] Some pieces of information may belong in both policies and profiles. For example, an opt-out or opt-in statement in a user's policy may have representation as opt-out and opt-in flags and other data in that user's profiles managed by various participants in targeting interactions.)
presenting (4520), to the user, the one or more consent categories; (in at least [0039] users have their own policies describing their preferences or requirements for participating in targeting interactions, at a minimum specifying opt-out and opt-in status within a certain scope. Scope can refer to entities, e.g., relative to certain targets, their affiliates and third parties, or location or other relevant restrictions. [0104] User preferences with respect to opt-out are managed in a centralized policy store via a remotely accessible policy manager with a well-known URL controlled by an entity (UserInControl). UserInControl also runs a privacy manager allowing users to open accounts and manage their opt-out settings in one place. The privacy manager allows users the option of a global opt-out of any currently known and known in the future behavioral targeting programs. [0105] The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains.)
receiving (4530), from the user, one or more preferences for the one or more consent categories; and (in at least [0039] users have their own policies describing their preferences or requirements for participating in targeting interactions, at a minimum specifying opt-out and opt-in status within a certain scope. Scope can refer to entities, e.g., relative to certain targets, their affiliates and third parties, or location or other relevant restrictions. [0104] User preferences with respect to opt-out are managed in a centralized policy store via a remotely accessible policy manager with a well-known URL controlled by an entity (UserInControl). UserInControl also runs a privacy manager allowing users to open accounts and manage their opt-out settings in one place. The privacy manager allows users the option of a global opt-out of any currently known and known in the future behavioral targeting programs. [0105] The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains.)
combining (4550) the one or more preferences to the one or more activities. (in at least [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0105] The policy fragment preferably has one binary piece of data: whether a user chooses to opt out or not. The scope preferably applies to domains and IP addresses under the control of entities the user chooses to opt out of. The privacy manager simplifies the process of users identifying their opt-out scope, e.g., by showing known entity names and behind the scenes mapping those to a set of URLs. The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains. UserInControl makes a reasonable effort to maintain an up-to-date registry of entities allowing opt-out via cookies and the specific format of these cookies that can be used by policy engines looking to encode the opt-out policy fragment in cookie form. [0106] The ideal policy engine on the user side looks at the domain or IP address of an HTTP request and, based on that context and the user's policy, modifies the outgoing HTTP request to either add an opt-out cookie and/or an opt-out header and, if the user so requires, a global opt-out header (which will go out with every HTTP request). In addition, the ideal policy engine implementation preferably includes an HTTP header with a link to the user's policy manager at UserInControl. The policy engine may reject known tracking cookies for entities the user has opted out of even if there is no known way to communicate an opt-out request to those entities or if they have for some reason failed to act on the opt-out request.)
As Claim 7, Simeonov teaches: The method of claim 1, further comprising:
receiving (4710) one or more preferences of the user related to tracking data; (in at least [0104] User preferences with respect to opt-out are managed in a centralized policy store via a remotely accessible policy manager with a well-known URL controlled by an entity (UserInControl). UserInControl also runs a privacy manager allowing users to open accounts and manage their opt-out settings in one place. The privacy manager allows users the option of a global opt-out of any currently known and known in the future behavioral targeting programs. [0107] the implementation shows the user their opt-out status as he or she is navigating the Web.)
storing (4720) the one or more preferences in the browser; (in at least [0108] the policy engine is embedded in an intermediary on the user's device such as a browser plugin developed by UserInControl. In addition to offering the policy engine in the form of a plugin or other software integrated into an intermediary, UserInControl may offer a web page which through a series of HTTP requests (typically, appropriately parameterized redirects) to entities that (a) the user has chosen to opt out of and (b) support opt-out cookies installs these opt-out cookies on a user's device. In a way, the code behind this web pages acts as a crude policy engine.)
configuring (4730) whether implicit mode or explicit mode is applicable to the website’s compliance settings; (in at least [0058] Policy processing preferably is governed by the active policy set, the interaction context and the policy engine. Some aspects of policy engine processing may be standardized. Some aspects may be implicitly governed by the prevailing regulatory climate and industry best practices. [0059] Preferably, the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine,)
if implicit mode is applicable, then performing the steps of; (in at least [0128] This example allows for some interesting uses of intermediaries. Consider the following situation. In a family, concerned parents can deploy technology that attempts to block adult content so that their underage children are not exposed to it. But people bringing their own computers to the home may not have such software installed and may expose the children to adult content. The likelihood of this happening can be diminished if a network intermediary, e.g., the home router, could augment HTTP requests with a header requesting that adult content is not returned. For example, this would automatically, temporarily, turn on safe search flags for compliant search engines even if the visiting friend hasn't explicitly requested that.)
executing (4740) syncs unless the browsing user opts out of tracking one or more categories; and (in at least [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0073] policy engines may need to communicate with multiple policy managers, some of which may not be on the same device as the policy engine. This enables aggregation of policy across devices. Of course, typical optimizations such as caching or multi-master data synchronization can be applied. [0106] The ideal policy engine on the user side looks at the domain or IP address of an HTTP request and, based on that context and the user's policy, modifies the outgoing HTTP request to either add an opt-out cookie and/or an opt-out header and, if the user so requires, a global opt-out header (which will go out with every HTTP request). In addition, the ideal policy engine implementation preferably includes an HTTP header with a link to the user's policy manager at UserInControl. The policy engine may reject known tracking cookies for entities the user has opted out of even if there is no known way to communicate an opt-out request to those entities or if they have for some reason failed to act on the opt-out request. [0170] if a user wishes to allow tracking only by companies that do not share their data with third parties, the consumer would have to visit the privacy policy pages of multiple networks, digest that information, and opt-out individually of them by locating the opt out link on each of those companies' web sites. Although some companies are beginning to expose to users exactly what they know about them (and to offer consumers a way to add, delete, and edit that information), consumers still have to visit each of those companies' web sites separately to perform these actions.)
if a browsing user has opted out of a category, then not executing (4750) the sync; and (in at least [0052] the Organization for Safe Ad Targeting on the Web may require all members to comply with the behavioral targeting opt-out fragment developed by the organization. In addition to how compliance may be indicated during interactions, the organization may maintain a machine-readable registry of members that are in compliance and together with the URI spaces they manage as first parties. Policy engines may know to check that registry and cache this information to expedite processing. For interactions with entities that support the policy, the policy engine may then modify interaction context appropriately. For example, it may add an opt-out cookie with a particular name and value or a specially formatted HTTP header to indicate a user's opt-out status. [0053] policy fragments evolve independently. They do not require centralized standards development processes. For example, XML namespaces and XML schema allow for the independent evolution of XML fragments that may be mixed in the same XML document. [0130] provides a general-purpose mechanism to opt-out of any content type (or even more broadly, any aspect of interaction context). It leverages existing manager and engine deployments. It allows for policy enforcement through intermediaries in lieu of users' explicit policy definitions )
if explicit mode is applicable, then performing the steps of; (in at least [0135] Opt-in for certain types of content or advertising, essentially an expression of use preference, are trivially implemented in exactly the same way as opt-out for certain types of content. The logical difference is one bit—whether the content should be avoided or not. The new policy fragment can reuse the scoping model previously developed. Encodings and protocol bindings need only communicate that one bit of difference, e.g., through a different header name.)
only executing syncs (4760) once the browsing user opts in to tracking one or more categories; and (in at least [0145] Rather than indicating that profile data will be shared, a policy would identify the targeting engine (TE1) that provides privacy-safe ad targeting according to the technique described in the previous paragraph. When needing to target, an entity would have the choice of using its own targeting engine with whatever data it has available or using the TE1 identified in the policy. There is a third option also. The entity could contribute its profile information to the profile manager associated with TE1's entity. Typically, this would be a safe operation from a privacy standpoint as the entity operating TE1 would not share any profile information with anyone. Instead of passing profile data to inform a targeting decision, TE1 sends the assertions (as described) that the user satisfies a certain audience profile.)
if a browsing user has opted out of a category, then not executing (4770) the sync. (in at least [0052] the Organization for Safe Ad Targeting on the Web may require all members to comply with the behavioral targeting opt-out fragment developed by the organization. In addition to how compliance may be indicated during interactions, the organization may maintain a machine-readable registry of members that are in compliance and together with the URI spaces they manage as first parties. Policy engines may know to check that registry and cache this information to expedite processing. For interactions with entities that support the policy, the policy engine may then modify interaction context appropriately. For example, it may add an opt-out cookie with a particular name and value or a specially formatted HTTP header to indicate a user's opt-out status. [0053] policy fragments evolve independently. They do not require centralized standards development processes. For example, XML namespaces and XML schema allow for the independent evolution of XML fragments that may be mixed in the same XML document. [0130] provides a general-purpose mechanism to opt-out of any content type (or even more broadly, any aspect of interaction context). It leverages existing manager and engine deployments. It allows for policy enforcement through intermediaries in lieu of users' explicit policy definitions )
As Claim 8, Simeonov teaches: The method of claim 1, further comprising:
associating (4920) the one or more identifiers with one or more domain name system (DNS) addresses associated with the one or more marketing partners; (in at least [0015] Registry 116. A registry is a machine, program or process, or a set of such functionalities communicating using agreed-upon protocols which allows for the registration, discovery and management of privacy managers, profile managers, policy managers, policy engines and targeting engines. Some registries are well-known entities. Registries can know of other registries, e.g., in a federation architecture similar to what UDDI registries use or the DNS system. Some registries may be well-known, e.g., safetargetingregistry.com. Others may leverage standards such as XRDS (eXtensible Resource Descriptor Sequence, or XRDS Simple. [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0084] To address the targeting issue at a fundamental level the ability of ad providers to track (through cookies in the web domain, for example) must be significantly limited. This can happens in one of two ways. If there is trust, it can happen contractually. If there is no trust, it happens through some type of proxying mechanism that would be protocol-specific and application architecture-specific. [0110] UserInControl also operates a registry where entities that support UserInControl's opt-out policy can identify themselves (entity name, URL scope, etc.). As part of the opt-out policy, UserInControl defines a policy manager API that provides information about opt-out policy form the perspective of the targeting entity (e.g., encoding and HTTP binding of the opt-out claim) as well as a profile manager API which can be used to query the opt-out status per entity. The latter requires a mechanism for identifying users. In the cases where user identification must happen through cookies, preferably the API requires issuing HTTP request(s) from the user's browser to the entity's domain such that the user's cookies related to this domain are passed. Those versed in the art would know how to parameterize such request(s) to establish a correlation in time between the UserInControl's user account and the profile of that user at other entities.)
sending (4930) a request, to the one or more DNS addresses, for additional data related to the one or more identifiers; (in at least [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0098] in the case of the no cookie-ing policy, the compliance entity may operate a pool of virtual machines at different domains and IP address ranges and issue request from them to various targets (potentially all that are discoverable through registries to subscribe to this policy) to see whether they comply with it. [0105] The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains. UserInControl makes a reasonable effort to maintain an up-to-date registry of entities allowing opt-out via cookies and the specific format of these cookies that can be used by policy engines looking to encode the opt-out policy fragment in cookie form. [0106] The ideal policy engine on the user side looks at the domain or IP address of an HTTP request and, based on that context and the user's policy, modifies the outgoing HTTP request to either add an opt-out cookie and/or an opt-out header and, if the user so requires, a global opt-out header (which will go out with every HTTP request). In addition, the ideal policy engine implementation preferably includes an HTTP header with a link to the user's policy manager at UserInControl. The policy engine may reject known tracking cookies for entities the user has opted out of even if there is no known way to communicate an opt-out request to those entities or if they have for some reason failed to act on the opt-out request.)
receiving (4940) the additional data; and (in at least [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0105] The opt-out statement preferably is encoded in two ways: (1) as an OPT-OUT cookie with name and value specifically formatted to match known entities expecting such cookies set for the domains the user has elected to opt-out of, and (2) as an opt-out header sent to request from those domains. UserInControl makes a reasonable effort to maintain an up-to-date registry of entities allowing opt-out via cookies and the specific format of these cookies that can be used by policy engines looking to encode the opt-out policy fragment in cookie form. [0106] The ideal policy engine on the user side looks at the domain or IP address of an HTTP request and, based on that context and the user's policy, modifies the outgoing HTTP request to either add an opt-out cookie and/or an opt-out header and, if the user so requires, a global opt-out header (which will go out with every HTTP request). In addition, the ideal policy engine implementation preferably includes an HTTP header with a link to the user's policy manager at UserInControl. The policy engine may reject known tracking cookies for entities the user has opted out of even if there is no known way to communicate an opt-out request to those entities or if they have for some reason failed to act on the opt-out request.)
combining (4950) the additional data with the one or more identifiers. (in at least [0059] the first step in policy processing is to identify the policy engine. Next, the active policy set must be determined using known policy information and the interaction context. The active policy set varies at different times in an interaction. An example sequence in the case of a Web browser, orchestrated by the browser's policy engine, may be the following: 1. Identify active policy manager(s) for the user. 2. Send available interaction context (URL and cookies relevant to the domain) to policy manager(s) and retrieve active policies from it. 3. Based on interaction context, i.e., URL, retrieve server's policy. (see P3P for example mechanisms for doing this) 4. Generate active policy set. 5. Process active policy set. 6. Modify interaction context based on active policy set, e.g., adds opt-out header. 7. Browser makes HTTP request. 8. Browser receives HTTP response. 9. Look for additional policy information in interaction context. 10. Send to policy manager, if any. Retrieve additional information. 11. Generate active policy set. 12. Process active policy set. 13. Modify interaction context based on active policy set, e.g., reject a cookie. [0108] the policy engine is embedded in an intermediary on the user's device such as a browser plugin developed by UserInControl. In addition to offering the policy engine in the form of a plugin or other software integrated into an intermediary, UserInControl may offer a web page which through a series of HTTP requests (typically, appropriately parameterized redirects) to entities that (a) the user has chosen to opt out of and (b) support opt-out cookies installs these opt-out cookies on a user's device. In a way, the code behind this web pages acts as a crude policy engine.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PO HAN (Max) LEE whose telephone number is (571) 272-3821. The examiner can normally be reached on Monday - Thursday, 9 AM-6:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rutao Wu can be reached on (571) 272-6045. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PO HAN LEE/Primary Examiner, Art Unit 3623
Prosecution Insights