Stimulus/response-based binding of identifiers across information domains while maintaining confidentiality

Disclosed are methods for extracting and using information about an entity that has a presence in a number of information domains. The entity has separate identifiers in each of several domains. Various techniques are described that bind together the identifiers of the entity across the domains. The results of the binding are provided to an interested party that can review information extracted about the entity's behavior in the multiple domains. The interested party is not given access to information that would compromise the confidentiality of the entity. A trusted broker has access to information about the behavior of the entity in the several domains. The broker analyzes that information and provides the analysis to the interested party, again without compromising the confidentiality of the entity. An “incentivizer” works with the broker to extract from the domains information that would be useful in binding together the different identifiers of the entity.

FIELD OF THE INVENTION

The present invention is related generally to data analytics and, more particularly, to correlating information across multiple information domains.

CROSS-REFERENCE TO RELATED APPLICATIONS

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 U.S. application Ser. Nos. 12/649,703, 12/649,728, 12/649,776,and 12/649,795, and they are included herein by reference in their entireties.

BACKGROUND OF THE INVENTION

An unexpected consequence of the proliferation of subscription services, retail “loyalty” clubs, on-line social networks, etc., is the fragmentation of consumer data. An “entity” (for example, a human being) may have a presence in several of these information domains: He subscribes to a cable-television service, uses a customer loyalty card when shopping in a local grocery store, and logs onto a number of on-line social networks. The behavior of the person in each information domain generates potentially useful information that can be collected by the owner of the domain. For example, the cable-television provider knows what shows and advertisements he watches, while the owner of the grocery store tracks purchases made using the loyalty card. This information can be very useful to the domain owners in helping them to know what their customers prefer.

While observations of behavior within one information domain can be valuable to the owner of that domain, potentially valuable observations of “cross-domain” behavior may be very difficult to obtain. For example, the person watches an advertisement for a soft drink on cable television and then runs out to purchase the soft drink at his preferred grocery store. The cable-television provider knows that he watched the ad, while the grocery store owner knows he bought the soft drink. However, it is very difficult to conclude that watching the ad led to (or, at the very least, shortly preceded in time) the purchase because that behavior does not occur within any one information domain. Instead, that behavior crosses the two domains of cable-television viewing and grocery shopping.

The manufacturer of the soft drink is, of course, very interested in measuring the effectiveness of the advertising campaign he is running on the cable-television service. In this example, all of the information useful to the soft-drink manufacturer has been gathered by the separate domain owners: The ad-viewing behavior is recorded in association with the person's presence in the first domain (the cable-television service), while the soft-drink purchase behavior is recorded in association with the person's presence in the second domain (the grocery store). However, there is nothing to connect the viewing of the ad with the subsequent purchase of the soft drink.

This person probably has a separate “identifier” associated with his presence in each information domain, that is, he has a subscription account identifier with the cable-television provider, a loyalty card number at the grocery store, and one or more log-in account names for the social networks he visits. The problem of cross-domain information correlation can be restated as saying that it is very difficult to bind together these multiple identifiers to say that they all refer to the same person. If a cross-domain binding of the identifiers could be made, then behavior associated with the user's multiple identifiers could also be correlated. In this particular example, the ad viewing could be correlated with the soft-drink purchase. While that alone does not prove a cause and effect, the correlated information is of great interest to the soft-drink manufacturer. If such information were available for a large number of customers, then the manufacturer could draw reasonable conclusions about the effectiveness of his advertising campaign.

Useful as correlating these identifiers across information domains may be to the soft-drink manufacturer, customers may perceive here a violation of privacy. Such perceptions are likely to lower customer acceptance of cross-domain identifier binding. In a general sense, such correlations may begin to interfere with the customer's privacy. The example given above may be innocuous, and the customer might not fret if the soft-drink manufacturer concludes that a purchase was motivated by viewing an advertisement. However, other examples may be easily considered that would make the customer suspicious of an invasion of privacy. Indeed, people are already concerned if, after searching the web for information on leaf blowers, they start seeing ads for leaf blowers appear on the web pages they visit.

Preserving customer confidentiality across information domains is also important to the domain owners. Each domain owner is reluctant to share, without compensation, the potentially valuable information gathered about behavior within his domain. Also, the owner does not wish to jeopardize the gathering of future information or even lose the customer's business if the customer feels that his confidentiality is being compromised.

BRIEF SUMMARY

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, in an attempt to bind together an entity's identifiers in two domains, a stimulus is created in association with a first identifier in a first domain. A response to the stimulus is noted in association with a second identifier in a second information domain. Because the response is known to be associated with the stimulus (the stimulus is created so that only the intended recipient can properly respond to it), the first and second identifiers are now known to refer to the same entity, and the two identifiers can be bound together. For example, a coupon (the stimulus) is sent to a cable-television subscriber (the first identifier), and the coupon is subsequently redeemed (the response) via a loyalty-card (the second identifier) program at a grocery store. The cable-television subscriber is then known to be the same entity as the holder of the loyalty card. 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 the 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.

The methods of the present invention can be applied across any number of, and any types of, information domains. In addition to the media-providing and retail domains of the coupon example given above, the information domains can include public-safety jurisdictions, social networks, and other association-based domains.

In some embodiments, the cross-domain identifier provides access to updated behavioral information collected even after the cross-domain identifier was created and sent to the interested party. In other embodiments, the cross-domain identifier only provides access to static information, and, in order to receive updated information, the interested party subscribes to receive updates via the cross-domain identifier.

DETAILED DESCRIPTION

Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable environment. The following description is based on embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein.

FIG. 1portrays a representative environment in which aspects of the present invention may be practiced. As a conceptual aid, the environment ofFIG. 1may be divided into three logical portions: First, the information domains100and102in which an entity exhibits some kind of observable behavior. Second, the three applications called the broker112, the binder114, and the incentivizer118extract useful information from the entity's observed behavior and package that useful information for another's use. The third logical portion is the interested party116that uses the packaged information.

Beginning the detailed description with the first logical portion mentioned above, it should first be noted that the entity itself is not shown inFIG. 1. For ease of the present discussion, the entity is usually taken to be a human being, but other entities are possible such as a business, social group, government entity, or other organization. It is the entity's behavior in the information domains100,102that is most important for the present discussion.

