Source: https://patents.google.com/patent/US20110161472A1/en
Timestamp: 2018-09-24 02:16:31
Document Index: 471259659

Matched Legal Cases: ['arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116', 'arty 116']

US20110161472A1 - Client-based binding of identifiers across information domains while maintaining confidentiality - Google Patents
Client-based binding of identifiers across information domains while maintaining confidentiality Download PDF
US20110161472A1
US20110161472A1 US12649728 US64972809A US2011161472A1 US 20110161472 A1 US20110161472 A1 US 20110161472A1 US 12649728 US12649728 US 12649728 US 64972809 A US64972809 A US 64972809A US 2011161472 A1 US2011161472 A1 US 2011161472A1
US12649728
The present application is related to four other applications, filed on an even date therewith and assigned to the same assignee. These four other applications are attorney docket numbers CML07506, CML07528, CML07529, and CML07530, and they are included herein by reference in their entireties.
The above considerations, and others, are addressed by the present invention, which can be understood by referring to the specification, drawings, and claims. According to aspects of the present invention, information provided by an entity that has a presence in a number of information domains is used to bind together the separate identifiers of that entity across the domains. A “cross-domain identifier” is produced that can be provided to an interested party (potentially for a fee or for other consideration). The cross-domain identifier allows the interested party to extract information about the entity's behavior in the domains. The interested party can use this information, for example, to assess the effectiveness of an advertising campaign or to extract other market intelligence.
Even though the interested party can extract such useful information, the techniques used to create the cross-domain identifier preserve the confidentiality of the entity. In some embodiments, the interested party can extract information about particular cross-domain transactions (e.g., about a coupon presented to the entity in a media-providing domain and redeemed by the entity in a retail domain) but cannot tie the transaction to the particular entity. In other embodiments, the cross-domain identifier is constructed so as to provide only higher-level intelligence, such as statistics gathered about the behavior of a number of entities.
FIGS. 3 a and 3 b together form a flowchart of a first exemplary method for binding together identifiers across information domains;
FIGS. 5 a and 5 b together form a flowchart of a second exemplary method for binding together identifiers across information domains;
FIGS. 6 a and 6 b together form a flowchart of a third exemplary method for binding together identifiers across information domains;
FIGS. 7 a and 7 b together form a flowchart of a first exemplary method for brokering cross-domain information;
FIGS. 8 a and 8 b together form a flowchart of a second exemplary method for brokering cross-domain information;
FIGS. 9 a and 9 b together form a flowchart of an exemplary method for incenting an operator in a domain to provide information about the presence of an entity in that domain;
A first technique usable by the binder 114 is illustrated in FIGS. 3 a and 3 b. The method begins at step 300 of FIG. 3 a where the entity itself gives the binder 114 enough information to bind together the entity's presence identifiers 104, 106. In a straightforward example of this, the binder 114 (or the broker 112 acting on behalf of the binder 114) establishes a web site that invites the entity to log in and list his presence identifiers 104, 106. Also, when the entity uses one of the presence identifiers 104, 106, he can be invited to provide information about whatever other presence identifiers 104, 106 he may have. The entity can be given coupons or other monetary or non-monetary rewards to induce him to divulge this information. The entity is assured that this information will not be abused, and that the privacy of the entity will not be compromised.
Regardless of how the binder 114 receives the necessary information, the binder 114 performs the binding and then produces, in step 302 of FIG. 3 a, a “cross-domain identifier.” As the output of the binding process, the cross-domain identifier is an important concept. In short, it provides access to the binding and, in consequence, access to some behavioral observations concerning the entity in at least some of the domains 100, 102 involved in the binding. However, because the privacy of the entity is a major concern, the cross-domain identifier is so constructed that it does not allow access to all information about the entity.
Step 306 of FIG. 3 a allows for embodiments wherein the cross-domain identifier 400 provides access to ongoing information. A simple implementation of this would have the cross-domain identifier 400 point to the actual source of the gathered behavioral observations as they are made in each information domain 100, 102. (Each domain 100, 102 may have at least one operator 108, 110 that gathers this information. Then, the interested party 116 could, via the cross-domain identifier 400, view “live” observations in the information domains 100, 102 as they are taken. It is expected, however, that in many situations this simple implementation would be very difficult to secure against privacy invasions. Also, the owners of the information domains 100, 102 may regard this as giving up control of their valuable information. Thus, many implementations, even those that provide access to ongoing information, support a more sophisticated interaction between the cross-domain identifier 400 and the information-providing operators 108, 110 in each domain 100, 102. This interaction possibly includes monetary compensation for providing the information, that is, the interested party 116 may pay to subscribe to the cross-domain identifier 400, while the provider of the cross-domain identifier (possibly the broker 112, discussed below) or the incentivizer 118 pays the operators 108, 110 to have access to the ongoing information.
The process ends with step 308 of FIG. 3 b when the cross-domain identifier 400 is provided to an interested party. This has been discussed already, so it only need be noted that the “interested party” of step 308 may be the broker 112 that may use the cross-domain identifier 400 for its own purposes (see the discussion below) and that may in turn offer the cross-domain identifier 400 to the interested party 116 of FIG. 1 for a fee. Also, the binder 114 may give one version of the cross-domain identifier 400 to the broker 112 and, for security or commercial reasons, give another version of the cross-domain identifier 400 to the interested party 116. The two versions allow access to different types of information.
FIGS. 5 a and 5 b present a different method usable by the binder 114. The difference between this method and the method of FIGS. 3 a and 3 b lies in how the binder 114 receives enough information to perform the binding of the entity's presence identifiers 104 and 106. The method of FIGS. 5 a and 5 b begins at step 500 when a stimulus is created in association with a first presence identifier 104 of the entity in the first domain 100. The stimulus here is intended to induce the entity to perform a specific cross-domain operation. Turning to our familiar example, the stimulus can be a coupon, electronically formed to include an association with the entity's presence identifier 104. Such entity-specific coupons are already known (even though the use of them as in the method of FIGS. 5 a and 5 b is new) and are sent, for example, in e-mail advertisements or are downloadable from a web site once the entity has asserted one of his identifiers by logging in. Other stimuli are possible including contest entries.
If the stimulus fails to induce the desired response, then the method of FIGS. 5 a and 5 b is unsuccessful. If, on the other hand, the stimulus is successful, and the entity performs the induced action, information about that induced action is received by the binder 114 in step 502. For example, the induced action can be redemption of the coupon or contest entry in the second domain 102, the redemption associated with the presence identifier 106 of the entity in that domain 102. For a product coupon, the presence identifier 106 can be the retail loyalty card as presented by the entity when he purchases the product at a retail outlet.
Once the binder 114 binds the presence identifiers of the coupon's redeemer (whether or not that is the same entity that originally received the coupon), the method of FIGS. 5 a and 5 b proceeds in parallel with the method of FIGS. 3 a and 3 b. A cross-domain identifier 400 is created in step 506. The cross-domain identifier 400 may provide information about a population of customers (step 508 of FIG. 5 b) and may provide access to ongoing behavioral information (step 510). The cross-domain identifier 400 is provided to an interested party in step 512.
Before leaving the method of FIGS. 5 a and 5 b, one point should be noted. If the coupon is redeemed but not by the original coupon recipient, then the chain-of-custody is itself potentially valuable information. It may be reasonably inferred that the original recipient is a friend or acquaintance of the second person in the chain, the second person is a friend or acquaintance of the third person in the chain (if any), and so on. Thus, by observing the passing on of the coupon, the method of FIGS. 5 a and 5 b can generate useful information about social contacts. While not specifically relevant to the task of binding together presence identifiers, this information can be passed along to the broker 112 that may be able to use it.
Yet another binding method is presented in FIGS. 6 a and 6 b. In step 600, the behavior observed in a first domain 100 is analyzed. Each usable piece of information is associated with one or more presence identifiers 104. Then in step 602, the behavior observed in a second domain 102 is analyzed. Again, the usable observations are associated with one or more presence identifiers 106. In step 604, the binder 114 attempts to extract from these observations likely bindings of presence identifiers 104, 106 in the two domains.
The word “likely” in the previous sentence is instructive. The method of FIGS. 6 a and 6 b may sometimes produce definitive bindings, but at other times this method can only produce reasonable hypotheses. For example, a soft drink purchased in a retail domain might be associated with a recent viewing of an advertisement for that soft drink presented in a media-providing domain, but without more information, it would be difficult to bind together the presence identifiers of the entity that watched the advertisement with the entity that purchased the soft drink. However, that “more information” is becoming more readily available as operators 108, 110 in the domains 100, 102 become more aware of how valuable behavioral observations can be and thus make the effort to gather more information.
It should be noted that in steps 600 and 602, the binder 114 may need to process behavioral observations associated with innumerable presence identifiers 104, 106 and thus with innumerable entities before beginning to construct even hypothetical bindings. This method, in contradistinction to the binding methods of FIGS. 3 a, 3 b, 5 a, and 5 b mostly rewards only those binders 114 that have access to information on large populations of entities. Also, the more information domains available to the broker 114 for analysis, the better, as the broker 114 may be better able to extract patterns of behavior when more examples in more domains are available for contemplation.
Once the binding in made in step 604, this method follows the previous methods by creating a cross-domain identifier 400 in step 606. However, because the bindings produced by the method of FIGS. 6 a and 6 b are often based on statistical probabilities rather than on observed certainties, the cross-domain identifier 400 may include some indication of how much confidence the binder 114 has in this particular binding.
Note that in step 608 of FIG. 6 b, the cross-domain identifier 400 may include population statistics about multiple entities, just as in the previous methods. Be aware that this is another statistical step in addition to the statistics that the method of FIGS. 6 a and 6 b often applies when proposing a single binding (in step 604 of FIG. 6 a). If the binder 114 is fortunate enough to have access to information on large populations of entities, then the value of this statistical population information may completely outweigh any concern about the uncertainty associated with any particular binding.
Before leaving the discussion of binding methods to talk about the broker 112, it should be noted that the three binding methods given above need not be implemented in separate embodiments. A single binder 114 can use whatever method, or whatever combination of methods, is most appropriate given the information resources it is allowed to analyze. Also, the steps in each flowchart need not occur exactly in the order given. For example, the binder 114 may be always “pre-analyzing” behavioral information and then only create actual bindings when called upon to do so. Again, especially in the case of the method of FIGS. 6 a and 6 b, the binder 114 may need to revisit a cross-domain identifier 400 that it earlier produced when the binder 114 comes upon more information that either throws the previous binding into doubt or increases the level of confidence in that binding.
Now turning to the broker 112, FIGS. 7 a and 7 b present a first exemplary method. Ignore the first two steps 700, 702 of FIG. 7 a for the moment. In step 704, the broker 112 receives behavioral observations from an operator 108 in the first information domain 100. As mentioned above in reference to step 600 of FIG. 6 a, the usable observations are usually associated with one or more presence identifiers 104. However, the broker 112 can also make use of observations that are not tied to a specific presence identifier 104. In step 706, the broker 112 receives behavioral observations from an operator 110 in the second information domain 102. These steps 704, 706 are repeated for as many information domains as the broker 112 is allowed to monitor. In the method of FIGS. 7 a and 7 b, these steps 704, 706 continue on as long as the broker 112 is operating. (Note that in some embodiments, the broker 112 receives the information of steps 704 and 706 in association with the cross-domain identifier 400 received in step 712, described below. In those embodiments, steps 704 and 706 are sub-steps of step 712.)
In step 710 of FIG. 7 b (another ongoing step along with steps 704 and 706), the broker 112 analyzes the received observations and attempts to extract meaningful intelligence from them. The broker 112 is in a unique position to make this analysis, because the broker 112 is trusted to receive confidential information. This intelligence is one of the chief products of the broker 112.
Return now to step 700 of FIG. 7 a. In some embodiments, the broker 112 works closely with one or more incentivizers 118 (described in more detail below). Sometimes, the incentivizer 118 works through the broker 112 to access an information domain 100. In step 700, the broker 112 receives instructions from the incentivizer 118 detailing what the incentivizer 118 wants the broker 112 to do. For a first example, the incentivizer 118 can tell the broker 112 what type of analysis it wants to see. Note that in some cases, the incentivizer 118 is working directly for an interested party 116. If so, then the incentivizer 118 cannot have the same level of access to confidential information in the domain 100 that the trusted broker 112 enjoys. Thus, requests for specific kinds of analysis (including specifics about data gathering) are often made through the trusted broker 112.
In a second example, the rule from the incentivizer 118 specifies particular actions that the incentivizer 118 wishes to have happen in the domain 100. Recall the stimulus/response method of binding described above in reference to FIGS. 5 a and 5 b. The incentivizer 118 can tell the broker 112 in step 700 of FIG. 7 a what kinds of stimuli the incentivizer 118 wishes to send into the domain 100. The incentivizer 118 can also specify the types of entities that should receive the stimulus, and the trusted broker 112 may be the only entity outside the domain 100 that knows enough about the entities to fulfill this request.
In general, the behavior analyzed in steps 704 and 706 can be any behavior observed by the operators 108, 110 in the various domains 100, 102 including media-consumption behavior, retail behavior, behavior with respect to a social or other association, and the like. FIGS. 8 a and 8 b provide a rather specific example of behavior that the broker 112 may analyze. The method begins as in the method of FIGS. 7 a and 7 b. In step 710 of FIG. 8 a, the broker 112 analyzes the received behavioral observations.
The interested parties 116 decide how they want to approach the social connector. For example, an interested party may choose to send a coupon for a relevant product or service to the social connector. For security's sake, the interested party 116 may not be given enough information in step 802 to do this directly, so the interested party 116 sends a coupon-generating rule to the broker 112 in step 804. Although the interested party 116 is in general not an incentivizer 118, the broker 112 receives and processes the rule in the same manner as discussed above in reference to step 700 of FIG. 7 a (where the broker 112 receives a rule from an incentivizer 118). In step 806 of FIG. 8 a, the broker 112 takes action based on the rule, for example by generating and sending a coupon or by instructing an operator 108 in the first domain 100 to do so.
In step 808 of FIG. 8 b, the broker 112 receives information about the redemption of the coupon. Of course, if this coupon is redeemed in association with a second presence identifier 106 of the entity in a second information domain 102, then the broker 112 can send this information to the binder 114 to bind together the entity's two presence identifiers 104, 106. In other situations, the binding was done before the interested party 116 got involved. Even if the binding was not done and cannot be done (e.g., the coupon was redeemed, but the entity did not use a retail loyalty card), the broker 112 has still provided a valuable service to the interested party 116 and, through that party 116, to the social connector himself.
FIGS. 9 a and 9 b present an exemplary method usable by the incentivizer 118. In step 900, the incentivizer 118 sends to the broker 112 a rule for carrying out an operation in the first domain 100. (This is the same rule that the broker 112 receives in step 700 of FIG. 7 a, discussed above.) In the particular embodiment of FIGS. 9 a and 9 b, this rule specifies how a particular transaction is to begin, that is to say, how to contact an entity via the entity's presence identifier 104 in the first domain 100 and how to persuade the entity to perform in a specific manner. (In other embodiments, the incentivizer 118 can operate without contacting the entity.) In this embodiment, the incentivizer 118 operates through the broker 112 because, as noted above in the discussion of the broker 112, the broker 112 often has access to an operator 108 in the domain 100 that the incentivizer 118 does not have.
In some embodiments, the incentivizer 118 is not yet done with the entity but may, based on the entity's response to the incentive, send a revised rule to the broker 112 in step 906. For example, an entity that often redeems coupons for products promoted by the incentivizer 118 can be rewarded by higher-value coupons or other considerations. Indeed, the incentivizer 118 can even reward the entity directly in step 908 of FIG. 9 b by sending a reward associated with the entity's presence identifier 104, 106 in one of the information domains 100, 102. Note that even in this case, the reward may need to pass through the broker 112 because the incentivizer 118 may not have enough information to send the reward directly. In other embodiments, the incentivizer 118 need not send a revised rule because the original rule sent to the broker 112 can be adaptive to cover these cases.
The methods of FIGS. 9 a, 9 b, and 10 are simply examples showing how the incentivizer 118 can induce entities to act in particular ways that will in turn help the entities themselves or help other participants (such as the operators 108, 110, the broker 112, and the binder 114) to perform their tasks more effectively.
1. In a multi-domain environment wherein an entity has a first identifier in a first domain and a second identifier in a second domain, the first domain distinct from the second domain, a method for a binding process to bind together the first and second identifiers, the method comprising:
receiving, by the binding process from the entity, information that associates the first identifier with the second identifier;
creating, by the binding process, a cross-domain identifier that logically binds together the first and second identifiers, the cross-domain identifier providing access to some information associated with the first identifier, the cross-domain identifier providing access to some information associated with the second identifier, the cross-domain identifier not providing access to at least some information associated with the first identifier or with the second identifier pertaining to an identity of the entity; and
2. The method of claim 1 wherein the entity is selected from the group consisting of:
a human being, a business, a social group, and a government entity.
3. The method of claim 1 wherein the received information comprises a pseudonym resolvable to the first identifier.
4. The method of claim 1 wherein receiving information that associates the first identifier with the second identifier comprises receiving, by the binding process, the information directly from the entity.
5. The method of claim 1 wherein receiving information that associates the first identifier with the second identifier comprises receiving, by the binding process, the information indirectly from the entity, the entity first providing the information to a process distinct from the binding process.
6. The method of claim 5 wherein receiving, by the binding process, the information indirectly from the entity comprises receiving information about a transaction performed by the entity, the transaction partially performed in association with the first identifier and partially performed in association with the second identifier.
7. The method of claim 6 wherein the transaction comprises redeeming a coupon in association with the second identifier, the coupon generated in association with the first identifier.
8. The method of claim 6 wherein the transaction comprises redeeming a contest entry in association with the second identifier, the contest entry generated in association with the first identifier.
9. The method of claim 6 wherein the transaction comprises purchasing a product or service in association with the first identifier and producing a review, recommendation, or rating of the product or service in association with the second identifier.
10. The method of claim 1 wherein the received information that associates the first identifier with the second identifier does not comprise information revealing an identity of the entity.
wherein the first domain comprises a media-providing domain;
wherein the first identifier is associated with an element selected from the group consisting of: a subscription in the media-providing domain, a software token, and a hardware token; and
wherein the information associated with the first identifier comprises media-consumption information.
12. The method of claim 11 wherein the media-providing domain is selected from the group consisting of: a television service, a music service, a video service, an Internet-based service, a social network, and a telecommunications service.
wherein the second domain comprises a retail domain;
wherein the second identifier identifies a customer in the retail domain; and
wherein the information associated with the second identifier comprises an element selected from the group consisting of: purchasing information, product-scanning information, and sign-interaction information.
wherein the first domain comprises a public-safety domain; and
wherein the information associated with the first identifier comprises information associated with a behavior of the entity with respect to the public-safety domain.
16. The method of claim 15 wherein the first association is selected from the group consisting of: a business, a social group, and a government entity.
wherein the information associated with the first identifier comprises information about past membership of the entity in the first association; and
wherein the information associated with the second identifier comprises information about potential future membership of the entity in the second association.
18. The method of claim 1 wherein the information associated with the first identifier or with the second identifier pertaining to an identity of the entity comprises information selected from the group consisting of: a name of the entity, an address of the entity, a telephone number, a credit-card number, a bank-account number, a customer loyalty program identifier, a social-security number, biometrics, a photograph, a voice sample, a software token, and a hardware token.
19. The method of claim 1 wherein the cross-domain identifier further provides access to some information associated with a third identifier of a second entity, the second entity distinct from the first entity.
20. The method of claim 1 wherein the cross-domain identifier further provides access to ongoing information associated with the first identifier, the ongoing information associated with the first identifier after the creation of the cross-domain identifier.
21. In a multi-domain environment wherein an entity has a first identifier in a first domain and a second identifier in a second domain, the first domain distinct from the second domain, a compute server comprising:
a communications interface configured for receiving, from the entity, information that associates the first identifier with the second identifier; and
a processor operatively connected to the communications interface and running a binding process to bind together the first and second identifiers, the binding process configured for:
receiving, from the communications interface, the information that associates the first identifier with the second identifier;
creating a cross-domain identifier that logically binds together the first and second identifiers, the cross-domain identifier providing access to some information associated with the first identifier, the cross-domain identifier providing access to some information associated with the second identifier, the cross-domain identifier not providing access to at least some information associated with the first identifier or with the second identifier pertaining to an identity of the entity; and
US12649728 2009-12-30 2009-12-30 Client-based binding of identifiers across information domains while maintaining confidentiality Abandoned US20110161472A1 (en)
US12649728 US20110161472A1 (en) 2009-12-30 2009-12-30 Client-based binding of identifiers across information domains while maintaining confidentiality
US20110161472A1 true true US20110161472A1 (en) 2011-06-30
ID=44188793
US12649728 Abandoned US20110161472A1 (en) 2009-12-30 2009-12-30 Client-based binding of identifiers across information domains while maintaining confidentiality
US (1) US20110161472A1 (en)
US20060242072A1 (en) 2006-10-26 Method and system for creation, management and analysis of distribution syndicates