These information domains100,102may be of many different types (and may number more than two). Two information domains used in several examples of the present discussion are a media-providing domain100and a retail domain102. In the first, media are provided to the entity, and the entity is a consumer of the media. Standard examples of media-providing domains100include a cable-television service, music and video services, telecommunications services including telephone services, Internet-based services, and social networks. A familiar retail domain102is a grocery store. A web site can be both a media-providing domain100and a retail domain102. Other types of information domains100,102include public-safety jurisdictions and domains set up specifically for the members of an organization.

The entity exhibits behavior in the information domains100,102, and that behavior is, at least to some extent, observed and recorded. For a cable-television domain100, the entity's behavior includes what shows and advertisements he watches. Observable behavior in a retail domain102includes purchases made, products scanned even if not purchased, and interactions with “smart” signs and advertisements. Behavior in a public-safety domain includes arrests by the police, warnings given, and fines or other penalties assessed. The observable behavior of other domains100,102can be easily imagined.

Observable behavior in the information domain100is associated with a “presence”104of the entity. This presence104is simply an identifier of the entity particular to this information domain100. If the information domain100provides media, then the entity's presence104may be identified by the entity's subscription account number. In some media-providing domains (e.g., Internet-based providers), the presence identifier104may be a hardware or software token (e.g., a “cookie”). The presence106of the entity in a retail domain102can be a “loyalty card” number assigned to the entity. In a banking domain, the entity's presence can be identified by a checking account number. In an on-line social network, the entity can identify his presence by a log-in name or avatar. In general, the entity may have a different presence identifier104,106in each of the information domains100,102in which he exhibits behavior. The proliferation of these presence identifiers104,106is one of the key elements driving some aspects of the present invention.

It may be useful to emphasize that the observed behavior of the entity within a particular information domain100is tied to the entity's identifier104in that domain100, and only to that identifier104. That is to say, the entity's behavior in the first information domain100is not, without further work, tied to the entity's identifier106in the second information domain102.

An “operator”108,110is shown in each of the information domains100,102. This term “operator” is to be taken very generally and is defined by its actions as described in the present discussion and in the claims. One operator108is the cable-television provider in a media-providing information domain100, but other possible operators include processes, such as one providing local viewing content or advertising, that have some access to the presence104of the entity in this particular domain100. In general, there can be multiple operators108within a given domain100. The domain100can include operators108provided by competing commercial concerns, each operator108providing coupons and advertisements and otherwise promoting their products and services. A good example of a proliferation of operators is a web page whose general outline is provided by one operator but which includes content, possibly actionable content, from many other operators such as news and weather services, other RSS feeds, advertising, and the like.

Much of what has just been described (here called the “first logical portion” of the environment ofFIG. 1) is well known in the art and is probably familiar to the reader (at least in some form or other). That is not the case for the “second logical portion” which includes the broker112, the binder114, and the incentivizer118. The bulk of the present discussion clarifies these applications, their operations, and their interactions with the other portions ofFIG. 1. For now, a short introduction of each may be useful.

The binder114discovers, by various techniques described below, that the presence identifiers104and106in the two information domains100and102, respectively, are in fact associated with the same entity. That is to say, the binder114“binds together” the two (or more) presence identifiers104,106of the entity. This binding can be very useful because it allows for the gathering of “cross-domain” intelligence. In general, at least one operator108,110in each information domain100,102observes and records the behavior of the entity within that one particular information domain. The work of the binder114allows a larger, cross-domain, picture of the entity's behavior to be developed.

The broker112analyzes the observed behavior of the entity as recorded in several information domains100,102and tries to draw useful conclusions from the analysis. The broker112works closely with the binder114. In some embodiments, the broker112feeds behavioral observations gathered from the several domains100,102to the binder114to allow the binder114to try to correlate the presence identifiers104,106across the domains100,102. In some embodiments, the output of the binder114is used by the broker112as the broker112develops cross-domain intelligence.

Because each information domain100,102operates separately and closely guards the behavioral observations it makes within its own domain (both for monetary and security reasons), an incentive may need to be given to “pry loose” some of this information so that the binder114and the broker112can be more effective. That is one purpose of the incentivizer118. In some embodiments, the incentivizer118represents the interests of a particular commercial concern or other organization (e.g., those of the interested party116). In other cases, the incentivizer118is a neutral party. Security issues, discussed below, flow from these possible allegiances of the incentivizer118.

Finally, the “third logical portion” ofFIG. 1is the interested party116. This is a consumer (and possibly a purchaser) of the cross-domain intelligence generated by the broker112(as the broker112works in conjunction with the binder114and with the incentivizer118). In many embodiments, this interested party116is a business or other commercial concern. It wants, as potentially valuable marketing intelligence, the cross-domain behavioral analysis provided by the broker112. However, simply giving that analysis to the interested party116may be a threat to the confidentiality of the entity. Several aspects of the present invention are focused on the problem of providing valuable cross-domain information to the interested party116while maintaining the confidentiality, and the confidence, of the entity.

The arrows inFIG. 1are meant to suggest information flows, but they are not definitive. Particular embodiments are supported by particular information flows, and these are detailed in the discussion below.

An exemplary compute server that can host aspects of the present invention is shown inFIG. 2. A communications interface202allows the compute server200to communicate with other processes as shown inFIG. 1, and a processor204can run the methods described below. Note, however, that there need not be a one-to-one mapping between a process fromFIG. 1(such as the broker112, binder114, or incentivizer118) and a compute server200. In some embodiments, for example, the broker112and the binder114are processes both running on a single compute server200. In other embodiments, the methods of the binder114(or of the broker112or incentivizer118) are distributed among several servers200. Portions of these processes112,114,118may even be delivered to and run on a server200run by an operator108or on equipment (e.g., a set-top box or cellphone) owned by an entity. In sum, consider the broker112, binder114, and incentivizer118to be methods whose steps are hosted on one or more compute servers200or on other computing devices as particular implementations require.

At this point, the present discussion turns to exemplary embodiments of the binder114, broker112, and incentivizer118. Later, examples are given that describe how all of the elements ofFIG. 1can work together.

A first technique usable by the binder114is illustrated inFIGS. 3aand 3b. The method begins at step300ofFIG. 3awhere the entity itself gives the binder114enough information to bind together the entity's presence identifiers104,106. In a straightforward example of this, the binder114(or the broker112acting on behalf of the binder114) establishes a web site that invites the entity to log in and list his presence identifiers104,106. Also, when the entity uses one of the presence identifiers104,106, he can be invited to provide information about whatever other presence identifiers104,106he 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.

In a somewhat less straightforward example, the binder114still gets the necessary binding information from the entity but gets the information indirectly. For example, the entity may perform a cross-domain transaction that contains enough information to perform the binding, and that cross-domain transaction is observed by the binder114. An example of this involves an electronic coupon given to the entity in the first domain100and redeemed in another102. (Permutations of this example are described below.) The coupon as issued is associated with a first presence identifier104of the entity in the first domain100(which in this example can be a media-providing domain). (The coupon “is associated with” the first presence identifier104by, for example, encrypting the presence identifier104within the electronic coupon.) When the coupon is redeemed in a retail domain102, the entity uses the loyalty card issued to him by the retailer. This loyalty card serves as the entity's presence identifier106in the retail domain102. When the binder114is informed about the coupon clearance (this informing is described in detail below), the binder114reasonably concludes that the two presence identifiers104,106associated with the coupon belong to the same entity, and the binder114performs the binding.

Depending upon the particular nature of the information domains100,102, the binder114can use other ways to gather the binding information indirectly from the entity. Instead of a coupon, a contest entry issued to the entity in one domain100and redeemed in another domain102can provide the information necessary to perform the binding. Even more indirect, the entity can purchase a product in a retail domain100and then post a review of the product in an on-line social domain102. If the purchase and review can be tied together, then the binder114can bind together the presence identifiers104,106of the entity in these two domains. As can be imagined, each particular type of information domain100,102supports particular types of observable behavior, and those particular types of observable behavior can often be correlated across domains to allow the binder114to perform the binding.

Note that in some situations, the information used by the binder114reveals the actual identity of the entity. In other situations, the binder114only has a pseudonym of the entity to work with and attempts to resolve that pseudonym to an actual presence identifier104,106when performing the binding. In some situations, the binder114cannot resolve the pseudonym to an actual presence identifier104,106but performs the binding on the pseudonym itself.

Regardless of how the binder114receives the necessary information, the binder114performs the binding and then produces, in step302ofFIG. 3a, 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 domains100,102involved 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.

FIG. 4presents an idealized structure for the cross-domain identifier400.FIG. 4shows that by accessing the cross-domain identifier400, a party is given access to some behavioral information402,404associated with the entity. Consider the case where the first information domain100is a media-providing domain, and the second information domain102is a retail domain. Then, after the cross-domain identifier400is constructed binding together the entity's presence identifiers104,106in these two domains100,102, the cross-domain identifier400may provide access to observations402of media-consumption activities (e.g., what shows and advertisements the entity watched) from the first domain100and access to observations404of retail activities (e.g., a list of products purchased by the entity, products scanned but not purchased, and interactions with intelligent signs and advertisements) from the second domain102.

Note, however, that for privacy reasons, the cross-domain identifier400generally does not provide access to the entity's presence identifiers104,106themselves because that could lead to a loss of privacy. Also, even if the binder114has gathered information that could reveal the identity of the entity, that information is generally not made accessible through the cross-domain identifier400. This potentially identity-revealing information can include, in addition to the presence identifiers104,106, information about the entity's name, address, telephone number, credit-card and bank-account numbers, social-security numbers, automobile license plate number, other identifiers, biometrics such as voice samples, photographs, and software or hardware identifiers (including tokens or “cookies”).

Even withholding access to the entity's presence identifiers104,106and information about the entity's identity may not provide enough security in some situations, however. Therefore, in these situations, the cross-domain identifier400is constructed to only give access to general information about behavior rather than giving access to specific instances of observed behavior. As one example, in step304, the cross-domain identifier400is constructed to provide access to information about a number of entities. That information may be accessible on an entity-by-entity basis or may only be available as statistical results covering a population of entities. An entity's confidential information is more carefully guarded when the cross-domain identifier400only provides access to the results of high-level analysis. That type of information is very valuable to many potential interested parties116, and indeed several interested parties116may only want the high-level analysis. In some embodiments, the price that the interested party116pays for access to a cross-domain identifier400is determined, in part, by the level of behavioral detail that the interested party116can access through the cross-domain identifier400. As discussed below, the cross-domain identifier400can be more valuable if it points to information extracted by an analysis of a large population.

Different embodiments of the binder114create different types of cross-domain identifiers400. As one example, the cross-domain identifier400can be created to provide access to either static or dynamic data. One way to provide safe access to static data is to extract behavioral data from the information domains100,102, scrub that data to remove identity-revealing or other confidential data, and then create the cross-domain identifier400to point to the scrubbed data. Whenever the interested party116wants updated information, the process is repeated (although the binding itself presumably need not be performed again), and a new cross-domain identifier400is given to the interested party116(possibly on a subscription basis).

Step306ofFIG. 3aallows for embodiments wherein the cross-domain identifier400provides access to ongoing information. A simple implementation of this would have the cross-domain identifier400point to the actual source of the gathered behavioral observations as they are made in each information domain100,102. (Each domain100,102may have at least one operator108,110that gathers this information. Then, the interested party116could, via the cross-domain identifier400, view “live” observations in the information domains100,102as 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 domains100,102may 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 identifier400and the information-providing operators108,110in each domain100,102. This interaction possibly includes monetary compensation for providing the information, that is, the interested party116may pay to subscribe to the cross-domain identifier400, while the provider of the cross-domain identifier (possibly the broker112, discussed below) or the incentivizer118pays the operators108,110to have access to the ongoing information.

The process ends with step308ofFIG. 3bwhen the cross-domain identifier400is provided to an interested party. This has been discussed already, so it only need be noted that the “interested party” of step308may be the broker112that may use the cross-domain identifier400for its own purposes (see the discussion below) and that may in turn offer the cross-domain identifier400to the interested party116ofFIG. 1for a fee. Also, the binder114may give one version of the cross-domain identifier400to the broker112and, for security or commercial reasons, give another version of the cross-domain identifier400to the interested party116. The two versions allow access to different types of information.

FIGS. 5aand 5bpresent a different method usable by the binder114. The difference between this method and the method ofFIGS. 3aand 3blies in how the binder114receives enough information to perform the binding of the entity's presence identifiers104and106. The method ofFIGS. 5aand 5bbegins at step500when a stimulus is created in association with a first presence identifier104of the entity in the first domain100. 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 identifier104. Such entity-specific coupons are already known (even though the use of them as in the method ofFIGS. 5aand 5bis 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.

Note that although the binder114will eventually use the information generated by the response (in step504below), the stimulus need not be sent by the binder114itself. Examples are given below where the broker112or an operator108actually prepares and sends the stimulus.

If the stimulus fails to induce the desired response, then the method ofFIGS. 5aand 5bis 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 binder114in step502. For example, the induced action can be redemption of the coupon or contest entry in the second domain102, the redemption associated with the presence identifier106of the entity in that domain102. For a product coupon, the presence identifier106can be the retail loyalty card as presented by the entity when he purchases the product at a retail outlet.

In step504, the binder114analyzes the stimulus and the response and, based on that analysis, binds together the two presence identifiers104,106as belonging to the same entity. In the simplest scenario, this binding is possible because the coupon is so constructed so that only the entity who is the original recipient of the coupon (as designated by the first presence identifier104) is allowed to redeem the coupon (as designated by the second presence identifier106).

A more complicated scenario is also possible. The original recipient of the coupon may be allowed to pass the coupon on to a friend who is then allowed to redeem the coupon for himself. The coupon can be constructed so that an electronic “chain of custody” is created. This chain-of-custody information is given to the binder114in step502. From the chain, the binder114can bind together the friend's presence identifier in the coupon-providing domain with the friend's presence identifier in the retail domain when the friend redeems the coupon. In this scenario, of course, there is not enough information to bind the presence identifiers of the original coupon recipient.

Once the binder114binds the presence identifiers of the coupon's redeemer (whether or not that is the same entity that originally received the coupon), the method ofFIGS. 5aand 5bproceeds in parallel with the method ofFIGS. 3aand 3b. A cross-domain identifier400is created in step506. The cross-domain identifier400may provide information about a population of customers (step508ofFIG. 5b) and may provide access to ongoing behavioral information (step510). The cross-domain identifier400is provided to an interested party in step512.

Before leaving the method ofFIGS. 5aand 5b, 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 ofFIGS. 5aand 5bcan 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 broker112that may be able to use it.

Yet another binding method is presented inFIGS. 6aand 6b. In step600, the behavior observed in a first domain100is analyzed. Each usable piece of information is associated with one or more presence identifiers104. Then in step602, the behavior observed in a second domain102is analyzed. Again, the usable observations are associated with one or more presence identifiers106. In step604, the binder114attempts to extract from these observations likely bindings of presence identifiers104,106in the two domains.

The word “likely” in the previous sentence is instructive. The method ofFIGS. 6aand 6bmay 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 operators108,110in the domains100,102become more aware of how valuable behavioral observations can be and thus make the effort to gather more information.

It should be noted that in steps600and602, the binder114may need to process behavioral observations associated with innumerable presence identifiers104,106and thus with innumerable entities before beginning to construct even hypothetical bindings. This method, in contradistinction to the binding methods ofFIGS. 3a, 3b, 5a, and5bmostly rewards only those binders114that have access to information on large populations of entities. Also, the more information domains available to the broker114for analysis, the better, as the broker114may be better able to extract patterns of behavior when more examples in more domains are available for contemplation.

Once the binding in made in step604, this method follows the previous methods by creating a cross-domain identifier400in step606. However, because the bindings produced by the method ofFIGS. 6aand 6bare often based on statistical probabilities rather than on observed certainties, the cross-domain identifier400may include some indication of how much confidence the binder114has in this particular binding.

Note that in step608ofFIG. 6b, the cross-domain identifier400may 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 ofFIGS. 6aand 6boften applies when proposing a single binding (in step604ofFIG. 6a). If the binder114is 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.

As is already familiar from the discussion of the previous binding methods, step610optionally constructs the cross-domain identifier400to have access to ongoing, rather than only to static, behavioral observations. This step610has a special significance in the current method, however, because as more observations are made and analyzed in steps600and602, the level of confidence that a binding proposed in step604is actually correct can increase (or decrease if counter-examples are found). Subscribers to ongoing information are thus given better and better information as time goes on.

In step612, the cross-domain identifier400is offered to an interested party.

Before leaving the discussion of binding methods to talk about the broker112, it should be noted that the three binding methods given above need not be implemented in separate embodiments. A single binder114can 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 binder114may 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 ofFIGS. 6aand 6b, the binder114may need to revisit a cross-domain identifier400that it earlier produced when the binder114comes upon more information that either throws the previous binding into doubt or increases the level of confidence in that binding.

Now turning to the broker112,FIGS. 7aand 7bpresent a first exemplary method. Ignore the first two steps700,702ofFIG. 7afor the moment. In step704, the broker112receives behavioral observations from an operator108in the first information domain100. As mentioned above in reference to step600ofFIG. 6a, the usable observations are usually associated with one or more presence identifiers104. However, the broker112can also make use of observations that are not tied to a specific presence identifier104. In step706, the broker112receives behavioral observations from an operator110in the second information domain102. These steps704,706are repeated for as many information domains as the broker112is allowed to monitor. In the method ofFIGS. 7aand 7b, these steps704,706continue on as long as the broker112is operating. (Note that in some embodiments, the broker112receives the information of steps704and706in association with the cross-domain identifier400received in step712, described below. In those embodiments, steps704and706are sub-steps of step712.)

As mentioned above in reference to the variously described exemplary binding methods, the broker112in some embodiments sends at least some of the received observations to the binder114in step708.

In step710ofFIG. 7b(another ongoing step along with steps704and706), the broker112analyzes the received observations and attempts to extract meaningful intelligence from them. The broker112is in a unique position to make this analysis, because the broker112is trusted to receive confidential information. This intelligence is one of the chief products of the broker112.

In some embodiments, the broker112receives, in step712, the cross-domain identifier400created by the binder114. There are several reasons why this may happen. In one case, although the broker112is trusted to receive confidential information, security may be enhanced if the most confidential information (that is, the information that leads to the binding of presence identifiers across domains) is handled by the binder114in a separate process. Here, the broker112itself makes no attempt to associate behavioral observations across domains but leaves that task to the binder114.

In a second case, the binder114always works behind the scenes and works exclusively through the broker112both to receive the behavioral observations on which the binder114operates and to send out the cross-domain identifiers400that encapsulate the bindings it produces.

In step714, the broker112provides results of its analyses to an interested party116. For security's sake, these results can be provided via a cross-domain identifier400created by the binder114. The broker112may sell this information or exchange it for something else of value.

As described above in reference to the cross-domain identifier400, the information accessible through this identifier400may be specific to one entity operating across domains or may include statistics about a population of entities. In some cases, only the highest-level results of the analysis of the broker112are provided. The fee charged by the broker112can vary depending upon the depth of the analysis and upon the amount of detailed information provided. Again as mentioned above, this information may be continually updated on an ongoing basis.

Return now to step700ofFIG. 7a. In some embodiments, the broker112works closely with one or more incentivizers118(described in more detail below). Sometimes, the incentivizer118works through the broker112to access an information domain100. In step700, the broker112receives instructions from the incentivizer118detailing what the incentivizer118wants the broker112to do. For a first example, the incentivizer118can tell the broker112what type of analysis it wants to see. Note that in some cases, the incentivizer118is working directly for an interested party116. If so, then the incentivizer118cannot have the same level of access to confidential information in the domain100that the trusted broker112enjoys. Thus, requests for specific kinds of analysis (including specifics about data gathering) are often made through the trusted broker112.

In a second example, the rule from the incentivizer118specifies particular actions that the incentivizer118wishes to have happen in the domain100. Recall the stimulus/response method of binding described above in reference toFIGS. 5aand 5b. The incentivizer118can tell the broker112in step700ofFIG. 7awhat kinds of stimuli the incentivizer118wishes to send into the domain100. The incentivizer118can also specify the types of entities that should receive the stimulus, and the trusted broker112may be the only entity outside the domain100that knows enough about the entities to fulfill this request.

Step702is a natural follow-on to step700in some situations. Here the broker112sends a rule to an operator108in the first domain100. The rule specifies those types of behavioral observations that are of interest to the broker112. Continuing the example of the stimulus rules sent by the incentivizer118to the broker112in step700, the broker112may not actually be in a position to send the stimuli itself but may send a rule (or download an application that embodies a rule) to the operator108, and the operator108performs according to the rule.

In general, the behavior analyzed in steps704and706can be any behavior observed by the operators108,110in the various domains100,102including media-consumption behavior, retail behavior, behavior with respect to a social or other association, and the like.FIGS. 8aand 8bprovide a rather specific example of behavior that the broker112may analyze. The method begins as in the method ofFIGS. 7aand 7b. In step710ofFIG. 8a, the broker112analyzes the received behavioral observations.

Because of its analysis, the broker112concludes, in step800, that an entity who has a presence in the first information domain100is a “social connector.” A social connector is a person who is a hub for a social network; other people in the network communicate with this person to discuss and plan social events. (This social network may be very informal: co-workers, a scratch bowling team, couples in the neighborhood with similar-age children). The broker112notices this person and concludes that he is a social connector by reviewing communications records such as telephone call logs, SMS logs, e-mails, and the like.

The broker112is also able to conclude that the social connector is planning an event. Again, communications records can be revealing: The social connector very recently called several local banquet facilities, for example.

The intelligence that the broker112extracts in step800can be quite valuable to businesses that provide products or services for events. Thus, in step802, the broker112attempts to sell this information to interested parties116working in a second domain102. By knowing something about the event (especially, by knowing more about the event than any of the potentially interested parties116can know), the broker112can pick one or more parties116that may reasonably be interested in this information. Through a competitive bidding process or otherwise, the broker112picks its customers116in step802and sells them information about the social connector and about the event. At all times, the broker112preserves the confidentiality of the entity and does not disclose personally identifiable information.

The interested parties116decide 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 party116may not be given enough information in step802to do this directly, so the interested party116sends a coupon-generating rule to the broker112in step804. Although the interested party116is in general not an incentivizer118, the broker112receives and processes the rule in the same manner as discussed above in reference to step700ofFIG. 7a(where the broker112receives a rule from an incentivizer118). In step806ofFIG. 8a, the broker112takes action based on the rule, for example by generating and sending a coupon or by instructing an operator108in the first domain100to do so.

In step808ofFIG. 8b, the broker112receives information about the redemption of the coupon. Of course, if this coupon is redeemed in association with a second presence identifier106of the entity in a second information domain102, then the broker112can send this information to the binder114to bind together the entity's two presence identifiers104,106. In other situations, the binding was done before the interested party116got 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 broker112has still provided a valuable service to the interested party116and, through that party116, to the social connector himself.

The discussion next turns to the incentivizer118. As its name suggests, the role of the incentivizer118is to incent operators with presences in the information domains100,102to perform in specific ways. In many instances, the desired outcome of the incented behavior is the creation of information usable by the binder114to bind together the presence identifiers104,106of an entity across the domains100,102.

FIGS. 9aand 9bpresent an exemplary method usable by the incentivizer118. In step900, the incentivizer118sends to the broker112a rule for carrying out an operation in the first domain100. (This is the same rule that the broker112receives in step700ofFIG. 7a, discussed above.) In the particular embodiment ofFIGS. 9aand 9b, this rule specifies how a particular transaction is to begin, that is to say, how to contact an entity via the entity's presence identifier104in the first domain100and how to persuade the entity to perform in a specific manner. (In other embodiments, the incentivizer118can operate without contacting the entity.) In this embodiment, the incentivizer118operates through the broker112because, as noted above in the discussion of the broker112, the broker112often has access to an operator108in the domain100that the incentivizer118does not have.

If the entity accepts the stimulus presented by the broker112, then the entity acts in a specified manner, and in step902, the incentivizer118receives results of the action. The transaction may occur all in the first domain100(in this case, the entity may not even have a presence identifier in a second domain), in which case the results are associated with the presence identifier104of the entity in that domain100. Other transactions occur across domains, so that the results are associated with the presence identifier106of the entity in the second domain102. In some embodiments, the incentivizer118is given statistical information about the results of its efforts but is not provided with information about specific transactions.

Turning back to our common example of the coupon, the incentivizer118may direct, in step900, the broker112to generate and send a coupon associated with the entity's presence identifier104in a media-providing domain100. The coupon is redeemed in association with the entity's presence identifier106in the retail domain102. Thus, the incentivizer118has incented the entity to perform a cross-domain transaction that results in gathering the information needed by the broker114to bind together these two identifiers104,106of the entity. In this situation, the broker112may have monitored the transaction and sent the information to the binder114. The results may then be received by the incentivizer118via a cross-domain identifier400created by the binder114.

In step904, the incentivizer118rewards at least one operator108,110in at least one of the domains100,102. (The reward may pass through the broker112as appropriate.) The reward is another incentive, in this case an incentive to the operator108,110to cooperate with the broker112in providing the incentive that produced the desired behavior in the entity. Different rewards are appropriate to different operators108,110in different domains100,102. Rewards can include, for example, money, publicity, increased traffic directed toward the operator's domain, access to information (such as that gathered by the broker112), increased public safety (when, for example, a domain is a public-safety jurisdiction), increased number of customers, and certification of compliance with a regulation.

In some embodiments, the incentivizer118is not yet done with the entity but may, based on the entity's response to the incentive, send a revised rule to the broker112in step906. For example, an entity that often redeems coupons for products promoted by the incentivizer118can be rewarded by higher-value coupons or other considerations. Indeed, the incentivizer118can even reward the entity directly in step908ofFIG. 9bby sending a reward associated with the entity's presence identifier104,106in one of the information domains100,102. Note that even in this case, the reward may need to pass through the broker112because the incentivizer118may not have enough information to send the reward directly. In other embodiments, the incentivizer118need not send a revised rule because the original rule sent to the broker112can be adaptive to cover these cases.

A distinction between the incentivizer118and the broker112should be drawn. In some cases, the incentivizer118is a neutral party, working mainly to help the binder114get enough information to do its work. In other cases, however, the incentivizer118works for a commercial interest, such as the interested party116, and pushes coupons and advertisements for that party's commercial interest. These non-neutral incentivizers118are able to work without compromising the entity's confidential information because these incentivizers118are made to work through the neutral, and trusted, broker112.

FIG. 10presents another exemplary method usable by the incentivizer118. In step1000, the incentivizer118sends a rule to the broker112. In this example, the rule tells the broker112how to contact business entities in one or more information domains100,102. When contacted, the broker112presents an incentive to each business entity. The incentive specifies that if the business entity is willing to release some of the information that this business collects about its own business transactions, then the business entity will be rewarded with a statistical analysis of business transactions in the same area of business in which the business entity operates.

In step1002, the incentivizer118receives the specific business intelligence from those business entities willing to participate. This received intelligence is then statistically analyzed, and the results are sent to participating business entities in step1004. As with the example concerning human entities given above, the confidentiality of the individual business entities is preserved during this analysis. Thus, in return for surrendering information about its own operations, a business entity receives general information about the marketplace in which it operates. That general information is based on the analysis of the information released by the individual business entities and is therefore probably more accurate and up-to-date than the information provided by other, less direct, business analysis techniques.

The methods ofFIGS. 9a, 9b, and10are simply examples showing how the incentivizer118can induce entities to act in particular ways that will in turn help the entities themselves or help other participants (such as the operators108,110, the broker112, and the binder114) to perform their tasks more effectively.

Having detailed the operations of the individual elements of the environment ofFIG. 1, the discussion now turns to a few examples illustrating how these elements can work together. Much of the discussion that accompaniesFIGS. 11 through 15is redundant with what appears above, but these figures clarify how the elements work together to achieve desired outcomes.

Note that the message flows inFIGS. 11 through 15are illustrative only and are presented at a high level. Details of message contents and the particulars of message exchanges vary with various embodiments and are readily implemented by one of ordinary skill in the art of data communications. Those engineers implementing the present invention will apply known data-communications techniques. For example, a large portion of the information exchanged in these message-flow diagrams should be encrypted; many messages should also be authenticated.

InFIGS. 11 through 15, time generally flows from the top to the bottom. However, many message flows, though shown at one point in time, are actually ongoing. For example, the message flow1110ofFIG. 11(collecting, by an operator108, observations of behavior in the first domain100) typically starts before the particular sequence inFIG. 11begins, continues all during the sequence ofFIG. 11, and goes on even after the sequence ofFIG. 11is complete.

The vertical dotted lines inFIGS. 11 through 15have no significance other than to guide the eye to the originators and consumers of each message flow.

InFIGS. 11 through 15, the broker112and the binder114are combined. While in some embodiments, these two processes112,114are indeed hosted by the same hardware, they are combined in the Figures merely to reflect the close operations of the broker112and the binder114and to avoid further clutter.

For ease of explanation, these figures only involve two domains and include only one operator108,110in each domain. (The domain on the left of each Figure is called the “first” domain, and the domain on the right is called the “second” domain.) However, as discussed above, the methods of the present invention can be implemented across any number of domains with multiple operators in each domain. Many of the message flows are shown going to only one operator in one domain: In some situations, these flows are repeated to multiple domains, and to multiple operators in each domain, as appropriate for each given situation.

FIG. 11shows how a coupon can be generated specifically for use by an entity while preserving the confidentiality of that entity's private information.FIG. 11begins with message flow1100when an incentivizer118registers with the broker112for services. The incentivizer118sends rules to the broker112detailing a coupon-generation function that the broker112will implement.

Having studied the received rules, the broker112, in message flow1102, contracts with an operator110in the second domain. In the example ofFIG. 11, the first domain (on the left of the Figure) is a media-providing domain, and the second domain is a retail domain, the retailer selling, e.g., soft drinks The incentivizer118may be working for the manufacturer of the soft drink.

1104is an optional message flow. Here, the entity registers its presence identifier106(e.g., a loyalty card for use in the retail domain) with the operator110of the retail domain. By registering, the entity indicates his willingness to participate in the services offered by the incentivizer118. (In some embodiments, the entity's willingness to participate can be indicated by his redemption of a coupon in message flow1116.) In some embodiments, this information is then sent by the operator110to the broker112.

The broker112prepares a software package that implements the coupon-derivation rules as specified by the incentivizer118. In message flow1106, the broker112delivers this coupon-derivation package to the operator108of the first domain (the media-providing domain). The package is distributed in this way because the operator108can access the entities in the first domain, while the broker112may not have any such direct access. In some embodiments, the coupon-derivation function is actually implemented by software (e.g., a cookie or applet) distributed by the operator108to the entities in its domain.

In message flow1108, the entity registers with the coupon-derivation function and receives a pseudonym that uniquely identifies it. The entity also registers the loyalty card it uses in the retail domain. Note that the message flow1108may not, in some embodiments, carry the loyalty-card information. (That information may go only to the coupon-derivation function which might run on a device owned by the entity rather than a device run by the operator108.) Note that in the example ofFIG. 11, the broker112does not know the entity's pseudonym, because that pseudonym is created by the entity and the coupon-derivation function (distributed by the operator108) working together. Note that in some embodiments, the message flow1108goes directly to the binder114without the broker112seeing this information.

As mentioned above, the operator108collects, in message flow1110, observations about the behavior of the entity in the first domain. These observations can include what shows the entity watches, what calls he makes (if the media-providing domain supports telephony), and what advertisements he watches. The advertisements for products promoted by the incentivizer118are of particular interest. These behavioral observations are associated with the pseudonym and with the loyalty card of the entity as registered above in message flow1108.

As this is going on, message flow1112proceeds. Here, the operator110collects observations of the entity's behavior in the retail domain. These observations are associated with the entity's retail loyalty card. Of particular interest are observations of purchases, by the entity, of the products promoted by the incentivizer118. (In a slightly more complicated scenario, observations of purchases of products directly competing with the products promoted by the incentivizer118are also of great interest.) In the particular embodiment ofFIG. 11, message flow1112continues from the operator110in the retail domain to the coupon-derivation function associated with the entity in the media-providing domain. Here, the coupon-derivation function uses the loyalty-card information registered by the entity in message flow1108to obtain the observations of the entity's retail behavior (at least those observations relevant to the products promoted by the incentivizer118).

Now knowing something about the entity's retail habits, the coupon-derivation function, in message flow1114, creates and sends a coupon to the entity, probably in association with an advertisement presented to the entity in the media-providing domain. The coupon is made specifically to appeal to the entity's interests as revealed by the behavioral observations made in the retail domain. As one example, the entity may be seen to be a loyal consumer of the products promoted by the incentivizer118, and the coupon can reward that loyalty. As another example, the entity may be seen to prefer products that directly compete with the products promoted by the incentivizer118, and the coupon is made to entice the entity away from the competitor. The coupon is electronically generated and includes, probably encrypted with a public encryption key of the broker112, the pseudonym of the entity (generated in message flow1108). This information is used to track the coupon (and possibly to limit its use to this particular entity and to allow its redemption only in association with the entity's retail loyalty card).

In message flow1116, the entity presents the coupon when he purchases the product in the retail domain. Electronic coupons are well known in the art: The redemption can involve printing the coupon (with a unique identifier) or presenting the coupon electronically.

As part of its regular business (and in response to the contracting in message flow1102), the operator110of the retail domain sends, in message flow1118, behavioral observations to the broker112. The observations include purchases, products scanned but not purchased, and, in particular, coupon redemptions. For security reasons, the coupon-redemption information as sent by the operator110may include information that the operator110does not know how to decode, such as the pseudonym.

In message flow1120, the broker112analyzes the information received in message flow1118and sends transaction statistics to the incentivizer118. Note that these statistics maintain the confidentiality of the entity, while revealing important marketing information to the incentivizer118. That is, the incentivizer118knows that an entity watched an advertisement for a product, received a coupon for that product, and then redeemed the coupon by purchasing the product. When the incentivizer118collects numerous examples of this type of transaction, it can draw conclusions about the effectiveness of the advertisement (or at least of the coupon).

In message flow1122, the incentivizer118rewards at least one operator108,110. (As mentioned above, the incentivizer118may reward all of the operators108,110that participated in the transaction.) The reward can be monetary or can include better intelligence as to how entities are behaving in the operator's domain.

FIG. 12presents a scenario slightly different from that ofFIG. 11. The first few message flows are similar. The incentivizer118registers its coupon-derivation rules with the broker112in message flow1200. The broker112contracts with the retail operator110in message flow1202. Then in message flow1204, the entity optionally registers its interest in the programs offered by the incentivizer118. The broker112delivers the coupon-derivation software to the operator108of the media-providing domain in message flow1206, and the entity registers with the coupon-derivation function in message flow1208, the entity receiving a unique pseudonym.

The scenario ofFIG. 12diverges from that ofFIG. 11in message flow1210. Here, the coupon-derivation function registers the entity's pseudonym and a routable identifier with the broker112.

Message flow1212ofFIG. 12is similar to message flow1110ofFIG. 11: The operator108observes the entity's behavior in the media-providing domain. Meanwhile, in the right portion of message flow1214, the operator110observes the entity's behavior in the retail domain. (The left portion of message flow1214, from the operator110to the operator108, is considered below.)

In message flow1216, a coupon is created in association with the entity's presence identifier104in the media-providing domain. The first time this happens for a given entity the coupon does not include the entity's loyalty card number because the coupon-derivation function does not know it. The coupon does, however, include the pseudonym assigned to the entity in message flow1208.

The entity redeems the coupon in the retail domain in message flow1218. Because the entity uses his retail loyalty card for this purchase, when the retail operator110sends the transaction statistics to the broker112in message flow1220, this information includes both the pseudonym (from the coupon itself) and the loyalty card number.

With that information, the binder114binds together the pseudonym with the retail loyalty card as belonging to the same entity. The broker112matches this to the routable identifier (received in message flow1210) and sends this binding information to the coupon-derivation function in message flow1222.

This binding information is used to streamline all future interactions between the entity and the coupon-derivation function. Returning to the left portion of message flow1214, the coupon-derivation function can now use the loyalty card information to receive observations of the entity's retail behavior from the retail operator110.

The scenario ofFIG. 12ends like that ofFIG. 11: The broker112sends transaction statistics to the incentivizer118in message flow1224, and the incentivizer118in turn rewards at least one of the operators108,110in message flow1226.

Note that as a result of running through the scenario ofFIG. 12, the binder114has been able to bind identifiers of the entity across the domains. Note also that the confidentiality of the entity is strongly preserved, as the broker112only knows the entity in the media-providing domain in terms of the routable identifier and pseudonym and not in terms of the entity's actual identifier104.

The opening of the scenario ofFIG. 13is similar to that of the previous two figures: The incentivizer118registers with the broker112(message flow1300); the broker112contracts with an operator110in the retail domain (message flow1302); and the entity registers his loyalty card to show interest in the offerings of the incentivizer118(message flow1304).

In message flow1306, observations of the entity's behavior in the media-providing domain are collected by the operator108and sent along to the broker112. The incentivizer118sends its coupon rules to the broker112in message flow1308.

In the scenario ofFIG. 13, it is the broker112itself that generates and sends the coupons, in message flow1310, through the operator108. The coupon is keyed to an identifier104of the entity in the media-providing domain. (This keying information may be encoded within the electronic coupon itself or may only be stored within the broker112.)

In message flow1312, the entity redeems the coupon in the retail domain. Information on this and other transactions is sent to the broker112in message flow1314. Now the binder114has enough information to bind together the presence identifiers of the entity: The coupon contains (or is keyed to) the presence identifier104in the media-providing domain, and the coupon redemption is associated with the loyalty card number106in the retail domain. Thus, the scenario ofFIG. 13is an example of using a stimulus/response transaction across domains to perform the binding.

This scenario ends as did the previous two: The broker112sends transaction statistics to the incentivizer118in message flow1316, and the incentivizer118rewards at least one operator108,110in message flow1318.

The scenario ofFIG. 14differs significantly from the scenarios of the previous three figures in that the broker112is now combined both with the binder114and with the incentivizer118.

The scenario ofFIG. 14involves a “social connector” as described earlier. At the beginning of the scenario, as in the previous scenarios, the broker112contracts with the operator110of the retail domain in message flow1400. The entity registers its interest in the programs of the incentivizer118in message flow1402.

The behavior of the entity in the first domain is observed by an operator108in that domain, and the observations are sent to the broker112in message flow1404. In this scenario, the first domain can be a communications domain, and the behavioral observations can include call logs and the like. From this (and possibly other) information, the broker112determines that the entity is a social connector and that the entity is planning an event (or, at least, that a social event will occur soon, such as a birthday of a member of the entity's social group).

The broker112uses this information to decide what types of retailers (or other providers) would be interested in knowing about the upcoming event. The broker112may run an auction of this information or may otherwise choose target retailers in message flow1406. In some situations, the broker112can evaluate the “connectedness” of the social connector and estimate the monetary value of the event and set the initial bidding price appropriately.

In message flow1408, those target retailers that agree to participate send to the broker112their rules for coupon and advertisement distribution. The broker112implements these rules via the operator108in message flow1410. (Because the social connector is, by definition, able to influence others in his social group, the coupons should be made transferable. In such cases, an electronic chain-of-custody for the coupon can be very useful. When the coupon is finally redeemed, the chain can provide valuable information about the social group. Also, if the coupon is passed on to and redeemed by another person in the social group, future coupons can be sent to that person as well as to the social connector.)

The entity redeems the coupons (or otherwise responds appropriately to the retailers' incentives) in the retail domain in message flow1412. Message flow1414carries the coupon-redemption information to the broker112. If it has not done so already, the binder114uses this redemption information, along with the information already at hand in the broker112, to bind together the presence identifiers104,106of the entity across the domains.

The broker112responds by sending transaction statistics to the participating retailers in message flow1416, and provides rewards to the participants in message flow1418.

The scenario ofFIG. 15also concerns a social connector, but here the incentivizer118is separate from the broker112. Various incentivizers118register with the broker112for services in message flow1500. In consequence, the broker112contracts with retail operators110in message flow1502.

The entity can register interest in the offerings of the incentivizers118via the message flow1504, and information about this registration is sent to the broker112.

In message flow1506, behavioral observations are made and sent to the broker112. As in the scenario ofFIG. 14, the broker112uses this (and possibly other) information to determine that the entity is a social connector and that an event is coming up.

The broker112auctions this event information, but, because the incentivizers118are distinct from the broker112, this auctioning occurs among the broker112and the various incentivizers118(message flow1508). The winning incentivizers118send their coupon-derivation rules to the broker112in message flow1510, and the broker112implements these rules to generate and distribute coupons in message flow1512.

As before, the entity redeems the coupon in the retail domain (message flow1514), and information on retail transactions, including the redemption, are sent to the broker in message flow1516. The binder114can use this information to bind together the presence identifiers104,106of the entity if it has not already done so. From the retail information, the broker112produces relevant transaction statistics and sends them to the participating incentivizers118in message flow1518. The incentivizers118reward the participating operators108,110as before in message flow1520.

Aspects of the present invention, as described above, can be readily adapted to other scenarios. For a first example, an electronic shopping list can be presented to various incentivizers118(representing manufacturers) and operators110(representing retailers) in an auction. The results of the auction can be used to procure the items on the list as well as to provide information useful for optimizing the supply-chains of the participating manufacturers and retailers. In a second example, an entity's browsing for a product (that is, electronic “window shopping”) can be observed and reported to a relevant incentivizer118. The incentivizer118can then send a targeted advertisement for the product to the entity. These two examples are combined when the product-browsing behavior of numerous entities is observed, and, based on those observations, a statistical analysis is produced. The analysis can be sold as market information to manufacturers and retailers.

When the information domains100,102are public-safety domains, the broker112may be able to analyze observed behavior and conclude that one person is acting (or has acted) in the two domains100,102. Correlating this information can be very valuable to public-safety officials in each domain100,102, especially when each domain100,102has not yet produced enough information by itself to guide a response. In this scenario, the observed behavior can include criminal incidents, facial recognition from security cameras (and other biometric information), as well as call records (which can place a person in a particular place at a particular time).

In another scenario, an entity wishes to provide information but wishes to withhold any information that could identify him. For example, the person may be a source for an interesting news story, or may have inside information on a nefarious activity. However, the recipient of the information does not want to act on the tip unless there is some way to authenticate either the tip itself or its source. The source can send his tip to a trusted broker112, and the broker112can correlate this tip with previous tips sent by the same source. (The broker112need not know the actual identity of the source but can establish some reliable log-in so that the broker112recognizes this source and can correlate the present tip with the source's previous tips.) Then the broker112provides the tip to the relevant recipient (newspaper, police) with an estimate of the trustworthiness of the source, all the while maintaining the secrecy of the source's identity. The broker112may also package related tips from more than one source and present the package to the recipient, thus shielding the identities of the sources even more. This is an example of the broker112making use of the enormous amount of information it receives to provide a valuable service.

In a scenario similar to that of the tipster described just above, the broker112can provide past employment information to a potential employer. As a trusted intermediary, the broker112can provide honest assessment of the entity's past employment while anonymizing the information. In one case, the potential employer tells the broker112the employer's specific hiring needs, and the broker112reviews its information to present suitable candidates that do not have bad assessments. The incentive for a previous employer to provide this information to the broker112is similar to the case of the businesses sharing individual business records as given above: By sending in information, the participants make the employment database of the broker112more complete and accurate which can help the participant in the future when that participant needs to hire someone.

In some situations, the incentivizer118may need to incent the entity itself rather than incent an operator108in an information domain100. For example, for a web-based domain100, behavior observations (e.g., web sites visited) can be made on a PC operated by the entity. Then, the techniques described above can be used, with the incentivizer118sending a reward to the entity for allowing observational software to be downloaded to the entity's PC. This observational software can add to the observations made by the cookies typically downloaded by individual web sites.

In view of the many possible embodiments to which the principles of the present invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. For example, aspects of the present invention may be used across other information domains and other operators in those domains. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.